Some people will say it is not necessary, others will say it is critical, but it really depends on the scale of the project/programme as to how much programme support a PMO could offer.
If you are using Scrum and running a small team you may have the right people to make the right decisions in the team and be 100% self-managing, with the occasional report to a portfolio function/director required. But if you are delivering a large Agile programme and using the agile method SAFe (Scaled agile framework) then having a strong programme office supporting could be key to success.
The support the PMO would usually provide would be to the Programme manager, Release Train Engineer and the Chief Product Owner. The following activity can sit within the PMO to enable quick, correct decisions and escalations.
The PMO would put in place the correct governance model, which ensure the right people at the right level are making the right decisions. They create, set-up and run the model, from ensuring processes are in place (and people know about them!) to attending and supporting the Programme Manager with presenting reports to Steering committees and Programme Boards. Having a central function owning the execution of this gives the Programme Manager more time to focus on mitigating the bigger risks and issues the programme may be facing.
Risks & Issues
Tracking risks and issues is the easy part and you don’t need a PMO for that but making sure they are fully mitigated and the appropriate action is taken is where PMO can really add value. Linking to the governance framework, having a good PMO can ensure that risks and issues which are starting to spiral are known by the people who need to know and can push people to act before it starts to impact the programme. Having a central view of these allows the Programme Manager to see where things may start to fail and focus their attention on fixing them… rather than having to find out when they become an issue.
In an Agile/SAFe world many risks and issues are identified during the daily stand-ups which is why the information chain into the Release Train Engineer and the Programme Manager is so important. If things stay a blocker for too long the RTE/Programme Manager really need to know about them. PMO would ensure this mechanism is in place and put in checks to ensure the process is followed. They may even attend stand-ups for some of the teams to get a sense of whether things are going well or if a team needs a little more attention. They can be the eyes and ears to support the Programme Manager.
Most reporting will come from whatever product backlog tool you use (JIRA, TFS etc.) and the Release Train Engineer will pull out the data and report up to the Programme Manager, but there is much more than team velocity and Sprint reporting which is required over the whole programme. What about Risk and issue reports, finance reports, headcount reports? How should these come together and how should they be presented? This is where your PMO adds value. If they are accountable for these things then it’s so much easier for them to pull out the reports, once again saving time for the RTE and the Programme Manager.
A list of deliverables are not required for agile projects, right?! This is just waterfall terminology, yeah?! WRONG!! Even in an agile world and especially when using SAFe you need some deliverables and you need to track them to completion. Take a RACI for example, if you are using 3rdparties to help you deliver you need to know who is doing what, the RACI needs to be created, reviewed and agreed. Tracking this process and ensuring it is stored and communicated to the right people is something your PMO team could do.
Yes, every Programme Manager is accountable for the overall budget and ensuring it stays on plan but do they really have time to ensure Suzie Smith has booked their time to the programme?! Not really! PMO would support with the finer detail of the programme finances, allowing the programme manager to focus on the wider issue of tracking to plan. They can help obtain true forecasts from individuals and match them to the actuals. If everyone is on holiday in August then the original forecast may be over and every penny counts, right?
Everything goes in the backlog and you measure everything by team/programme velocity to see if everything can be done. This of course is true in an agile world but planning is still very important. Planning could be used to manage cross-programme dependencies if you are working in a large organisation. Or if you need to meet industry or regulatory requirements that have fixed dates, you need these planned somewhere and not just in the backlog. PMO would support this activity and flag any risks to key dates. They would need to work with the SAFe teams to really understand the true dependencies to be able to link to specific User Stories. It may not be easy, but will be well worth the effort if the outcome of non-delivery is a hefty fine from your industries regulator.
This covers loads, on-boarding, off-boarding, training, recruitment, link to financial model. There is so much involved in the resource side, no matter what project you are delivering, if you are a small Scrum team or you are part of a big SAFe programme you need someone accountable for monitoring the resources. If you have a central team then great, if not you might want to give this to your PMO to control.
Still think you don’t need a PMO in agile?! As mentioned at the beginning it really depends on the size and scale of your project/programme. Some would argue that the things above can be covered by the Programme Manager, Release Train Engineer, Chief Product Owner, Product Owners and Scrum Masters and given the amount of roles and people then maybe they are right. But imagine having a central team to take that away from them so they can just focus on delivery and start to realise benefits much sooner! It might cost a little more but well worth the investment if you can get a strong enough PMO to support. If you get an inexperienced PMO then they may end up becoming an admin function so make sure you invest in the right PMO which will become an enabler for your Programme and not an unnecessary overhead.