Using the terms goals, deliverables, objectives, targets and KPIs interchangeably, misses out on the value each word brings.
In my last post, I gave a list of transformation project success factors.
It wasn’t a comprehensive list of project management tools, nor did it advocate a specific project framework.
Most Project Managers won’t get to choose the framework they use. Their employers and clients have encompassed a methodology and made it their own. Pulling together the continuing professional development of a good PM with the need to pick up and run with organisational project processes, we can see that a key attribute of a Project Manager is the ability to adapt to the circumstances of the project. Not so much their background or their framework qualifications.
Whether you are well versed in Agile, Prince 2 or the APM Body of Knowledge, you will have recognised the elements. Let’s take the project definition, called a business case in “No mop-ups in here – why planning to mop-up compromises your transformation”, and see how each of the frameworks creates its project definition:
|Uses the Charter and Product Data Sheet||Uses the Project Initiation Document (PID)||Uses the Business Case|
Agile has less content at this stage, mainly because the Speculate stage of the first sprint will work out the timeframes and costs for the overall project.
In all honesty, do you think there is much difference between the frameworks? I would suggest not. Further, a good project manager picks up and uses techniques as she works with other PMs or in new organisations. These techniques form a toolkit to be drawn upon as required – not to be used by rote.
A project framework is no more than a checklist – it’s the way you approach your project that counts.