Happy Christmas

So enough of disasters, let's look at the bright side of life. Christmas is a very old festival, originally pagan. The Romans called it Saturnalia, a week long period of lawlessness celebrated between December 17th and 25th, and during this period the law dictated that no one could be punished for damaging property or injuring anyone. So that's one answer to the question: what did the Romans ever do for us? 

Unfortunately it was then hijacked by the Christians when they came on the scene and turned into the fable we know today. But fear not some of us are keeping the old traditions alive and will eat and drink to excess and have a thoroughly good time. I am also blessed to have my birthday on the Winter Solstice so yet another excuse for merriment. 

There is a lot of sadness in the world these days and we should always spare a thought for those less fortunate than ourselves but that is no reason for not wishing everyone a very happy Christmas and every success in the New Year. 

A Seriously Challenged Project

Another one from the Why Do Projects Fail website:

Edinburgh City Council: Tram Network (Sep 2003 to May 2014)

When originally conceived the project was intended to reduce traffic congestion, reduce carbon emissions and help the city cope with the increased demand for public transport in the next decade. Today the project is regarded as a shambles and although Edinburgh does now have a tram, what they’ve ended up with falls far short of what was envisaged. Needless to say the public aren’t happy with what they got for their money.

Political influence and disputes between the contractors and consultants marred the project and the project came to a halt on several occasions. As early as 2005 the Scottish Parliament shelved the project when new cost estimates revealed an increase of 30% to the original £375m budget and although the project did get going again, those early cost increases were a warning sign of what was to come.

Soon after construction started in 2007, delays and cost overruns started to accumulate. Disputes between the various parties, quality issues and changes in design plagued the project and between 2008 and 2009 it became clear that the project had some deep seated issues. After 3 years of construction delays the City of Edinburgh Council stepped in. To limit ballooning costs and ongoing delays, the project’s scope was significantly reduced to one single 14km tramline from the airport to the City centre with 15 stops, about one third of the network initially envisaged.

Edinburgh residents had to endure the inconvenience of roads being dug up for the best part of seven years causing congestion and financial harm to businesses. The tram eventually took its first passengers in 2014.

The final cost of £1 billion, or £71.4m/km, compared to the average cost of about £22.7m/km for tramlines completed in 17 other cities in the northern hemisphere in the same period. A 314% cost increase for one third of the original scope.

Public opinion remains divided as to whether or not the project will eventually prove to be beneficial. An enquiry is currently underway to find the root causes and who was accountable for the fiasco. Contributing factors as reported in the press were: underestimating the complexity of the project; lack of contractor oversight; lack of quality controls; and failure to establish appropriate controls and management processes to ensure the project was properly organized.

Once again the real reason is plain to see: poor project management.

More Project Disasters

And another one from the Why Do Projects Fail blog...

Los Angeles Unified School District 
e-Enabled Learning Tools Project
Apr 2015  
Cost: $1.3B

The Los Angeles Unified School District’s efforts to provide every student, every teacher and every administrator with a iPad turned into a disaster. Launched in 2013, the initial plan called for more than 100,000 iPads to be purchased. Some were to be loaded with apps containing curriculum that would be used for instructional purposes while others were to be used for standardized testing.

From the initial roll out the problems were clear. Students were able to bypass the built in security to access non-authorized content while the authorized content that was provided suffered its own quality problems. Reports indicate that the authorized content was not written in accordance with applicable teaching standards and those problems were compounded by the fact that the system suffered reliability problems that frequently rendered the content inaccessible anyway.  

The project’s Director publicly criticized the system saying “Making the materials ‘usable’ has required extraordinary, unsustainable, and un-scalable resources.” Publishing an open correspondence the Director reports that only 2 of 69 schools in the initial pilot were still attempting to use the tool. The remaining schools had given up. Noting that less than 5% of the target student body had reliable access to the content, the letter also noted that even when used, the content failed to meet all appropriate requirements.

