News Stay informed about the latest enterprise technology news and product updates.

Ignore customer stress at your peril

What dooms a project? Users stressed out by change and by time spent away from their day jobs.

During the past six months, two CIOs asked me to analyze why five project deployments spanning sales, fulfillment and customer service had failed. The budget for each project ranged from $500,000 to $1 million, and development time from seven to 11 months. Interviews with project managers revealed that despite numerous project management governance problems, four out of the five projects progressed fairly well to the end of their build phases. But as these projects moved into customer testing, training and implementation cycles, problems emerged. Eventually, three projects were canceled before implementation, and two were canceled three months into the operations stage. In-depth assessment of the development history of these projects showed that high customer stress was the primary source of failure. The following five factors determined customer stress levels:

Customer time spent away from primary responsibility. The projects required a high proportion -- frequently 40% -- of customers' time for requirements definition, design reviews and implementation training. No action had been taken to reduce customers' day-to-day responsibilities, despite the fact that compensation was based on job performance. As a result, most customers didn't devote the necessary time to new projects. On a scale of 1 to 5, with 5 being the highest, customer stress -- based on time away from primary responsibility -- scored a 4.0.

Degree of change. All five projects involved a high degree of change in technology, workflow processes and level of customer accountability. Project managers had overlooked the effort customers needed to expend to learn the new technology, especially the new navigation protocols. The prevailing attitude among the sponsors (all of whom were members of IT) was that customers would simply have to adjust to the new processes. But customers failed to, and consequently customer stress scored between 3.5 and 4.5.

Willingness to accept change. My experience shows that customers' willingness to adopt new processes is directly proportional to the goodwill that project teams build with them. Here consistent and sustained effort from project sponsors and champion stakeholders is a must. In all five projects, management was only minimally involved, and champion stakeholders supported the project poorly. Customer stress scored between 3.0 and 4.0.

Ability to accept change. This is directly related to the quality of customer training and support. In three projects, training was hit-and-miss because multiple schedule slippages resulted in last-minute postponement of training sessions. In addition, most of the training documentation was posted online, and customers found the training materials difficult to use. During the first few weeks of project deployment, many customers ran the old system for their routine business, resulting in extensive after-hours work. Customer stress scored between 3.0 and 4.5.

Timing of change. The fulfillment and customer support projects were deployed at the height of the annual sales cycle, creating extensive overtime. The primary reason for poor timing was slipped schedules on three of the projects. Management's decision not to provide work relief to customers further complicated these problems. Customer stress scored between 4.0 and 4.5.

The aggregate customer stress rating for the five projects fell between 17.5 and 21.5, toward the high end of the stress scale. No wonder the five projects imploded.

CIOs must ensure that project managers assess the customer stress factor as a part of the project planning process and then diligently monitor and report this vital sign to project sponsors. My experience with scores of similar failed projects shows that most project management methodologies ignore this critical assessment.

Gopal K. Kapur is president of the Center for Project Management in San Ramon, Calif., and author of "Project Management for Information, Technology, Business and Certification. Write to him at Note: This column originally appeared in the January 2006 issue of CIO Decisions magazine.

Dig Deeper on IT project management and portfolio management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.