Setting the Budget

One of the most important questions at the start of a project is how much it will cost. It is vital to make sure that enough budget is available to allow for the development of a viable product.

The difficulty with setting a budget at the start of a project is that everyone is at the point of maximum ignorance. At the beginning of a project, all of the requirements have not matured. Scope may not be fully defined, the market approach may be a bit hazy, or the technical requirements may still be in flux. It is okay to move forward with a loosely defined project as long as the scope and budget are refined at several steps along the budget roadmap.

How Big Is the Pie?

After a project has been loosely defined, the profit generating, or cost savings, potential should be estimated. Refining scope and budget will cost time and money. Knowing the potential reward will ensure that the research, design and planning effort stays within perspective.

Early Estimation

We use the early project requirements, historical data from previous projects, and our experienced intuition to initially estimate cost. At this point the estimate will have the broadest range. We might estimate that the project will definitely cost $50,000 but probably not go over $100,000. If the estimate is much higher than expected, we can revisit the requirements to make sure that scope expectations are aligned. We can redefine the scope and estimate again.

Research, Design and Planning

If the initially estimated cost range is acceptable, we’ll move forward into a research, design, and planning (RDP) phase. This phase provides further definition of the product’s users and functionality. We will create a story map to define the user activities and tasks and use that map to define a minimum viable product. We then estimate the development effort, in ranges of days, to implement the features that allow users to complete the defined tasks. To aid in our estimation effort, we may create sketches or wireframes that roughly define the features. We’ll also qualify each feature as supporting the context or core of the product and how high or low the frequency of use may be.

More Decisions

Our refined estimate coming out of RDP usually falls within the range of our initial estimate. Sometimes the estimated cost increases because we have learned more about the product. A higher estimated cost is okay. Money has been spent to gain knowledge. Risk has been reduced and we’re more certain about the cost of chasing the reward. At this point a decision is made to move forward with development or not.

Predictable Delivery

We start development with the estimated budget from RDP as a constraint. We create a backlog of development stories. Stories to be completed in the near future are more defined than stories in the distant future. We track our progress through the backlog of stories on a weekly basis. We give weekly updates of the projected final cost. We define stories further when appropriate and negotiate scope to keep the project on budget. At the end of the project, we deliver a final release within a predictable time and budget.