Contributing factors as reported in the press: failure to gain stakeholder support; missing requirements; quality related issues; and failure to fully recognize the transformational shift in learning that e-enabled learning represents.

What They Should Have Done

• appoint a good, experienced project manager
• buy a copy of 'Agile Project Management in easy steps'
• take an agile approach, with full user involvement 
• user experience design 
• try it out on a small pilot (1 school not 69)

The report also mentions that this is the second project from the Los Angeles Unified School District that has featured in the Catalog of Catastrophe, when will they ever learn?

Project Disasters

I've decided to have a look at some project disasters to see if there is anything new to learn and just had to start with this one:

Volkswagen Group: Vehicle Emission System
Probably the most expensive scandal in recent history, where Volkswagen basically put in special software to cheat the emission testing protocols used by governments. It has shaken confidence in a once solid brand. It is both an embarrassment for the company and a financial disaster for the shareholders. In addition to fines of up to $18 billion at least $25 billion has been lost due to a dive in stock price.


And not to forget that Volkswagen also own and produce Audi, Seat, Skoda, Bentley, Bugatti, Lamborghini, Porsche, Ducati motorbikes and truck makers Scania and Man. In total more than 11 million vehicles are affected.

Full report available at: http://calleam.com/WTPF/?p=7666

So what went wrong?

They put profit before quality 
They flouted government regulations
They failed to disclose and actually withheld information 
They didn't test the diesel vehicles on real roads
They failed to live up to customer expectations 
They deliberately falsified advertising claims

This is not a project failure it is a corporate failure but somewhere in there was a project manager who went along with an illegal project instead of pushing back.

Bonfire Night

Well it all went very well in the end and we got a very good write up and photographs in the local paper. It rained pretty solidly up until about 5pm but stopped on cue. The only problem was the ground was so soft we had a few problems parking all the cars and ended up with people parking in the street. Also we had to cancel two of the three games we had scheduled on the Saturday to be on the safe side with the state of the pitches but could probably have got away with playing them.

We had a few other minor issues but the wash up meeting should capture those and hopefully next year can only be better still. Now back to the day job...

Something Completely Different

and now as they say for something completely different...

Bonfire Night

Topsham Rugby Football Club have one of the biggest and best firework displays in the county and that takes a lot of project management. So at the current moment everything else is getting put off until after the 5th of November.

Thereafter normal service will be resumed as soon as possible.

Making It All Happen

The six steps I have been illustrating over the past six weeks are all fairly straight forward and very achievable, but they will take some time. However help is at hand:

Resources
I have mentioned the resources provided by the Project Management Institute and the Office of Government Commerce (now Axelos) but there are also some of my books that provide a more straight forward alternative:
 

If you want detailed guidelines for the implementation of all the things I’ve been talking about, they are all set out in Project Program and Portfolio Management in easy steps.

If you want guidelines for developing project management excellence, they are set out in Effective Project Management in easy steps.

If you are running agile project, then guidelines for developing agile project management excellence are set out in Agile Project Management in easy steps.

And last but not least if you are wondering where you will find the time to do it all then Effective Time Management in easy steps will provide you the answers.

So draw up a list of what you want to achieve and plan and manage the project like any other major business change. I say project but it could require a program (unless your organisation is already a good way up the capability maturity matrix) as it is likely to take several years to implement fully (and that by definition that should be a program not just a project).

Your Mission

I would like to leave you with one final point to consider: without the full commitment of your organisation (and that really does mean support from your very top management) none of this will happen, so I would suggest that’s your starting point. 

Your mission, should you choose to accept it, is to produce a high-level plan for what you want to achieve, then sell the benefits of these best practices to your organisation. If you need any help I am always pleased to offer help or advice to fellow professionals and this is the URL of my web site should you wish to contact me: johncarroll.org.uk

Step 6: Portfolio Management Deployment

The final step in the deployment of best practices is the big one, portfolio management. Not many organisations have yet achieved this, so this is the area that can deliver real competitive advantage to any business.

