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:
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?