It's time to kill big IT contracts

"I've met many programme directors who've said 'I'm doing a £100m programme', I say 'I feel very sorry for you'"

Phil Pavitt - the man in charge of the UK government's largest IT outsourcing deal - believes Whitehall needs to end its love affair with supersized IT contracts.

See the interview on Silicon.com : http://bit.ly/bRj2wU

I have a cunning plan..

Building your project plan is the most critical step in any project. Your plan is the basic way of measuring the progress of the project - and if you can't measure it you can't manage it. If your project is to be successful it must start with a solid plan. Much of comedy of BlackAdders sidekick and servant Baldrick lies in the unachievability of his "cunning plans" and are there lessons to be learned from the succinct communication of his plans?
But how can we access the quality of the project plan before execution - or before it goes pear-shaped? Here are my "top three"

• Completeness. Has everything been included? The best way to validate is through product based planning. You take the deliverable product and simply break it down into its component parts and assemblies (where there is some effort to put the parts together). So when planning a conference one area will be preparation of conference documentation - made up of component handouts for each session with the extra item of assembling the handouts into the conference binder. There should be activities corresponding to each component part and assembly.
• Accuracy. As well as requiring a reliable basis for estimating the effort required for each task the accuracy of the interdependance of tasks and resources is critical. So a simple plan (below) to code and test a simple client-server not only requires the accurate estimation of each task - overrun of any task will cause a delay to the whole project -  but also the accurate scheduling of resources. The resource to perform task 2 needs to be available immediately task 1 completes to meet the schedule. Overruning task 1 will waste the time for the resources committed for task 2 - which may also be the same resources for coding in task 3? If the complexity of the data needed is underestimated that will extend not just the database setup but the middle tier, the user interface and testing. 

• Socialising the plan. Most importantly the plan needs to be checked and committed to by everyone involved in the project. Too often the gantt chart will be produced by the PM - probably in Microsoft Project - and emailed out. However how are responses expected? Is there any narrative? Is there a list of assumptions used? Does everyone has the skills to use MS Project or even the software? So the ownership of the plan - and more importantly the committment to the plan and its accuracy- remains with the PM. Any mistakes remain the PMs problem. "I don't understand how the PM estimated this task so if I take longer then it's the PMs fault."
  To get commitment and belief in the project plan it needs to be "socialised" and fully communicated to get ownership by everyone involved. This communication needs innovative approaches - See Geof Lorys great "Lego My Schedule" and John Estrellas "How to create visual project timelines". But more importantly don't just depend on gantt charts; use narratives, brainstorming, risk workshops, feedback surveys or any way you can to get a true two way dialogue going to build trust and group committment. 

Drive a stake through this cliché

Kill off "Stakeholders". Not my esteemed business partners, suppliers, customers, technology, providers, shareholders, backers, funders, board members: I love you. Really.

It is just the word. "Stakeholders". Worse still the phrase: "Stakeholder Management". It is very convenient shorthand - and I have been guilty using it in CVs and general project communications. So what's wrong?

It's lazy. The shorthand conveniently lumps everyone involved in a project or enterprise into a single bucket. But they are all different. And they need to be treated differently. What is their stake? They are all in it for their own benefit, and they have to be approached and communicated based on their interest.

It's patronizing. You don't "manage" stakeholders. They cannot be herded like sheep or bossed around. You can influence their expectations and get them to deliver their commitments, but you don't manage stakeholders.

It's dangerous. Having "Stakeholder Management" as a simple heading encourages the mentality that this is a single task, which can be done once, or in a single communication, or in a regular meeting. Its continuous. It is different for each counterparty involved. It is multi-media. Its two-way.

Communicating change requires a different approach for each individual.

Communicating to people in an office about an upcoming move can't be done in a single communication. Some will want to find out about the carpet colour or their chair, and will complain like hell about the new office if not involved. Others will want a detailed document about the move, being told each step in the move. Others will just want to be shown the boxes to pack, and the labels to stick on their belongings. Some will only be interested what pubs and cafes there are near the new office, or the route between the two. You have to communicate for every style and every possible concern.

I first came across "stakeholders" in employee communications from a bank I worked for. They communicated the need for change for the benefit of stakeholders: shareholders, management, employees, customers. The expensively produced video showed a bank branch manager who was now happily delivering milk. It just left everyone asking "Why?" and seeing a cynical underlying message. It failed because it tried to communicate change for the greater good, when you have to sell the benefits of the change to the individual.

I recently came across the one time you must use stakeholder; a small private bank to the horse racing community. They look after the prize money until it is paid out to the winner. They are the true stake holder.

So let's kill off "stakeholder management" - unless you are really managing a real stakeholder.

PPM and Agile dont mix.. Right?

Let me give a blatant but well deserved plug to the PM Podcast - An excellent podcast on all aspects of project management. Catch it at http://www.thepmpodcast.com .

The recent one that has caught my ear in particular was PPM and Agile dont mix.. Right? with a really good discussion of how you can combine the top down orderly approach of Programme Management with the bottom up informal (to the point of being anarchic) approach of Agile.

All Cornelius Fichtners prodcasts really earn the valuable space on my 8Gb iPod! There can't be a better way to earn professional development credits while walking my dogs.

Lets Do The Risk Warp Again

In this trilogy of blogs (triblogy?) we have been seeing how some basic intuition and understanding of projects can lead us to manage and master risks. Dont think all these charts and graphs are any great theory - they are just a graphic representation of common sense!

Having understood the "cone of uncertainty" let us see what we can do to reduce uncertainty by warping it - bending the rules of project management.

