Initiation phase of a large IT program – Key things to keep in mind

Many global companies are using business transformation initiatives to meet changing market needs. Implementing large IT programs is a key component of these change initiatives. Given that the failures of such programs are now commonly discussed; a recent McKinsey/Oxford study highlights that the failure rate of such programs is indeed more often. According to the study, half of IT projects with budgets of over $15 million dollars run 45% over budget, 7% are behind schedule and deliver 56% less functionality than predicted. What should organizations do to mitigate failure of such programs, and successfully implement their program?

Most IT programs struggle during the initiation phase since key program management activities are not completed to effectively start the program. This leads to longer startup times and missed budget targets, even before the program begins. The model outlined below contains the key activities that need to be completed during Program Initiation.

Figure: Program Initiation Model

All programs must work within the guiding pillars of Program Management – Mission, Time, Budget, Resource and Governance. Outlined below are the key activities that need to be completed during the Program Initiation phase.

Mandate – This is one of the key activities without which no other activity can begin. It provides the blue print for the entire program and all key decisions thereafter are based on the mission and objectives of the program. You can compare this to a country’s constitution that outlines the fundamental principles of the program. The mandate should include business case, project justification, high-level requirements and success criteria.

Time Management – This process is a crucial part of any successful project. Without careful time management, projects are set up to fail. This process organizes the team to meet deadlines by defining activities, estimating the durations of activities, scheduling activities and ensuring adherence to the schedule. All programs must have the following activities completed:

  • High-level Roadmap – provides a framework to help plan and coordinate the program. The key objective is to provide consensus within the project teams and stakeholders on how the Program is going to achieve its goals in a timely manner.
  • Development Approach – In this activity the Software Development LifeCycle (SDLC) development approach, such as Waterfall, Iterative, Agile needs to be identified.
  • Estimation model – the estimation model for the program need to be identified since it is used as an input to project/program plans and budgets.

Budget Management – This Process is involved in estimating, budgeting and controlling costs to complete the project within the approved budget. It requires that managers create and managed the budget effectively to yield maximum profitability.

  •   Financial Management – This activity provides the processes and the financial checks and balances required for the program to meet its financial commitment.
  • Contract Management – The activity includes the legal framework to engage with its clients, vendors and suppliers.

Resource Management –This process manages the most crucial aspect of the project – its people. This area ensures efficient and effective deployment of an organization’s resources to achieve the program’s objectives.

  • Resource Management – defines the processes for resource estimating and deployment. This activity ensures resources with the right skills are available as per the timelines in the Program Plan.
  • Stakeholder Management – this activity includes identification of stakeholders and managing them to align with the program and business objectives. Communication is an important factor in stakeholder management.

Governance – This process establishes structured communications throughout the levels of organization and assures that the organizational strategy, mission, vision, and desired outcomes are aligned within the Program mandate.

  • Governance – this activity defines the governance structure and decision making responsibility within each team.
  • Change Management – each program needs to define a baseline and any change beyond that needs to go through the Change Management process. The Change Management process needs to be identified early on so that teams understand the baseline and change management processes.
  • Risk Management – this activity defines the processes for identification, prioritization and mitigation of risks.

Program Kick-off – All the above processes have to be completed before Program kick-off since they are very tightly interrelated to each other, for e.g. Budget management ties into time management, because in order to ensure that the project is completed on budget, it also has to be completed on time.

The program kickoff meeting is scheduled for introducing the members of the project team (including clients, stakeholders, employees, contractors and external vendors) to the program mandate, the program roadmap/plan, and the roles of the team members. This is essential to align the program team on the program objectives.

The program initiation model outlined above ensures a successful program start-up and gives a solid head start in achieving your program objectives. These critical steps will prevent program startup failures and provide a higher rate of successful program execution.

Would be happy to hear your views on other areas that need to also be focused during the program initiation phase!

The article was originally published on IT Business Edge on March 7, 2014 and is re-posted here by permission.

Naushad Kapasi

Director - Client services, Virtusa. Naushad Kapasi currently manages some of the top customer accounts at Virtusa. Naushad has over 20 years of experience in the software industry with a background in account management (including P&L), client management, program management, product management, software architecture and development. He has extensive experience in leading products through their entire product/project life cycle, including creating proposals, leading the pre-sales team, managing requirements gathering through focused user group meetings and workshops; resource planning and team assembly; leading products/projects through development lifecycle; and aligning various functional teams to deliver products/projects in a timely fashion. Naushad has been involved in several process improvement initiatives with Agile rollout at Virtusa, as a Certified Agile Scrum Master, Rational Unified Process (RUP), Capability Maturity Model Integration (CMMI) for development and ISO 9001 processes. Naushad received his Bachelor’s degree in Computer Science from P.I.C.T, Pune, India.

More Posts


  • Prabhu N March 21, 2014

    Hi Naushad,
    Your post does sum up all required aspects to initiate a Large Engagement. I have been in one of the largest engagements (with a leading US automobile manufacturer) as a QP while working for a leading IT provider. The engagement had all types of services including Development, AMS, Testing, and Consulting through human resource sharing. An engagement which started with few hundreds onboard at the start, was estimated to scale up by 400% in headcount in a year. It failed miserably. It did not scale up more than 50% after a year. Lot of retrospective was done, infact, few client related budgets were also the constraints. But in hindsight, I think those weren’t the main pitfalls.

    As you mentioned, the roadmap was not clear, and the client wanted to move all his applications and services to this IT provider from another vendor. I believe that a phased transition never happened. I have summarized below few pitfalls and issues as assessed from a QP point of view –

    1. A Clear Road map was missing. There was one, but for such a huge engagement I believe the team underestimated its scale and complexity.
    2. Phased Transition was not done. It was an one shot KT of transferring all services to one vendor.
    3. I believe an in-depth due diligence was not done.
    (One of my ex-colleague, who worked for a global IT Consulting company, highlighted an incident. This was about one of the largest Banks from US wanting to move its services to this consulting company and invited a bid from it. The consulting company said that they would require a year’s time to explore the bank’s applications, which were close to 100 in number, if they were to support the applications and enhance their business with newer apps. However, they reiterated this assessment would be a different contract. The Consulting company indicated that they would come out with the current performance, issues, and improvements required for those apps and legacy systems and thereafter start the engagement. This approach of conducting a due diligence, should be a practice rather than a norm, prior to getting into large engagements as this may eliminate many challenges and issues that are commonly observed in large IT programs.
    4. Software Development Process – In my earlier example, the automobile manufacturer had his own process, and it was a mandate for the vendor to follow It. However, the vendor’s employees were tuned to their own processes and methodologies ; and moving into a new set of processes in a shot span was difficult and challenging. Over and above the client’s processes, the vendor’s team also had to comply to few of its internal processes, which became an overhead.
    5. Complexity – At that point of time, a single project with 1, 25,000 person hours of effort was way too high. The vendor did have 3 different sub projects, under an umbrella, but it didn’t work out. Further, onsite – offsite co-ordination was also not effective.
    6. Reverse KT – The client’s business users (Not the End Customers) – and IT team did not co-operate as most of the IT team’s work was being outsourced to the vendor. This was one of the most inflicting factor.
    7. Margins – I believe, the vendor’s team should be given a bare minimum time to scale up. This lead time will enable the Project Manager /Client Services team/Program Manager/Development Team to better understand and align with the new environment, applications, processes, etc. The vendor can then start targeting the margins.

    Hope the above few cents from me share some inherent challenges and issues in managing large IT programs.

  • Bill Klages March 24, 2014

    Naushad…great revisit of fundamentals and disciplines needed for driving a successful program

Comments are closed.