Who is accountable in a large transformation program? We are talking about budget, time and quality of solution. The classic triangle in all projects.

There are three caveats with this question.

The first is the scope of the program. Is it end-to-end, both business and IT in scope? Second, does the program manager have the knowledge and time to do the work needed as accountable? Last, but not least is the conflict of interest. You wish for time, budget and quality and you very often have to give at least of them lower priority.

Unless the program is only a 1-1 technical upgrade, you must include business operations and how business have to change their ways of working. The scope for then end-to-end solution must be both business and IT. It doesn't help much either to outsource accountability to a system integrator or other third party. You own your business.

I've been accountable as project manger and architect in a medium size implementation project, (11 months and 2.5 M€ budget, not including hardware or internal time. In this project, I was accountable, but also as Anne Lapkin mentioned, I had the authority to take decisions, given by the steering committee.

As we delivered on time, within budget and quality, why don't I always continue to work like this? The reason is that this is two demanding roles and I worked 80h per week most of the year, which is not sustainable in the long run.

A few years later I was involved in another international project where I had both roles, PM and EA. When the stakeholders wanted the scope to increase, I said no, as the effort would be to high, but also due to internal politics, that make the PM & EA work even more difficult.

The second is more subtle. In larger programs, we often have more complexity and there are always different trade-offs we have to do to have and end-to-end solution that fits within budget and time. A solution that consists of several solution architectures and the responsibility of each solution architect.

In the best case, a project manger have learned a project method, but those methods focus on time and budget, not how to design an end-to-end solution.

Ad-hoc doesn't work in large programs, and agile doesn't scale when we have to many depencies in the program. We must therefore use a method for designing end-to-end solutions. A method we often call Enterprise Architecture. A version that needs to be adapted to programs and not high-level company strategy, e.g. Ivory tower EA.

Very few project managers have the skills of an enterprise architect. Even if they done smaller projects before, large programs are of a very different magnitude and require different skills.

Have you played chess with yourself?

It's very difficult to be your own opponent and question your own priorities and decisions. In this case two heads are better than one and will result in 1+1 > 2. It's both about priorities and have a sparring partner for your thoughts. This is also why the personal chemistry between the PM and EA is important, as they have to work very tight together and share the same values.

To succeed in larger projects, my recommendation is to to have two roles, project manager with responsibility for time and budget, and a technical project manager responsible for the solution. It aligns very well with what we teach at Capgemini, one Engagement Manager and one Enterprise Architect in programs with accountability.

Disruptive architecture