Life's change agent

Death is very likely the single best invention of life. It is life's change agent. It clears out the old to make way for the new.

Steve Jobs 1955-2011

Knock, Knock. Who's There? IT

IT; "Have you got a minute?"
CEO; "As long as it's just a minute - I have a customer meeting."
IT; "We need to upgrade to Windows 7. XP is going out of support. I have worked out the licence cost - we got a good deal before the suppliers year end. I have got the justification...."
CEO; "I've got to go. I suppose we have to do it.... While you are here, can I connect my iPad to the network?"
Discuss....

From Global Solution to Big Problem

In six easy steps:

1. Central:     "Here's our Global Solution"
   
2. Local:         "Does it work for me?"
   
3. Central:     "We will get down to the detail later but it can do everything we need. We will work together on this, now let's get on.."
   
4. Local:        "But I can't use it because it doesn't do this"
   
5. Central:     "This is the central solution – you have to use it"
   
6. Local:         "OK. Make me.."
   

Coach a team with 100 words

Footballers are not known for their extensive vocabularies.

So it was hard to tell whether it was a compliment or an insult when Italian Fabio Capello, England's football coach, said he could manage the national team using just 100 words.

"If I need to speak about the economy or other things, I can't speak," he told reporters. "But when you speak about tactics, you don't use a lot of words. I don't have to speak about a lot of different things. Maximum 100 words."

To see if it could be done, first the BBC went to the Oxford English Corpus, which has identified the hundred commonest English words found in writing globally:

1. the 2. be 3. to 4. of 5. and 6. a 7. in 8. that 9. have 10. I 11. it 12. for 13. not 14. on 15. with 16. he 17. as 18. you 19. do 20. at 21. this 22. but 23. his 24. by 25. from

26. they 27. we 28. say 29. her 30. she 31. or 32. an 33. will 34. my 35. one 36. all 37. would 38. there 39. their 40. what 41. so 42. up 43. out 44. if 45. about 46. who 47. get 48. which 49. go 50. me

51. when 52. make 53. can 54. like 55. time 56. no 57. just 58. him 59. know 60. take 61. person 62. into 63. year 64. your 65. good 66. some 67. could 68. them 69. see 70. other 71. than 72. then 73. now 74. look 75. only

76. come 77. its 78. over 79. think 80. also 81. back 82. after 83. use 84. two 85. how 86. our 87. work 88. first 89. well 90. way 91. even 92. new 93. want 94. because 95. any 96. these 97. give 98. day 99. most 100. us

Source: Concise Oxford English Dictionary (11th edition, 2006)

You will be pushed to make many phrases from these – although you may do better from the list of the top 25 Nouns, Verbs, and Adjectives.

The list of nouns makes interesting reading:

• man is 7th, whereas child is 12th and woman 14th
  
• the highest-ranking body part, hand, is 10th - eye is the next in 13th place, followed by head at 27
  
• Work is at number 16 whereas play and rest do not feature in the top 100!
  
• war is at 49 with no sign of peace
  
• problem is 24th and there is no solution in sight
  
• friend is 30th with no enemy or foe
  
• book is number 41 whereas computer does not feature in the top 100 and is below paper
  
• Money is surprisingly low at 65 and cash is nowhere to be seen: this low ranking is perhaps explained by the fact that we have so many synonyms for money.
  

 

Not to be outdone, Cambridge has now been through the Cambridge International Corpus.

The dictionaries contain more than one billion English words, and their context, used regularly in newspapers, books, emails and conversations. Experts tracked down around 8.5 million football-related words before refining them to the 100 most commonly used football nouns, verbs and adjectives.

The list of 100 football words are:

