651.288.7000 info@intertech.com

The holidays are approaching. For many kids, this means writing long, wish-filled letters to Santa in hopes of snagging enough toys and games to keep themselves satisfied throughout the new year. While this strategy frequently works for children with indulgent parents, it’s a poor model for devising agile project planning budgets for IT.

Yet agile project budgeting is remarkably similar to kids at Christmas for many project managers. They’re asked to deliver a wish list of projects and price tags in December to serve as the foundation for the next year’s budgets. Project managers are reduced to guessing at (and hoping for!) what they think seems like reasonable projections and budget requests. This involves trying to define most of an agile project plan’s requirements in advance, or what IT business consultant and writer, Scott Ambler, calls “the classic Big Requirements Up Front (BRUF) tactic.” He correctly notes that BRUF is rarely accurate.

“BRUF adherents must understand what needs to be built, so they can accurately plan and develop a robust system design. This approach doesn’t reflect the fact that requirements change as knowledge and environments evolve. Worse yet, when people try to get everything they want in a single release, requirements bloat beyond recognition. At best, this approach results in building too much of the wrong thing. At worst, nothing gets built at all because you’re too busy trying to get the requirements right,” says Ambler.

There is a better way to do agile project planning and agile provides the framework.


Act-Learn-Build. . . Budget

Saras D. Sarasvathy from the University of Virginia’s Darden School of Business has written about a strategy based on agile called “act-learn-build.” It’s as effective for launching new endeavors as it is for creating budgets for agile software development.  The simplicity is breathtaking:

Act: Take a step

Learn: Evaluate

Build: Continue until goal achievement or cancellation

and, I would add,


Act-Learn-Build-Budget is something we’ve been doing at Intertech since our inception. It provides an excellent framework for estimating costs in increments as projects are built. Many managers prefer budgeting the agile way because smaller requirements are easier to estimate. And, best of all, stakeholders have complete control over how they invest their IT dollars, enabling them to get the best value for their investment.

We adults know there’s no Santa Claus. And Scott Ambler, perhaps the most passionate evangelist for agile on the planet, acknowledges that this ideal budgeting strategy can be a tough sell inside many companies with traditional accounting and budgeting cycles. For managers in those situations, there’s a “middle of the road approach”:

“With a middle of the road approach you do enough architectural modeling to determine a potential strategy to build the system. This modeling efforts provides just enough understanding to put together an initial budget and schedule without paying the price of excessive documentation. The most effective strategy to put the initial budget and schedule together is to gather a small group of people who have relevant experience from similar projects in the past, and more importantly have a stake in the new project (e.g. they’re on the team and accountable), and ask them to provide a good guess.”

And, he continues…

Agile modelers understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted. Instead they will do just enough initial modeling to identify their project scope and develop a high-level schedule and budget: all you can really hope to achieve at this point is a good “ballpark” estimate, so you should only do enough work to get you to that point.”

At Intertech, we work with clients as necessary to develop realistic “middle of the road” scope estimates. Our experience with a broad array of technologies and applications makes it easier and faster for our clients to devise smart estimates that leave room for the inevitable changes that result from agile collaboration.

Now where is my list for Santa again?!