If you’ve designed and built software for as long as I have (more than 20 years), you’ll have a whole lot of experience dealing with disasters. I’ve had a couple in my lifetime that could have been expensive disasters if not for my knowledge of trading stocks.
You see, there’s this little secret to trading stocks, and it’s the one technique that separates the chaff from the wheat. Knowing when to cut your loss. That’s right. You’re going to run into something some day when you’ll just have to know when to quit. If you can see the disaster coming early enough, you can avoid the cost of the disaster. Sort of like seeing a tornado far enough in advanced to jump out of the way. In the case of stock trading, you need to cut your loss before you lose too much money. In the case of software, you need to cut your loss as soon as it starts to look like a loser.
Enough of the metaphors, time to get serious. The number one thing you need to do when designing and estimating is break your software project into the smallest pieces possible. Then estimate the tiny pieces and roll it all up. If you have a chunk of software that is kind of gray in your head, you’ll need to focus on that piece and maybe do some mock-ups or a small and cheap demo. When you have your numbers, your resources are in place, you’re authorized to start the project, then you need to actively track your progress. By the time you’re 5% into your project, you should start to see a pattern emerge. Is it behind schedule? Is it really behind schedule (more than 20%)? How do the tasks that are currently completed compare with the tasks left to do? If the remaining tasks are comparable to the tasks that have been completed, then you’ll never finish within your budget.
Let me clarify what I’m talking about here. I’m not talking about meeting a scheduled deadline. If your company needs this software and is willing to just throw more money at resources, then you should attempt to throw in more resources early on to get ahead. However, most companies base their software development on ROI. Than means cost. So being behind means that either you have to work your current programmers more hours and pay them more, or you have to work more programmers which costs more (I know, that’s really obvious, except “programmers” don’t think that way).
So you’re already behind schedule and it appears that the project is going to go into ugly territory. In other words, it looks like the whole thing will probably cost 1.5 to 2 times as much as originally estimated. What do you do?
The first thing to look at is the features that this software will contain. Are there any features that have questionable value for the customer? Maybe you can trim back on those and make up the difference. The ROI will come out the same if the value of the overall software package is perceived as the same. Maybe the software you are developing has only 5 primary features and all other features are secondary in nature. It’s possible that you could defer these features to a future version of this software, say, after the profits start rolling in.
Let’s say that your software is cut to the bone. It’s lean and mean and any feature left out will reduce it’s value as a package. Like leaving out the accounts payable section of an accounting package. Just can’t do that. Now what do you do? This is the point where I usually think about cutting my loss. I would build my supporting evidence, show my projection of how much this project will cost to the people who authorized the funding. Then give my recommendation. Maybe they will think it’s worth the extra money. Maybe budgets are tight and the funding will not be available to complete the project. If that happens, then it’s ALL STOP!
Fortunately, you’ve put a stop to potential loss. Now you can re-evaluate the project and possibly use a different technology. Maybe the interface is not worth the effort and an easier to build interface could do the trick. Maybe a different programming technique can be used to make things easier. Programming tools? Different mix of programmers? There are so many options at this point. Fortunately, you’re not bleeding money while you’re re-analyzing the project.
Cutting your losses is not necessarily a good thing. Sometimes you have to go with your gut, grit your teeth and push through. If the remaining tasks in your project appear to be easier than the tasks that were completed, you can probably pull it out of the fire (assuming you’re not too far behind). Don’t be too averse to risk or you’ll never finish a project. I’m just telling you that you should be aware of your situation at all times and never ride a disaster into the ground.