Managing implementation oversight of projects

This is the seventh posting in a series on TOGAF’s ADM. In the previous posts we zoomed in on defining a vision, modeling baseline and target architectures, finding delivery vehicles for implementing the target architecture as well as defining a set of projects to implement the delivery vehicles. At this stage, we shift our perspective to implementation governance: overseeing the projects that were defined in the previous phase.

Objectives, steps, inputs and outputs

This phase is all about oversight; meaning that “others get to do the work” and architects “check if it is done right”.  In the light of the adage that no one likes a bully, the objectives for this phase are not only to govern and manage compliance to the architecture contract, but also to formulate recommendations and to obtain support from supporting organizations (i.e., operations) that will underpin the future working lifetime of the deployed solution.

In this phase, typical project details such as acceptance criteria and measures of effectiveness become more important.  In assessing compliance, the TOGAF standard (in chapter 48) even defines terminology for specifying whether an implementation is irrelevant, consistent, compliant, (fully) conformant, or non-conformant. The inputs for this phase are all the artefacts that have been defined so far throughout the ADM as well as the architecture repository.

The steps of this phase include a check on scope, identification of development resources and skills, provide the project with implementation recommendations, etc. Even more, at the end of the project architecture compliance is assessed and a post-implementation review is performed in order to obtain lessons learned.

The main outputs of the phase are the signed architecture contract as well as a compliance assessment. Even more, change requests may be issued as well during implementation; e.g. when it turns out that elements proposed in the architecture turn out to be less practical than anticipated in earlier phases.

Best practices

An issue that we have frequently encountered in this phase pertains to resource planning. We often see that there are a few critical resources that are severely overloaded as they play a necessary and critical role in several projects

It is understandable that projects / project leads would all prefer to have the best staff on their team. However, as strong and smart as these champions may be, the law of raspberry jam states that attention by these champions for each individual project will be little. Possibly too little. This suggests that looking for a different resource may be the better option in many cases.

A second best practice lays in the observation that close co-operation and co-ordination of mental activities (such as defining a vision, performing impact analysis etc.) and implementation activities is necessary.

 Overstating slightly, failing to get this right will result in a beautiful architecture that is “tossed over the wall” to the implementation team who picks it up and runs with it, vaguely going in the right direction. In the end, this will result in disaster when e.g., the developed solution does not link well to current processes, IT infrastructure, or results of other projects.

Outlook

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.