Delivering IT projects is extremely difficult, and this is proven by the high failure rate. At least 65 per cent of projects terminate before the cutover, exceed the budget, or fail to yield the anticipated benefits. This is an astonishing failure rate, and it has been consistent for over two decades.

So, what are the root causes of the failures?

Pathway has been rescuing business-critical projects and programmes for many years. This experience provides a unique insight into the core reasons for the failures. There are multiple reasons projects aren’t delivered, but the common threads are:

1. Poor project initiation.
2. Issues that aren’t discovered in standard testing phases.
3. Lack of preparation for cutover.

These are also the areas that standard methodologies pay the least amount of attention to. (If they are covered at all.)

There is a direct relationship between the gaps in methodology and severe project issues. The failure rate of 65 percent may sound high, but many experienced project managers will have worked on projects that have been restarted several times. It’s not a coincidence that so many projects are named Phoenix!

Let’s look at the three common threads in more detail.

1.    Poor project initiation

Professional initiation is essential if you want a successful project.

A London-based consultancy found that problems with project initiation were responsible for 80 per cent of project failures.

What are some of the common issues with project initiation?

• Lack of focus on dependencies and constraints.
• Underestimating effort. (Tasks typically take twice as long as the estimate.)
• Overestimating project team and third-party resource availability
• Not allowing adequate time for the first use of development tools or implementation of new technologies. 
• Insufficient focus on training, non-functional tests, data quality, and security.
• Not including business and cutover dress rehearsals in the plans.
• Lack of alignment with the organisation’s strategic objectives.
• Not including critical success factors.
• Unrealistic timescales and budgets.
• Not preparing detailed plans on projects/programmes that require them. 

These are just examples; there are many more potential issues with project initiation.

The project initiation phase must be given the time and attention required. There may be a hard deadline for delivery, but don’t skimp on project initiation. Please remember that the level of documentation for this phase must be commensurate with the size of the project or programme.

My advice on project initiation is the same as for other aspects of project management. Be pragmatic but rigorous. You would rather not overlook things. As you move through the project lifecycle, the cost of correcting omissions increases exponentially. This scenario applies to both Agile and Waterfall projects. For instance, neglecting security requirements at project initiation could lead to alterations in the product and infrastructure.

Key activities in project initiation

The Project Initiation Document (PID) should contain the following sections:

• Background.
• Project definition.
• Project objectives, including critical success factors.
• Project methodology.
• Project scope.
• Deliverables.
• The project resource is responsible for the deliverables.
• Constraints.
• Dependencies.
• Assumptions.
• Quality assurance.
• Risk management.
• Test approach.
• Dress rehearsals.
• Cutover planning. 
• Post go-live support. 

These are examples. Other items may need to be added or removed depending on the type and complexity of the project. This is a critical document; allocate the appropriate amount of time to prepare the PID.

Work Packages

Work packages are very useful for estimating effort and for managing progress on a project. Initial work packages are prepared during project initiation and typically contain the following information:

• Work package title/name.
• Code.
• Status.
• Total budget. (Based on days of effort.)
• Start date.
• Completion date.
• Personnel/resource.
• Project code. 
• Comment.
• Purpose of the work package.
• Key objectives.
• Success measure.
• Tangible deliverables.
• Type of deliverable.
• Key dependencies.

Additional work packages may be added during the project if required.

Project budget

On some projects you will be given a budget to work to, and on others you may be asked to provide estimates and work with the stakeholders to agree on the budget. If you are involved in setting the budget, ensure the estimating process is rigorous. This is critical; you don’t want to go back to the project board for additional budget. This undermines confidence at best, and in the worst-case scenario, additional budget is not available, resulting in the project being cancelled.

However, we all know that things in the real world can impact projects. Agree on a reasonable contingency percentage based on your confidence in the estimates.

Benefits management plan

The key to a benefits management or critical success factors plan is being able to measure the outcome of the project. This section of the document should contain the following information:

• Descriptions of the critical success factors.
• The methods for measuring and reporting the factors.
• Stakeholders and business owners that will be involved in the review of the project.
• Project owners responsible for delivering the required outcome.

