Six things you should expect of a modern PMO

When it comes to software, in many organisations the PMO – Project Management Office – is part of the problem rather than part of the solution. Part of the reason for this is that the approach doesn’t really fit the context. Developing great software that people love is not like building an office block. As I’ve written about before, the project paradigm is a poor match for software. This is especially true in larger enterprises where the product will need to be quickly and frequently updated, and the teams need to be long-lived and sustainable. Projects are a poor vehicle to use to get what we really want.

These days, unless they’ve been hiding under a rock for the last decade or so, your teams already get this. But the PMO tends to be the last bastion of old-skool, outdated thinking. They often mean well, but they just don’t know any different and they’re using what they’ve been taught as “best practice”. The thing is, the PMO, with it’s wider portfolio level view of teams is actually well-positioned to really add value and improve the system as a whole. But maybe they don’t know how they could be helping?

Here are six things you should expect from a PMO working with software teams today:

1. Forecasting
The collection and monitoring of cycletime and throughout statistics, using these to produce forecasts based on actual data (rather than estimates or overly optimistic commitments). Forecasts to be based on Monte Carlo simulation using Weibull Distribution with confidence intervals that are shared with stakeholders (who may also need to plan activities).

2. Smoothing Flow
Monitoring and process improvement for the upstream refining of ideas, breaking down ideas, epics and features work down into small enough chunks for teams to independently develop and release.

Manage (and protect) the constraining of Work-in-Progress in order to optimise for speed to market and sustainable flow. Teams only pull work when they have capacity according to process policies designed to reduce cycletime and smooth the flow of work.

3. Reducing Cycletime
Many of the impediments that teams have to navigate are outside their locus of control. There needs to be some function that is looking at making system wide improvements to reduce cycle time and increase the frequency of releases. Teams need to be able to raise systemic impediments that are slowing down the discovery and release of value.

4. Breaking Dependencies
The early identification of dependencies between work streams and team that need to be broken, minimised or managed in order to improve the ability for teams to quickly flow value from lightbulb to live. Decoupling teams where possible and, where required, help teams to collaborate and coordinate.

5. Visualising Portfolio & Roadmap
Produce and maintain a physical and/or virtual visualisation of the amount of work in progress across the portfolio. Extending from this, maintain a visualisation of the roadmap of what is coming up, based on what we know today.

6. Monitoring Outcomes
Benefits realisation in the form of key outcome metrics that the teams are working to improve. Close the learning loop from what we hoped the impact of a change would be to what it actually was and trigger actions to amplify the positive and dampen the negative.

What have I missed? Share your views in the comments below, or ping me on twitter here.

Comments 8

  1. Hi Joshua,

    Really enjoyed your post. Thanks!

    On point 3 you talk about reducing cycle time. This is indeed a good goal but I think it’s also important to focus on reducing variation in cycle time as well. Reducing variation improves predictability. Improved predictability makes planning more reliable. Better planning makes managing expectations easier.

    Cheers,

    Ian.

    1. Post
      Author

      Agree that reducing variation in cycletime can be useful, especially when it comes to making forecasts more reliable. I would say that it is (to some extent) already covered by Point 2: “Smoothing Flow”. In addition, focusing on reducing cycletime itself will typically reduce variability.

      Allow me to test an alternative perspective: Can you go too far in focusing on reducing variability in cycletime? Product Development is inherently uncertain, no matter how much we would like our forecasts to be precise. Might it be better to invite stakeholders to better understand and share in the uncertainty that exists than to manage unrealistic expectations? I realise some stakeholders may not be ready for this, but at some point I would hope that they were more focused on the value being discovered as quickly as possible than the precision of forecasts. What decisions are they trying to make with this information? Is there an alternative approach that makes them less reliant on forecast precision?

  2. If someone can give some advice on how to help developers provide realistic estimates I would appreciate this.

    Our developers work in sprints on new stuff but continue to get slammed by production work, ad hoc meeting requests etc which is unquantifiable. So our sprints aim at %45 of each developers time, however the estimates are still way too loose to ensure release dates can be ‘fixed’.

    1. In my view, developers working on a “project” should be, as far as is practical, ring-fenced for the relevant development work. This is, I believe, a Resource Management issue. If your resource pool of expertise is large enough and if you can avoid the situation of having only one developer with a certain type of skill/experience, then you may be able to create a sub-pool for BaU (Business as Usual) work, i.e. production support work, technical advice and consultancy, attending ad-hoc meetings, etc, i.e. anything other than work on current development projects. The size of this sub-pool, and the skills required in it, can be determined from a historical log of time spent on these BaU activities (or initially using an estimate if there is no log). In some organisations a rotational system is used rather than having specific people permanently in the BaU pool. I accept that “emergency” situations from time to time in BaU (or in a project) may require some flexibility but it can be much more controlled in accordance with recognised business priorities and any impact on delivery deadlines assessed and (hopefully) accepted. If such a sub-pool for BaU is not practical then a similar outcome can potentially be achieved by a “virtual sub-pool”; this tends to be more difficult to manage because it can involve “parts” of a developer (e.g. 25%). I would expect your non-BaU development pool to achieve very much higher than your current 45% on sprints AND you will be able to base your estimates quite confidently on the (new) percentages, with the result that releases will occur on the fixed dates, with very few exceptions. This will require some good Resource Management to achieve these benefits. Is this post helpful to you at all?

    2. we had this issue about 3 years ago. During 3 months, we registered everything that felt outside the realms of the project, classified in “meetings”, “corporate tasks”, “prod support” and a rate from 1 to 5 in two aspects: relationship w/ the project and value (worth the time spent?)
      this gave 2 important things:
      1. helped us to reduce the amount of unrelated
      2. we could forecast the impact on our deliveries

  3. HI Joshua,
    Interesting post on PMOs. I am not a Lean/Agile practitioner (but would like to be!). Reading the sections about Forecasting and Monitoring Outcomes, I’m thinking of a (potentially) related topic – the relevance of Lessons Learned, if you’ll excuse the Prince2 terminology.
    Is there a place in the theory/practice of Lean software development for recording, evaluating and somehow using Lessons Learned? If so, could/should the process of making previous Lessons Learned usable (and used!) fit into the PMO’s Forecasting role in some way? May not be relevant but would appreciate your thoughts.

  4. I think this post is very valid since PMO is very often the last barrier of defence against change. Inherently PMO is an antipattern to agility and lean thinking and I could (should probably) write about that :). The whole idea about projects doesn’t fit into software product development or I would even say any creative knowledge work (Allen Kelly has written very well about that). It’s almost a little heartbreaking to see how we try to fit PMO into a modern company.

    To be a bit more concrete, I think that points 1, 2 and 3 must be handled inside the teams (Scrum) or by the owners of a particular service (if we are talking Kanban). However, the essence is that the people doing the actual work are in the best position to improve their processes and workflow. The result of activities from these 3 points could flow into activities 4, 5 and 6 which are supporting decision making on a higher abstraction level in an enterprise. All this makes PMO collectors of information they need to compile into a format that makes sense for decision makers. At this point, I would, of course, start thinking about automating 5, 6. That leaves dependency management to PMO. I have yet to see any PMO that actually managed dependencies to reduce them. At best they have created meta processes to be able to dance around the dependencies and mitigate them instead of creating a workflow environment that reduces dependencies. This is, again, one of the antipatterns of PMO in a lean and agile organisation.

    /peter
    @germanicus1

  5. Great post Joshua.

    Re: 2. Smoothing Flow – Monitoring and process improvement for the upstream refining of ideas:
    in my experience, the PMO is typically not staffed with people who can do this. The PMO’s I have dealt with have been passive, back-end teams who rarely attend Daily Stand-ups, Project War Rooms or deal with functional issues. They generally look after

    Project Admin – such as Budgets, Contract & Cost variations
    Onboarding & exits of project staff
    Work arrangements, such as staff seating, security accesses, PC’s, phones, mobiles, etc

    Happy to get feedback from others on different experiences :)

Leave a Reply to Joshua Arnold Cancel reply

Your email address will not be published. Required fields are marked *