10 Commandments for Large Business and IT Transformation, Part 2

Part 1 of this three-part series looks at a real-world case of IT transformation breakdown and explores the causes for the failure.

There are 10 basic principles that can have a substantial influence on the successful implementation of a large IT transformation program. These recommendations, or “10 Commandments,” will help direct energies toward the most fundamental aspects of program management.

This installment explores the first five recommendations in detail.

1. The Program Management Office (PMO) must be independent of business and IT delivery teams with full-time empowered members responsible for the success of the program.

All large programs are driven by some form of PMO or the other. In most cases, PMO serves as the administrative arm of the program lead. The general perception of a PMO member is that of a person who follows up with the track leads for status reporting. It’s true that the PMO is responsible for defining and implementing the processes, tracking progress against schedules, and providing status reports to the steering committee. What makes the PMO effective, however, is its independence and empowerment.

The PMO should be independent of business or IT delivery and validation teams. The business team is responsible for defining the requirements and acceptance criteria. The IT delivery team is responsible for design and development of the solution. The validation team is responsible for testing the solution and certifying conformance to business requirements defined by the business team.

An independent PMO enables objective analysis of the status and options for course correction, when needed. A PMO that is controlled only by either the business or the IT delivery team will not have the mandate needed for objective analysis.

The PMO should be staffed by full-time members who are charged with the success of the program. The PMO should have the authority to request status; define, enforce and audit project management processes such as change management, risk management and issue management; and negotiate with all the stakeholders.

Subordinate everyone involved with the program to the PMO. It’s the responsibility of the executive sponsor to ensure that all teams report into the PMO, so the PMO does not end up as an administrative body churning out reports.

2. The methodology of execution and exit criteria for each phase of the program should be clearly defined at the beginning of the program.

It never pays to plan the entire program in great detail at the beginning. In most cases, it’s not possible to get into the level of detail required to come up with an exhaustive list of tasks or accurate schedule. However, the methodology to be followed MUST be defined and agreed upon before embarking on the program.

An implementation methodology and gating criteria (entry and exit criteria for each phase) MUST be defined. The criteria should be specific (unambiguous), measurable and verifiable. It’s important to follow gating approach and make explicit Go/No-Go decisions at the end of each phase.

In the real-life example illustrated in Part 1 of this series, the methodology and gating criteria were not clearly defined and signed off. The generally accepted sequence of phases in a typical IT implementation program is as follows (actual terminology may vary from organization to organization): scope definition, requirements definition, business process design, solution design (functional design, technical design), solution development, validation and deployment.

In the example, the functional solution design was dependent on the business process design. The team was fully aware of that. However, the methodology and gating criteria were loosely defined and were not enforced. The program team proceeded with solution design before completing business process design. Detailed solution design documents based on a loosely defined and incomplete business process design formed the basis for subsequent development efforts.

The result, as you can imagine, was a solution that was developed on business processes that were neither accurate nor agreed upon by the business team. In the end, the program was delayed, resulting in significant cost overrun.

3. Plan a time-buffer in the schedule that can be invoked only by the steering committee. Re-plan at the end of every phase.

It’s not uncommon to budget for a contingency in any project and especially so in large programs. Most budgets include a cost contingency, but few plan for an explicit time-contingency (time-buffer) at the program level. Not having an explicit time-contingency at the program level forces all tracks within the program to build buffers that will result in longer duration for the program as a whole. Figure 2 is a simple representation of the concept of program-level time-buffer.

Fig 2: Timeline with and without program-level time-buffer

(click image to enlarge)

The argument can be made that having a program-level time-contingency will not prevent individual track leads from including buffers. However, having a program-level time contingency at the end of the program schedule, coupled with incentives to meet the schedules — rather than punishments for not meeting the schedule — will motivate teams to work collaboratively.

Leaving the decision to use the time-contingency with the steering committee allows for greater control to manage the variations in schedule slippages of various tracks and across project phases. Re-planning at the end of every phase is the key to ensure that the schedule is relevant, realistic and achievable. Commercial agreements with service providers need to be reviewed and firmed up at the beginning of every phase.

4. Involve end-users throughout the program and not just during requirements gathering and deployment phases.

It’s a common practice to involve end-users actively during requirements gathering and acceptance testing phases. However, the users need to be actively involved in other phases as well, namely prototype design, solution development (application walk-through) and test planning phases.

Change control is an inevitable aspect of any large program. The end-users need to be actively engaged as part of change control process. The PMO should ensure that the long-term impact of each change request is clearly understood and accepted by the end-users.

Active involvement from end-users comes at a cost. Trying to save this cost will cost the entire program dearly.

5. Not all resources are equal. Identify bottleneck resources and manage them closely. Re-assign tasks to other non-bottleneck resources where possible.

Human factors greatly influence the outcome of any project more than any other factors — more so in programs involving IT service delivery. In the real world, you may not always have the resources with the right skills in the right numbers at the right time. There are always some resources or roles that are more critical than the others, either because they have unique (niche) skills that are hard to find, or the roles are highly knowledge-intensive and need longer training to develop the expertise.

Whatever be the reason, it’s important to identify critical (read bottleneck) resources early in the program, and manage their time and monitor the progress of tasks assigned to them diligently. It’s easier said than done, but not doing it is a sure recipe for failure. As with any tracking, managing bottleneck resources requires additional management focus and bandwidth.

Any activity that can be carried out by non-bottleneck resources should be taken away from bottleneck resources. For example, an SME (subject matter expert) is expected to define the business process, but documentation tasks are a sub-optimal use of the expert’s time. Assigning a more easily available resource to shadow the SME and do the documentation will not only expedite the deliverable but also help train a new resource as a backup.

The third and final installment in this series will explore commandments six through 10 for implementing a successful large business and IT transformation.

10 Commandments for Large Business and IT Transformation, Part 3