Success! It works! Now what?

Unless the software we've just developed together is a solution to a one-time, unique problem, you'll want to keep it up-to-date, adapting as your needs and priorities shift. Even if it is such a project, you may have other such "special" projects in future; information generated and lessons learned during this process may well make that future project easier.

One well-known Winston Churchill quote reminds us that "He who fails to plan is planning to fail." Many people keep that in mind while embarking on a new venture or project, but fail to follow through and continue the process after reaching the initial "success" that they'd planned and worked for. And then they wonder why things don't keep running smoothly along the course they'd started... without realizing that it's because they'd only started. Today's short-term, "next quarter is 'long-term' planning" business mentality doesn't help that situation.

Early on in the development process, we'll start having discussions with you about what happens after the project is completed. These discussions will generally focus on two key areas: operations, and continuing development.

Operations: keeping the lights on and the visitors happy.

One of the core concepts we've been trying to reinforce through the entire process has been building on top of open standards. History shows this to offer greater flexibility in hosting, operations support, and so on. For instance, if widely-deployed, platform-neutral libraries and tools are used to create your software, then you have a wider variety of options when deciding how and with whom you'll continue after the first version has been completed. (Naturally, we hope we can continue to provide great service to you over the long term.) We will work closely with your internal or outsourced operations and support teams, as appropriate, to ensure a smooth, seamless experience for you, the customer.

Continuing development: build on success.

What are you using the software for? If it's a one-time fix to a problem, you may well think "I don't need to worry about maintaining this thing; once we've used it to solve the immediate problem, we won't need it anymore." Fine. One question: Is this the last such one-off project your organization will ever do? Or might the materials, information and craft knowledge generated and used here be worth capturing and preserving for future reference?

More customarily, the project will be an ongoing tool for your organization, with regular addition of new features, changes to adapt to new requirements or environments, and so on. That brings up the questions of how those changes are going to be made, and by whom. We, as most developers, generally provide these options:

  1. We would be happy to continue to provide support and development work for you, either on a per-project or continuing-retainer basis;

  2. We could instead create either a "handover snapshot" of all materials and supporting documentation for the project at the time of delivery, or a full historical dump (including, for instance, source-code management materials and so on).

The choice, of course, is yours. We generally agree on which will be done early in the project, and discuss what (if any) changes to cost and schedule would be needed were you to change later. (The full history of a large project can be complex; we would also prefer to assure ourselves that your staff or associates can make use of it effectively.)