Why are software projects so hard to deliver on-time and on-budget? Here are 5 steps to avoid setbacks.

As IT systems become an important competitive element in many industries, technology projects are getting larger, touching more parts of the organization, and posing a risk to the company if something goes wrong.

Unfortunately, things often do go wrong. Research suggests that, on average, large IT projects run 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns.

So how do companies maximize the chances that their IT projects deliver the expected value on-time and within budget?

Surveys of IT executives indicate that the key to success lies in mastering a value-assurance methodology for large-scale IT projects. This approach gets companies to focus on managing strategy and stakeholders, master technology and project content, build effective teams, and excel at core project-management practices.

Of course, doing all of this is much easier said than done. In order to avoid huge costs, you need a carefully constructed plan. Digital plumbing and enterprise architecture are getting more sophisticated and integrated each year, increasing the complexity and dangers of replatforming.

This being said, improvements in software can help lead to greater returns. This makes the process necessary, in spite of the risks and costs involved. New functionality gains can help an organization become more effective and more competitive. In fact, by not replatforming, you can lose market share to better-equipped competitors.

Replatforming can improve customer experience, speed up time to market for new products and services, increase the ability to expand and scale, improve security and compliance, and evolve enterprise architecture. Therefore, it can be one of the most important processes an organization undertakes.

The Perils of Software Projects

As discussed above, software replatforming comes with some giant perils. It is expensive and disruptive. It requires trust in vendors who are focused on their own interests. A replatforming failure can (and often does) set an organization back years and cost the organization dearly in time, money, and employee satisfaction.

There are many reasons why software projects fail. These reasons include (but are not limited to):

• A lack of experience with the size and scope of the effort
• Immature internal project management processes
• Poor vendor selection
• Poor vendor negotiations
• Failure to properly document needs and requirements
• Failure to properly test and/or train employees on a new solution
• Confused decision making

There are also many reasons why re-platforming will always be needed:

• Increasing Market Competition & Continually Improving Customer Experience Techniques
• Better Control, Manage, Predicting (though not necessarily lower) of Operational Costs
• Faster Time-to-Market for new Products/Services
• Moving from On-Prem Solution to Hosted/Cloud-based Solution
• Moving from Home Grown to Commercial off the Shelf Solutions
• Increased Ability to Expand and Scale
• Increased Focus on eCommerce and Self-Service
• Regulatory Compliance (i.e. Cybersecurity)
• Better Enterprise Architectural Fit / Technology Marketplace Viability
• Loss of Support / Vendor Viability

The solution to the software problem is adopting a comprehensive SOFTWARE REPLATFORMING FRAMEWORK (SRF).

What is a Software Replatforming Framework?

The SRF process involves four key stages. Here is our specific process:

Stage 1: Go / No-Go – In this stage, we help you decide if you should invest the time and energy on the replatforming project. We help with strategy and approach to the problem, develop a business case or return on investment analysis, understand true readiness and the challenges and issues you will face, and ultimately help you make the final decision on whether or not to proceed.

Stage 2: Discovery/Requirements – This stage is devoted to understanding your processes and requirements. We help to inventory and prioritize processes, interview process owners, and ultimately engage in process mapping. Finally, we help to identify and quantify your requirements and develop a requirements matrix.

Stage 3: Solution Decision / Contract & Purchase – We begin by helping you make a build vs. buy decision. If the decision is to buy, we begin the process of vendor selection. This includes RFP development. We take the RFP responses and begin scoring vendors based on your requirements. We help you organize and hold vendor demonstrations. Then we help narrow the finalists down and engage in vendor due diligence. Finally, we utilize our vendor relationship and contracting process (VRCP) to engage in vendor negotiations (Learn more about our VRCP).

Stage 4: Implementation / Program Management – In the final stage, we help you understand the resources you will need and decide how to restructure your team for the project. We walk with you in the development of a planning and release strategy, through the installation and migration, and finally into testing, training, and release.

Stage 5: Lessons Learned – The final stage helps you to forensically examine how the effort went. Throughout the process, we are conducting pulse surveys to understand how the project is unfolding. In this stage, we take a look back at the entire project, including these surveys. We interview stakeholders and develop an analysis and evaluation of the the results. This is shared with leadership so they can understand potential areas of improvement. This is also the stage where we permanently upgrade any necessary governance and policy changes.

When an organization does not have a good software replatforming framework in place, the following is likely to occur:

• Meeting unrealistic expectations in duration, effort, and cost
• Cost overruns and delayed delivery.
• Distracting your organization from its core mission for months at a time
• Being locked into a toxic relationship with a software vendor for years
• Purchasing a solution that does not live up to its promise as sold
• Project fatigue with the implementation process
• Failure to well align business processes to new available solution functions/flows
• Failure to adequately train personnel in new solution and processes
• Rushing to “Just Get It Done”