1 – ball 2 – cup 3 – player 4 – Game 5 – Match 6 – Win 7 – Lose 8 – Play 9 – Team 10 – Goalkeeper 11 – Defender 12 – Fullback 13 – Midfielder 14 – Winger 15 – Striker 16 – Forward 17 – Defence 18 – Midfield 19 – Attack 20 – Pitch 21 – Goal 22 – Goalposts 23 – Crossbar 24 – Woodwork 25 – Box 26 – Touchlines 27 – Left 28 – Right 29 – Kick 30 – Pass 31 – Tackle 32 – Cross 33 – Dribble 34 – Shoot 35 – Strike 36 – Score 37 – Equalise 38 – Foul 39 – Defend 40 – Attack 41 – Header 42 – Touch 43 – Mark 44 – Dive 45 – Referee 46 – Linesman 47 – Assistant 48 – Offside 49 – Handball 50 – Free kick 51 – Penalty 52 – Corner 53 – Goal-kick 54 – Caution 55 – Suspension 56 – Yellow 57 – Red 58 – Cards 59 – International 60 – Tournaments 61 – Stages 62 – Competition 63 – Friendlies 64 – Qualifiers 65 – Group 66 – Quarter-finals 67 – Semi-finals 68 – Progress 69 – Final 70 – Shoot-out 71 – Tactics 72 – Training 73 – Formation 74 – Possession 75 – Pressure 76 – Defensive 77 – Attacking 78 – Patience 79 – Fitness 80 – First-half 81 – Second-half 82 – Half-time 83 – Injury-time 84 – Extra-time 85 – Physical 86 – Technical 87 – Clever 88 – Pace 89 – Skill 90 – Talented 91 – Fans 92 – Supporters 93 – Passion 94 – Spirit 95 – Pride 96 – Excitement 97 – Defeat 98 – Disappointment 99 – Humiliation 100 – Sack.

 

Perhaps we could run a project with just 100 words? Maybe even just 40:

Meeting, stakeholder, initiation, deliverables, deadlines, scope, budget, sponsor, on-time, quality, document, time, report, review, communication, progress, management, change, office, benefits, cost, business, case, plan, control, milestone, task, estimate, program(me), team, design, analyse, package, work, schedule, risk, slip, delays, overrun, shelved…

Leave a comment with your suggestions.

The Project Mahout

How do you get an elephant from A to B?
There are four ways: You can

• Push it,
• Pull it,
• Pick it up and carry it, or
• You can climb up onto the elephants back and whisper in its ear "There is a bun in that direction."

In change management, the subject has got to see the benefit of the change. If change is being imposed then you have to carry the elephant.
And for programme management and international project management, you have a herd of elephants.
This will take:

• A whole tray of Krispy Kreme donuts.
• Good knowledge of the individual tastes of each elephant.
• You also want to pick the right elephant to ride – and lead the herd.

This blog is the bastard lovechild of reading the "Lazy Project Manager" while watching "Passage to India"!

Keep your plans agile and objectives personal

Your project plans need to be detailed for the near term so that everyone knows:

• What they are working on,
• What their accountability is for the deliverables and quality and
• How this fits into the greater objective.

The only thing that is certain about a long-term detailed plan is that it will be wrong. PMs can learn a lot from military strategy—a General doesn’t plan a battle in detail but depends on soldiers knowing their objectives, so they can react to events and seize opportunities.

“A good plan violently executed now is better than a perfect plan executed next week.”—General George S. Patton

This was my contribution to Lessons Learned in Project Management: 140 Tips in 140 Words or Less
A compilation of project management advice put together by John Estrella  - which is available from Amazon - Kindle edition only in the UK

The Global Project Managers toolkit

As you venture forth on a multinational project delivery, what tools you need to increase the chances of success?
As soon as you start to cross borders, the geographic and cultural separation mean that the trusted team management techniques such as "Management by walking around" and "the team that drinks together, thinks together" no longer apply.

Project Management.

A management process is essential for the success of any project. Let's face it: most Financial Services companies are very good at transactional execution but major projects are not their strong point. Project management is not about what you need to do on the project (see development methodology below) but how you control it:
•    Setting the scope and the business case for the project.
•    Identifying the tasks to be performed during the project, controlling the resources, managing the deliverables and quality.
•    Managing changes to the scope of the projects and risks.
•    Having gateway checkpoints and audits of the project.
•    Ensuring that the project meets the requirements, stays within budget and delivers the benefits.
Project management methods such as Prince2 and PMP are built around the core of the Executive Sponsor and the Project Manager. The Sponsor leads the project, makes the big decisions and assigns business resources the project needs. The project manager plans the project and is accountable to the business for the project delivery and achieving the benefits.
Software vendors and consultancies will, of course, offer to do the project management but Prince2 is very specific that the PM should not be from the supplier as they will ultimately be accountable to the supplier not the business, and introduce "lock in" with one supplier. Project management should anyhow start before the supplier is selected.
An international rollout may need broader programme management –providing strategic control of subsidiary projects such as the RFP process, software delivery and business change by country. Treating a multinational project as a programme can allow local project management and local accountability for achieving benefits.

