How we work – encouraging success

We've all seen too many development projects where the "team" made great efforts to understand the customer's initial requirements, then "went underground" to develop the solution which they understood to have been agreed to, only to "pop up" months or years later with something that did a "pretty good job"... only to find that the customer's needs had changed, or there was critical information that had not been conveyed (especially common on new projects where the customer literally can't know everything, because he's never actually laid eyes on what he's describing before)... and suddenly fingers start pointing, lawyers get phone calls, and what seemed to be a great project dissolves into chaos and acrimony. Meanwhile, the customer has needs that still haven't been met yet.

Software practitioners have a name for the process that often leads to this: it's called a "waterfall." Like a real waterfall, once you start going down, it's really hard to change your mind about decisions made earlier. Also like a waterfall, those who enter it ill-prepared tend to have spectacularly negative outcomes.

One of the things we as an industry have learned over the last three decades, and particularly the last one, is very simple: we can't afford to work that way anymore. Customers don't have the time, money or inclination to pay for endless rework, putting "patches" on a system with what in hindsight are fundamental flaws and inefficiencies. Good developers don't stay on projects like that very long; they have career alternatives that don't involve death marches. In short, nobody benefits, and all involved experience significant pain.

There is a better way. (Several, actually.)

Our process is based on the reality that, even when a project has strict outside (e.g., regulatory) requirements, less than one hundred percent of all information needed to successfully deliver the project is fully known and communicated at the inception of the project. Priorities change, needs change, and if the project does not accommodate those changes, it will not achieve maximum success. This isn't a reason to point fingers and say "you should have said thus-and-so;" it's a simple acknowledgement that:

  • change is a natural effect of the passage of time;

  • people learn, make mistakes, correct them and learn more; and

  • any process that does not take these realities into account makes its desired outcome significantly less likely.

This process, "agile development," takes these realities into account. By involving you, the customer, pervasively throughout the development timeline, you continually understand the progress and course that the project is on. The need for changes can be observed and addressed much earlier than in a traditional "waterfall" process, mitigating risk and reducing wasted effort and other resources. Priorities can change, and timely information about the effects, benefits and cost of those changes can be communicated accurately and effectively to aid in the customer decision process.

Finally, by building on open standards and appropriate existing tools where practical, we reduce the time, cost and risk of delivering a particular project. We proceed on the assumption that all stakeholders want a successful project – and execute based on that assumption.