Railroaded
by jed simms on April 22, 2008
Projects can be likened to trains. If you want to be going northeast but set off on rails leading northwest, you can’t easily just turn right and correct your course. You often have to go back to the start and realign your project.
(This explains why a problem project is always a problem project regardless of how many ‘rescue’ attempts are made.)
When I do health checks and find projects in trouble the root causes can often be tracked back to the early stages of the project. How it was set up, how it was categorized (eg as an “IT project”) and how it was pursued.
Mistakes made at this early initiation, set up, commencement stage will come to haunt a project in later times. And, there is often no remedy later other than (almost) starting again.
In our video “Understanding how projects are condemned to completion” (Understanding how projects are condemned to completion” will be available on valuedeliverymanagement.com by May 10th, 2008) we take you through a real 30 month project so you can see how it started off on the wrong foot and then made one decision after another that progressively destroyed more and more value with the full involvement and support of the project leadership and governance teams. Had different decisions been made at the start of this project, a very different result would have been delivered.
Project set up and initiation is a critical part of value delivery management. Yet it is too often seen as just organizing the resources, building a business case and generally getting the project up and running.
But, at this time, fundamental assumptions and decisions are being made that will colour the whole project. You are, in effect, deciding the ‘rails’ your project will run on. And, while in the very early days you can move across from one set of rails to another, once the project gets momentum your options as to how the project goes, where and what it can deliver are increasingly limited.
The greatest danger at project set up is the desire for visible action — producing a plan, a business case, a technical specification, or whatever. (Project managers can be great deliverers, ever keen to deliver something. In a recent discussion to identify what exactly a division wanted to achieve with a new initiative, 10 minutes into the discussion the project manager was listing ‘deliverables’ and ‘actions’ long before we’d decided where we were trying to go!)
Those in charge of project set up should think of a building project. If you buy a block of land and then start designing your house, you’ll come back to that block of land in three months and nothing will have happened on the site. Meanwhile, the house is designed, costed and submitted for council approval; the materials and building staff have been organized and any unexpected problems with the job have been discovered and dealt with. Now, you’re ready to go. Now, you’ve defined clearly what ‘set of rails’ you want to be on.
So, before you rush into your project, take the time to define your business requirements, design your solution and identify all of the possible options, approaches and risks. Then select which ‘set of rails’ will deliver you the best results. (The Governance Guide “How to govern your project’s set up” will be available from www.valuedeliverymanagement.com by May 2nd.)
Don’t be railroaded down the wrong tracks from the start.
Post your comments on our blog at valuedeliverymanagement.com
4 comments
If value delivery momentum could be maintained from the beginning to the end of the project with the stakeholder engagement and participation at a high, projects would be delivered on the right tracks each time. It is so often the case that a lack of planning of the whole picture in the beginning results in so many challenges when you reach the end.
by Roslyn on April 22, 2008 at 3:14 pm. #
Ah, stakeholder engagement!!
Business execs often fail to commit and engage as they don’t know what to do and don’t understand the importance. And IT scares them
To address this I’ve created several tools such as
“Why IT is different” – addressing their fears and misunderstandings about IT projects
“Understanding business project leadership” – that explains why business involvement is so critical (something many execs don’t appreciate)
the key to engagement is, in the short term, education and that’s what Value Delivery Management and project-sponsor.com is all about. You can look for thse tools on project-sponsor.com – if they’re not there today, they’ll be there shortly
by Jed Simms on April 23, 2008 at 1:48 pm. #
When you say “take the time to define your business requirements”, aren’t you describing a common pitfall? The pitfall that the business already has requirements by the time they consider bringing about change with a Project? They may need to be understood, brought to the surface of conscious thought, and prioritized. But do requirements need to be defined? I could think of one scenario: to match an intuitive solution.
by Chris on March 10, 2010 at 11:52 pm. #
There are two types of ‘requirements’
The first is ‘Where do we need to end up?” – which we define as ‘desired business outcomes’ – measurable end states. These give you your end point, your destination and measures of success
The second type of requirement is “How is it going to work?” This is the process view – how the processes should work.
Mgt may have a view of what they want to achieve but this rarely if ever in either outcomes or process form – hence the need to translate their unspecific ideas into specific outcomes and process steps. This takes time to get right; but unless it is done well you’re off and running in the wrong direction.
When, on Health Checks, we define the desired business outcomes for a project it is often a revelation to the business. The process business requirements are usually missing having been replaced with ”functions and features” instead, which are no substitute
JED
by Jed Simms on March 15, 2010 at 8:18 am. #