Top critical review
One person found this helpful
Peoplepieces: Is there ever an easy way to teach P2?
on 16 March 2017
I am not sure Nick Graham has fully cracked the art of simplicity with this book but then it does aim to be an accurate interpretation of a course syllabus on a subject matter notoriously 'process-tastic' that could have led to a case of confirmation bias, i.e. a left-brain methodology for left-brain types in a left brain descriptive style; but what about those who don't have the Myers Briggs judging preference gene of 'predict and control' - possibly the 'perceivers' (like me) who like to surf a project instead?
For certainly Part 1 it is all about customer/supplier structural planning at 3 levels of detail (post-initiation, stage and team), 7 event and time driven processes consisting of products, activities, and resources calling in 7 themes... and that's a lot to remember for newbies. Lest we forget we are talking about the 7 critical themes (and 7 control factors) which are:
- business case (cost & benefits)
- risk controls (risk)
- organisational roles (comms)
- quality controls (quality)
- change controls (change)
- progress controls: event/(time)
These themes are built on 7 principles - akin to an Agile manifesto - and 3 levels of decision points: the board level (directing), the PM level for project and planning skills (managing) and the Team level of work packages (deliverability). An outcome is a soft product, a changed perception versus the hard product, a deliverable.
Therefore, quite logically P2 defines the outcomes and deliverables up front, and then assigns resources and activities to build up the actuals of the products. Each process along the waterfall sequence carries a number of activities and each activity adopts a number of management (wetware) products e.g. plans, reports, records, checklists, registers, packages, logs, descriptions etc. Each management product is supported by the infamous overload of tick-box documentation. For instance, take a look at the break-down of a Product Description, a necessary part of the acceptance criteria produced during the Start Up and Initiation processes: identifier, title, purpose, description (composition), derivation, format and presentation, development skills required, quality criteria, quality tolerance, quality method, quality skills required, quality responsibilities and so on.
But wait... two of P2s Principles allow for either a certain tailoring to suit the project environment and a flexible response to learning from experience. Nick is careful to assuage the doomsayers of P2's reputation by emphasising a defter lightness of approach in trimming the tool-kit but never at the expense of resorting to "fire-fighting that can end up more time consuming than planning." Always, the baseline is making the method fit around the project not the other way around is a welcome reminder.
However as lapsed P2 Practitioner and practising Agile Practitioner this was the kind of revelation I had unfortunately cared to forget which made me question the degree P2 might loosely be defined as stream-lined without over-dilution; for it brought to mind the often paradoxical debate I have wrestled with between the two approaches - if an Agile practice is familiarly "learn to fail, or fail to learn" how does it interface with a "fail to plan, then plan to fail" P2 methodology?
The meeting point is surely somewhere in the middle, to reach a more realistic place of 'sense and respond', and Nick points out you can alter the sequence of activities by asking "is this a sensible change for this project?" i.e. is the adjustment better than the default, but never without a method, a justification, or an approval. You can overlap processes like the Initiation stage with the first stage, but slightly grudgingly lest the method be unduly stressed, only as a last resort when you need to move quickly; further for good measure you can shift activities between processes, alter the sequence of activities within a process and leave out activities in trim mode.
However P2's achilles heel is possibly it assumes it has the advantages of hindsight experience in producing excellent planning up front and this depends on having a very experienced team in place and more importantly the time and inclination given over at Board level; otherwise for all P2's noble aims a project's tactical planning tends to become wholly reliant on the experience of the stage and team levels operating as specialist products teams (internal/external). These guys become the real owners of the check lists and it is interesting to note that an Agile project backlog often works in a similar way being given the breath of life from encounters with failure from the ground up, not from the plan - go figure?
Possibly then P2 should be relabelled Pre-success Failure in Controlled Systems (prics) or Planned Product Led Projects in Controlled Customer/Supplier Structures to make Technical Deliverables using Processes and Activities through allocated Resources, but then it would be a rather difficult acronym to digest - you get the point. You chose your weapons and you takes your chances but choose wisely.