The Agile Budget Conundrum

Joe is a project manager in Maitland, Florida. He is skilled in helping clients solve their complex technical problems through extreme requirements definition and prioritization of scope, time and cost to meet their objectives.

Over the last few years, companies have embraced agile over waterfall for managing projects. But for all the hoopla around Scrum and sprints, one area of the business has resisted agile because it means it must change the way it operates.

In the beginning
Back in the days when the only project management methodology was waterfall, things were simple and straightforward. When a project was created to deliver a product or process, a team was pulled together from various disciplines in the company and a project team was born. The process was always the same: gather requirements, estimate time and resources, then create a capital budget to submit to finance for approval.

Straightforward process? Yes. But as we have seen over the years, the success rate of delivering the product or process to the customer’s satisfaction by following the traditional route was not smashing.

The dawn of enlightenment
Back around 2001, some very smart people got together and decided that there had to be a better way. Why not shake up the process by not spending a lot of time on analysis and planning up front? Maybe it would work better if we just identified enough to get started, then develop and deliver minimum viable products (MVPs) over time. This would provide the customer with an opportunity to provide feedback, and the team could make adjustments so that the final product was just…

Please log in or sign up below to read the rest of the article.


Continue reading...

Log In
Sign Up

"Time is a great teacher, but unfortunately it kills all its pupils."

- Berlioz