Too frequently, IT systems are designed at headquarters, by headquarters and for headquarters. When the perspective is that narrow, the systems that result probably won't fit the needs of most of the organization.
Headquarters staffers often belittle the importance of functions located elsewhere, and they just as often have things backwards. Sure, headquarters usually provides critical direction and structure, but without the field, very few businesses could deliver products and services to customers. That's true of retailers, oil refiners, manufacturers, and even companies like Google and nonprofits.
There's a lack of respect behind such behavior, an egocentricity that can lessen the effectiveness of new systems. How many project teams complete the majority of project designs at headquarters and visit the field merely to give the appearance of soliciting input (or worse yet, only for the rollout)? One project manager recently admitted to me that his team was soliciting input from a particular field location only for political reasons. This is not uncommon, but it's a huge mistake that contributes to distrust between the field and headquarters.
A collaborative approach that involves the field in creating solutions to business challenges engages people and builds support for system rollouts. Include the field from the project's earliest phases, and integrate key opinion leaders from the field into the project team. Yes, this approach requires more time and resources, but it can help you avoid problems later on. Post-release disasters are far more costly than up-front planning. Even if the headquarters staff somehow manages to design a fine system in isolation, those in the field will be more resistant if their input was never sought. Few people readily embrace systems that are imposed on them, and pushback impacts rollout. Field support is invaluable.
Superficial outreach isn't enough. It can take extensive field involvement to identify local challenges. Few local conditions can be discovered during brief interviews, phone calls or Skype sessions. And headquarters-based interviewers rarely know enough about field operations to ask the right questions. For example, when a global organization recently decided to replace all field accounting systems with an ERP system, headquarters staff designed accounts payables to run monthly. But the folks at headquarters narrowly avoided running afoul of a Brazilian regulation that treats contractors who are paid monthly as employees (with benefits). In another case, a U.S. restaurant chain decided to implement a new management system using consumer PCs. Shortly before rollout, the project team finally spent time in a store and realized that it would take ruggedized PCs to survive the heat, grease and liquids that are unavoidable in a commercial kitchen.
Conversely, field staffers may be unaware of current industry products and trends and therefore aren't able to optimally define desired capabilities. The communication goes both ways.
Successful enterprise systems depend on widespread field acceptance. Products and services are delivered in the field, not at headquarters. As Colin Powell stated in It Worked for Me, "You've got to get out of your paneled rooms. Go downstairs and see what the hell is going on in the basement." Better yet, go out into the field and watch everyday business transactions. And do so before you design a system for field use. Treat the field well; it pays the bills. And its effectiveness can be the difference between profit and loss.
Bart Perkins is managing partner at Louisville, Ky.-based Leverage Partners, which helps organizations invest well in IT. Contact him at BartPerkins@LeveragePartners.com.
Read more about management in Computerworld's Management Topic Center.