Is PRINCE2 agile?

Might it be that Prince2 the goliath of project governance frameworks, with a manual of over 450 pages could be agile? Dr Peter Merrick visited the recent Best Practice Showcase and discovered some answers to this and other topical questions.

The latest OGC sponsored Best Practice Showcase took place at the QEII Centre in London at the end of June. The programme included a presentation on the possibility of using Prince2 in an agile way. This possibility seemed too good to be true, or to miss.

In the event, the presentation to discover what they had in mind would have to wait - it was not scheduled until last thing in the day. In the meantime there were plenty of other short presentations and birds of a feather (BOF) gatherings.

Adrian Dooley of The Projects Group presented Simple Not Easy. He gave the participants two identical lists of why projects fail and asked what the difference between the two might be. Being identical, of course, there was no difference. The identified reasons for project failure from 30 years ago and those of today are unchanged.

A sobering thought in a world that has supposedly been applying structured project management techniques in an effort to make projects more successful. They dont appear to have made any difference.

Of course, this was not a scientific study, and it could be that although the reasons for failure are unchanged, the number of projects that suffer from these failings has declined.

Unfortunately, lessons to be learned from successful projects are seldom made public.

Is this another example of bias where good news is not considered interesting enough? Surely the opposite is true in a project environment reeling from mishap and missed deadlines successful projects would qualify as news on the basis that they are truly rare.

As a representative of a training company for project management tuition, Adrian was forthright in suggesting that 70 per cent of what was learned was forgotten within two weeks. Sobering!

Was this a pitch for more solid application of the core principles to reinforce them, a call to continuous training, or a recognition that there was more to successful project delivery than the application of pure method? According to Adrian, success is a combination of the right project, the right people and, only lastly, the right method.

Unfortunately, those choices are not always available to mere mortals.

Patrick Mayfield and John Edmonds work for PearceMayfield, another training consultancy, doing some innovative research to try and understand the secrets of alpha project managers.

The premise under investigation was whether or not there were techniques, captured in a mental crib sheet, that successful managers use that others could benefit from. They have commissioned some research and were giving a preview prior to presenting the full results at the end of the day.

They asked the participants to answer a set of questions. One of the questions was: At the beginning of a typical week, how much of your time is left unallocated?

There were a range of answers from the most popular none to over 20 per cent. This turned out to be an interesting metric, because if one has no free time in the week, and something unexpected arises (as it is bound to) there would be no available time to deal with the problem. This would then cause anxiety in the manager, causing them to perform at below their peak ability.

Patrick cited companies such as Toyota and Google who have a reputation for being successful and innovative as good examples of this phenomena. Apparently, at Google, 20 per cent of employees time is reserved for discretionary projects. One of the results of this approach was the creation of Google Maps, which did not arise out of corporate strategy, but rather from the enthusiasm and creativity of the employees themselves.

As contributors to the P2 re-writes it was fascinating to see the emphasis placed by PearceMayfield on soft project management skills, and team work. These are areas that the formal project management framework ignores. Their evidence suggests that the role of the effective individual cannot be ignored in an organisation that is truly committed to success, and that corporate strategy should include time for creativity that transcends the philosophy of formulaic frameworks.

The role of the Senior Responsible Owner (SRO) was a subject dear to the hearts of the attendees at the presentation made by The Home Office Centre of Excellence.

The Home Office has recognised that SROs may not know how to perform their role, and do not know how to find out without going on P2 training a course of action they are very reluctant to do.

This BOF session was unusual in that the men were considerably outnumbered by women, perhaps a sign that women are more sensitive in recognising the role of the SRO to project success.

The training programme was conceived in the civil service and draws upon lessons learned, regardless of the source, to present a stripped down series of four half day sessions that form the core of the course for SROs to understand what is expected of them.

There was a strong degree of concern expressed from the attendees that although it was definitely a good thing that the course existed, the main problem was encouraging their SROs to take part.

