In the prior installments of this series, we presented a pattern for how PMOs can better bridge the gap between executive and executor:
- First, we discussed the need to define progress in terms of business needs met and not technical tasks performed, so that we measure in terms of results, not effort.
- Next, we showed how we can track and forecast progress in these same terms – e.g., by using burn-up charts – so that we have unambiguous line-of-sight into what a team is actually doing. Again, consider the spiral diagram: we can dive into the details without any “translation” between a status report and day-to-day execution.
- Then we presented how we can measure meaningful attributes on the asset itself so we have strong, clear signals of underlying quality and a more complete picture of what it is we’re creating: harmonious greenfield or toxic brownfield.
- Finally, we saw how we can vastly simplify the burden on our delivery teams by automating metrics collection.
By doing these things, we align team execution with the needs of the PMO. This makes us more effective at governing IT:
- By reconciling actual results with our business cases, we know the in-flight NPV we’re tracking toward. This gives us a continuous assessment of whether we’re getting value for money of our IT investments.
- By exposing the quality of the application itself, we know whether we’re producing IT assets in accordance with expectation.
A few years ago, the blue boxes in this diagram were disjointed, independent activities. Today, we can automate and integrate collection to a point where in the PMO we can know what’s going on in any given team. If we're using a product like Mingle, our performance reports are updated every time somebody advances status of a story card. If we're using a product such as Cruise, our quality data is updated every time a build is triggered.
This gives us real-time information on what matters the most to us in the PMO. We have visibility into our project situations: scope changes, performance changes, lags, as well as the quality of the asset being created (and by extension, a limited degree of knowing how they’re going about doing it). We have this in near real time. It’s not burdensome: it’s an extension of what people are doing, and it lives within the tools. It’s not conjecture: it’s a reflection of functionality that works and driven right off the asset.
Becoming a Real Time PMO
So, that sounds like a great future state to target, but it won't happen of its own volition. What can we do today that will help us become a “real time PMO?”
If you have no Agile projects in flight now, stand up a couple. There are different adoption patterns, but one very common approach is to start with requirements shaping and “level 1" Agile practice adoption. As you stand up Agile projects, define each of your gatekeepers to be functional, tested, useful and deployable asset. Avoid having any gatekeeper (aside from the project chartering phase) that consists of deliverables that merely describe an asset.
If you have Agile projects, but adoption is inconsistent or you're not seeing the impact from Agile practices that you anticipated, scrutinize the state of Agile adoption in your project teams. Before building out a PMO, it's important for team fundamentals to be in place. Not all change is created equally, and Agile adoption takes time. Perform an Agile Maturity assessment to identify practice gaps and call out actionable items teams can do to bridge those gaps.
If you do have well-running Agile projects, hone in on metrics collection, automation and consolidation. Take a look at Mingle and Cruise from ThoughtWorks Studios. The build pipeline management features in Cruise are pretty impressive. Be aware that there are ramifications to increasing team visibility. Don't assume that this is simply an exercise in implementing tools, and be prepared to iterate to achieve greater degrees of transparency.
If you have well-running Agile projects today with efficient data collection, take your project tracking to the next level. Don’t just report burn-ups, report projected NPV. As things happen in a team - if scope is changing, dates are changing, quality is slipping and needs to be corrected, etc. - report out the business impact of the change in business terms to your business partners.
We do have to be careful not to put too much stock in numbers. We still have to look at code, look at the quality of requirements, run the actual software, and above all else, talk to IT people and businesspeople in the teams. We have to make sure that tasks aren’t masquerading as stories, that unit test coverage isn’t simply being gamed with meaningless tests, that progress isn't being overstated. The numbers are indicators, but they're no substitute for really understanding what’s happening in a project team. Nothing alleviates the need for fundamental project management.
That said, clear line-of-sight into trouble spots and risk areas early in a project allows us to take better decisions about projects, meaning we can avert the spectacular, late-stage blindside. With responsibility for capital investments in a difficult economic environment, we need to win and retain the trust and confidence of our business partners. We need to be on top of our game. We can do that by being an Agile PMO.
