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.

Pathway has extensive experience rescuing business-critical projects and programmes. This includes organisations in the insurance, banking, media, rental and charity sectors. This experience provides a unique insight into the core reasons for the failures.

Please note that some issues may span different phases of the project. For example, lack of stakeholder engagement could be an issue at any point in the project. These points aren't duplicated in every section.

Let’s look at the following: 

Project Initiation

• Failure to align the project with strategic business objectives.
• Not agreeing on critical success factors.
• Inadequate budget.
• Inaccurate estimates.
• Lack of planning.
• Not allowing additional time for the first use of new technology/development tools.
• Overallocation of resources.
• Failure to review all constraints and dependencies.
• Not considering items with long lead times in the planning. Examples of this include data quality assurance, security, infrastructure and system integration.
• Failure to consider that virtually every project is different and the organisation’s standard methodology may not be suitable is a common mistake. For major transformation programmes, a hybrid methodology may be the best choice.
• Lack of stakeholder engagement and input.
• Not agreeing on critical success factors.
• Selecting the wrong technology for the project.
• Not enough consideration for business change management.
• Inadequate provision for training.
• Failure to include quality assurance activities in the plan.

Project Resource

• Insufficient training of project managers and other key people on the team. 
• Inadequate level of resources.
• Booking resources 100% of the time, therefore not taking holidays and illness into account. Best practice is to never exceed 80%.
• Incorrect assumptions on third-party resource availability.
• Not having contingency resources. Especially SMEs, senior technical resources, third-party resources and security.
• Not having named resources in the plan.
• Inadequate resource planning, resulting in excessive demands on the team and burnout.
• Project managers allocated to complex projects/programmes above their skill level.
• Project managers attempting to run cutovers without the required level of knowledge.

Managing the Project

• Introducing new methodology without training or support. 
• Lack of understanding regarding stakeholder management and communications.
• Requirements are not defined, or there is a lack of agreement on the functionality that must be delivered.
• Using the wrong methodology or refusing to use hybrid methodologies.
• Reluctance to enhance methodology.
• Not updating plans or project boards in a timely manner.
• Not managing dependencies and constraints.
• Not proactively managing risks and issues.
• Lack of understanding of the Agile methodology.
• Teams working in solos.
• Poor communication within the project team and with stakeholders, users, and the organisation.
• Not challenging third-party project plans or their approach. Please be wary of overly aggressive vendor project plans. Don’t agree to them without a thorough review of the plan, including resource availability of your team and demands on the wider organisation. On many projects, it will be beneficial to prepare an overall plan and embed the vendor’s activities in your plan.
• Not engaging the support team at the appropriate time. (Throwing the project over the fence during the cutover weekend is not advised!)
• Assuming specialist security resource availability. (The best third-party security test companies will usually have a long lead time.)
• Underestimating the time required to make updates to the configuration, infrastructure, applications, etc. after the first security test.
• Not including time for additional security tests in the plan. (After the recommendations from the first test and required updates.)
• Inadequate change and configuration management in the pre-production environment.
• The configuration of the pre-production environment not mirroring production.
• Underestimating the time required for data extraction, transformation and load.
• Overestimating data quality and underestimating the time required to update the data to make it fit for BAU after cutover.
• Not having a simple way to objectively determine the risk level at any point in the project.
• Not being able to determine the expected level of cutover risk early in the project. (For example, things that will remain high risk regardless of the team’s actions.)
• Inaccurate status reports, possibly due to fear of reporting items as amber or red.
• Testing with data that does not represent BAU, therefore invalidating the tests.
• The scope of tests is too narrow.
• Not testing the critical business processes end-to-end. 
• Inadequate time for non-functional/performance tests.
• Not using testing tools.
• Not automating regression testing or other test phases.
• No contingency in the plans or insufficient contingency.
• An inadequate number of environments to allow the required level of parallel activities. Examples of such activities include development, testing, and dress rehearsals.
• Inadequate testing of data flows over integration points.
• Not testing the BAU schedule for overnight processes.
• Inadequate testing of monitoring leading to BAU issues.
• Not controlling the scope. Accepting change requests without analysing the impact on the budget and timelines.
• Not running dress rehearsals. They are the most effective risk management activity you can undertake.

Cutover

• Not engaging the BAU support team at the appropriate point in the project. (Please engage them early in the project. This will benefit everyone.) 
• Using a paper-based exercise instead of proving the cutover by running a cutover dress rehearsal.
• Not having contingency resources on standby in case of illness or emergency.
• Not having agreed escalation procedures for the cutover, including agreeing on members of the escalation group.
• Not determining whether rollback is possible or the only option is to fix forward.
• Not preparing the correct level of handover documentation for the support team.
• Not training the superusers or the support team to the required level.
• Not agreeing on roles and responsibilities between the project and support teams.
• Inadequate warranty period for project team support.
• Monitoring not in place or inadequate coverage.
• Not agreeing on the frequency of support meetings for the period after cutover.
• Lack of communication to the stakeholders and to the complete organisation.
• Not communicating the role of the superusers.
• Not ensuring that key resources from the project team will be available during the warranty period.
• Not involving the support team in the dress rehearsals. This is a key opportunity to prepare for BAU support. 
• Not preparing quick reference documents.
• Not communicating the formal handover from the project team to the support. (To the relevant people, this should be transparent to the users.)

These are examples of things that cause, or contribute to, project failures.

Pathway IT has a number of ways to help you to deliver projects successfully, including training and support.

Training courses:

• Advanced Project Management Training
• Cutover Management
• Dress Rehearsals
• Methodology Selection and Enhancement
• Project Governance
• Project Initiation
• Risk Management

 Our comprehensive support includes:

• Training requirements review.
• Project management support.
• Project reviews.
• Mentoring. 
• Project rescue.

This is practical project management training and support based on real-world projects and issues. Everything is based on lessons learnt from delivering demanding, complex, and business-critical IT projects and programmes.