Establishing a project management office (PMO) using the agile approach
PMO consultants have been trying different approaches to establishing the right PMO for organizations. Based on real experiences in the Middle East and North Africa (MENA) region, we think that using the main concepts of agile could be the right approach to coming up with an effective PMO.
This paper discusses: (1) the nature of the PMO as the first project management supporter, (2) the characteristics of most organizations looking for a PMO, and (3) the agile way of thinking and how all these factors can interact during the PMO establishment phase.
Although we believe running PMOs should adapt agile as well, this paper focuses only on the establishment processes, given that the establishment method introduces and facilitates the right platform for future operation.
Over the past years, establishing PMOs has become a logical movement to support the widespread knowledge and practices of project management. Different consulting firms have established new teams and departments just to tackle this mission: some establishing PMOs, others started to offer running/support running organizations’ PMO.
From our experience in establishing and running PMOs for both governmental and private sectors, we have come to the conclusion that if we consider establishing a PMO as a regular and repeated project, we will be using a Formula One car to drive through the desert.
Clients’ differences, project management best practices update, new project management systems, and the interactions between these factors, make the establishment of each PMO as a unique project that should be tackled in a special way, much like developing a new software program to address the specific requirements for each client.
If the agile software development is a group of software development methodologies based on iterative and incremental development, in which requirements and solutions evolve through collaboration between self-organizing, and cross-functional teams, using the same approach for PMO establishment would solve many of the problems we face and save the time and effort of consultants.
PMO: Models and Functions
Project Management Supporter
A project management office (PMO) is an organizational body or entity assigned various responsibilities related to the centralized and coordinated management of those projects under its domain. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of a project (A Guide to the Project Management Body of Knowledge [PMBOK® Guide]—Fourth edition). Although this definition and others mentioned in different books and papers have described the variety of PMO roles, still they all share the core role of supporting project management in the organization regardless of the level of support.
There are many PMO models on the market; one of the most common is the Official Field Guide to the program management office developed by the executive leadership group, INC, in which six PMO models were described as follows: (Casey & Peck, 2001 p.48 )
Weather Station PMO
1) Provides executives with credible and useful project progress information
2) Frees project managers from the “curse” of spending more time reporting on projects than managing them
3) Acts as management’s “ear to the ground”
Control Tower PMO
- Create consistency in the practice of project management and predictability in its results
Resource Pool PMO
- Provide top-notch selection, development, and retention of project managers
Portfolio Manager PMO
- Help resolve the perennial project selection problem that the organization’s needs seem infinite, while its financial resources and talent are annoyingly finite
Benefits Verifier PMO
- Determine whether the promises made in business cases have actually been kept
- Ensure that a program (i.e., a business initiative composed of two or more projects) delivers its promised benefit.
The Top Ten Most Important PMO Functions
The top ten most important PMO functions (Hobbs & Aubrey, 2010, p 40) are:
- Report project status to upper management
- Develop and implement a standard methodology
- Monitor and control project performance
- Develop competency of personnel, including training
- Implement and operate a project information system
- Provide advice to upper management
- Coordinate between projects
- Develop and maintain a project scoreboard
- Promote project management within the organization
- Monitor and control performance of PMO
The role of a PMO remains one of the project management supporter; models and/or functions interpret the level of support, the model is only a way to group number of functions and no more.
Establishing the PMO Dilemma
A Real Need or a Trend?
Some organizations perceive PMO as the answer to all problems; others say that if it is being spread then it is good. Some people view it as a new trend, so why not have one because other departments and/or sister companies have established one.
During the regular establishment of a PMO, when we start talking about organizational structure and cultural changes, most of our clients start to re-think about things and ask themselves: “I thought it would be easier. Why are those consultants complicating things this way?” This is when conflict starts to appear, the client wants a PMO the way he or she likes it, not necessarily the way he or she needs it.
PMO practitioners (whether the internal team or external consultants) usually use the same approach for establishing a PMO: defining the current status, the desired one, performing a gap analysis, then, a transitional plan can be developed and later executed.
The first deliverable a client usually gets after two months or more is the current status report. “That is great; these are really my problems stated in a nice report and illustrated in graphical charts... So, what? This is nothing new.” This is what the client is usually thinking and sometimes says.
Another discussion starts when consultants start speaking about the desired status and the necessary prerequisites, which usually includes organizational structure changes, personal competencies development, and so forth. “Is this going to bring me new problems or will it solve my current ones?”(This is the client talking about the new PMO.) On the other hand, the consultation teams feel they are late, the client doesn’t want to approve the is deliverables so they can’t get paid, and management demanding they finish it by any means. The end result is either unapproved deliverables or a PMO that satisfies the client’s imagination and sense of what is in fashion at the moment.
The Need for a New Approach
Over the years, we have come to realize that there is a need to find a different way to tackle this issue, a way that helps clients to see some real value from the beginning and put their team in a high buy-in mode to support the establishment project. In the Middle East, the main drivers for this need are as follows:
People in our area of the world look at the consulting business as a luxury, a not needed but nice to have service. Generally, they look at consultants in one of two ways: either as an oracle with a solution for everything or a liar wearing an expensive suit. In both cases, consultants are forced to demonstrate their value and credibility from the very early stage of a project.
Lack of Enough Information at Start-up
When using the traditional way, consultants will start documenting the current status (“as is”) by interviewing the client’s employees, without any interference from the actual work. While moving into the second phase, they will start finding out that much of the information was not accurate and given only to make the picture look prettier.
The PMO is a New Concept for Clients
Many clients ask for PMO establishment because they have heard about it and believe it might help them. Even some organizations with project management practices and qualified project managers look at the PMO in a very basic way and rarely differentiate the traditional projects department from a PMO.
The PMO is a Change Management Tool
By its nature, the PMO is a very powerful change management tool because it helps organizations in launching, managing, and linking initiatives that lead to change. By looking at change as a live process that requires close monitoring and periodical revision and modification, we realize the importance of using a non-fixed approach in setting up the PMO.
Establishing a PMO Using the Agile Approach
Generally, assuming that any organization’s team is ready and willing to accept all the changes that a PMO would bring is not a correct assumption. Organizational change projects, such as PMO implementations, are not easily achieved and need a high level of flexibility and ability to adjust quickly.
The agile approach requires minimal planning, maximum collaboration, and provides the ultimate benefits. We need to analyze, while working in parallel, moving one step at a time, and being able to smoothly change directions.
1) Start with end solution orientation: Start with the final solution prototype to get a good impression from the client and to ensure the directions will go through.
2) Skip some steps: Skip the sophisticated analysis and reports and don’t seek approvals for every step. The client will give the approval when the benefits are realized.
3) Empower people first: Start with ongoing training and mentoring for all teams from day one, and as you go along, and make sure to set up a PMO process help desk.
4) Expose the environment: Form mixed teams (from your side and the client’s side) and start working; be very transparent with everyone to ensure you receive the same level of transparency in return, and conduct regular face-to-face meetings.
5) Apply and change as you go:
a) Changes are welcomed throughout the project, according to continued evaluation, and plans will be done through continuous iterations and will be client-driven by focusing on benefits.
b) Develop a simple project management process and apply it; evaluate and move on to the next step
c) Evaluate the progress after each iteration (based on time, not requirement)
6) Client involvement:
a) Make sure the client is involved in selecting the steps based on priority and added value. This will help to provide full support of the client’s team.
b) Client will be committed to providing feedback after each step.
Establishing a PMO is a challenging task—actually it is a perfect change management example, and every project is a new story. Over time, we have created our establishment approaches as well as discovered and/or developed new concepts and terminologies. Following are some new terminologies in this regard:
The “As to Be” Report
Consultation usually goes through three stages: capturing and documenting the current status in what is called the “as is” report, the second stage is developing the “to be” report, in which the desired status is indicated, and the third stage is performing a gap analysis between both reports to come up with an action plan.
In most of our consultation projects, discussing the “as is” report always took too long, especially if we were straight forward while the client’s project management maturity level was low.. The client keeps discussing and changing the report to what he wishes it could be, and this long discussion and delay of approval move a part of what is to be in the future into the current status. At the end, and for the sake of moving on to the next step, we get a new report in between the current status and the desired one, and we started calling it the “as to be” report.
A milestone is a significant point or event in the project (PMBOK® Guide—Fourth edition)—thinking agile in establishing a PMO should change the meaning of significant points, because we move based on time not requirement.
People generally avoid signing papers, especially those that state things are being done incorrectly; this is one of the many reasons why clients don’t help in reaching milestones. Consultants should be thinking of something shorter than a mile. We should be thinking of iteration deliverables, and in terms of a “Footstone” rather than a “milestone.”
Because clients are always late and in a rush, it is essential to show some results as “quick wins” that help the PMO sponsor show some progress to his or her managers. This can be achieved with the agile approach, because selecting and prioritizing steps are done in full coordination with the client.
While putting the methodology and process manual into the implementation phase, this is where issues start to evolve, depending on the complexity of the work and maturity of the stakeholders. The agile approach helps consultants to find out about these issues at an early stage and modify their way of implementation accordingly.
When the client’s team is involved in all the steps and planning is being done on short deliverables with quick wins in mind, the buy-in of the PMO concept becomes much faster and consultants enjoy a high level of cooperation.
We normally choose the PMO model based on the picture we have about the business after studying the current status, but problem start to appear when details come. As you progress you find out more about the business-related details that are not covered in the PMO setup. Developing the PMO methodology using the agile approach helps in tailoring the PMO to suit the business’ exact needs.
Train by Practice
Using a new methodology is a painful process. The agile approach helps practitioners to get trained on new methodology, while the consultants are still available to support them and provide coaching.
Challenges and Suggestions
Most of the time, establishing a PMO is a deliverable based contract; in other words, it is a fixed price type, which is why consultants go on several visits to the client trying to discover the expected effort amount and required time. It is clear that in this contract type, all the risk goes onto the consultant’s side, whether a deliverable took six months instead of two, or for whatever other reason.
We recommend a time and material contract when establishing a PMO; if not the whole contract, then try to prepare a partial one, which will encourage everyone to work toward project success. Another important point: don’t assign a permanent consultant (or consultants) to a client’s site—keep him or her as a consultant, not a regular employee unless your contract includes a full-time position.
For sure there is a negative side to scope creep; for example, delivering the extras, which translates into extra cost without return as well as exceeding a milestone deadline could result in a bad reputation, while there is a positive side to encourage scope creep: we –as professionals- will never add un-useful extra tasks, meanwhile we as consultants working on time and material contract, we can encourage adding more to the original scope.
Set an Example
As a project management consultant, you should be setting an example of how to manage projects; for different reasons, stakeholders need to know the status of this consultation project, so upload your plan online, using a system similar to the one you will be using to implement the PMO.
Agile software development: http://en.wikipedia.org/wiki/Agile_software_development
Casey, W & Peck, W. (2001, February) Choosing the right PMO setup PM network 15(2) 40-47
Hobbs B., & Aubry M. (2010). The project management office (PMO): A quest for understanding. Newtown Square, PA, USA: Project Management Institute
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide— Fourth edition. Newtown Square, PA: Author.
© 2011, Imad Alsadeq, Mahmoud Akel, and Nagy Hamamo.
Originally published as a part of 2011 PMI Global Congress Proceedings – Dublin, Ireland