The Agile Enterprise PMO – Part 1 – Principles of organisational control

Agile software development is here to stay and has quite a dramatic impact on the “traditional Enterprise PMO”, the department that was originally set-up to bring order into the chaos of projects and software development.

In a series of blog posts, I will explain firstly the principles of three organisational control mechanisms: the market-, bureaucratic and “clan-based” control system. Depending on the scenario some work better than others and sometimes only the clan-based system achieves the desired control (hint: this is about Agile).

The Enterprise PMO needs to understand if a particular control system works in a given scenario. I will then give some ideas how the PMO can gather evidence via metrics and KPIs to what extent the outcome of Agile principles can be evidenced to become acceptable as control mechanism.

Finally, I will explain how the PMO can transform itself by adopting agile concepts to stay relevant in the long run.

Overview

Part 1 – Principles of organisational control

Part 2 – Agile transformation is a process, not an end-state

Design of Organizational Control Mechanisms

The Market, the Bureaucracy, the Clan

Before I start with the more practical aspects of control in Agile software development, I would like to introduce some theory behind Organizational Control mechanisms that was originally published in a series of papers by Prof. William G. Ouchi starting in 1979  and has often been cited in works about the theory of Agile software development. I will apply these concepts to the requirements of an Enterprise PMO and Project Portfolio Management.

Ouchi outlines three principal control mechanisms that can be employed to achieve control in an organisation.

The market system

In the context of PPM, the market system can be used as a control mechanism if the project outcomes or benefits can be linked easily to the market environment of the organisation. A project that delivers new products can be controlled by observing the revenues created by these products. If we can measure client satisfaction reliably and relate this back to project deliverables then this gives us external benchmarks of our project outcomes. To solely rely on market control however, we either need short projects (so we can wait until their end to verify the outcome) or the ability to observe progress of the outcome during the project delivery phase. 

The bureaucratic system

This is often at the heart of many PMOs: there are rules how to submit, plan, budget, manage and close projects; how to deal with risks and issues and how to escalate them. At approval or toll-gates and sometimes during execution there are checks for compliance; and the degree of compliance is seen as the factor of success of the project. How the agile practitioners view this kind of PMO is neatly summarised in “The Agile PMO – Smile, it’s the Process Police”

Bureaucratic systems work best when there is a good understanding of the “transformation process”, i.e. there is enough expertise with the project type and evidence that following a prescribed process improves the chances of success or at greatly diminish the likelihood of failure.

A well-researched bureaucratic control system is used in commercial air traffic. Pilots have to go through pre-flight checklists to ensure proper procedures are followed and this has greatly increased aviation safety (and by the way: pilots are being checked regularity that they have completed the checklists).

Frameworks like PMI or Prince2 have helped to improve project success, however only when applied to suitable project types, adapted to the respective environment and within appropriate governance structures (Joslin & Müller, 2014).

Limited understanding of achieving success

Sometimes there is limited understanding how success can be achieved. Ouchi uses the example of the buyer in a women’s boutique as example when following rules cannot guarantee to be successful. Whilst success of the decisions of the buyer can be clearly measured using market control (sales, required reductions, items that are left unsold etc.) it is impossible to prescribe via rules how to be a good fashion buyer, so a bureaucratic control system would not work. It would only create overhead and be intrusive without delivering the form of control that is expected.

The clan system

The “clan system” is based on informal value-based rules that allow innovation and collaboration. Individuals work well together and do the right thing because they share the same values, methods, beliefs. It requires individuals who have completed lengthy periods of socialization to share the values of the clan. Ouchi also explains that clans “cannot cope with heterogeneity nor with turnover”.

The clan correlates with the values and principles of the Manifesto for Agile Software Development, in particular value #1 – “we value individuals and interactions over processes and tools”.

In Ouchi’s last example: a research and development centre, he explains that neither market nor bureaucratic control systems work: several years might have gone by before any research result becomes marketable and following strict rules will not ensure you make new discoveries. You are left with clan control as the only option.

So, only clan control then?

A critique of Ouchi’s model was that he did not argue for a combination of different control forms (see Organizational control and project performance. Paper presented at PMI® Research Conference). So instead of using exclusively one control method over the other I will also recommend combinations if they bring control: if we can link our projects to outcomes – we should do so! This will give us the evidence that they bring us forward. If we care how our projects are delivered, then we should ensure that there is a common understanding of values. If following good governance is a predictor of success then we should ensure it is being followed!

Use cases for control methods

Ouchi has drawn use cases by two dimensions

1. Can I measure the outcome?
2. How well do I understand the transformation process?

The chart above shows possible control mechanisms depending on the combination of these two factors with some example type of projects or activities to control. Whilst clan control (i.e. agile methods in our PPM context) can be complementary control methods they might be the only one if we can neither understand nor directly control the transformation process nor measure the outcomes.

So, is there clan control yet?

If we want to – or need to – rely on clan control we still have to ascertain that it actually works. Putting teams into clans, scrums or release trains and announce that they are now agile is not enough. It takes typically several years to embed values of the agile manifesto, together with its principles and also specific implementations (e.g. SAFe, LeSS, Scrum etc.) into the minds and hearts of all affected employees.

To rely on clan control we need to ascertain whether the agile transformation in our organisation is already effective. The adoption of agile values is difficult to measure. However, we can start with measuring the impact of agile transformation on software development, e.g. the frequency of releases should increase, the lead time from request to production decrease etc.  We observe that the agile transformation is changing the way how software is being delivered and has become effective. Being effective we can hence rely more on “clan control”.

In part 2 of this series I will explain how we can make the progress of the agile transformation visible for our Enterprise PMO and will suggest some metrics and key performance indicators sourced from PPM and other systems (watch this space)!

References

Elatta, Sally, and Anthony Mersino. ‘An Agile PMO Transformation’. presented at the PMO, Agile Practises, 23 October 2012. https://www.pmi.org/learning/library/pmo-agile-transformation-6063.

Liu, Li, Philip W. Yetton, and Christopher Sauer. ‘Organizational Control and Project Performance’. 14 July 2010. https://www.pmi.org/learning/library/organizational-control-modes-ouchi-model-6447.

‘Manifesto for Agile Software Development’, 2001. https://agilemanifesto.org/.

Mitchell, Ian. ‘The Agile PMO’. Scrum.org. Accessed 10 January 2020. https://www.scrum.org/resources/blog/agile-pmo.

Ouchi, William G. ‘A Conceptual Framework for the Design of Organizational Control Mechanisms’. Management Science, 1 September 1979. https://doi.org/10.1287/mnsc.25.9.833.

Robert, Joslin, and Ralf Müller. ‘Project Methodologies’ Impact on Project Success in Different Contexts’. Accessed 10 January 2020. https://www.pmi.org/learning/library/project-methodologies-impact-success-contexts-8947.

Scaled Agile Framework. ‘SAFe 5.0 Framework’. Accessed 14 January 2020. https://www.scaledagileframework.com/.

Tikka, Ari, and Ryan Nyman. ‘Scaling Agility or Bureaucracy’. Gosei (blog). Accessed 16 January 2020. http://gosei.fi/blog/scaling-agility-or-bureaucracy/.