IT Project Guiding Principles

Over the last 25 years I have been involved in many projects as everything from a junior analyst, to project manager, program manager and in recent years overseeing them as a senior leader.

This article is a follow-on to a previous article on Success with IT Projects and tries to build on those thoughts with some guiding principles (no apologies for repeating a couple of really important things from the previous article!!). Some of the principles are more applicable to larger projects, but in a reduced form also apply to smaller undertakings.

Feel free to comment on this article and provide your own thoughts on principles I might have missed.

.

1. Business Projects NOT IT projects
   • IT should not be the driving force behind the project
   • Unless the Business wants the project, why are you doing it? (see my article Implementing Technology for the right reasons)
   • Be clear on the business value, this helps to align everyone behind the project
2. Executive Sponsorship
   • A senior executive must champion and be the cheer leader for the project
   • Without that change management becomes very difficult
   • See my article on the importance of Change Leadership
3. Business Lead
   • The IT project manager (PM) should not lead the project, you need a good business leader
   • The Business Lead will often need to be full time (essential for Large projects)
   • They need to work hand-in-hand with the PM
   • Note the difference between the Business Lead and the Sponsor – the Business Lead is heavily involved in the project day by day, the Sponsor is at a higher level and provides assistance only as needed
   • The Business Lead with typically be a manager from the business area most impacted by the project, so they will know the processes and the people involved
4. Build a strong team -> Get the Right people assigned (full time for large projects)
   • This is tough, as you need the A players
   • Without them you are going to struggle
   • This is where the Executive Sponsorship and a strong Business Lead are essential
   • BUT (for larger projects) the people you pick for your team must be backfilled (they cannot continue in their existing roles). Otherwise you will be in a constant struggle for their attention and time
5. Alignment
   • All of the executive team, management team etc must remain aligned and heading in the same direction – without this you get constant challenges and disruptions
   • If necessary, be prepared to stop the project until alignment can be achieved
6. Organisational Change Management
   • Biggest cause of project failure is lack of proper Organisational Change Management
   • Must have a formal, structured approach (it’s NOT just a communication plan & a training plan)
   • Often starts years before the project and goes on throughout (for large initiatives)
   • See my various articles on Change Management for a more in-depth discussion on the importance and keys to Change Management success
7. Structured Project Methodology
   • A structured project approach is essential, be it waterfall, agile or …
   • Help everyone to understand the methodology and stick to it
   • Scale the methodology correctly to the project
   • Use Stage Gates properly – do not pass thru a gate until you are ready – if necessary STOP or pause
   • Avoid short-cuts
8. Process First then Technology?
   • Traditional approach is to sort out the process first, then look to technology for solutions
   • However, more common these days is what Gartner refer to as ‘Package based development’ – or put another way, define your to-be processes around how your chosen tool is designed to work
   • That way you take advantage of the best practices the tool already embraces and you avoid unnecessary customisations
   • It also stops you falling into the trap where you are unable to find a tool to implement the utopian to-be process that you have defined
9. Get clarity up front
   • The cost to rectify or add to the scope goes up x10 for each project stage you go past (e.g. in analysis x 1, in design x 10, in Build x 100, in Build x 1000, in Launch x 10000 etc)
   • So make sure your requirements as clear as early as possible in the process
   • Iterative approaches with the end customer, like Agile, are useful in this regard

What is missing from the above?
Do you have any additions to the list?

Related articles:

IT Project Success – A CIOs View

Change Management (Part 1) – Cracking the Code of Change
Change Management (Part 2) – Step Models of Change
Change Management (Part 3a) – Change Capability
Change Management (Part 3b) – Success with IT Change
Change Management – What’s in a Name?
Why are IT projects Change Management time bombs?
The Importance of Change Leadership – Beyond “Step Models of Change”

IT project failure: symptoms and reasons by Pearl Zhu
Five “Super-Pitfalls” Why Large IT Projects Fail by Pearl Zhu
Four questions CIOs should ask before taking on a new initiative by Joel Dobbs
Project Leadership: Key Elements and Critical Success Factors by Richard D. Lang