This is a story of a project that was critical to a company’s continued success that had a hard deadline due to governmental regulations. Though things started out ok and progress was good unknowns quickly cropped up and caused trouble. Programs were making it to the quality assurance folk just before the deadline or slightly after the deadline. This didn’t include getting the programs to the user acceptance testers let alone production. Everybody was stressed out. All because software development ALWAYS takes longer than you think it will.

It Starts With Requirements

Over the years I’ve come to realize that, even with a capable team of business analysts, project managers, QA, and developers, estimating the amount of time necessary to complete the requirements is HARD. Yes this team of folks will get better at estimating as they work together and gain experience with the code base and domain of work. However there are always unknowns when determining what has to be done to complete a project. Unknowns will be present whether the project is a new feature or maintenance of old code. This requirements analysis needs to end with sensible expectations of what can be completed in a defined amount of time. Because of this there are several things that I think can help:

• Make sure that the requirements are carefully broken down as much as possible
• Once they’re broken down review them again to determine the minimum viable product
• Prioritize the requirements to make the minimum viable product and beyond
• Regularly re-review the requirements as work is completed to redefine the minimum viable product and the priorities.

Minimum Viable Product

The big question that needs to be asked when gathering requirements is: What is the absolute minimum that has to be done for this project to succeed? What can’t we live without?

The answer to this question will very likely be less than what anybody wants or expects. I am not advocating for developing barely functional software. What I am suggesting is that the end product needs to get the job done. Everything else can be done later.

• Having all the convenience items on a user interface? Those can come in a subsequent release.
• Looking fantastic? Also in a subsequent release.
• Easy to use? Subsequent release.

Years can be spent planning out what would be the “best” way to make something look and work. All that hard work won’t survive contact with the users. They’ll find the real pain points and things that are important quickly. Those are the problems you need to solve and polish first.

Understand and Accept the Risks

Part of deciding what the minimum viable product is when faced with a hard deadline is understanding what risks are acceptable to meet the deadline. This involves one basic question: What happens if we don’t have all the requirements done at the deadline?

This is an important question that will likely spawn many more questions. In the situation I found myself in the questions that came up by asking the above were:

• What will happen to reports that are run if we haven’t gathered the newly required data?
• Can we back fill the data and re-run reports so they show the appropriate values?
• How do we communicate to our clients what is going on with the reports and why?

By asking these questions we were able to generate a better understanding of our situation. This allowed us to quell the panic that was rising with the looming deadline and, instead, handle the situation as best we could. In short, we were able to define some of the risk we were facing even though there were unknowns in the project and schedule.

How did these affect my project?

So far I’ve listed a few things that can be done to safeguard a project from running to long but haven’t listed how they affected what I was working on. It turns out that the unknown we hit with how long it would take to update a particular section of code. Because we didn’t have a minimum viable project plan in place we had to scramble to figure out what we could live without to get the project finished ASAP.

There were several lessons that I learned here that were important. First, it pays to have both a set of best case scenario plans and a minimum viable product plans. Second, there are always things in development that will go wrong or take longer than initially estimated. And, lastly, take time to re-evaluate your plans regularly to determine how much of them can be realistically finished.