14.05.08
Getting to grips with GRIP
Martin Bishop gets to grip with GRIP, the Guide to Railway Investment Projects which describes how Network Rail manages and controls projects that enhance or renew the national rail network
I think it is true to say that whereas most people understand in general terms what GRIP is very few have actually read it. Perhaps that’s not too surprising since GRIP consists of some seven manuals and 47 documents, in all some 1750 pages. I confess at first blush to have been somewhat bewildered by the sheer volume of documentation. It is perhaps also therefore not entirely surprising that whereas most senior managers purport to be delivering projects in accordance with GRIP, it is, to quote Hamlet, more honour’d in the breach than in the observance. How do I know?
Project management is nothing new, no matter what people might tell one. Don’t tell me that when the Great Pyramids of Giza or the Coliseum in Rome were built that they didn’t have a scope of works, outline proposals, a detailed design, a work breakdown structure etc. More recently, over the past twenty or thirty years, there have been many attempts to codify what is, at the end of the day, an innate common sense process to dealing with major projects. GRIP is no exception in that within GRIP, like many similar processes, projects must pass through a series of mandatory stage gates, and for each stage gate a number of integrated products must be prepared.
Although GRIP talks of GRIP products, I have observed that there is some confusion as to exactly what a GRIP product is. The manuals are in fact made up of delivery processes, reporting regimes and GRIP products. It is through the delivery processes and reporting regimes that the projects are controlled. The products demonstrate that the processes have been followed.
The products fall into two groups:
• Generic
• Technological
The generic products apply to all projects whilst the technological products selected and applied will depend on the nature of the project.
It seems to me therefore that in order to manage a programme (or linked series of programmes) in accordance with GRIP the process must be as follows:
1. Define the programmes
2. Within each programme, define the projects
3. For each project define the stage gates
4. For each project stage gate define the products
This then looks something like the above diagram.
The next steps are to:
5. Create an integrated high-level programme for the programme for each project subdivided into stage gates
6. Create a sub-programme for each stage gate showing the delivery of each product
Naturally many of the projects and stage gates must be linked with dependencies and this should result in an overall critical path for the programme. This would be a simple high level tool against which progress could be reported at the highest level. Again within each stage gate there will be linkages between the products, and a critical path will emerge for each stage gate which will be linked to the high level programme.
By definition the programme will then be delivered through GRIP and will be manageable at high level.
Only those involved with the major rail projects will know whether such programme exists. Personally I’ve not seen one. Indeed I sense that there is a conceptual conflict as to how GRIP should be applied at programme level. I have been shown programmes which purport to be prepared in accordance with GRIP which show the gates but the products are simply not identified. To me it is difficult to demonstrate how any major project could be delivered within GRIP without such an approach.
What is needed, and I think missing from GRIP, is a simple procedure which would encapsulate this process. This would not need to be more than two or three pages but I believe would give a clear guide as to what is expected and enable any third party of approving body to satisfy themselves that the programme was being delivered through GRIP.
Finally, for my money I find it difficult to see without such a clear approach how any major programme could result in a satisfactory gateway review, but that’s quite another matter altogether.
Tell us what you think – have your say below, or email us directly at [email protected]