Top Principles for Large IT Projects

When it comes to large-scale IT transformation projects, some basic principles have a great impact on implementation success. The following is a list of principles, some of which the folks at the IT consulting firm Infosys freely admit they came by the hard way.

These recommendations, or "10 Commandments," are intended to help focus your IT organization's attention on the most fundamental aspects of program management.

Click through for 10 recommendations from Infosys to help focus your IT organization's attention on the most fundamental aspects of program management.

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.

What makes the PMO effective is its independence and empowerment.The PMO should be independent of business or IT delivery and validation teams. 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. Subordinate everyone involved with the program to the PMO.

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

It never pays to plan the entire program in great detail at the beginning. However, the methodology to be followed MUST be defined and agreed upon before embarking on the program.The criteria should be specific (unambiguous), measurable and verifiable. It's important to follow a gating approach and make explicit Go/No-Go decisions at the end of each phase.

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.

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.Active involvement from end users comes at a cost. Trying to save this cost will cost the entire program dearly.

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

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.

Avoid tracking progress of the project based on arithmetic (weighted) average of individual tasks. Focus on critical path activities and continuously review the critical path.

A slight delay in one project (track) may have a cascading impact on other tracks, thereby putting the entire program in jeopardy. It's important to collect details on critical path activities from various tracks in a consistent and uniform manner, so that the real status at the program level is visible to all stakeholders. It's more important to know the "expected completion date" of tasks in-progress rather than just percentage completion.

Be aware of the organization's risk appetite.

The risk appetite varies from organization to organization. It depends on several factors, such as the industry that it operates in, the type of product or service it sells, the maturity level of the product or service it sells, the competitiveness of the marketplace, and the inherent culture of the organization. While evaluating the options to address the risk, it's important to take into account the risk appetite of the organization.

Reach out to all levels to identify risks. Do not rely entirely on reports from track leads.

The key is to identify the potential risks proactively. Though there are no foolproof methods to uncover all the risks, it is important to reach out to lower levels of the management pyramid and not rely solely on reports from the track leads/project managers.

Keep an open mind, and be ready to make course corrections.

As many of the business transformation programs run into several months (12-18 months), the team is confronted with many changes. Keeping an open mind and following a rigorous change management process are critical to ensure that these changes/challenges are addressed as objectively as possible.

Time is the only common unit of measure. While you may have to make short-term compromises, do not lose sight of long-term objectives.

Any issue or change that affects the elapsed time of the program not only increases the project cost, it also delays the business benefits expected to be realized by the program. Everyone needs to ask the question, how does this affect the elapsed time of the whole program?