Project management methodology, how to choose

When thinking about Project Management Training or finding an Interim Project Manager or Consultant, the first decision you have to make is about the best approach for your project and the choice can seem bewildering.
In this article I will give you an overview from which to base a decision or drive further research. The following order is logically the easiest way to get a rasp of key concerns when deciding between PMP, Prince2 and Agile or iterative approaches.

What a project is
Why you might want to use fundamentally different approaches for different projects
An introduction to the main players in the project management field
Where the different approaches came from and hence the needs they address best
The skills needed for project management
Where projects sit within the organisation-
Ways to govern and monitor project activity

What a Project is

Some definitions

“A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources”

“Planned set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations.”

The key thing all the definitions have is that it is a temporary thing. Agile projects have no scope so you can no longer talk about confined scope or time, unless you exclude agile altogether from the definition, which is not an entirely foolish thought.

Why you should use different approaches depending on the Project

The important takeout form any attempt at defining a project is that given how vague the concept, it is then foolhardy in the extreme to imagine that you can take a one size methodology and expect I to fit all projects.
They are all different and understanding these key differences should always be the very first order of business.

Selecting the best approach to fit the problem or goal at hand.

There are vastly different reasons to start a project and a wide variety of environments in which projects are run. This is the first place to look when making this sort of decision.

You are a private builder and you construct buildings for your customers. Each building or development is therefore a Project and its primary goal is to turn a profit. Typically, in this scenario you appoint a Project Manager to each project and he takes responsibility for completing the job and making the target profit margin. This PM is usually a construction expert and lays a big role in technical decisions. He generally has a well -rounded training in how these things are sold , estimated and so forth. Most of us would find it fairly easy to decide on the right approach and sourcing the right person would also be fairly straightforward from a strong body of well suited candidates.
You run a large specialist Publishing and Knowledge business. You are at the cutting edge of the industry and you have to keep adapting fast to remain competitive. You take a lot of risk, but you control and manage it, only investing heavily after you proven a concept at minimal cost.
You need each project handled carefully with instinctive risk/opportunity awareness and you need the ability to learn by trial and error. Up front detailed estimates and plans with fine detail have little place in a large part of this effort, however the appearance of chaos to some observers disguises carefully managed projects that deliver gains consistently.
You run a large complex business that has a long tradition and staff who have been here forever, but nevertheless you have a constant portfolio of critical change projects as you adapt to disruptive competitors and grasp technical opportunities. Getting things done in this organisation requires political will and skillful manoeuvring. For every change, there are winners and losers not everyone is who they seem, responsibility, accountability and power to do things can be tricky to nail down as often there are simply stand-offs maintaining the peace between rival interests. These vital projects need to be handled by someone impartial to the vested interests, but sufficiently skilled and equipped to identify and engage the right people in the right way to drive key decisions and keep the show on the road.
You are in charge of the Technology Function. Your life is a tussle between pandering to the needs and sometimes whims of business leaders who show little or no sympathy for IT and attempting to avoid the spaghetti bowl of mismatched systems that eventually becomes unmanageable to the point where you need to move on. You need a way to maintain a big picture and a long-term strategy while dealing with today’s issues today.

We sometimes refer to these categories as:
Profit centres or BAU, Innovators, Business change, and Shared service

For all of these problem areas there are two viewpoints you absolutely must address:

The framework or strategy. How do we solve problems, make decisions manage WIP, report and communicate?
The skills and capabilities. What hard skills are needed to manage this, e.g Procurement, Estimation, HR, etc? What tools and other supports do we need? E.g. Documents, systems

None of the approaches answer both of these questions in fact you may struggle to fully answer one, so it is critical to be aware of what it is that you need and what these approaches have to offer if you are to start off on the right footing.

The candidates for project management approach

PMP-(PMBOK)

The Project Management Institute controls and awards the PMP. PMI is the most recognised qualification globally for project managers. It has it’s roots in the Profit centre or BAU style of project, talks about “Power” in the narrative caters for an environment where the PM exerts a lot of influence. This again would seem to emerge from the scenario where the PM is an employee and the project team report to him/her, as opposed to a Matrix where they report to someone else other than while completing a task for a specific problem.
In my personal experience I have found the long-term PM from this environment to be vulnerable outside of the BAU/Profit centre type project where strict hierarchies are enforced with power to discipline or fire someone.
The huge strengths of PMP and they are considerable, is that no other qualification teaches people the actual skills required to manage successfully. Not only does the PMP pass a very tough five hour exam, he has to demonstrate a third level education plus substantial verified experience in the workplace of applying all of the required skills. This places the PMP a long way ahead of the rest on the capability front.

Prince 2

Prince 2 has its roots in British Government. This background is noticeable in the emphasis placed on good stakeholder management and excellent reporting and communication as is critical to all political environments. The Prince 2 framework when used intelligently makes it possible to get the job done despite political uncertainty, opposing factions, lack of all-out support, doubts and all the other problems typically associated with delivering business change or getting stuff done in a political environment.
Although it can and does happen, Prince 2 will rarely be used in an environment where the PM is also the line manager of her team, but is more commonly used in Matrix environments.
Decision making is defined up front and can be different for each project, but ultimately the PM operates like a CEO with his project board making the bigger decisions in formal minuted board meetings.

