Using the Right Amount of Project Management Discpline for Your Project
I am asked this question frequently: "How much Project Management process should I place on the [insert project name] Project?".
Most PM's and Executives struggle with this question because it seems as if a rigid and thick process can kill smaller projects and at the same time a very lightweight and agile process may not be enough to guide a complex project to success.
So, how much process is enough for any given project? It seems impossible to answer this question without knowing the depth and scope of a project but there is a short and sweet answer to this question that, if considered when pondering any Project Management process, will guide your mind and heart in the right direction.
The Answer"Just Enough to Make the Project Successful"
I realize this answer seems like an evasive maneuver to a complex question but there isn't necessarily a heuristic or rule of thumb to answer this question. When considering the answer you must consider several factors:1) The size and scope of the project
2) The amount of inherent risk associated with the project3) The methodology by which execution of the project will be undertaken
4) Other softer attributes that may be specific to your company or the project itself
Size and Scope of a ProjectGenerally speaking, the greater the size and scope of a project, the more discipline(s) necessary to continue to drive successful delivery.
This is not necessarily always true, but generally speaking, one would exercise more discipline in higher risk situations and larger projects can tend to be higher risk situations. They require more people, more money, longer timeframes, more departments, and can be higher visibility, than smaller projects. All of these elements introduce higher levels of risk which, in turn, must be managed diligently.The Amount of Inherent Risk Associated With the Project
I wrote a great deal about risk in the earlier paragraph so I won't go into it again here. I will say though, that larger projects generally require greater attention to risk management than smaller projects. It is true that you could have a very high risk project of smaller scope or duration, but smaller projects won't necessarily get the same risk planning and mitigation treatment as larger projects. Think about it; are you going to spend as much time in mitigating risk on a project as you would on the entire project? Probably not.The Methodology by Which Execution of the Project Will be Undertaken
When I write this, I am speaking specifically to Software Engineering projects. What I mean is this: If you, the Project Manager, have enough understanding of how the product or service will be delivered by development staff, then you may choose to make certain important decisions about which Project Assets are most valuable.For example, say you are involved in a Software Engineering project and you find out that the development team will be using an agile methodology such as XP or SCRUM to develop the software. You know that the tenets of agile software development are fast turnaround, constant requirements and technical discovery, and frequent test and release intervals.
Knowing that there are elements of "constant requirements and technical discovery" you may choose to use a thick and more rigid Change Control process to ensure timely delivery.I am sure that you can think of many more examples.
Other Softer Attributes That May be Specific to Your Company or the Project ItselfThis pretty much covers all other aspects of the project such as corporate culture, project intricacies, product cycles, politics, and any other factors that may play a role in how you drive execution.
It is safe to say that you will need to customize a list of project governance assets for almost every company you are part of.Using Dollar Amounts to Guide Your Project
Some companies set thresholds on how much governance or structure one must place around any given project. They generally do so by dollar amount and set a threshold so that any project over $X million gets XX Project Management disciplines.I recommend against this though and here's why: The amount of money you must spend in order to complete a project is simply not a measure in itself of how much structure the project will require. You must take into consideration a multitude of factors when making this decision and money is only one of those factors.
In ClosingI feel that an agile set of baseline assets and practices for ALL projects is the best approach. Meaning this: draft up a few "must have" assets and activities that must be undertaken for all projects and then build on top of those for larger or more complex projects.
For example, you may choose to always require a Project Charter, Risk Assessment, and Change Management process, but may only employ a full Project Review on certain projects. You will also choose to undertake the baseline set of assets and activities to differing degrees depending on the size of the project as well. There will always be a Project Charter but it will not always be multi-page. Sometimes, it will only be a half-page depending on the project.I think you get the idea. We are here for project success, not simply to provide a process which project team members must follow. At the end of the day, it is a bout the product or service delivery, NOT about the process and it is always important to ask yourself if you're helping the project along or potentially hurting it with thicker processes.
Jason Becker, PMP, CPM