Why Projects Fail: Part 7, Poor Project Planning

Some years ago we taught a group of business staff whom had never planned a project before in their lives how to reverse plan — i.e. start with the end and work backwards to the present. "What do I need to do to deliver this outcome/output?", and then "What do I need to do to deliver this input?", and so on.

Once they'd got the hang of the questions to ask, they busily created a set of very reasonable project plans. Except for one group. They were from a systems vendor and resolutely refused to plan in reverse as forward planning was all they knew and trusted. But, eventually, around 3pm in the afternoon, they were cajoled into trying it. By 3.30pm, they were believers and went back to their organization to change their planning approach to reverse planning.

Forward planning tends to result in an accumulation of tasks near the end of the project (especially if the project has a deadline to meet). Reverse planning avoids this. It also better highlights the tasks to get going on early, as they will impact downstream activities and the critical path.

Importantly, the starting point and focus for reverse planning is the delivery of the project's desired business outcomes and associated benefits. This is what the project is being commissioned to deliver and so should be the focus of the delivery planning. Even if the project team is not going to deliver all of the activities and tasks required to realize the outcomes and benefits, at least they're now known and planned.

Project plans with large lists of tasks in the last weeks of the project set the project up to fail. Reverse planning avoids this and spreads the workload more evenly across the duration of the project.

(Another problem with project planning is getting into too much detail to soon. If in month two you have a 3670-item project plan you'll be lost in the detail before you start. Map out the overall activities (top 100-200) and then take them down to detailed action tasks as you get to them.)

The second reason why planning can fail is losing sight of the critical dimensions. This is much more than just having a "vision" or even a list of carefully defined "desired business outcomes" as you also need design parameters and other guides to ensure what you plan to deliver meets the organization's (often unspoken) expectations.

For example, a project was automating some processes and so had to train (a reduced number of) staff in how to use the new system. The project team's measure of success was that the staff were adequately trained so as to operate the new system effectively. The organization's measures of success included, that the new jobs were worthwhile, there was a career path for the staff, they were not put under undue pressure during the changeover or subsequently. Quite a different set of measures!

However, the organization's measures of success were valid design parameters for the project team to take into account in their planning. It isn't enough to just train staff, you need to also think through the ramifications on their jobs, work pressures, careers, recruiting options, etc. This is not so much extra work but how the work is performed and thought about.

When planning a project these additional dimensions make all the difference between a project that is seen to be successful and one that is seen to fail.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email CIO
• Follow CIO on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark