An Executive’s Guide To Project Recovery.
You’re exhausted. Beyond frustrated. Nothing is going as planned with the organization’s software development project. The entire project is significantly overdue and over budget. And no one appears to know the source of the breakdowns. You reluctantly admit it’s starting to take a noticeable toll on company morale and performance. Now fast forward ten months.
You’ve just witnessed the rescue and recovery of your organization’s largest software initiative. Looking back, you realize the situation was more critical than initially thought, so the turnaround is that much more unbelievable. How was it saved? Because you recognized, addressed and did what was necessary to recover the project. And after months of work, it is paying off – the company is experiencing significant growth.
When faced with the possibility that your software development initiative might be in jeopardy there are two choices:
01: Stay the course. Identify the root causes putting your project at risk and work with your current software development partner to resolve them. The deeper into your project you are, the more difficult this will be.
02: Recognize it’s too risky to continue, cut your losses and find a new software development partner to work with.
What’s the right path for your situation?
Use these four key considerations when trying to determine the fate of your project.
01: Recognition: How do I know if my project is in jeopardy? Is it time to shift course?
02: Evaluation: What is the cost of changing course, and what is the cost of not?
03: Expectations: Am I totally committed to doing my part in the project recovery process?
04: Partner: What should I do to find the right software development partner?
How do I know if my project is in jeopardy? Is it time to shift course?
The first and perhaps most important step – recognize you have a serious problem and conduct the proper analysis to determine if the project can be saved (i.e. stay the course with your current partner and hope the root cause of the problems are not only identified soon, but can be fixed once they are found). If you are experiencing the following symptoms, you should consider shifting course:
1. Significant timeline and budget overruns without any end in sight.
Software projects are by nature complex and require multiple people with diverse backgrounds, focuses and skillsets to work in harmonious coordination. Because this is a difficult proposition in and of itself, it’s common for misunderstandings to result in mistakes that result in overruns. Tweaking code early on is typical. Major rewrites deep into the project are a good indication that there could be issues with the application’s architecture. If your vendor routinely expands scope and misses milestones, this is a warning sign that something is amiss.
2. Important features and capabilities fail to operate as intended and designed.
User acceptance testing is critical to ensure your application performs both as designed and as intended, which are two different things. If the application performs as your partner designed it but fails to meet your requirements, this may be a sign that you and your partner are not on the same page regarding your goals. If you’re satisfied your new application does include all your requested features, but fails to operate properly or breaks easily, this could be an indication of brittle architecture and/or bad code. Either situation can keep you from reaching your ultimate goals and result in an artificially inflated total cost of ownership.
3. Communication and trust breakdown.
Good communication and trust are critical to the success of any project. Constructively challenging your partner’s thought processes and rationale for overruns is a normal and healthy part of the process. However, if you begin to feel as though you’re getting more excuses than action, it’s time to have a frank discussion with your partner about your concerns. At this point you should also begin evaluating your alternatives. This will at a minimum shed light on whether your suspicions about your partner are valid and if so, how feasible it would be to switch to a new partner.
What is the cost of changing course, and what is the cost of not?
When evaluating your alternatives it’s important to not only analyze your partner’s performance but yours as well. If you discover that your team is equally to blame for the inordinate amount of project dysfunction, switching partners may only exacerbate the problem. Unfortunately however, as with any partnership there may come a time when the only viable option, no matter who’s more at fault is to sever the relationship. Two key questions should be considered before making a change.
1. What are the costs and risks to the company of staying the course?
As with any investment you must consider both the hard and soft costs of staying the course with your current partner. The key hard costs that should be considered are your partner’s fees, your internal labor costs to support the project, cost of financing the project, if any and the total-cost-of-ownership (TCO) to maintain the application. TCO often gets lost in the mix but it can have a significant impact on future budgets. A poorly architected and or coded application can be an ongoing money pit. The key soft costs that should be analyzed are the potential negative impacts to your customer experience and subsequent revenue losses as a consequence of launching a poorly constructed solution. You should also consider the potential negative impact to employee morale and the cost of diverting key team members from other important internal tasks.
2. What’s the feasibility and costs of switching partners?
Switching software partners isn’t like switching out a building contractor to finish a failed remodel in your home. Unlike a building contractor who can quickly assess the state of construction they’re inheriting, your new software partner will need time to understand your goals, requirements and the application’s architecture and code before coming to any viable conclusions. They will need to engage in a bit of detective work in order to gain a deep understanding of your prior partner’s coding style and technique. At the conclusion of this analysis they should be able to provide you with a ballpark level of effort necessary to accomplish your goals.
Am I totally committed to doing my part in the project recovery process?
Switching software partners in the midst of a key software initiative is a critical business decision and one that requires serious consideration. Be prepared to invest time in your new partner’s education regarding your goals, requirements and lessons learned. Making a switch to a new partner will almost certainly cost more in the short run, but if it’s the right decision, it will save you significant money in the long-run.
1. What to expect when switching to a new software partner.
Switching to a new software partner will require that they get up to speed quickly. Your involvement and commitment is critical for a successful outcome. They will need to:
a. Understand the goals and requirements for the new system.
It may feel a bit frustrating to revisit this initial planning phase, but keep in mind that your new partner currently has only a rudimentary understanding of what you want to accomplish. The good news is that you’ll be far more efficient in communicating your vision this time around as you should now have written requirements, specs and a working prototype to share.
b. Review the quality of architecture and source code.
Once your new partner has gained a deeper understanding of your goals and requirements, they’ll need to take a deep dive into the application’s architecture and source code. This is best accomplished by your new partner working with your old partner’s development team to gain a high level understanding of the architecture, code and documentation. This collaboration can be challenging based on the state of your relationship with your old partner. However, if they’re local, they’ll most likely cooperate if for no other reason than to protect their reputation.
c. Determine how much of your prior investment can be salvaged.
If you’re switching software partners it’s likely because the application isn’t performing to your expectations. Thus, it’s just as likely it will require some rework to remedy this situation. The amount of rework required is always the million-dollar question. The more accomplished and experienced your new partner is the more likely they will be able to salvage major parts of your investment. However, like a house that’s built on a faulty foundation, software is only as good as the architecture it’s built on. If the architecture isn’t built to enable the application to perform as designed, you could be faced with choosing between a major reinvestment to correct the issues or compromising the performance of the application.
d. Determine the estimated time and costs to complete work.
Estimating the cost of building a new application from scratch is an extremely difficult exercise in and of itself. To estimate the cost of taking over the build of a new application that is considered to be at risk of failing is exponentially difficult. Still it’s important to size the effort with your new partner. This will require that they provide you with time and cost estimates for the option(s) you’d like to consider. This isn’t the time to be coy with your new partner. Nothing should be left on the table. This decision requires frank and honest dialog to determine which course of action is best for you. It’s also advisable at this time to develop a risk mitigation plan that will govern future decisions for known and yet unknown risks.
Selecting your new software development partner is critical to the long-term success of the application to be built and the business processes it supports. While there are many factors that should be considered when choosing the best partner for your needs there are three that stand out.
1. Do they have expertise with the same software platform?
If you’re in the process of searching for a new software development partner, you’ve already determined that your project is in dire trouble and at risk of failing. This isn’t the time to start working with a new partner that “kind of” knows the software platform your application is written on unless you’re open to totally rewriting it in another language. Only a partner that has deep expertise and experience with your current platform can provide you the insights and options necessary to right the ship and achieve your goals.
2. How much experience do they have with project recovery work?
Helping a client through a project recovery effort is very different (and much more challenging) than managing a project from the beginning. It requires a strong aptitude for business, superior communication skills and a willingness to look for opportunities that preserve as much of their clients’ prior efforts and work as possible. You should request references from your potential new partner that will validate they have these skills and a history of helping their clients successfully navigate similarly difficult situations.
3. Do you believe your prior issues can be resolved by using them? When analyzing your potential alternatives, you’ll undoubtedly identify a number of things that your partner and internal team could have done better to avoid arriving at this point. Trust and communication, barring any incompetence, are the typical root causes of almost every other potential issue. Thus, it’s critical that you select a new partner you can trust, and one you feel understands the value of quality communication. Select a partner that will quickly bring issues and potential solutions to your attention, challenge your ideas for the betterment of the end product and is genuinely committed to ensuring you achieve your goals.
Anyone who’s been associated with a failing software project knows it’s a relentlessly frustrating and exhausting experience. It can totally consume every ounce of your available life space and negatively impact your company’s morale and performance. However, most will also admit that much of the chaos and pain they experienced could have been avoided had they heeded the early warning signs that their project was in trouble and taken corrective action sooner.