The downside of Prince 2 is that it provides no skills at all and assumes that each individual has the skills necessary to do the job, a rare occurrence indeed, though not to be blamed on Prince 2, but those who implement it. It is also a real heavyweight that is equipped to handle the biggest of big projects and requires considerable experience and skill to tailor it ideally for each project.

Agile (Scrum)

Agile has been around rather longer than most recent evangelists would have you believe. It had its heyday and disappeared, then re-emerged more than a decade ago as a solution to the dynamic environment of web development. It has since become something of a religion with some and is difficult to have a sensible discussion about in many environments.

Agile emerged as a solution to the struggles to accurately define requirements, communicate them to a development team, and end up eventually giving the business customer the thing she asked for.
A. Requirements were lost in translation, further manipulated in architecture and design and along the way the customer changed her mind, sometimes honestly with a polite request or other time with a denial and a dispute.
Later the size of solution grew monolithic and the need had changed before the system could be completed and rolled out.

The new approach that addressed these problems was to form a new team with some developers sitting beside their customer and developing not by analysis and documentation, but by building prototypes and discussing, then working prototypes and gradually building up to a Minimum Viable Product, i.e the smallest version of the product that might be useful, then adding more features till somebody said stop

This worked well, especially for the web, but the addition of complication, politics and an almost religious set of ceremonies has diluted the initial power and created far too much redundancy, yet done right it still works very well for the right projects.

Agile again provides little or no skill simply a framework and is not strictly project management, but a way for software engineers to manage requirements and to build and test software. The exception is DSDM which at practitioner level provided a degree of very good management skills focused on team building and dynamics.

Many methods have been tagged on to agile such as the use of User stories which simply reinforces user requirement best practice and Kanban and other approaches, all of which are positive contributors when used intelligently by open minded people.

Iterative (MSF)

Many iterative approaches have been used very successfully. MSF is one I used a lot at one time.
The simple idea is that you develop a Vision for the project which includes how far it might eventually grow and what it might integrate with or any other impacts it might have so you are able to risk manage this and decide whether you should cater for potential future opportunities and risks.
Then you designed a Minimum Viable Product, built that in a fairly traditional manner and pulled the customer and team together to decide on what if anything to add in the next iteration. Simple, straightforward, easy to learn and follow and solves many common problems that we see other approaches misused for. Iterative is only a simple framework and it provides no skills. Iterative was developed for systems, but could be used for anything.

To recap on background and use:

PMP has a strong background in commercial projects and needs a project manager to be in control and accountable for the project. It is used very widely but is perhaps less useful for business change and needs considerable adaptation for the software world

Prince 2 is widely used much like PMP is, but is very much at home with business change and Public sector and is barely recognisable when adapted to commercial projects. In software it is useful as a wrapper to handle the overall project or a large procurement, but has little applicability close to the software engineering action.

Iterative has fallen out of fashion a little which is a shame because it is applicable in a wide range of situations and is compatible to use alongside of PMP and Prince 2.

Agile is a software engineering methodology and I would baulk at calling it Project Management, though some flavours like DSDM came closer. It is occasionally tried in other environments but doesn’t really work outside of development and struggles to scale. Agile supports the innovation cycle such as think-do-check-adapt etc.

Skills needed for project management

(Based loosely on PMP)

Project Communications

Leadership and planning

Managing Scope

Schedule Management.

Cost Management.

Quality Management.

People Management.

Risk and opportunity Management.

In Agile you still need the items marked blue but they are not so obvious and the organisation as a whole requires visibility and reporting plus some level of certainty even if it is not emanating directly form an agile project.

Start with the goal of the project. Who asked for this project and why? Who is expecting what outcome form the project? What are the constraints? Time, money, scope, etc
What are the main known risks

Based on these answers define what your constraints are paying attention to Internal and external influences

Urgency	Scope	Cost	Complexity
low	high	medium	low	Customers
low	medium	medium	medium	suppliers
			high	compliance
medium		high		Stakeholders

Write out a trade-off agreement and place this in your charter or other documentation to e agreed and signed on.

Given fixed —-Cost—- , we will choose a —Scope— and adjust —Urgency — as necessary.

Now decide whether you have a choice of capabilities in-house to serve the potential options. If you only have Prince 2 or XP then ask yourself, is it fit for purpose? Can I trust it? If the answer is yes and you have no other reason to change things adapt what you are already doing fairly well.

If you need an agile approach, but you don’t have the skills, hire a professional to come in and establish the capability. The right person will have experience of coaching and training and be able to do needs analysis with you and define the best approach.

If you have the team, but you are not happy with the skills, then speak to someone about a series of training sessions and maybe coaching to bring them up to speed. Again, good needs analysis is the right starting point.

In summary:

There are many possible approaches. The fundamental differences have been outlined above, but in every other way, most approaches will end up looking much the same once they have been adapted to your unique project circumstances. The absolute key to it is adapting and knowing what to adapt and what must remain.
For business change projects it is rarely smart to use an internal Project Manager and Prince 2 used intelligently is very useful in this circumstance.
When you need to innovate in a risk/opportunity environment then Agile works well, but avoid the religious agile types and look for common sense explanations.

Final word. We have been delivering projects of every possible type for many years all over the globe and one thing is constant, the most common cause of failures is poor sponsorship, leadership and direction so don’t expect a few Gantt charts or stand-up meetings to change anything unless you commit the organisation to doing it right and give your people confidence.