p2msp Background

p2msp is the brainchild of Laurence Kelly, founder and CEO of Structured Project Management Solutions, interviewed here by Joe Pemberton about the origins of p2msp.
 

JP:	So when did the idea for p2msp first come about?
LK:	I first started using the original Prince methodology on my  projects and programmes back in the early 1990s, using Ken Bradley's excellent book as a reference, however it was the advent of Prince2 in 1996 that saw things really start to take off. Even in those early days it was clear that you needed to be both dedicated and well-organised to make Prince work for you, and I was constantly looking for better ways to use the method.
JP:	Why dedicated?
LK:	As a working Project Manager, one of the things I found most compelling about Prince was the product based planning technique, because it addressed the single most common problem I had seen on projects beforehand - the problem of different people having different expectations and assumptions about the project's deliverables. Often those differences only came to light after a deliverable was completed, which was generally disastrous for the project - lots of rework required, maybe changes to earlier or later products, or compromises on requirements, not to mention rounds of recriminations and finger-pointing. All very costly and time-consuming, and incredibly unproductive. This common problem occurred not just with the end deliverables that the project's customer receives, but even more so with the interim deliverables that the project had to produce along the way - these were often quite difficult, challenging & stretching products that were not clearly defined and understood by all in the same way. Product based planning struck a real chord with me from day one because it recognises this key issue and sets out to resolve it, by establishing a common understanding of the important aspects of deliverables before the project starts work on producing them. The drawback of course, is the additional time required up-front in planning the project, compared to the quick alternative of producing a schedule based on 'the information available at the time'. Most project Sponsors want the work on their project to start ASAP after gaining approval, and work in their eyes means producing the end deliverables, not planning! So you needed to be dedicated, because you often found you had to fight for that additional time.
JP:	Surely there are other ways used to define deliverables, such as specifications?
LK:	Well I absolutely agree, but that's not how I see product based planning - if you try to write a fully detailed specification for every product at the planning stage, you'll never get started! The way I see it is this: many projects, especially large ones, start out as a vision of the future. That vision is the endpoint of the project, and is usually articulated in terms of how the endpoint looks and what benefits can be expected from it once we have got there. The aim of product based planning is to transform that vision into describing a bridge built across a number of stepping stones (the Product Flow Diagram) that adds up to a coherent path showing how we can get everyone and everything from today to the future without getting wet - because every project execution has to cross the "river of risk" in order to reach the endpoint vision. Each stepping stone is important - you only need to fall in once for the project to falter - so we need to demonstrate that each stepping stone is credible enough for us to commit to it : that's the purpose of the Product Description Forms. They aren't detailed specifications of the product, just answers to some basic & fundamental questions; What is its purpose? What does it consist of and look like? How will we know it's completed OK? And most importantly, can we really reach that distance from the previous product or stepping stone? (You don't want to find out you can't halfway across)
JP:	I like your 'stepping stone' analogy - can you expand on it further?
LK:	OK, well if I was giving this as a high-tech presentation it would go something like this; Slide Group 1 - The Endpoint Vision  these slides show the endpoint vision that the project sponsor is enthusiastically describing to his or her peers and superiors in the boardroom, in order to sell the idea of the project. I like to imagine this endpoint as a glittering and futuristic building complete with full-motion 3D fly-bys and walk-throughs that communicate the concept and its benefits in an enthralling and convincing way. The building represents the new company environment, whether it be a systems upgrade, new product launch, M&A - or even a relocation project to a futuristic new building! The 3D vision of the future will be presented to be as graphically realistic as an "artist's vision" can possibly be - this helps not only to clarify some of the details but also adds a feeling of realism - which subconsciously implies achievability, because if we can see it and almost touch it, then surely we can do it! This first slide group ends with a summary of the high-level estimated costs and timescales of the project, followed by a usually more powerful summary of the projected benefits (which will far outweigh the costs over time), and a quick return to the glorious 3D endpoint.
JP:	So the concept is accepted & agreed and project approval is given, and now you have a live project- -what happens next in terms of project management and your 'stepping stone' analogy?
LK:	Well, the next step is to ensure we have analysed and and have a good understanding of the journey that our project requires, so step 2 of my presentation is; Slide Group 2 - Analysing the Journey these slides show the reality of the journey that needs to be undertaken in order to achieve the project - this is what faces the Project Manager at the start of a project. I like to imagine these slides as first showing a somewhat grim and depressing picture of the reality that is today's pre-project environment - imagine a black & white portrayal of a set of decrepit old factory sheds and prefab office buildings that are loosely connected as a site, and just about manage to function as a whole in order to do business. We travel these decaying halls and corridors of failing processes with our cerebral camera (still in B&W), now & again focusing on the mundane & repetitive production line tasks and archaic hand tools, and the struggling but still-smiling faces of the unsung everyday heroes who keep this business running. At this point our glittering colourful 3D endpoint seems to be a long, long way away. Now we move outside and scan the horizon searching for the glittering future presented in Slide Group 1 - but there is no sign of it from this level. Pan left 360 degrees, still no sign. Luckily our cerebral camera allows us to take to the air and zoom up and out from our surroundings (think Google Earth), until we reach such an altitude that we can finally see both our start and endpoint in the same frame. Depending on the scope and scale of our project, we may have had to pass a couple of satellites or even planets to achieve this, but whatever the distance we can finally see it (if not then "Houston, we have a problem ...") Now that we can see both our start and end points in view, we can mentally draw a line between them. That line represents our project path and the distance & terrain that it crosses represents our "landscape of risk". Let's end this slide group with a more zoomed-in detail view of the terrain of our project path - depending on the  size and scale it may be just a few miles with one 'river of risk' to cross or it may be a few thousand miles with deserts, mountains, canyons and seas in between. It's important to get a good understanding of what the distance and terrain of a project is before even starting the project planning - this understanding may require some up-front  research and analysis for which you can find some helpful suggestions in the analysis stage of our p2msp example project which is part of the p2msp trial download. How do you build such analysis and planning of your project's journey into your overall plan? You need to map out a 'Plan-the-Planning' stage whereby you allocate time & resources to producing the elements of a product-based plan i.e. PBS / PFD / PDs. You may also need to include a 'Plan-the-Plan-the-Planning'' stage - confusing but I'll come back to this in more detail a bit later on.
JP:	OK, that was a bit long-winded. So now we have a birds-eye view of the journey required for our project, what comes next?
LK:	Apologies for that, however I think it's all important stuff. What comes next is; Slide Group 3 - Mapping the Journey. These slides how what is involved in producing a product-based plan (PBS), and how this planning approach starts to differ from producing a work-based planning structure (or WBS). This is where it gets difficult - this is where we have to map out exactly how we get from A to B or from start-point to endpoint. This is where Product Based Planning (PBP) really shows its strength. There are 3 logical steps to this PBP process, however in practice it is fair to say that these three steps are normally an iterative process which require a number of repetitions to get to a finished Product Based Plan - and even then it is not a finished plan! The three steps are; 1. Identify the products required (the Product Breakdown Structure or PBS) 2. Specify the logical sequence of production of the Products (the Product Flow Diagram or PFD) 3. Define what the products are by producing a Product Description (or PD) for each product, which provides enough detail to enable the author/producer to know exactly what is required, and also how the quality of the finished product will be measured (and accepted or rejected accordingly). I cannot emphasise enough how important it is to undertake each of these steps to the utmost, because the outputs from this work will define the entire plan for the project - if you get it wrong at this stage you will really suffer when it comes to executing the plan. So, returning to our slideshow analogy of 'Mapping the Journey' this is where we plan out our series of 'base camps' on the way to achieving our objective. Each of our 'Products' represents a 'base camp' for that particular area of the project - a definable objective that can be produced, reviewed and signed-off before we move on to the next one. It's worth noting that there is not just one single route on our project path - we need a separate route for each area of the business which leads them to the end goal. For example, if our project is a major software upgrade which introduces new levels of integration and functionality we might need a number of paths; - a path for the software development of the project, starting with an agreed requirements document and culminating in a fully tested and working software product - there may also be separate paths for the interim development and testing deliverables - a path for the end-user training requirements of the project, starting with a Training Strategy document and culminating in fully trained set of users able to operate the new application(s) - this may well include a TNA (Training Needs Analysis) and a schedule of training courses and attendees, as well as training course materials and examinations and results etc. - a path for the new hardware and infrastructure required for our project - again this might start with a hardware/infrastructure strategy document and culminate with the successful installation, testing and sign-off of the required new hardware/infrastructure. So Slide Group 3 in our multimedia journey actually consists of four logically  separate slides as follows;
JP:	Sorry to interrupt, but when I said the last answer was a bit long-winded, that was a lot shorter than this one! You said we were mapping the journey, so far I don't see how we have done that...
LK:	You are absolutely right, I do get a bit carried away in the details... Ok to put it simply The Products we define in the PBS are our mapped-out nominated 'base camps' in our journey - they describe where we will 'pitch our tents' before moving on to the next goal. The PBS is normally drawn as hierarchical diagram where each leg represents a particular area of the project - this enables one to easily assimilate the scope and completeness of the project plan.   The PFD shows how we progress in succession from one base camp to the next on towards the endpoint goal - NB there will not be one single route but rather there will be a separate route for each area of the business/project - however all the routes will meet up at various points throughout and at the end of the project. The PFD is often a cause of debate, normally based around what degree of completeness is required in product A before work can start on the subsequent product B. In reality such decisions are expressions of risk-appetite - and starting work on Product B before Product A is completed is always a degree of risk - this should be noted in the Risk Log.   The PDs describe what we expect each base camp to consist of in detail - we need to be sure that it will have not only all of the necessary sustainables, but also the necessary building materials required to reach the next base camp... And we need to get all of this understood and signed off by all the key stakeholders before we even start work on producing the Products! Now you can maybe see why Product Based Planning requires more time up-front than the traditional approach of 'just getting on with it'.
JP:	Yes thank you, I can see that!! So tell me why would I as a project sponsor agree to all this additional time and cost - let's face it, as far as I can see you don't yet even have a Gantt Chart or resource plan yet!!! I'm really losing patience now, I want you to start work on delivering my project, not all of this endless and pointless planning rubbish!!!!! You know there are plenty of other Project Managers available out there!!!!.
LK:	Wow - that is familiar stuff - well done, you really got into the role of a frustrated project sponsor there!
JP:	Actually it wasn't difficult - as far as I can see you have waffled on about the need for endless planning, but so far nothing concrete has been achieved at all. If I was a project sponsor holding the budget for this, I would seriously be recruiting your replacement right now!
LK:	And you would be right to do so. Because I have omitted the very first step I should have undertaken, which is to explain to and agree with you - the Project Sponsor - exactly how and why I want to approach the planning of this project, and to agree a plan for the work involved in producing the plan. In fact, I should probably have taken one even earlier step in order to plan out how I was going approach the planning activity and still ensure I kept all of the key stakeholders and sponsors engaged and committed throughout the planning process - this is known as the plan the planning of the plan step which I mentioned much earlier. If you fail to do this or otherwise get it wrong, you are likely to find yourself with disgruntled and unhappy sponsors and stakeholders before you have even started your project!
JP:	OK so maybe I should calm down and assume that you have explained all of this to me already, so that I am happy with the overall process and where we currently are.
LK:	Exactly so - there is a famous quote by Albert Einstein along the lines of "If I had 1 hour to save the world, I would happily spend 55 minutes thinking and 5 minutes in action", so he was definitely a believer in good planning before execution! So now we have completed Slide Group 3 - Mapping the Journey. We know exactly what products are required from our project in order to reach the end goal, and in what sequence.
JP:	So what's the next step?
LK:	The next step is; Slide Group 4 - Planning the Journey

Prince2 Distance Learning
Practitioner - Accredited Training from just £299+VAT