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