Bogus budgets, missing sponsors, communication breakdowns, scope creep: these are just a few of the 'gotchas' that can cripple or hamper a project, and all project managers have a tale about one that brought them to their knees. Four managers tell their stories . . . anonymously. Kathleen Melymuka reportsBut every crisis is an opportunity for growth, and project managers say the hardest lessons are the best learnt. Here are lessons well learnt in the crucible of project management that four managers are willing to describe anonymously.
Disengage at your peril
The project: A large information technology services company contracted with a government agency to handle a complex logistics project.
About 60 people were involved.
What went wrong: during the proposal process, the service company's project staff carefully determined a bid that would get the job done on time and at a profit. The bid was about 14 per cent over the government's guidelines, but they told their salespeople to present it anyway.
Unbeknownst to the project manager, the salespeople trimmed the budget for project management staff and presented the new, lower bid.
Hitting bottom: "The best day was also the worst day," the project manager recalls. "We won the bid, and we were ecstatic that we had gotten this big piece of business. Later on, when all of the hoopla had calmed down, I read what we had, in fact, submitted. I realised that I couldn't get there from here. The goals were unachievable with the staff we had contracted to apply. That was the worst day."
Follow-up: "We had to make a decision," he recalls. "Are we going to soak this up and work this at no profit or perhaps a loss and achieve what we set out to achieve and still be held in high regard by the customer? Or are we going to try to fudge this thing?"
The services company decided to augment the staff at its own expense and eliminate its profit. Luckily, the client later added requirements that allowed the project manager to make a case for staffing up to the original level, and the client agreed to underwrite the cost, providing a little profit after all.
"In this case, a little scope creep helped us out tremendously," he says.
Lessons learnt: "The project manager has got to be responsible from end to end and anywhere in between," the project manager says. "If the project manager disengages, which I did during that proposal process, there can be a tremendous surprise."
The project: a Fortune 100 consumer products company in the US sought to develop a standard suite of Y2K-compliant back-office business software to bridge international acquisitions in five European countries. Two hundred people were involved.
What went wrong: Despite efforts to be culturally sensitive, there were problems inherent in the Americans' view of Europe. "I always had a vision that Europe is this big melting pot, but there is no such thing as 'Europe'," the project manager says. "There are individual countries, and they have a history of not getting along."
Attempts at standardising a system became an exercise in futility. "Through our whole process of gathering requirements, we were not able to uncover one thing that was shared among the countries," the project manager says.
Language was also a barrier, and the use of terms that meant different things to different people aggravated the problem. A simple word like location could have different connotations in different countries.
The project was sponsored and driven by IT rather than the business, and the business people didn't really "get it," says the project manager.
Moreover, the IT sponsor quit in midstream.
Team members were constantly travelling between Europe and the US, and the strain on them and their families was causing people to burn out.
Hitting bottom: "The worst day was the day we found out that our IT sponsor, who was really the salesperson behind this whole vision, had left the company," the project manager says.
Follow-up: Ultimately, systems were cobbled into place that suited the various countries, the Y2K deadline was met, and the project was deemed a great success. But the broader vision of standardisation was never achieved and the cost in human terms - such as frustration, low morale, burnout, high turnover - was unacceptably high.
Lessons learnt: First, diversity counts. "Just being aware that you've got cultural issues isn't enough. You've got to build that into the management of your teams," the project manager says. "The one thing that will unify the different cultures of Europe is to have an American tell them that this is the way to get things done."
Second, sponsorship must come from the business, and the project manager must speak in business terms, "not time lines and Gantt charts and scope statements", he says. "Business people can help resolve your issues if they understand what they are."
Third, focus on your people. Co-locate teams whenever possible, the project manager says. In any event, "set an example for the team that you have a life outside of work that's important to you and they should have one too".
Failure to communicate means failure
The project: A large retailer acquired a Web start-up so it could establish a Web presence quickly. Twelve people from the two companies would integrate a mainframe back end with Web business systems.
What went wrong: The traditional retail and Web teams were on opposite coasts geographically and culturally. "They were on an old-style mainframe system. They didn't have a lot of experience in Web development," says the Web project manager. "Our group had little experience with mainframe systems."
Effective communication "was the first hurdle that we didn't adequately address", she says. The result was "different expectations on each end as to what we were building together".
During the development of functional requirements, things seemed to go smoothly, and both sides went off to write their code. But in retrospect, the project manager recalls that the Web folks were "very busy, and maybe we didn't take as much ownership of that as we should have".
That became apparent a couple of days before the start of integration testing, when the roof fell in. "The other side delivered a Cobol copybook, and nobody on our side was sure what it was," the project manager recalls. The copybook outlined a mainframe-style file format that was very different from what the Web people thought they had agreed to six weeks earlier.
Hitting bottom: The worst day was the day the Cobol copybook arrived. "It was a big shock to know that close to the point where we were going to start testing, we were almost back at Square 1," the project manager says.
Follow-up: They came to a compromise, with both sides sharing in the considerable rework. It wasn't a tough negotiation, she says, "because we both realised that maybe each side had failed to ask some critical questions six weeks prior."
Lessons learnt: Be very, very careful with communication. "Always ask the question twice," the project manager says. "And make sure you try to understand the group you're dealing with on the other side."
Sloppy requirements come back to haunt youThe project: A simple file conversion in a retail revenue accounting system that would allow data to be automatically extracted from incoming files and fed into other systems such as reporting and decision-support. Five people were to be involved for three months.
What went wrong: The project requirements were all wrong. It immediately became apparent that the reporting systems that were to receive the data extracts used data fields that didn't exist in the incoming revenue files and couldn't even be deduced from them. The team would have to design entire subsystems to extract the data and channel it properly.
But when it came to writing the new requirements, the team was like a Tower of Babel. "It was a technician-to-technician problem caused by too many people trying to do too much at one time and not having time available to communicate and not having the knowledge of what to communicate and not having the skill to communicate it," recalls a then-junior team member who is now a project manager at an IT services company.
Because no one could put a requirements document together properly, requirements changed and the scope grew daily. The "simple" project that should have taken five people three months ended up consuming 30 people for more than a year.
Hitting bottom: The worst day was the day the project was supposedly finished. One piece of the system handled daily revenue accounting for the client, so it had to run on a daily cycle. When the first live production cycle ran, it took more than two weeks to complete, and even then it was full of bugs.
Follow-up: It took another six months to consistently turn a daily cycle in 24 hours - and there were still bugs. Team members spent many nights fixing errors and reworking code, and many burned out. Eventually, the project produced a successful application.
Lessons learnt: "Give yourself enough time to understand and document your requirements so that when it's time to build it, you do get it right the first time," the project manager says.
Consultants' role in IT disasters
By Kim Nash
When a multimillion-dollar information technology project heads south, the finger pointing and litigation begins. And frequently, users blame the disaster on what they view as dirty tricks by high-priced consultants.
Some consulting tactics are familiar to IT veterans; other ploys are less common. They include the following:
* The consultant company implies that high-level, seasoned consultants will do the work but then replaces them with greener staff.
* In a corollary to that bait-and-switch manoeuvre, the company claims expertise in a given area but uses the client's project to train new consultants.
* The company overbills, often by putting extra consultants on-site, overcharging for living expenses or doing work outside the contract scope.
* The company disagrees with definitions of key terms, such as "product" and "test", frequently leading to delays while the parties haggle.
* The company claims that it owns much of the intellectual property produced during the project, leaving the user vulnerable to ongoing maintenance fees.
Of course, most of the trickery can be prevented with sharper negotiating and eagle-eyed management.
"Consultants are used to walking in and being totally in charge and having no one question them," said Ella Conrad, a former IBM consultant and now CIO at Utility.com. "You have to remind them of what their role is," Conrad said. "You have to manage the hell out of them."
Early this year, Conrad threw one consulting company out, in part, she said, because it ignored her own IT people and tried to run up billable hours by putting extra people on the job. "I walked into a meeting and there were 20 of them sitting there whom I'd never met," she recalled.
"Here's your project team," the lead consultant said.
"Whoa," Conrad said. No way. "I'd never seen resumes, and you don't need 20 people overnight to start a project."
Bruce Webster, a director in the Dispute Analysis and Investigations practice at PricewaterhouseCoopers in the US, said there are ways to prevent the classic personnel swap. Look at resumes and interview all prospective workers, he advised. In the contract, name the people who will work on the project and set a maximum turnover rate.
"Screen these people just like full-time employees. Given what you're paying, it's important," Webster said.
The user's role
Users typically approach the consulting deal the wrong way, said Marlene Bauer, who helps companies bargain with consultants.
Consultants typically push for long, open-ended engagements where deliverables aren't specific. After all, those are the big-money deals.
IT managers go along, contracting for resources - a certain number of workers for a particular hourly rate, for example - instead of results, said Bauer, who works at International Computer Negotiations in the US.
She said the contract should include a detailed project plan that lists which software pieces will be delivered when, how they will be delivered and how well they will perform, as well as criteria and schedules for acceptance and consequences if the software fails. Payments should be tied to the completion of each phase.
Consultants "don't want you to do that. They want to throw bodies at it and bill and bill and bill," Bauer said. "But if you haven't defined what it is you want, how do you know when you get it?"
Users aren't angels either
Users aren't always blameless in disputes with outside consultants. Inexperience and arrogance among IT people can certainly mangle a big project.
It's not unusual to find out that the people who told top management bad things about a consultant are trying to hide the facts and blame the problems on someone else.
Sometimes IT doesn't live up to its contractual duties, such as stress-testing new pieces of software by a certain deadline. Slipping behind on testing can make the whole project late. Similarly, if the user company fails to provide promised testing facilities, including clean data, the project can go off kilter.
Perhaps the No. 1 thing a user company can do to damage a project is to change key IT managers in midstream. And that isn't uncommon, given today's jumping IT job market. Such projects will continue on their own momentum, but with original IT managers gone a chasm can grow between developer and client - a situation which often ends in litigation.