On Deadlines and Prototypes

In the software world, deadlines are often viewed with suspicion. Rushing to meet an artificial deadline leads to bugs and technical debt. Trust the team to work as fast as reasonable, and the work will get done when it’s done. Estimates are a common replacement for deadlines, but even that can be a stretch.

This approach can work if your user is a hypothetical member of a large target market. But if your target user is one of a handful of people inside your organization, you need to make sure that the project is ready at the same time they are: when the data is available, when a decision needs to be made, when the investors expect to see results.

Aligning the development timeline with these external events can make the difference between the project making a big impact on your organization, or your project sitting on the shelf unused. But how do you meet these external deadlines without imposing the sort of hurry that will lead to longer-term problems?

From the very start of any project, you should be thinking about the earliest opportunities to have internal users try it out. But rather than rush to have the project completely finished in time, you should think about how you can turn the pieces that can be ready in time into a partial prototype. That might mean using Excel for some parts of the process. It might mean manually handling some steps that will be automated the next time. As long as the general shape is right, it doesn’t matter if there’s cardboard and duct tape under the hood.

Not only will this give you early feedback that will help validate and refine the project; it will begin to form the external processes that your software will fit into. And those external processes are often much harder to implement than the software itself.