I recently had a chance to look into the detail of the P3O work being done by the Office for Government Commerce here in the UK. Now, while I don’t agree with everything they propose as best practice (more on that in another post) it did clarify something that I’ve instinctively felt for some time – architecture is a sub-set of the program office (PO) function.
That isn’t really the point behind this post though; the point behind this post is to explore why, when I mentioned this to some fellow architects, I got so much negative reaction:
- You’re kidding, right? Architecture is about long-term planning, PO is about day-to-day reporting and delivery
- No way. Architecture is about functions and capabilities, PO is about schedules and resources and stuff like that
Well, I’m sorry, but if you don’t believe that architecture is about delivery and if you believe that PO is only short-term then you’re doing at least one, and probably both of them, wrong!
Let’s take a look at what P3O aims to achieve (from their website):
- Informed senior management decision making on strategic alignment, prioritisation, risk management, optimisation of resource etc to successfully deliver their business objectives (portfolio management)
- Identification and realisation of business outcomes and benefits via programmes
- Successful delivery of project outputs that enable benefits within time, cost and quality restraints.
Now, as a manifesto goes, I can sign up to that without much disagreement, but let’s break it down a bit. The first bullet cannot be achieved without a strong architecture function, especially as regards strategic alignment and business objectives. The second bullet also has strong links to the road-map and, therefore, strong links to the architecture function. The third bullet has perhaps weaker connections to the architecture function but still has links to selecting the right scope and the right solution.
But, and this is the clincher for me, look at how many times there is reference to “delivery”, “outcomes”, “benefits” and “objectives”. If our role as architects is to ensure the delivery of the right thing at the right time for the right cost – and if the best way of doing that is to plan, monitor and control the change road-map – then how can we not be part of the PO? How can we not be part of shaping and delivering the change agenda?
Maybe this is just my particular philosophy on things. Maybe it shows through in my post about process and people elements of an EBA function. But I truly believe that unless you are getting your hands dirty and are actively plugged into the mechanics of delivery you are not doing your whole job.