Development Processes

There are broadly two types of development or implementation process:
The first, Waterfall - or "Big Design Up Front" – concentrates on gathering requirements at the start of the project, before going on to the traditionally more expensive design and programming stages.
The second, iterative processes, are widely seen as more suitable for package implementation and where there is business change going on in parallel, with requirements evolving through the project. They use prototyping, rough cut of configurations of a package, and pilots to test assumptions and refine the requirements. Each iteration can be seen as a mini project, which has a better chance of completing successfully and with measurable benefits coming out from each cycle.
The most highly iterative methods, such as scrum and extreme programming, where users and programmers are locked together in intense brainstorming and prototyping sessions, could be seen as less suitable for international projects because of the need for the team to be co-located, defining complex requirements like lease accounting and considering the collegiate requirements of different business units.
The implementation method is distinct from the project management. Where you are working with a supplier it is often best to use their methodology will be geared towards defining the specific deliverables for their system configuration..

Business Process Management

Many large organisations, particularly with manufacturing origins, will have their own Business Process Management or Re-engineering methodology – such as Toyota and Six-Sigma at GE. These are built around scientific calculation of the value each step adds to the end product. Many of these will be difficult to apply to financial processes – let's be mischievous and ask what value Credit add to a deal? – although Citibank in the eighties embraced the concept of "the bank as a factory".
In practice for systems enabled business change it will be better to build process redesign around best practice workflows provided by the systems supplier.
With a multinational implementation a single "cookie cutter" standard process can be difficult to impose, because of regional requirements, the different sizes of each business, and even particular individual talent.
But what is more important than the one-off process design is to develop a culture of continuous improvement across the operation with international sharing of best practice.

Collaboration Tools

Initial face to face team meetings are essential to build up trust and understanding at the early project stages. For teams that are dispersed for their day to day work it is important to use collaboration technology to keep them together virtually.
Audio conferencing (with local dial in numbers to cut down on cost) can be enhanced by web conferencing (using tools such as Webex or GoToMeeting to view presentations, whiteboards and even application demonstrations). Videoconferencing using webcams will work with these – up to a full telepresence if project budgets are that big.
Instant messaging is not just for teenagers and helpful to ping a quick question to a distant colleague. Email, although pervasive, is not best for project communications with long and intertwined email exchanges hard to follow. A central project document storage, intranet (shared within the organisation) or extranet (giving access to suppliers as well) provides a common project "knowledge base". Web based document storage or a Wiki (based on the technology behind Wikipedia) are now common solutions. Microsoft SharePoint 2010 adds the ability to have simultaneous editing of Office documents, publish and track project plans, create web based databases and even workflows from Visio diagrams.
And for the future, look at the demonstration Google Wave – think of a combination of instant messaging, email and a wiki.

Technology

For the global system itself what help is there from the technology? Microsoft's dotNet and rival J2EEE application development provide support for the basic number and date formats. But architectural solutions for the all the "multi" stuff has to come from the system design.
A web based application will certainly greatly assist with the deployment of the system over long distances than an older "thick client" PC application would allow. The amount of data displayed on the screen is improved with modern design and improved features like "type-ahead" make many web applications a richer experience than PC desktop programs.
Highly modularised service oriented applications speed system configuration by having "building blocks" to quickly support particular requirements. You also use web "applets" components to tailor your own screens and dashboards.
Virtualisation frees your application from being tied to particular hardware and servers. Software as a Service (SaaS) allows you to get software on a "pay per use" or utility model. If the software supports your needs this can be a quick way to set up and test software. On-going costs may come out higher in the long run but you are insulated from many of the hassles of in-house IT such as upgrades, and if things don't work out you have not lost the upfront investment! Make sure that SaaS software supports multinational requirements and don't forget that although it simplifies the technology delivery it doesn't take away any of the complexities of Business Process changes needed.
The logical conclusion of this is cloud computing, highly virtualised, highly scalable, internet based software. One note of caution is hidden in the terms of service of Amazon Web Services: "We strive to keep Your Content secure, but cannot guarantee that we will be successful at doing so, given the nature of the Internet. Accordingly... you bear sole responsibility for adequate security, protection and backup of Your Content and Applications."
Of course, while these tools can assist your international projects, in themselves they will not assure success. When combined with experienced practitioners they can leverage skills, reduce project risks and greatly increase productivity.
© Nic Evans 2010.