Lets look at bending it three ways:

• Firstly let's reduce the long period between the user saying what they want - Requirements Specification - and being able to get a finished product and saying "Yes - That's It!" - Delivery Acceptance.
• Then let's compress the process to get to the requirements.
• And then let's compress the design and development process.

How?

• Use iterative and prototyping approach - "So is this what you mean?"
• By getting the user and the developer together - to avoid the risk of misunderstanding so well illustrated by the Tree Swing Design cartoon.
• By breaking the process down into small steps.

While this is has the characteristics of an Agile approach, many of these concepts have been around a long time. Iterative methodologies grew up in the eighties when PC development tools and 4GLs allowed programmers to design databases with the screens and reports in hours rather than weeks. They could talk straight to users and show them the programs to get feedback on the spot.

This develops into Agile methodologies where:

• Product definintions and requirements get cut down to brief "User stories"
• The requirements and design specification are replaced by scrums of colloboration between users and developpers
• Rapid development techniques allow the deliverables to be demonstrated to get rapid confirmation of the design

What does all this do to the Cone of Uncertainty?
Well the risk reduces:

• the time between design and acceptance is reduced.
• The risk will increase again at the start of each new iteration stage.
• The initial risk is also cut down because the early stages of definition are reduced to a high level description of what each stage is going to address.
• There is still some final acceptance. But this is reduced to what I would call integration acceptance - confirming that the deliverables from each stage work together.

So our Cone of Uncertainty is warped into the Christmas Tree of Collaboration!

What have we got to loose?

Let's develop some consequences of the cone of uncertainty - in particular the high risk and uncertainty at the start of the project.

All is not lost down the cone of uncertainty. Although the inaccuracy is high at the start, the stakes aren't high because you have no investment in the project.

We're talking here in general terms about a typical project.

You could see scenarios where you have to have investment or commitment right up front; where, say, you are committed to a fixed price delivery or have to meet some absolute deadline like a regulatory change (although in

such cases you would have requirements specified so you would be some way down the curve already).

If we look at the spending through the project (Shown in the second chart of cumulative expenditure - with the steepness of the curve showing the "Rate of Spend" ):

• Spending doesn't really start in earnest until you get into the main development phase of the project - when construction starts or the programmers start to cut the code.
• That's the point too where most of the project capital expenditure gets made, such as purchases of hardware and licences for the production environment.

If we put together the risk and the cost we end up with the Value at risk - or to put it in plain English -"What have we got to loose?"

This goes from the start of the project when the risks are highest but the investment is low. The value at risk then rises steeply as we progress; the spending rockets while the uncertainties and risks are still significant. As we reach the home straight the risk decreases. You will see that I haven't taken it down to zero when the project is delivered. Most phased project payment schedules will have a "retention" at the end to cover those snags that come up after delivery.

(Try that the next time you call out a plumber to fix a leak - "I will pay you 90% now and the rest when it has stayed dry for a month")

Let us not forget too, that for the user, delivery acceptance is only the start of the benefits that will come from the project, which will have risks too.

So what does this all mean for project risk management?

• If the project is going to fail it is best to let it fail at the start - and your early risk assessments should consider this.
• You need to have gateway reviews at the start - for assurance you have the governance in place.
• You then need to have reviews at the start of any project phase where the value at risk is going to increase.
• And you need to have project assurance all over the project through the main build/development phase when the value at risk peaks.

This, of course, assumes complete honesty and assurance that each phase is complete with the quality needed. So what if you start development -with its high spend rate - when in reality the requirements aren't fully defined? Well the simple maths says that you should apply the higher rate of uncertainty during the requirements specification to the higher spend during development and the value at risk suddenly rockets!

We've seen how by taking a few generalisations about a project we can quickly infer a lot more about the risks of a project. Let's go on to think about how we can bend some of these rules to our project advantage..

Planning Uncertainty

I came back to Mike Cohn's great book on Agile Estimating and Planning. The Agile Manifesto that values responding to change over following a plan doesn't at first seem to warrant a whole book on planning. It still needs to be done - as well illustrated by his quote :

"A good plan violently executed now is better than a perfect plan executed next week." - General George S. Patton

The book starts with a useful tool for any project manager - "Cone of Uncertainty":
This clearly shows what we all know:

At the start of the project, when we don't know exactly what needs to be done, our estimates for the work to be done are the least accurate.

Unfortunately for the hapless Project Manager it's at start of the project, when the business case for the project is being prepared that accurate estimates are most needed!

Different authors give different vertical scales to this cone of uncertainty, with the upper extreme of estimate accuracy (or should I say inaccuracy?) varying between 1.4 and 4. Some (as I have) also skew the uncertainty toward the high end - on the basis that most things get more complicated, rather than easier than expected.

So what are the lessons for the project manager as he gets drawn into the Cone of Uncertainty?

• It is essential to communicate to the project board and stakeholders that the initial estimates are inherently less accurate.
• It is good advice that project managers should always qualify any estimates with a probability: "There is a ninety percent chance this phase will be delivered ontime" - although you may get a reputation for avoiding commitment to deadlines if you do this too much!
• It shows that the milestones/project checkpoints, particularly before the start of detailed design and development, are essential steps to re-estimate costs and the business case, before committing to the increased expenditure as you get down to detail.
• If you have a project contingency budget to cover this early uncertainty you may need to review that contingency as the estimating improves, so it doesn't get spent "covering up" other issues that arise later.
• It is not an excuse that you should leave all estimating until the end of the project so it will be 100% accurate!