Yet again it is absolutely essential to involve all the project and program managers in the process and yet again the steps are similar to those involved in deploying project or program best practices, with one main exception at step 2:

Step 1: Define and document a standard portfolio life cycle. This is my own particular take on a portfolio life cycle diagram:

Step 2: Set up a central project database, which is essential to the process.

Step 3: Define the portfolio management processes to support the portfolio life cycle. These can be based on off-the-shelf standards such as the PMI's Standard for Portfolio Management, OGC's Management of Portfolios or a good book on the subject (such as my own Project Program and Portfolio Management in easy steps). This will put you on level 2 of the CMM matrix for portfolio management.

Step 4: Establish a portfolio office to maintain and develop the processes, or develop the program or project office into the role. This will put you on level 3.

Step 5: Define portfolio reporting standards and metrics and transfer them to the portfolio office to implement, support and maintain. This puts you on level 4.

Step 6: Task the portfolio office with optimising the processes and standards, which takes you to level 5.

Next week I will look at making it all happen, some resources you can use and how to go about it.

Step 5: Peer Review Deployment

As with the earlier steps, I believe once again that it is essential to involve all project and program managers in the process.

Start by defining, documenting and agreeing a high-level peer review process based on fixed points in a project and program life cycle.

Develop the necessary standards and guidelines to support the process or base them on something like the gateway review process (see below).

Transfer everything to the project and/or program office to maintain, support and develop.

Identify potential peer reviewers and provide them with any necessary training in the process.

Select a pilot project, run peer reviews on it, review the outcome of the pilot, refine and roll out the process and standards.

Then repeat the same steps for a program.

Gateway Review Process
This is an example of the Gateway peer review process as it is applied to programs and projects:

A project (on the left) has a review at the completion of each stage, with a focus on: 1) Business Justification, 2) Delivery Strategy, 3) Investment Decision, 4) Readiness for Service, and one or more on 5) Benefits Realisation.

A program (on the right) has a review during the Definition Phase, one for each Delivery Phase, and a final one during the Closure Phase. But please don’t ask me why they decided to call them all gateway 0!

Next week we will look at the final step in the process, portfolio management.

Step 4: Program Management Best Practices

Last week we looked at deploying project management best practices, this week we look at a very similar process for deploying program management best practices:

Deploying Program Management Best Practices 
Once again it is essential to fully involve all the organization’s project and program managers in the process. 

Once again the process starts with defining, documenting, agreeing and implementing a standard program life cycle.

Then define, document and agree program management processes to support the project life cycle. These can be based on standards such as Managing Successful Programs (MSP) or Standard for Program Management (SPM), or a good program management handbook such as my own Project Program and Portfolio Management in easy steps. This takes you from level 1 to level two on the program management capability matrix.

Then establish a program office (or develop the project office into the role) to maintain, support and develop the agreed processes. This takes you from level 2 to level 3.

Define program reporting standards and metrics and task the program office with maintaining, supporting and developing and them. Which takes you from level 3 to level 4.

Once again you could stop here but why not take the next step and task the program office with optimising the processes and standards. This takes you from level 4 to level 5 and completes the deployment of program management best practices.

Next week I'll look at deploying a peer review best practice process.

Step 3: Project Management Best Practices

Deploying Project Management Best Practices
Having established where the organisation currently is on the capability maturity model and planned how to get to the next level in steps 1 and 2 we can now start to roll out the best practices. I am going to assume that you are starting from level 1 (if not you will already have some of the earlier items in place).

Before starting any of this I believe it is absolutely essential to involve all the organization’s project managers in the process (after all they are all key stakeholders). So these are the steps involved:

Define, document and agree a standard project life cycle (if you don’t already have one), then define, document and agree project management processes to support the project life cycle. To speed up the development, these can be based on existing standards (such as PRINCE or PM-BOK) or on a good project management handbook (such as Effective Project Management in easy steps). This takes you from level 1 to level 2.

Next establish a project office to maintain, support and develop the processes. This takes you from level 2 to level 3.

