Embarking on a custom software development project is essentially crossing into uncharted territory. Although we most likely won’t face dragons, there are risks. But, it’s by taking risks that you reap rewards. The creation of new software with custom functionality gives you a powerful tool that’s unique to your business. Building that tool requires trusting in a non-linear process.

Software development is called an empirical process because the requirements are expected to evolve; the process can’t be defined from the start with a set series of steps. To people outside the software development world, this flexible process is often a surprise. Within the industry, Agile software development and the Agile manifesto are well known. I like this quote from Estimation is Evil by Ron Jeffries, Signatory of the Manifesto for Agile Software Development:

Most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this: “requirements,” “the very beginning,” and “all.” At the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we “require.”

Of course, we start with discovery and a plan, but it’s more useful to think of the plan as the definition of the project’s value rather than a destination. For deliverables, we use the adaptive approach favoured by Agile methodology. What that means is we develop and deliver features incrementally. Regular delivery of working software gives our clients the opportunity to see value early. Incremental delivery also builds confidence in the team and our process, and gives clients the opportunity to provide feedback right away.

Collaboration and communication are essential for product success

As we embark on the process of creating something unique, issues, questions, and problems will arise. These challenges are an expected part of the process, and they serve as opportunities to recalibrate the project’s value. Throughout the project, our team collaborates with the client team to find the simplest, best solutions to every problem. In some cases, a problem may be a rare occurrence that’s best solved by allowing manual intervention rather than increasing the scope of the project and expending more resources.

Project value must take priority

To minimize problems, it’s essential to keep functionality and value as priorities. Two factors can threaten functionality and value are feature requests with low return on investment, and schedule constraints. It’s normal for some additional feature requests to arise after the project is underway, but to maintain project integrity, those new features must be evaluated against the overall goals for the project. New features may be great ideas, but can also cause endless rework and compromise the forward momentum of the project.

Meeting scheduled milestones is important to keep the project moving in the right direction. However, there can be instances where sticking to the immediate schedule could have a high cost in the long term. If implementing the best solution to an issue requires some schedule flexibility, then a difficult decision must be made. Sticking to the schedule purely on principle doesn’t support the objective of creating a unique product with high value.

While in a sense a product is the result of software development, the process is closer to research than manufacturing. New information will be revealed as the process moves along. Each new piece of information must be evaluated and incorporated to best serve the overall project. If the schedule takes priority over project value, essential information may be discarded to the detriment of the project’s overall value.

The reason for examining these misunderstandings isn’t to cause hesitation in starting a project. My intention is to offer some insight about why the process isn’t straightforward and why we want to keep it that way. Ongoing discovery throughout the process allows the end results to be innovative and transformative.