News

This article was inspired by Seth Godin's blog post titled "How long will this take?" Seth asks a series of questions that when answered would help shape the answer to the titled question, "How long will this take?" In our last quarter, we experienced firsthand the consequences of building a feature without asking all the right questions. The short answer to the question is, which we now know both in theory and in practice, by increasing the time spent planning, the faster the project will go overall because a detailed map will have been developed, reducing the chances of going astray.

Three constraints that determine the length of a project are budget, quality, and available resources. A deadline can be set first, but a realistic deadline will factor these in. Tight deadlines assume all the required resources are already in place or can be quickly gathered. We were asked if a timeline of a little over a month was achievable. On the surface this sounded reasonable because the request appeared simple - create a web interface for our pre-existing desktop software. The problem that we ran into however was that we didn't investigate what the implications would be of creating this interface, and how it would need to interact with our desktop software.

We started from this point: speed is of the essence. With this in mind, we didn't adequately consider these other questions:

• Will the spec change after we begin?

• Is this work that has been done by this team before?

• Are all the people, budgets and assets in place already?

• Is finishing it fast more important than doing it well or on budget?

This all happened at the start of the second quarter. It is now late-August. You probably see the issue. The web interface didn't take a month to create followed by two weeks of testing; it has taken us five months and counting. Ironically, we believe if we spent more time at the start answering all these questions we probably could have completed the projected not in a month as originally hoped, but within the quarter because we would have outlined and agreed on a specification document. The specification document would have highlighted new data structures that would prompt changes to our desktop software instead of catching us off guard.

Let's consider the questions above; our goal is to create customised software solutions, after all our name is "We Don't Do Simple" trading as Logical Developments. By definition our software needs to change to suit the needs of our clients. This means we should anticipate a specification that will change and evolve over time. An evolving specification is fine, but without a record of how a project evolves there will never be an opportunity to ask the follow up question "how important is this feature right now?" If the priority is high, the spec can change - affecting the timeline and budget in a predictable and acceptable way. If the priority is low, it can be tabled for another day.

Next question, "is this work that has been done by this team before?" The short answer was actually no! We typically produce our web applications using the tools made available within the Omnis development environment. However, due to the constraints associated with the desktop software this wasn't an option. No worries we thought! We had been thinking of branching out anyway, but this is where not having a record specification came back to haunt us. Out team was caught doing two tasks. They were learning the ins and outs of a new language and framework while also designing the architecture of the web interface on the fly. What we thought would be a simple task with some learning opportunities was instead a very involved process that broadened what our desktop software does.

Flowing from this is the question of people, budgets and assets. We set the budget on the misconception of project scope and difficulty. Secondly we had fewer assets than expected because the new web interface generates data that doesn’t fit the current architecture our desktop software uses. The outcomes our client wanted required us to re-imagine how all the data linked together while being constrained by the existing software. In essence we rebuilt our desktop software from the ground up as a web application using a tool set that is new to our team. Lastly we are a small business with other clients, so as much as we'd like to throw our resources and people 100% at any given project that can never happen because our other clients, understandably, would like time and attention to maintaining and improving the software they use.

In the end, speed wasn't of the essence. To begin with, we thought that working fast and delivering a simple, but workable product was more important. However, while we still feel the pain of each additional hour spent over time on this project, what matters most is delivering a high quality product that suites our clients’ needs. We always set out to create tools that enable our clients to grow their business, which in turn requires us to grow the capability of our software. This project hasn't gone quickly, nor is it on budget, but we believe it is to the standard we hold ourselves to. We hope that the experience our client has is that it “just works” out of the box, waiting for them to push it in new and exciting ways that allows them to grow, and give us a new challenge to deliver on.

How long did this take? It took longer than we would have liked. The scope wasn't as narrow as anticipated and skipping the steps we thought we could came back to haunt us. The problem with saving costs by cutting corners is they'll reappear in different and more difficult places. The more familiar the territory, the easier it is to answer the question how long will this take? For something new and complex, that could an entirely different experience - even the most simple of request could turn out to be very difficult to achieve. By spending more time upfront planning and thoroughly defining the parameters, the faster the project will go in the long run.

In short, it will take as long as it will take. Whether or not it is on time and under budget will come down to how well the initial project is defined. Let's work together to ensure that it always is. At the end of the day, We Don't Do Simple and we want to build the tools your business can rely on and grow with.

Have questions about how we work? Check out our software design process - it outlines how we work with our clients to outline their needs, generate a specification document, create a quote, and work toward the final product that meets the defined need. Otherwise, give us a call or send us an email today!