The Balanced Programme Management Team

I often see programmes fall into the trap of over reliance on certain individuals.  Unfortunately the more effective and useful a person is the more that person seems to be branded ‘Super Man’ and burdened with commitments that make it ever more difficult for them to do the things they were valued for in the first place.  The other issue is a programme with an unbalanced leadership team, a programme director who doesn’t work well with his peers (yes peers, he’s not the boss) or missing roles.  Here are some examples:

• The Programme Director who takes on too much Programme Management because the customer and account teams except him to have programme management detail at his finger-tips.  Solved by a combination of excellent management information, setting expectations and not being afraid to reinforce those expectations.  Fall into the programme management trap and you won’t be there for the team when they need you, won’t have time to manage the key relationships and won’t be able to see the wood for the trees, the classic “programme is red – surprise!”.
• The Chief Architect who forgets that his job is to preserve the conceptual integrity of the solution and to nurture its evolution through logical and physical development stages.  Solved by having a very good definition of the concept initially, making sure that the architecture leads responsible for the logical solution definition have a clear understanding of the whole concept and making sure that as the solution definition progresses it is regularly cross checked against the conceptual definition and either the concept changed or the logical/physical definition bought back on track.

However there’s more to this balanced team idea than that.  First we need to make sure that the programme has a team structure that allows all views to be well represented, ideally I like a model that does not create conflicts of interest, and provides people with sufficient time to support their teams.  There are some of the key roles I like to see:

• A Programme Director – note the emphasis in this role on directing.  I never like it when I have a programme director who is too BUSY, ideally they get home by 6:00PM.  They need to be their for their team, and to manage key relationships and to see the big picture and resolve the big issues.  A programme director who is working more than 48 hours is managing, not directing.  Personality wise they need to be very approachable, not afraid of bad news and always happy to talk, at the same time they need to give key stakeholders confidence that they have a good team and good processes and that these are well executed.
• A Chief Architect – responsible for ensuring the the solution that is delivered meets the objectives that it is designed to meet.  They achieve this by ensuring that the solution has conceptual integrity, and achieves this by designing the way the solution will be described and verified.  Most of the points made about the Programme Director apply to the Chief Architect as well.  Its also worth remembering that on many infrastructure programmes, users don’t know what they want!
• A Programme Office Manager – primarily responsible for ensuring that the programme management team receive the information they need to direct and manage the execution of the programme.  This primary role is one of supplier to the programme management team.  If this information provision role fails, the programme usually fails.  The secondary role of the programme office is to ensure that the programme level processes, (those followed by every project), are executed correctly, (evidence of this should be part of the management information).  In my view the Programme Office manager’s role in the Programme Team is not as a contributor to the management of the programme, but as a supplier of information, so he needs to be in the meetings, so he knows what information is needed first hand.
• Development Manager – responsible for executing the projects that develop the solution. The emphasis is on execution, not definition.  The project content should have been defined conceptually at the programme level, it is refined by the projects as the logical and physical level definition is created.  Individual projects should not be allowed to change their scope, project scope is owned at programme level.  What do I mean by scope? the conceptual architecture, the functional service definition, key volumetrics, budget, major milestones and dependencies, principles, assumptions, issues and risks.
• Customer Experience Manager – there are two issues that generally fail to to be managed well on large programmes.  The first is the user community is rarely well prepared for the change that is about to hit them, and certainly ill prepared to exploit it once it has arrived.  The second is that the disparate deliverables from the programme do often not integrate very well from the perspective of the end user.  This role is designed to solve this problem through ownership of a variety of elements, including, end-user communication, end-user organisation and roles, solution integration testing, dog-food testing and piloting, user acceptance testing, end-user training and documentation, the end users deployment experience, the end-users post deployment experience, customer surveys and other end-user focussed programme success metrics, exploitation.  Ultimately this person is the users advocate, an interesting video that illustrates some of these points is available here.
• Service Transition Manager – Each project that is delivering services that need to be operated and managed needs to take ownership of ensuring that these service elements integrate into the management infrastructure and have processes that have been developed, accepted and implemented by the lines of service responsible.  The role of the Service Transition Manager is to ensure that the lines of service are ready to accept the services and processes that have been developed.  This means ensuring that they have the right level of resources, budgets, trained/skilled staff, that they understand the processes have metrics in place and management processes in place etc.  In many ways this person acts as the Programmes agent within the operational organisation working to ensure that the delivered services are success.
• Deployment Manager – responsible for executing the deployment activities on the programme.  It depends on the programme the degree to which deployment processes/tools are developed by deployment/development and its largely an issue of skills, for complex deployment activities that are executed a small number of times, my preference is for the development team to do the development of the deployment process/tools, (and sometimes even do the deployment).  For processes with less technical complexity it’s often better to develop them within the deployment programme to increase ownership.

The programme management team should not be afraid to create additional programme level roles, to reduce the burden on them, for example roles focussed on communicating with business stakeholders.  However these should report to one of the team identified above.  This group should be selected to work as a team, and motivated to do so.  Ideally they should be collocated and should be encouraged to meet ad-hoc and not just at formal risk/issue/change/status meetings.

The picture is of Cleveleys promenade, a great example of balance between form and function.