Methodology, What If

PME_StandardMethodology: a set of methods, rules, or ideas that are important in a science or art : a particular procedure or set of procedures1

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 Waterfallcomponents 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
Re-Blogging of this or any other post on Passion for Excellence is expressly forbidden. Copyright and Privacy Policy available in The Office.

Posted in Methodologies | Tagged , , , , , , , , , , , , | Leave a comment

Troubled Projects: First Steps

StandardImageStepping into a troubled project might be one of the most challenging undertakings a project manager can take on. This is especially true if you are brought in after the project is in trouble as the new PM or as the “fix it” adviser to the current PM. In either position you will need to walk softly in the initial stage of correction so as to not step on already bruised toes.   As with any endeavor, managing a troubled project necessitates specific actions and activities be completed in sequence.  Following a clear methodology will ensure project stakeholders, sponsors, and team members are all ultimately on the same page with you and working toward the same goals. 

 The first step should always be a Project Audit. The Audit is critical and should be thorough, pragmatic and unbiased. You will be looking for and at all the project artifacts, including the Charter, Project Management Plan (PMP), Scope Statement, Project Schedule, WBS, Risk Management Plan (RMP), Work Authorizations, Resource Planning, Schedule Management and Reporting, Progress Reporting, Status Reporting, Milestones Achievement, Scope Changes, Integrated Change Control, Quality; and in addition all of the other artifacts both formal and informal that have been collected and maintained by the project since its inception.  In my experience, Audits usually find three problems consistently:

  • Original assumptions were not fully vetted or aligned with organizational strategies at time of project authorization.
  • Project ‘rules of engagement’ have not been adhered to by all team members or leadership.
  • Leadership is not fully engaged in project sponsorship and communication of goals to all team and organizational members.

There are often many other reasons for troubled projects, these three though are generally at the top of the list.

Upon delivering your findings to project stakeholders and sponsors you will also need to provide a case for change and a plan for recovery. The rule of Project Audits should always be, never identify the problems without providing clear solutions and a path forward. Taking each of your findings you will need to address the root cause first, whether it is organizational behavior, lack of necessary resources, or improper scoping during the initial phase of the project; each issue will require additional detail to include impact on project and finally recommended solution and expected impact on project. Be clear in presenting your findings what costs are involved in implementing all of the recommendations and what benefits the organization should expect to receive. The project sponsors and stakeholders will need to take a decision at this point whether to implement all or some of your recommendations; alternatively, at this stage they may decide to terminate the project. 

Assuming that termination is not the selected option the next step in managing a troubled project will nearly always be re-planning.  The project schedule is only one piece of the Project Plan and should never be thought of as the entire plan.  The Project Management Plan performs a much broader function; it is the “how we work” rather than the “what work we will do and when we will do the work”. Since you have already performed the Audit this part of the Troubled Project Management step should be easier for you.  You will re-constitute the Project Management Plan with the project team. 

First review the Scope Statement and either confirm that it is valid with any changes that have been accepted or re-scope the project and ask for approval of the new Scope Statement from the Sponsor.  Next revise the WBS including all Activity Sequencing, Resource Sequencing, Duration Estimates, and finally the Project Schedule itself.  When this is complete compare it to the current baseline, is the revision substantially different from the baseline?  What are the differences?  What are the impacts on the Triple Constraints of Budget, Schedule, and Scope?    With this assessment in hand return to the Sponsor and request approval to proceed with the new project schedule, additional budget, and required resources. 

Re-baseline your schedule!

Finally revise your Project Management Plan to reflect new and improved project management processes for the following:  Communications, Risk Management, Issues and Action Item Management, Schedule Management, Quality Management, Conflict Management, Resource Management, Stakeholder Management, Integrated Change Control.  When the revisions are completed and the project Sponsor has accepted the changes you have one more step to take and you will be on your way. 

HOLD YOUR PROJECT KICK-OFF.  It is not business as usual until you Kick-Off the project with the new project processes, procedures, standards, and expectations in place.  It is likely that you have new members on your team. It is also likely that moral on the project has been less than ideal while you have been going through this transition.  The Kick-Off will give you the opportunity to revitalize the team and introduce them to the new and improved approach.  The sponsor should be there to communicate commitment.  This meeting should be upbeat and positive.  Your job from here forward is to manage the project under the new terms of engagement; no recriminations for past mistakes and no looking back.  You are going forward.

The idea is that it’s nearly impossible to “recover” a troubled project if you continue to do what has been done before.  If the project is truly troubled, you must get to the root cause of the problem and correct it.

Not all project will require a full restart, your audit will guide you to the right answer. Whether a full restart or a gentler course correction, the Project Audit is always the first step. Gaining an understanding of where the problems exist and addressing them specifically put projects back on track.

Posted in Troubled Projects | Tagged , , , , | 2 Comments