The civil service has solved this problem by working with HR, to include experience of project and programme management in employees career objectives as a prerequisite of career advancement.

This was a very pragmatic approach and one that could be applied equally well in the private sector, provided one is able to get HR to cooperate. Without the direct support of the most senior management in an organisation, willing to direct HR to include these objectives, it could still remain a tricky subject to bring up with a colleague who is more senior.

The good news for anyone interested in learning exactly what the responsibilities of a good SRO are, is that the course has been released by the Home Office for delivery by commercial training organisations. Encouraging SROs to play their role better is a crucial step in making P2 work better and helping projects deliver more successfully in general.

Finally, after a long day, it was time for the presentation entitled Agile Project Management Running P2 projects with DSDM Atern which was given by a representative of the DSDM consortium.

Many people were interested in this presentation, as the room was full with over a hundred attendees. The speaker started by suggesting the level of interest was very encouraging and from the feedback he had had so far the reason was the desire to know what was exactly meant by the word agile.

Agile in this context is related to a style of software engineering known as Extreme Programming (XP). Essentially XP is characterised as involving very little (or none at all) documentation, instead relying on small talented teams, excellent communication, and a willingness to work with uncertainty; it is very different from P2, to the point where it is not obvious how they can even be mentioned in the same breath. Hence, no doubt, the interest in the presentation.

DSDM Atern is the latest version of DSDM. If there is a continuum of approaches to project management, then P2 would be characterised as being predictive, Agile as emergent and DSDM would be somewhere in the middle, characterised as convergent.

The message they present is that DSDM is the acceptable face of agile, due to the fact that for many large organisations the lack of governance in pure agile methods would make them very problematic to embrace.

DSDM Atern is easy to understand, although not necessarily simple to accomplish. It has a catchy difference because with DSDM, project iterations are always on time. This is achieved by tweaking the functionality that is being delivered.

The idea is that if a project is going to fail, it will fail very early on, and the stakeholders will know that the way the project is constituted makes success unachievable.

The central premise can be understood as a kind of horse trading between customer and supplier, with respect to what is realistically going to be built that delivers real business benefit by the end of the current phase.

Caution must, of course, be taken that third party suppliers do not leave all the important (and perhaps difficult) parts out when trying to hit a deadline.

What was less clear was how the marriage of P2 and DSDM Atern was going to be accomplished. The presentation highlighted the failings of P2 in terms of it giving no prominence to the functionality set or the team composition, instead being completely centred around time, cost and quality.

The suggestion therefore was that P2 could be used for what it was good at, and DSDM Atern could do the rest.

There is a problem with that proposition, however, because DSDM Atern is capable of doing everything, which made it unclear why P2 should be involved at all, except to satisfy those organisations that have already made a big P2 investment.

A metaphor was employed of a fighter aircraft with small wings, that was very agile in the true sense of the word. Without software (the governance in this metaphor) the aircraft would fall out of the sky. This appears more an argument for the role of governance than it does specifically for the role of P2 as a configurable agile method.

One attendee, from the world of embedded software, wondered how DSDM Atern, which is billed as being an all-purpose project management framework not just for software, would work in practice. On a project to build a hospital, for example, is it realistic for the function set to be tweaked? Would the client, who has specified a three-storey building, really be satisfied if the contractor delivered a building two storeys high? Would this be acceptable to the customer against the set deadlines and the letter of the contract?

In the final analysis, maybe a formalisation of agility does not translate well out of software engineering.

In the rush to generic methods, would we not be better off with a project management framework specialised for construction, for infrastructure, for physical engineering and for software engineering? If this is going backwards, it is really just a swing back of the pendulum. It may be convenient to believe that all projects can be abstracted to find commonality. Unfortunately they may just be too different for this to be helpful on a day-to-day basis.

• Dr Peter Merrick represents PrinceLite, a combined project management and software engineering framework for IT projects http://www.princelite.co.uk Dr Merrick is speaking at the APM Project Management Conference in October