Then define project reporting standards and metrics and task the project office with supporting and enforcing these, together with collecting and processing the data and reporting it to management. This takes you from level 3 to level 4.

You could stop here but why not take the next step and task the project office with optimising the processes and standards. This takes you from level 4 to level 5 and completes the deployment of project management best practices.

Next week I'll set out the process for deploying program management best practices.

Step 2: Improving Your Capability Maturity

Last week we looked at the Capability Maturity Model and the process of establishing where your organisation is on it. Once you have established that you can plan what you will need to do to move up the model. But remember that you can only move up one level of maturity at a time so plan on the basis of achievable short-term objectives. 

For example if you decide you are currently at project management level 2: repeatable (you will have documented project management methodologies and a standard project life cycle in place; and you will be involving your project managers in the definition and agreement of these standards). You will now plan to move to level 3: defined. In order to achieve this you will need to carry out the following steps:

1. Establish a project office to maintain the standards and documentation and provide an interface to the project mangers.
2. Obtain management support and authorisation to enforce compliance with the standards and monitor this through the project office.
3. Involve the organisation's project managers in reviewing and improving the standards.

Once you have that in place you are ready to plan for moving to the next level of organisational maturity. Next week we will look in more detail at the steps involved in deploying these project management best practices.

Step 1: Establish Your Capability Maturity

Last week I outlined my deployment road map and the first step was to establish the current level of project management capability maturity in your organization.

Capability Maturity Model
Most project managers will by now be familiar with the capability maturity model (CMM) and this is an example of the project management CMM (there are also program, portfolio and combined P3M versions):

If you want help with establishing your organization’s capability maturity the CMMI Institute have a self-assessment questionnaire you can adapt and use. You can find it at: 

http://cmmiinstitute.com/assess-your-organizations-capability

Next week I'll look at the second step of moving on up the maturity matrix.

The Project

At long last Agile Project Management in easy steps 2nd Edition is out in print. More pages and two more chapters (Feature-Driven Development and Agile at Scale) and now co-authored with David Morris, who was responsible for most of the additional content. And even better value for money as it is still only priced at £10.99 UK / $14.99 US.

Deployment Road Map

So the four things we can do to stop projects going wrong are to consider the needs of the project manager; consider the needs of the organisation; select the right projects; and to review them regularly. So what do we need to do to ensure this happens?

We need to start with the organisation. If an organisation is going to thrive in the current environment it will need to embrace project management as a crucial element of the business. The organisation will practice portfolio management and will have a project focus. They will value their project managers, support their development and see project management as a vital part of management development. Having implemented this in several organisations, I have developed a simple road map to that successful deployment

Deployment Road Map
Step 1: Establish the current level of project management capability maturity in the organisation;
Step 2: Plan how the capability maturity needs to be developed and improved;
Step 3: Define and document sound project management processes, with a project office to support and develop the processes;
Step 4: Define and document sound program management processes (if you are going to implement program management) again with a program office to support and develop the processes;
Step 5: Introduce a peer review (gateway) process for all projects and programs; and
Step 6: Implement portfolio management at the highest level in the organisation.

I will be looking at each of those six steps in detail over the next six posts. So until the next time: don't forget to enjoy your project management.

What We Can Do About It (4)

Step one was to consider the skills of the project manager, step two was to consider the needs of the organisation, and step three was to consider the projects and make sure they are business critical. But we can't just stop there, for even if a project is business critical it can still go wrong or cease to be business critical. The way we deal with these two potential problems is: 

Review the Projects
So step four is to put processes in place to ensure that all projects are reviewed at set times during the project life-cycle. 

What is needed is some form of peer review process, where a small team (external to the project) or just a single person for a small project, carries out a quick review against a standard check-list. Ideally this would be at the end of each project stage. The process is sometimes referred to as a gateway review process and uses a Red, Amber, Green (RAG) traffic signal against each point on the check list. Red is critical and urgent: the problem must be addressed or the project will fail. Amber is critical but not urgent: the problem should be addressed before any further key decisions are made. Green: the project is on track on this point. 