The six worst things I hate about lists

1. There is an annoying tendency of bloggers to resort to lists to connect random thoughts rather than writing a coherent article
2. Worse still they call it the “eight greatest..” or the “five worst..” and did they do any actual polling to find out which are the most important? I think not.
3. They have lots of similar points and don’t clearly distinguish between them.
4. They repeat themselves a lot and haven’t really thought through the points.
5. It would be OK if they were checklists that you could usefully use to make sure that you have done everything.. but they are not.
6. You get the feeling that the number of items in the list is dictated just by their attention span.

Sorry seems to be the hardest word

I've been getting a lot of stick about my car. Jeremy Clarkson berates me every week calling me a "Pious Driver". But it suddenly got a lot worse. Now it's open season for Toyota drivers: first with the accelerator pedal problems, then with the brake problems on newer models of the Prius than mine, and now the steering on the Corolla.

I joined an internet forum to find out how to connect my bluetooth phone to the car and I get a cascade of comments: "that's the least of your problems" was the kindest. The poster slogan "The car in front is a Toyota" has graffiti "lucky it's not behind you".

So it was good to see Toyota president Akio Toyoda making a sincere bow of apology. I accept his apology.

It is the sign of a good leader to take responsibility for errors and failures of their team.  Then to fully take on board the lessons learned.

“FIRST, get the cow out of the ditch. Second, find out how the cow got into the ditch. Third, make sure you do whatever it takes so the cow doesn’t go into the ditch again.” This is the advice - quoted by the Schumpter business column in the Economist - that Anne Mulcahy, the former boss of Xerox, says became her mantra as she fought successfully to revive the fortunes of the copying and printing firm.

And I am talking about sincere apology too. None of this "SORRY. This bus is not in service." or spinning to play the issue down. You have to admit the cow is in the ditch.

To "do whatever it takes so the cow doesn't go into the ditch again" Toyota now offer a five year warranty, and their slogan in the UK is Your Toyota is My Toyota accompanied by pictures of a committed local workforce.

Some say that Akio Toyoda did not bow low enough. I say that we could do with a lot more sincere bowing for apology. Bow .. Sir Fred Goodwin. Bow ..Victor Blank. Bow ..Rick Fuld.

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!

Passing the point of no return

Pilots will know that when you are taking off there is a speed called V1. The plane has reached such a speed that there is not enough runway ahead of you to stop. So you are committed to take-off. Unfortunately V1 is usually less than V2 - the speed at which the plane can safely get off the ground. Any change after passing V1 – like a critical engine failure - can be catastrophic.

Many projects will feel like they have a similar point of no return. You have spent so much of time, effort, money and emotional investment that you have to go on. Going back to your old process may no longer an option: it is out of support or it won’t support new statutory requirements.
So what can you do if your project starts to fail after it has built up such a momentum?

Firstly Avoidance: your project management should have identified the risks before they happen, and mitigated them – a four engine plane is inherently safer that a single engine plane.

Secondly Act Decisively: A crew faced with an engine failure on take-off has to act quickly. They will have rehearsed the routines in simulators. Faced with a real situation they act in a split second. Can your project objectives and business case be quickly reconfigured so you still have a viable configuration? Throw out the catering trolleys to reduce weight for take off! But you can only act decisively if you have identified the risk.

If You Can, Stop. It is better to run off the end of the runway than to try to take-off without enough speed.

Finally Learn Lessons. All Air Incidents must be reported. There should be no fear of victimisation. Spin, cover-up or denial will only cause future catastrophes. If the crew followed procedures then they have nothing to fear. "Sully" Sullenberger, the US Airlines pilot who put down his crippled plane on New York’s Hudson River became a national hero. A project failure should lead to a process improvement.
A bank that bought PCs to re-equip its branch network found they were underpowered for the teller application when it was delivered. They could have sold them immediately to recover some cost but that would have realised an accounting loss. So the PCs sat in a warehouse for three years until they could be quietly scrapped. Was that the right outcome for me as a shareholder?

Risky Business

Here's a great white paper on project risk assessment in the context of corporate risk appetite.

http://www.projectperfect.com.au/white-paper-a-different-view-of-project-risk.php?b3note=riskmat

