When embarking on a new project, our clients often ask, "How much is this going to cost?"

That's a reasonable question to ask, but one that can be surprisingly difficult to answer. Why is that?

The Myth of "In Scope/Out of Scope"

Despite your best intentions and efforts, there are always many unknowns at the start of a project. We have seen lengthy project specification documents (designed for purposes of obtaining a fixed-bid estimate) that still barely begin to describe the eventual product that is developed. We've also seen the opposite extreme— project descriptions that are so scant and loosly defined that they could mean anything. But neither of these extremes have proven reliable as a way to determine whether a feature or design idea falls "within scope" or "out of scope." Invariably, the fixed-bid approach to estimating software projects leaves somebody with the short end of the stick. Either the project is over-estimated for safety, or under-estimated based on incomplete facts. If the estimate is too far from reality, the result can be building the wrong finished project in slavish devotion to the original scope document— an unfortunate tug of war to determine what portion of the development should be considered in-scope or out of scope. There has to be a better way…

Controlled-Budget Development

Because requirements and implementation details always evolve during design and development, our standard approach is to recommend a responsible budget that gives each project enough resources to be successful. Based on our review of your project requirements, competitor sites, and our conversations, we agree to an appropriate amount of developer hours that seems sensible for the kind of project you are looking to build. Then we divide the budget of hours into a series of weekly development sprints, reviewing progress and refining goals each week. In this way, you will have a clear view of progress as budget is applied, and together we will be able to prioritize new ideas that invariably emerge throughout the project timeline.

Our goal is to arrive at a usable product as early in the schedule as possible. You may pause or discontinue development at any point, and if you choose to do so, launch your project without using all of the allocated budget. Conversely, sometimes custom features or design ideas might be introduced after development is underway, and these may require additional hours beyond the approved project budget (or may require that other project elements be scaled back in order to stay within budget).

The key concept here is that we are all partners in building the best possible product for your company or organization, and we need to work together to apply the available resources as efficiently as possible. Some projects have fixed deadlines— a product or business launch; a tradeshow; a customer event. Others are perpetual— ongoing improvements for a business system. Our process is intended to deliver a high-quality end-product within the available budget and to keep you in control of your budget. You decide whether to continue using developer time or to pause development and launch.

Example:

Company Y intends to launch a new product line in 12 weeks, and desires a new Drupal-powered eCommerce site to launch along side the new product. Following initial project discussions, Company Y and RDG determine that a budget of 500 hours of development should be adequate to accomplish the majority of the project's objectives.

Because the product line is slated to launch in 12 weeks, a development pace of 50 hours per week is set so that the 500 hour budget will be reached in about 10 weeks with a couple of weeks to spare for last-minute tweaks before launch.

Each week, RDG and Company Y have a meeting or conference call to review progress from the prior week and to set priorities for the coming week of development. Depending on many factors, the project may progress more quickly or more slowly than anticipated, but the weekly development sprint approach allows for course corrections to stay on track for schedule and budget.

The eventual cost of the project will reflect the actual development hours incurred, but all decisions that affect the amount of development effort will be made in the light of the available budget. This process gives you the flexibility to build the right product while staying in control of your budget.

404