This process is nice and simple and I like ‘simple’ processes. Used properly the process works as it ensures that projects that are going wrong get fixed or stopped before they can have a serious impact on the business. It also checks that projects still are critical to the business.

So those are the four steps I believe we can take to stop projects going wrong. In the next post I will start to look at deploying them in an organisation.

What We Can Do About It (3)

Step one was to consider the skills of the project manager and step two was to consider the needs of the organisation. 

Consider the Projects
Step three is to make sure that only projects that are critical to the business take place and that the projects that do take place are measured on the actual benefits they deliver to the business at the end of the project. Most organisations are currently failing in both of these areas.

These decisions must be made at the highest level in the organisation and portfolio management provides the mechanism for this (although you don’t have to call it that, particularly in smaller organisations, where it might be considered overkill). 

When I’ve run project portfolios I usually work on a three year focus, with a quarterly review of the portfolio and a strict rule that nothing is bullet-proof. The most business-critical projects are always prioritised and anything else (including projects that are already under way) can be deferred or delayed. This way all projects are business critical and will get full top management support.

Up to now, not many organisations have implemented portfolio management and of the few that have, many still suffer from what I call ‘project amnesia’. Some people call it the ‘approve and forget’ approach as once they have approved a project they seem to forget all about it. So there is one final important fourth step, which we will look at next week.

What We Can Do About It (2)

As we saw last week, step one was to consider whether the project manager actually has the necessary skills to manage projects and if not, to move them somewhere else where they can do less damage to the organisation. And speaking of the organization:

Consider the Organisation
Step two is to consider the needs of the organisation itself. Business today needs to be agile and able to change and adapt quickly, if not it will fail. Because of this the business environment today is becoming more and more project driven, which means the business must have a project focus. That means embedding project management into the business strategy and making sure the organization understands it.

Then if we are going to do projects we need to do them right and that begins with putting our best people into the role (not just anyone who is available). Maybe as part of a career development process for a couple of years. Good managers will be stretched and will blossom in the role and be capable of taking on greater things in the future. But the organisation must support this and be fully committed to it, not just put anyone who is available into a project management role.

Agile Project Management in easy steps
And speaking of agile, the second edition of the book (now co-authored with David Morris) is due for publication in the next couple of weeks.

What We Can Do About It

Consider the Project Manager

First of all we need to consider if a project manager actually has the necessary skills to manage projects. A lot of people get thrown into project management because they are available, with no thought about what skills they need to carry out the role. I get a lot of feedback on this point so I know it is still happening today.

So a good honest appraisal should clearly identify any areas of skills shortage and development needs. But we need to be honest, not everyone can become a good project manager. Not everyone will have the right temperament or basic management skills. However, if they show promise then give them any necessary training but more importantly I think we should provide mentoring for them from an experienced (and therefore hopefully a wise) project manager.

But if they are not cut out for it, move them to somewhere else, where they can do less damage to the organisation.

Why Projects Really Fail

To recap:

The Real Cause
Earlier in this blog I listed the top ten ‘causes’ often cited for project failure and then examined them one by one. They all turn out to be just symptoms of poor project management or selecting the wrong project. But a wise project manager would also deal with the wrong project, so let's bite the bullet, the real reason projects fail is just poor project management.

Wise project managers are aware of these symptoms as they will have learned about them the hard way from their own early projects. They take the necessary steps to ensure they don’t have these problems in future on their projects. 

But that still leaves us with the problem of what to do about the unwise project managers whose project run into problems or fail altogether. The answer is not to send them all on training courses. What I believe we need to do is develop the project managers, develop the organisation, select the right projects in the first place and then regularly review them. I'll be expanding on these topics again over the next few weeks.

PMI Netherlands Summit

The summit was a great success with some fine inspirational speakers and it was good to meet so many PMI members. What was interesting was the number of common topics that were covered by the different presentations. Lots of food for thought for the future. Now I've delivered the talk I will post the remaining bits on this blog.