Unfortunately it doesn't extend onto management of project risks.

The Office Of Government Commerce also has some really useful risk potential assessment tools and techniques . They even have the spreadsheets set up to save you the math!

It just a shame that too many UK public projects don't stick to these principles. It is a major victory for common sense, the UK tax payer and for students of project management that Gateway Reviews are now published under Freedom of Information.

Whatever your views are on Prince2 there can be no doubt that its approach to project risk management is a sound framework. It will be interesting to see how the new guidance for Directing Successful Projects with PRINCE2 2009, aimed at project executives and sponsors, will clarify the project directors vital role in risk management.

How long will it be before this guidance has an impact on the Gateway Reviews?

Labour Saving Devices

Very occasionally an IT project will be producing something totally new and innovative which hasn't existed before. But the vast majority of IT change is all about improving business efficiency. The business case for the projects will have the costs of the projects which are offset by the benefits of reducing costs – most of which will be likely to be salaries.

In the new world economics you will need to go back and reassess any savings and benefits because there are some fundamental changes and major discontinuities in the economics that have come in to play.

In the old world order:

• your business volumes were growing at a healthy rate of, perhaps, ten percent. So your project efficiency gains will easily pay for the project costs. You simply don't have to recruit extra people to support the extra volume. You also save the additional HR costs including the recruitment fees and training costs.
  
• If you have very dramatic performance improvements then the headcount savings can be increased by normal staff turnover. When someone leaves you don't replace them. Again you save on the cost of on-boarding new staff.
  

Now the whole balance changes:

• As general unemployment increases then staff turnover suddenly stops. No-one will give up a job with several years of accumulated benefits for the uncertainties of a new job with the risk of "first in – first out". The goodwill of employees for a projects objectives will, not surprisingly, evaporate as benefits become threats to their personal livelihood.
  
• Any saving in employee costs completely change if the company has to make compulsory redundancies, with the costs and compensation that have to be made. These may well come on top of other redundancies that the organisation has hade to make because of drops in business volumes.
  
• And leaving the sensitive subject of job cuts – do the ecomomics of your project still stand if business volumes have dropped by ten percent?
  

I hate to see irony in such a black situation, where real people's livelihoods are at stake. Believe me: I've been there myself. But it is "funny" that as the need to make efficiency savings increases then it actually becomes harder to make those savings.

Risks out of control

In any project some of the projects costs and benefits are out of your control. Not through any fault of the project. It's just the way it is.
In any business case there will be a number of macroeconomic and other external factors in play, and with the market discontinuity in the last year these have seen unprecedented turbulence:

• Cost of funds -used for your IRR or NPV of cost and benefits, and possibly any project financing.
• Exchange rates, particularly for multinational projects : although for offshore work, the vendor bears this risk, any adverse movement in x-rates can impact the vendors appetite for continuing work, and so still pose a risk to the project.
• Raw materials costs, for the business or the project. Will high fuel prices blow your travel budget?
• End product prices and sales volumes. You will have heeded my warning not to justify projects on increasing sales without demonstrable justification but still a 50% drop in sales is going to impact the businesses willingness to invest in projects.
• And throw in a few non ecomomic factors. What would happen if 30% of you project team were suffering from swine flu in the month of go live?

How should a project cope with this turbulence?

• Firstly you should identify the risk. Any assumption made in planning should be documented and the risks from changes to the assumptions identified.
• Stress testing and scenario planning. Once you have established the assumptions see the impact on changing them: Double them and halve them. Double some and halve others. What does this do to your business case?

On the outcome of your scenarios then you can use the standard risk countermeasures:

• Prevention. If the risk has too big an impact then terminate the risk - even to the extent of stopping the investment.
• Reduction. If the project travel budget can't absorb a future increase in airfares then reduce travel plans now, and buy a good conference phone.
• Transference. Speak to your CFO or treasury department. Will they accept the risk for you? If you have FX exposure does the business have some opposite exposures? Offshore profits to be repatriated? Can the business hedge the risk?
• Acceptance. Just get over it. If your scenario planning shows the impact is small then the project board can decide to live with the risk and bear the costs when the happen.
• Contingency. Plan and budget for the impact, if the risk materialises. If airfares increase then stop travel or have a contingency budget only to be used if air fares increase. To be fair to your project sponsor you should also reduce the budget if air fares go down!

Management of risk should be a core discipline of your project management.