Establishing a PMO using the agile approach - feasible?

Last week I was over in Dublin for three days for the PMI Global Congress EMEA; one presentation certainly took my eye “Establishing a Project Management Office (PMO) Using the Agile Approach” from three speakers based out of Saudi Arabia. To be clear, the presentation was to cover the establishment of a PMO using Agile – not running a PMO using Agile. The presentation was also carried out by “PMO Consultants” – those hired in by an organisation to establish a PMO and then leave when implementation is complete.

The establishment of a PMO was initially defined as ” a logical movement to support widespread knowledge and practices of project management” and the speakers – Alsadeq, Akel and Hamamo felt that establishing PMOs as a”regular and repeated project” would be the equivalent of wadding about in concrete boots.

So what was their proposed alternative?

Clients’ differences, project management best practices update, new project management systems, and the interactions between these factors, make the establishment of each PMO  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.

The traditional approach to establishing a PMO (in the Middle East) normally starts with a documenting of the current status, then work moves on to understand what the desired state would be (what will the PMO do when established). There would be a gap analysis performed and then finally a plan to reach the desired state. All pretty straightforward and logical you might think. The issues start when the delivery of the first stage – documenting of the current state – appears two months later when actually the expectations of the business are that you’ve been doing something of worth,  starting to deliver value ASAP, rather than producing pretty pictures and documents. At the end of the day, all that has been delivered at this stage is a current status report.

The need for a new approach was specifically driven by some experiences from the speakers, the first; the issue of there not being enough information available at the start-up of establishing a PMO. The documenting of the current status (AS-IS) was flawed through inaccurate data and personal views of key players. The second; that PMO is still a relatively new concept that organisations still believe is the Holy Grail and that much can be delivered from a PMO that will solve all the organisation’s ills – false expectations?. The final point; recognising that the PMO is a change management tool because “it helps organizations in launching, managing, and linking initiatives that lead to change” and because change is a “live process” here is the argument that establishing a PMO should be done using a “non-fixed” approach.

So the “non-fixed” approach leads us to the Agile approach. So how can a non-fixed establishment of a PMO work and not be reduced to chaos?

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.

I can’t help thinking that the steps proposed may be different if an external consultant was not establishing the PMO but rather a permanent employee brought in to create and manage the PMO and I would be interested in any thoughts from current practitioners from both these viewpoints.

The aim of using an agile approach is to essentially ensure quick wins can be delivered; allow greater degrees of flexibility in the set up process; gain faster buy-in to the PMO (assumption based on quick wins) and interestingly the belief that it is a “business driven PMO” that is created in the end. Why business driven?

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.

A valid point I think; especially when it is easy to get bogged down in process, standards,  methods, tools, techniques and a whole host of other deliverables which the senior managers are interested in but ultimately not as much as bottom line results. In other words the PMO has to be created for the business and ultimately the formation of the PMO has to be driven by the organisation’s needs and expectations. The question remains of course, is an Agile approach the answer because the final part of the presentation in Dublin fell flat for me when the presenters revealed that they had not yet seen if this approach does actually deliver a successful PMO; it’s still work in progress or should that be an iteration?