I thought I’d share the way I organise programme teams. I’m interested in software delivery so I’m talking about programmes that have software development at the core. Non-software programmes would have a different structure and mix of roles. I push Agile but the same organisation would work with a less nimble approach.
There is nothing mysterious or radical about my programme organisation. In fact it is entirely in keeping with the guidance from Managing Successful Programmes (MSP). If you didn’t know Organisation is one of the nine Governance Themes from MSP.
Although I tend to apply the same shape to all of my programmes I do adapt it to local conditions. The size of the team makes a big difference so I’ll show how I have organised large, medium sized and small programme teams. I’ll also take a quick look at a poor structure for a programme team – with role based teams – and explain why I don’t fancy it.
There are obviously other ways of structuring a programme team but this is what has worked for me.
Large Programme Team
Programmes can be organised in any number of ways. The organisation chart below shows the general shape of the programme teams I’ve led over the last few years.
Large Programme Org Chart
The programme team, i.e. the people on the programme, are all those people in the organisation chart from the programme board and down (in blue). The Sponsoring Group and Business Liaison Group are outside but interested in the programme (in orange).
The programme is divided into projects or workstreams that, more or less, correspond to Agile Teams. Many of these are technical but at least one is the Business Change workstream. The technical teams are responsible for building the software, putting in the infrastructure, building tools, and integrating the product.
The structure is not fixed. If I need to get people focussed on a new product area then I’ll spin up another Technical workstream. If we’ve done enough in an area of the product then I’ll wind down the associated workstream.
Programme Board
The Programme Board is the management team on the programme and includes the Programme Director, Agile Programme Manager and Technical Architect. I find it very useful to have all three perspectives – business, project and technical – in the room when discussing the health of the programme.
Business Change Team
All of the workstreams tend to have a business change aspect but I always have an explicit Business Change workstream. This group specialises in change – it is all they do. The existence of this group makes it clear to everybody that the programme is about organisational transformation.
The Business Change workstream is where:
- the majority of stakeholder communications happens
- improvements to business workflow are considered, articulated and sold
- training is prepared and delivered
- roll out is planned and executed
- benefits are identified and tracked
Product Development Teams
Being software most of the technical teams are about Product Development. These teams have a mix of roles including UX designer, business analyst, developer, tester, project manager, and product manager/owner. It is only an accident of my drawing package that I’ve shown the Product Development teams grouped together; they all report to the Programme Board.
Infrastructure Team
Software has to be hosted somewhere and the Infrastructure team is responsible for providing that environment. Typically this team is staffed by IT Engineers seconded from the IT / Operations Department. Having those people on the programme team facilitates the inevitable transition to Business as Usual (BAU).
Toolsmith Team
The toolsmith team builds development tools for the Product Development teams. Build scripts, continuous integration, one click deployment. All that kind of thing. Better to solve it for everybody rather than have the different teams all going their own way. The nature of the work means the composition of the Toolsmith team will be development heavy. But there is space for a Project Manager, Testers, and perhaps even a UX Designer. The Product Owner for this workstream is likely to be somebody technical, e.g. the Technical Architecture, although on one occasion I acted as Product Owner.
Integration Team
The Integration team is responsible for gluing the overall product together. In terms of composition they look quite like a Product Development team. Definitely with project manager, developers and testers. Less often a UX Designer. Often somebody on this team is the Release Manager for the whole product. The Product Owner can be the Programme Product Owner but because a lot of glue is technical the Technical Architect can also fill that role.
Sponsoring Group
As programme manager I, and the Programme Board as a group, report into the Sponsoring Group. These are the people who commissioned the programme, provided the funds, and expect to see benefit.
Terminology is never easy and sometimes this group is called the Programme Board. In fact all of the programmes I’ve run have called this group the Programme Board. But according to MSP it should be called the Sponsoring Group. Fair cop as they sponsor the programme.
Business Liaison Group
There is usually a separate group, which I’ve called the Business Liaison Group, populated with the stakeholders who are interested in the detail of the product and can be recruited into the change initiative. In change mode they provide management support for the roll out and advise on who would make a suitable local champions. The Business Change team liaises with this group.
Smaller Programme Teams
For a smaller programme the same principles apply but you don’t need as many teams. You will still need a Business Change workstream but the number of Product Development teams will be less. In addition you might not need all three of integration, toolsmith and infrastructure. You do need people worrying about and working on those things but not necessarily in dedicated teams. So, for example, one of my teams had only a couple of product development teams, alongside toolsmith and infrastructure teams. Integration was the responsibility of the product development teams so wasn’t a separate workstream. Another variation is to combine toolsmith and infrastructure into a DevOps team.
Medium Sized Programme Org Chart
Most people on the team are dedicated to a particular workstream. Other people, in particular user experience (UX) and business analysis (BA), tend to float around as required – these are the people in the “Shared” box in the diagram.
The smallest programme I’ve run had a business change workstream, a product development workstream and an DevOps workstream (with the responsibilities of the infrastructure, integration and toolsmith teams).
Small Programme Org Chart
Role Base Structure – Don’t do it like this
Don’t organise a programme around roles. Although I believe that all organisations, including programmes, have an implicit matrix structure with projects on one axis and roles in the other, the emphasis should be about deliverables – working software in use by a transformed organisation.
Making the disciplines (roles) the primary focus takes the emphasis away from the work. It also encourages a more waterfall approach with formal handovers between teams. The cross-functional Agile teams I use have these handovers but they are minimised.
I’ve included this org chart just so you know what not to do.
Bad Programme Org Chart
References
Best Management Practice. (2011). Managing Successful Programmes (MSP) [4th Ed.]. London: TSO.