jim@millikenproject.com

jim@millikenproject.com 207-808-8878 Our book "Life is a Project: How are you managing?" is now available!


Tuesday, March 2, 2010

How to Rescue Yourself


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.
Now Sergei shifts into diplomacy mode: How does he carry out a conflict management phase, followed by a persuasion negotiation? By doing his homework and tuning up his political skills.

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.




           



3 comments:

  1. 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.

    ReplyDelete
  2. Thanks Jim,
    Stopping 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!

    ReplyDelete
  3. A follow up on why 80% of IT projects don't meet goals would be an interesting read.

    When 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.

    ReplyDelete