In the United States, the Project Management Institute (PMI) is the methodology most frequently referenced in project management today. It is important to note however, globally there are many other methodologies of equal validity, when working with software and technology. Truthfully, the processes and standards found in the PMBOK© (Project Management Body of Knowledge) are not a methodology. In fact, the PMBOK© does not say it is a methodology rather it says it is a framework it also says the following:
· It is the sum of knowledge within the profession of project management.
· Identifies the subset of Project Management Body of Knowledge that is generally recognized as good practice.
· Describes knowledge unique to the project management field that overlaps other management disciplines.
So what is the difference between a Framework and a Methodology? Good question and one I will attempt to answer.
Answer: Nothing really except how we apply the rules and what we call them.
I once had a client with a PMO based entirely on the PMBOK, they asked me to help them determine why their projects consistently failed to deliver ‘on-time, on-budget and within quality guidelines’. The audit followed their PMBOK based homegrown methodology for the first week and my status report was delivered based on their structured methods. I did not meet the sponsors’ expectation; fortunately, I had also prepared a report based on my audit methodology, which also followed PMBOK just not quite so rigidly.
What was the difference between these two reports? Primarily, the relevance of the information was tailored toward the project and the audience. The outcome of the audit led to the identification of activities the PMO had adopted as ‘required’ for every project, no matter the size, complexity or content. Project managers and teams were spending significant time doing tasks and producing work products not relevant to their projects to satisfy ‘methodology’. The inflexibility had produced barriers thus defeating its original and primary purpose.
What the PMO needed was to clarify its purpose, define a Charter and from there set about establishing real standards with a library of tools, customizable work-products and project strategies that covered the entire portfolio. This client had a portfolio that included IT, business re-engineering, construction, as well as, Merger and Acquisition activities; one size did not fit all when it came to projects. The PMBOK was a valuable framework, but they needed more in their toolbox.
In part, the PMO needed to provide project management solutions and an executive dashboard for reporting. What made sense for projects, what types of methods and standards could or should be applied to provide the best opportunity for success? Taking the PMBOK framework, the common standards of what must be done during the project life-cycle and agreeing with the project sponsors’ the core requirements, outputs and deliverables it is then possible to determine the best methods to achieve success might be. With the right tools available, including trained resources the possibilities are far broader than one might expect.
Is your organization taking on a new ERP solution? If the answer is yes, you will be bombarded with organizations that have expertise with the software, with the software vendors’ implementation methodology and with their own ‘improved’ methodology. Just a hint, most of these are based on PMBOK with a nodding familiarity to Waterfall development methods. Rarely are they complete and generally they will leave large components out.
Are you taking on process re-engineering? Many organizations have done so with mixed results. Six Sigma is the favorite of organizations doing large or small process re-engineering projects, my personal experience with this methodology is unless you are working with machinery and widgets, it is difficult to implement identified improvements.
Got custom development projects? How about large Testing or Data Conversion phases within ERP Projects? Now is the time to bring in your Agile experts. These are the perfect environments for Agile methods, they work well and your project will benefit from the sharp focus.
These are just a few examples of how different common methodologies can be used within a single PMO and even within a single project. This isn’t to say PMBOK shouldn’t be used as starting baseline, why would we throw the baby out with the bathwater. It is simply to say when we look at our projects we should be looking at the requirements, the complexity and the outcomes expected. We should design our PMO with a core of expected deliverables and tollgates, with the flexibility to expand and contract based on project type and content. Whether we are conducting the project or we contract the project to outside vendors, we should always require our core deliverables be consistent thus, we build up our library of lessons learned and over time, we are able to replicate our successes and avoid our past mistakes.
(c) Linda Valentine-Dean 2012