Communications plan

In many cases the communications plan isn’t delivered at the start of the activities, and this is a mistake. It is critical to keep the team and stakeholders updated from the beginning of the project. Such communication builds confidence in the management of the tasks and prevents people from making assumptions on progress.

Please ensure that you are delivering relevant messages to the different stakeholders. The IT teams will have different communication requirements compared to the senior stakeholders. 

Align the communications and reporting to the dates of the programme board meetings. Furthermore, please don’t use IT jargon or acronyms in communications to senior stakeholders.

Quality plan 

A quality plan is an essential component of a successful project. How many times have you heard the following statement? ‘Quality assurance is just part of managing a project.’ Please push back on this. A document with the following is required to ensure that you deliver a quality project:

• Quality standard principles. You should adhere to principles that are relevant to the project you are managing.
• The individual or individuals accountable for meeting the predetermined quality standards.
• Quality standard measures. (Data quality, training satisfaction, reduction in manual effort, delivery of critical success factors, risk score, IT and business cutover readiness, dress rehearsal results, etc.)
• Quality reviews.
• Quality reports.

As with all documentation and activities, take a pragmatic approach. This doesn’t need to be a long document, but it will be beneficial to prepare a quality plan and communicate it to the project team and stakeholders.

2.     Issues that aren’t discovered in standard testing phases

There are several serious issues with the standard approach to testing on IT projects:

• Test coverage. Scripts and scenarios may not represent the complete business process.
• Assumptions regarding timings. It's possible that issues won't surface until after the cutover. This is a particular risk for complex business processes with multiple steps.
• Limited user participation. When a relatively small number of people test for the entire organisation, issues may be missed, including data issues that can cause severe disruption.
• Lack of exposure to the new systems is a problem if you have a limited number of users involved in testing.
• Using data that does not reflect BAU after cutover. This can cause issues on any type of project, but the problems can be acute on finance or safety-critical systems. 
• Security testing may not be scheduled at the appropriate time. Updating the security configuration may take considerably longer than anticipated. In addition, third-party organisations may have a long lead time for retesting.

These issues are the reason dress rehearsals are invaluable. 

Dress rehearsals  

Dress rehearsals reduce risk substantially, and they do more than any other activity to prepare the organisation for go-live. They can be included in any project, work with all methodologies, and provide a high level of cutover assurance.

Let’s look at two types of dress rehearsals: business scenario dress rehearsals and cutover dress rehearsals. Let’s start with business dress rehearsals.

What are business scenario dress rehearsals? 

In this activity, users complete core business processes in an isolated environment to provide the highest level of assurance for cutover and BAU. The business decides on the key business scenarios with advice from the project team, if required.

What are the principles of dress rehearsals? 

• Users run their critical business processes in a dedicated environment to prove readiness for go-live.
• The mindset of the dress rehearsal participants is that this is the first day of go-live.
• The business scenarios are agreed upon, and the users run them exactly as they will in BAU.
• Test scripts are not used.
• The dress rehearsal sequence is based on business priority and level of risk. The most critical ones are completed first. Please note that multiple scenarios may be run in parallel.
• Superusers assist the participants, and the support team is on call in case there are any issues.
• People responsible for the role after go-live should complete the activities in the dress rehearsal. They could identify system or data problems that the test phases overlooked.
• Run at least the first week’s BAU activities and additional weeks if possible. (One full month is recommended.) Include any additional priority activities, such as critical reports, etc.
• Dress rehearsals are not a rerun of UAT or any other test phase.
• Ideally, production data should be used for the dress rehearsals to ensure data quality and to confirm the validity of the dress rehearsals. Run real-life scenarios using live data wherever possible. For example, processing a full day’s worth of transactions.
• Roles and permissions are validated to ensure they will support BAU processing.
• Run integrations using the production schedules and BAU volume data to prove timing.

3.   Lack of preparation for cutover

A failed cutover is an unmitigated disaster for a project team. After all the work during the project lifecycle and the effort of achieving approval to go live, aborting the cutover over the weekend is soul-destroying. The result is additional work for the team, concerned stakeholders and disappointed users. This is not the result any project manager wants.

