How to Restart Development on a Project

Finishing Projects

Unfortunately, there are many software projects that fail to be completed. The development at some point became stalled, and while costs racked up, the project wasn't moving closer to being finished. As a software development firm that specializes in taking over failed projects, we've seen a lot of examples. Usually the reason for failure is some variation of the list below:

1. Failure to work on the critical path first

   Developers have to determine the trickiest parts of the project (the ones with the greatest technical risk) and prove that they can implement those. Often we see projects where all the "easy" work was done, but the part that is required to actually make things work is left undone. Usually the developers have backed themselves into a corner, and it is impossible to connect the work that they have done to the missing piece without significant rework of their code. Recently we worked on a project where another company had tried to make a website to connect to a database driven application. They made the UI, but they ignored the database until the end. At that point, they discovered that the database was not structured as they assumed. For example, they assumed that each client would have a single contact person. But the database allowed multiple contacts per client. They assumed that all clients had the same starting and ending times for their work shifts. But of course, each client has different times, and different facilities or occupations within a client have different times (i.e. a janitor may work a different shift than a receptionist). Their UI just had a shared list of starting and ending times for all clients. Of course, that would never work. I suspect that the other firm had web programmers and almost no experience with databases. They ignored the critical part of the project because they had no ability to review the database and determine the semantics of it.

   They should have started with manually adding clients and modifying the client data using SQL. Then testing their changes with a test system. Then before they started on the UI, they would have known how the data was structured, and how the UI should be designed to support that structure. The customer initially thought they were making great progress, as they created the UI quickly using dummy data. But then weeks and finally months went by without the completion of the project. They were never able to successfully display the real data in their UI. In this case, the UI had so many areas that would have to be rewritten that we used another code base (a different website that used the same db) to create the client portal. We started with the integration to the database and added functionality in steps, where each step was fully functional. The portal was completed in much less time than the initial work.

2. Failure to define the minimum effective product

   Some projects never seem to end. As more functionality is added, new ideas are brought forth, and changes requested. This is a normal and natural process, especially for a project that is successfully implementing its functionality. But at some point, the project needs to be released. I always describe to customers how Microsoft Word was released in 1983 and has had continual development since then (for 42 years!). For many projects, there are useful features that can be added without a end in sight. Just because there is "one more feature to polish" doesn't mean that the project wouldn't be useful to customers now. A business decision has to be made as to what is the minimum set of features that will be useful and provide value to the customers. And the development must be initially focused on that set of features. That doesn't mean as development proceeds that a new feature or change will be discovered that is important, but it does mean that each change must be evaluated against that minimum set of features, and its impact on the schedule determined. It is much better to make many small releases, than a few large ones. You will provide value to your customers sooner, and most importantly, you will receive feedback earlier in the process. The sooner you get that feedback, the sooner you can make changes, and the less code will need to be altered to support those changes. In other words, it can be vastly cheaper and more effective to implement those changes as early in the project's life as possible.

3. Not developing the software incrementally

   This brings us on to the third failure method. In order to lower the risk of a project, you can make a series of small releases instead of one (or a few) large releases. These days with websites and mobile apps, the hassle to users for an update is very small. Most people never notice when a website or mobile app is updated. They may discover some new feature, but in general, the updates are seamless. Your developers must structure the implementation of features, so that they are implemented in an order that allows the project to be released frequently.

   The risk for a project usually is exponential to the number of changes made. That is because each change usually has an effect on all of the other changes and the existing code base. For example, if you want to make six changes, according to the simple chart shown, if all of those changes were made in a single release, the risk factor would be 36. But if you made three small releases of two features each, then the total risk factor would be 4 + 4 + 4 = 12. Or just 1/3 of the single release risk. Obviously, those numbers are just made up, but they do tend to correlate with the real factors based on my experience. Small incremental releases are the lowest risk way to release code.

4. The developers not focusing on (or even know) the business goals

   Some developers will not want to know the business goals for the project that they are working on. You do not want those developers working on your project. They are being lazy, and just want someone to tell them exactly what to program. The idea that someone can specify a project so well that even without knowing the goals of the work, that the developers can implement it is bogus. You want a developer that is curious about your business, and tries to understand the business goals of the software. No matter how well specified a project is, there are always numerous small things in the software that can be made better if the person creating the feature understands the business goals behind it. If your developers do not understand what you're trying to accomplish, they are essentially programming with one armed tied behind their back.

5. Inability to determine the ROI of features

   Along with understanding the business goals, you and the developers together must be able to decide the return on investment (ROI) for a feature. This is almost always requires the combination of both the developer and the business. The business can determine the return (the value) of a feature, but they cannot usually determine the cost. While the developer cannot specify the value of a change very precisely, but they can determine the cost to implement it. Both of those pieces of data are needed to determine the ROI. We've seen cases where a feature had weeks of development on it, but an alternative implementation might have provided 90% of the value, with 10% of the work. This just reinforces the need for the developers to know something about the business goals, and for the business people to be talking to the developers on a regular basis. Then the developer will know enough to question the ROI of a feature, and possibly suggest alternatives. This type of back and forth is needed to avoid mistargeting development dollars.

The correction of these issues is just the reverse of the errors. Define the minimum effective product and work on the critical path first, creating a set of small releases that steadily moves you to that goal. Understand the business goals, and in consultation with the business, make sure that the features have a high ROI. Obviously, counter examples to my list of reasons can be thought of. But, those will be exceptional cases, and in the vast majority of cases, the rules above will apply. We'd love to talk to you about your project, and what can be done to get it back on track and completed. Please call or contact us using the form below.