Sergei is deep in it. Over deadline. Over budget.
Overworked. This is a troubled
project.
Sergei is the project manager. His project, implementing a
new order entry system for a printing company, is not going well. He was asked
to take over the project because it’s a key part of the company’s strategy, but
had fallen seriously behind.
There was no time to lose, so Sergei hit the ground running.
As far as he was concerned, the time for rational planning was long past.
The team includes members from sales, accounting, inventory
management, IT and the general manager’s office, all of them overloaded with
work. There are eight people, including Sergei, who is an assistant foreman in
the warehouse.
Unfortunately, no one seems to share Sergei’s sense of
urgency – or maybe they’ve just given up. There rarely are more than four
people at the regular weekly project meetings, and often even those people
haven’t completed – or even started – their assignments on the order entry
project. The vendor supplying the software doesn’t seem able to meet some of
the terms of the contract, and the company reps don’t always show up when
they’re supposed to.
Sergei’s boss in the warehouse knows nothing about the
project, and has made it clear he doesn’t want to get involved. The vice
president for facilities contracted with the software company and set a
deadline for implementing the new system. He has arranged for removal of the
existing system at the same time.
Sergei has sent messages to the vice president’s office
asking for postponement of the deadline, but the word he gets back is that the
company is committed to the schedule, and there’s no turning back. Sergei and
the vice president have never actually discussed the project.
What causes project problems?
I’m asking project managers all the time: What are the most serious/frequent causes of project failure? What are the most important/dependable practices of project success? My collection of respondents now is in the countless hundreds, and . . .
Ninety percent of the project managers 90 percent of the
time tell me: Poor planning and ineffective management lurk in the wreckage of
every ruined project. Sound planning and good management drive every successful
project.
Today’s blog outlined the sad tale of a project manager
mired in a failure-in-progress. I asked that you answer two questions:
How does Sergei rescue this project?
What does this experience tell Sergei about his next
project?
One customary response of a project manager in Sergei’s spot
is to take on the “champion” role, driving self and team members through night and
weekend work in a heroic flameout. An alternate is the “grim soldier” approach,
is to put one’s head down and march obediently over the cliff.
Sergei is by no means alone in this situation. Every study I’ve seen shows a majority failure rate for projects in all fields. PM Network, a publication of the Project Management Institute, provided these numbers:
17% Canceled
33% Issues with Budget, Schedule and Functionality
28% Successful, but not meeting Return on Investment Standards
22% Successful, and Meeting ROI Goals
I believe a successful project comes in with variances of no
more than 10 percent either way on schedule, budget and completion criteria.
And that’s without fudging by moving the goal posts as the project slides
sidewise.
OK, so what does
Sergei do now?
First, he must address the root problem here, which is a
failure of senior management (the VP/facilities) to put his authority behind
development of a rational base for the project. This fundamental failure was
compounded by whoever was the project manager at the time, accepting the
situation and proceeding to drive the project into the ditch. Sergei himself picked
up the downward spiral from his predecessor.
How does Sergei reverse all this?
For starters, he must attempt to reconstitute a realistic
basis for the project. Instead of asking for a postponement of the deadline, he
must declare a halt to the project, and inform the vice president. His message:
He has acted to stop a serious waste of resources and must have an immediate
conference with the VP. That should get some attention.
This may seem insubordinate enough to end this phase of
Sergei’s career, but what other choice does he have? He never should have
agreed to attempt the impossible in the first place – that didn’t make it possible,
it simply volunteered him to take the fall.
If the vice president truly wants the project to succeed, he
will agree to meet – however angry he might be.
And he must thoughtfully examine this experience as soon as
it’s over, zeroing in on what precisely started this ball rolling out of
control down the hill, what accelerated that destructive process, and what
specifically will prevent it from starting at all in his next project.
Jim, I've seen this before- more than once. A memorable situation was when sales pushed a major change that systems and operations could not implement on deadline. It was a project that grew in scope, championed by the senior sales leader. The development team worked smoothly and created a wonderful new product. Putting it in place was a nightmare. The department ended up issuing mandatory every night and every weekend overtime,for months, for the progammers, who still could not program quickly enough. Operations staff had to process the changes manually, for months, because customer orders were flying in. The manual process was cumbersome and time consuming, so the operations people ended up with the same mandatory overtime. The kicker came when the department senior leaders, finally noticing that people were exhausted, resentful and angry, issued to every person involved a nice picture frame with a gift certificate to get a photo portrait done. The accompanying note acknowledged that families were likely missing their loved one, so get a photo taken and give it to your family. They could look at it and feel you were there with them. Had the project been handled as you suggest in your blog follow-up, the company could have saved much pain and money, and the good will of its employees.
ReplyDeleteThanks Jim,
ReplyDeleteStopping a project doesn't normally make the short list of options - we're so intent on making something happen, that letting it die would be admiting personal failure... but, as you point out - it might be the only way to save the project in the long run.
Great post!
A follow up on why 80% of IT projects don't meet goals would be an interesting read.
ReplyDeleteWhen a project goes off track, there are two potential solutions. Put your head down, press on in chaos with success only through herculean effort (maybe) or, stop the project and replan. Without the commitment of the project sponsor and key stakeholders, the project is doomed anyway. The only thing left is the 'hunt for the guilty'.
This scenario is more common than though and is overlooked in the bright beginnings of a project. This should be at the top of the risk management planning.
Keep up the good work.