What’s amazing is how often people claim that simply walking through the runbook with a paper-based exercise will ensure everything goes smoothly during the cutover. Please don’t take their advice! The stakes are too great to depend solely on a plan review.

The only way to have the assurance you need is to complete a cutover dress rehearsal. You may hear dissenting voices explaining all the reasons why this can’t be done, but please push back on this. You may have been told that there isn’t enough resource, they don’t have a suitable environment, the data isn’t ready, security settings haven’t been signed off or any number of other excuses why the cutover dress rehearsal is impossible.

Please do everything possible to run a cutover dress rehearsal. If you are close to cutover and critical data and security activities are outstanding, demanding a rehearsal will focus minds and ensure completion before cutover.

Please find below an overview of cutover dress rehearsals.

What Are Cutover Dress Rehearsals?

Cutover dress rehearsals are specifically designed to verify your readiness for go-live by simulating every task in the cutover runbook. These rehearsals take place in an isolated environment or, ideally, in your To Be production setup. Here’s what makes them special:

• They focus on executing all technical tasks, such as data migration and integrations, exactly as they’d happen during the actual cutover period.

• They include communication protocols, ensuring everyone involved knows what to do and when to do it.

• They address data quality assurance. Using production or mirrored data lays bare any hidden issues that could derail your go-live.
• 
  

Cutover rehearsals create a safety net, capturing potential problems before they have real consequences.

Key Principles of Cutover Dress Rehearsals

Follow Every Step in the Runbook

The cutover runbook is the reference document. The purpose of rehearsals is not only to complete tasks but also to ensure that each step is feasible and within the allocated timeframe. If you can’t meet the timings, please find out why and adjust.

Treat Time as a Constraint

Timings dictate the success of your cutover. Will an eight-hour data load really complete in that timeframe? Can integrations activate without bottlenecks? Dress rehearsals let you refine and perfect these timings.

Prioritise End-to-End Practice

From initial notifications to final system checks, every detail matters. Ensure members responsible for their respective roles during cutover are also the ones performing these duties during rehearsals. This continuity boosts confidence and reduces uncertainty.

Validate Data Quality

Use real data wherever possible. This not only uncovers data migration issues but also ensures end-to-end integrity across systems.

Include Communications

Cutover rehearsals aren’t just technical exercises. They also test your communication plan. Simulate conversations between stakeholders and test how effectively updates are shared during each phase.

Project examples that show the value of these activities

Every project is different. Understanding how to view each one holistically and add the required actions is critical. You need proven principles and actions that work with any methodology.

A few examples include:

• A complex transformation initiative for a prominent charity. This project involved an application that replaced manual processes, new infrastructure and substantial business change. It had a fixed deadline, and dress rehearsals were critical in the successful delivery of this project.

• A programme for a prestige car company required professional project initiation and management. There was a hard deadline and fixed budget on this multi-year programme. Work packages were used to define deliverables, resource requirements, dependencies, budget, start/completion date, objective and success measures. The work packages were used as building blocks for the detailed plan. They were also used extensively for reporting to senior stakeholders. The project was delivered on time and £10K under the original budget. On average, projects of this type went back to their boards four times for additional funding.

• A major insurance company with over 5 million customers replaced their legacy systems with a leading claims management system. The cutover was complex and time constrained. It required detailed planning with tasks at no more than 15-minute intervals. The estimates for data migration were incorrect. After a change in strategy and a cutover dress rehearsal, the team confirmed the timings. This allowed the system to go live successfully.

Summary

Regardless of the methodology, or if you are not following any formal approach, it is important to include these activities in your plans. They have been proven on multiple projects and will significantly increase your probability of success.

Pathway IT offers leading project management training courses and consultancy for project initiation, dress rehearsals, and cutover management. The principles taught in the courses have played a crucial role in the success of major programmes for leading companies in the media, automotive, insurance, banking and charity sectors in the UK.

The Pathway IT project management courses are pragmatic and provide invaluable insights that will allow you to deliver complex projects with certainty. They are available in Milton Keynes or at your location anywhere in the UK as instructor-led or self-study courses. 

Best of luck with your projects!