Project Management

….. to misquote Hamlet.

Having stated that I deliver projects on time, I was sure to become the butt of some well judged jokes when I was late to a meeting yesterday when a number of small delays in combination meant that I was 15 minutes late in total.

The learning from the situation (apart from one or two choice funnies that I’d prefer not to repeat in public) is that DSDM’s key techniques can be applied almost anywhere. In my morning timebox, before I left for the meeting, I tried to cram too much in. I had not defined and prioritised all the requirements correctly; filling the car with petrol was a “must have” that I had not taken into account. Also, while “having lunch” was a “must have”, a sandwich from the petrol station would have met the requirement better than “gold-plating” it by sitting down for bread and soup at home.

…£2bn cost of government’s IT blunders is a new report in the Guardian this weekend. It niggled me a bit that they had detailed this list of massive failures but had done no analysis of why this was.

What struck me is that I expect that one of the common denominators is that all of these projects were managed using the PRINCE 2 project management methodology, it is impossible to do any IT project in the public sector without it. Now I am not saying that this is why these projects failed, I don’t have access to enough information to say, but it is a common factor and so should be analysed.

The other likely common factor, linked to both PRINCE 2 and the typical government approach to procurement is the practice of Big Requirements Up Front. This is where the users sit down and decide what they want the system to do in detail, partly so that external contractors can pitch for the development contract and their bids “objectively” compared for “best value”.

This is likely to be the 3rd common factor, use of external contractors, competitive tendering, the perception of transfer of risk and confrontational legal agreements. The problem is that risk is not transferred in reality; when was a government contractor last successfully sued for a failed project?

As Scott Ambler points out in the article in the link above, the whole BRUF approach has been proved to be flawed for a number of reasons

1. The requirements change because the business changes. This is inevitable and as true in government (average tenure of a minister?) as in the private sector.
2. People’s understanding of the requirements change. In reality most end users can only adopt the “I’ll know it when I see it” approach as they don’t know what technology can do and people just change their minds
3. People make up requirements. If they are only being given one chance to specify what they want before it is tendered, they will put in stuff “just in case”. This is a particular problem in the public sector as IT suppliers to government are notorious for charging through the nose for changes in requirements (bid low, make margin on the inevitable changes)

There is a different way. Use a project management approach called DSDM and change they way you procure IT systems. Don’t specify the project in detail up front, just do enough to provide a sensible budgetary estimate and procure developer time rather than a finished system. This does mean a different approach to risk management but as the Guardian’s list of failure shows the current approach does not work!

Kubernetes case study on the National Packaging Waste Database project has now been published!

NPWD Case Study

We’d like to thanks John Turner and Phil Conran, from the Advisory Committee on Packaging, and Keith Stonell and Steve Watkins, from The Environment Agency, for their permission to publish this case study.

… a case study of the delivery of the National Packaging Waste Database at Unicom’s Agile Approaches for Delivering Business Value conference in London on 18th February 2008.

We are delighted that Steve Watkins, Head of the Project Office at the Environment Agency, has agreed to present with Jeremy at the conference.

Working through some navigation exercises and came across this diagram from the RYA Yachtmasters course guide

What the manual says is that the errors associated with trying to measure your position (without GPS) accumulate exponentially. In navigation this becomes critical as you try to avoid hazards during a passage.

It struck me as a useful analogy for any planning activity, specifically project planning for IT systems. I challenge anyone to be able to see exactly the “course” of an project at the beginning. Even in the middle and sometimes right at the end something will happen to throw you “off-course”, but at least in these circumstances you know about it.

The real issue is the “Zone of Uncertainty” were little delays here or errors there add up exponentially to make a significant delay or project creep.

This is where DSDM as a project management methodology is both theoretically correct and common sense. DSDM’s primary technique is the application of rigid timeboxes of between 2 and 6 weeks in which the project team decides what are the deliverables. The project review and lessons learnt sessions at the end of each timebox act as “GPS” positioning for the project so that one knows what course the project is on and whether it is heading too close to a “hazard”.

Just a thought; if you are running a project without the discipline of timeboxes how can you be sure that you are not about to “hit the rocks”?