Agile project management approaches for on-time and on-budget delivery

Joseph Flahiff, Contributor

Joseph Flahiff has more than 15 years' experience in agile and traditional project management. For the past five years he has managed agile projects in enterprise organizations exclusively. He now works for a multistate health insurance company, providing agile project management and training for a three-year $20 million project that coordinates the work of more than 100 team members.

Flahiff is the author of a SearchCIO.com agile project management guide that includes real-world examples of agile project best practices, agile project definitions and agile terminology. In this and in a previous story, he outlines the ways an agile project can be managed to make it easier to understand when the often-elusive end date of an agile project can and should be set.

This is the second of a two-part series on agile project management. The first part focused on managing an agile project by scope and the three sides of the iron triangle, or triple constraint for software and project development. This article delves into managing an agile project using a schedule-managedor budget-managed approach to capturing the often-elusive end date of an agile project.

Budget-managed agile projects

In 2007 I was named manager of the Transparency Program, a collection of a half-dozen projects related to creating transparency in health care insurance, pricing and service delivery. The program, one of the company's two key initiatives, was high-profile and high-risk. We were on course, chugging out releases, and the releases for the next 18 months were planned out in front of us. Then came October 2008 and the dramatic drop of the Dow Jones Industrial Average that plunged the United States into a recession. In July 2009 I received a call from our project sponsor: "Transparency has been canceled. Close out the project." It felt like a sucker punch to the gut, and took the whole team by surprise. Fortunately we were using agile, and each iteration was self-contained. That made closing the project easy. We already had delivered the highest-value features to the customer.

In the Transparency Program's case, the scope of the project changed, as often happens with agile projects, but we remained focused throughout the project lifecycle on scheduled release dates. Let's take a closer look at agile project management from the point of view of schedule and budget.

Budget-managed projects are closely akin to schedule-managed projects. In agile projects, teams ideally are allocated 100% to the agile project alone, and have no other responsibilities. Because of that, budget equals the team's monthly burn rate, or the amount of money needed per month to run a project. In enterprise organizations, this is typically not the case: Staff are allocated 50% or 25% or sometimes even 5% to a given project because they have other duties. Because of the cost of task switching , this allocation is not optimal for any work situation, not just for agile projects. That's a topic for another article, however. The ideal is 100% allocation, but even in situations where staff is percentage-allocated, the burn rate can be applied. It is just a little trickier to calculate.

Projects best suited for a budget-managed approach

Pure research and development projects are ideally suited to be handled as budget-managed agile projects. The nature of R&D or exploratory projects is that they can go on for a very long time if they're not given a limit. A schedule-managed R&D project is OK, but it's easy to spend a lot on research if you have only a fixed amount of time. The fixed-budget approach is a better choice because it provides boundaries for the project and encourages optimal delivery. Burn money fast or slow, whatever is best for the research, but when the money is gone, it's gone and the project is over. Again, this is not a problem with agile because each iteration is self-sufficient. When the work is done, the project can be closed down easily, just as we did with Transparency.

Schedule-managed agile projects

A friend of mine is a manager in the production Web support group at retail store Nordstrom Inc. He related to me recently how his slowest time is late November and December. This surprised me: I figured that November and December would be really busy for Nordstrom's. He went on to explain that in his department, everything has to be in place by mid-November; after that, the website just chugs along. No changes are allowed during this busiest time of the year. If a new release was allowed and it went bad, the loss of sales could be very significant, so no changes are allowed. This is a perfect place to use a schedule-based agile project management approach.

Schedule-managed projects get a set amount of time to deliver, and then the project part is over and sustainment begins. This creates a very clear delineation of the end of the project and the start of product enhancements. Remember, we are not combining scope- and schedule-managed projects. I am saying, set a schedule limit, and let it go. The project sponsors probably are used to combining scope and schedule limits, so this approach needs to be clearly communicated to them. Heck, they may throw in budget management too, for good measure. Where is the agility in that approach?

In a schedule-managed project, we take advantage of setting priorities for the feature backlog, as well as of the fact that the product potentially is shippable at the end of each iteration. What management needs to understand is that the product will be shippable and the most important features will be there. What will not clear (at least at the start with a new team) is how many top-priority features will be complete. As the team completes a few iterations, your ability to estimate the remaining work accurately will increase exponentially, and you will be able to communicate how much probably will be done by the launch date.

If the sponsors are still uncomfortable when you explain this, you can simply suggest that the project might be more suited to a fixed-scope approach, but then they will not be guaranteed a specific completion date. In that case you will have a good idea of how long it will take after a few iterations.

Projects best suited for a schedule-managed approach

I have found that three types of projects are ideally suited to being schedule-managed: product kickoffs, projects whose scope is ambiguous, and projects driven by a specific date.

Staff are allocated 50% or 25% or sometimes even 5% to a given project because they have other duties. … This is not optimal for any work situation.

Product kickoff projects are really slippery. They can easily expand and go on forever because the product is new and has no defined boundaries of what it "should" be. New features can become "necessary" quickly and thus are added to the project scope. Agile makes scope additions easy, but with a fixed schedule the answer is, "Sure, that is great, but that will push the following features into sustainment." Agile forces management to make hard tradeoffs that often get glossed over too easily.

Projects whose scope is ambiguous also are ideal candidates for fixed-schedule management. In agile terms, these are called spikes. A spike normally is not a project but a small, time-boxed exploration of some new feature, function or approach that is ambiguous. The exploration's goal to clarify the ambiguity within a fixed period of time enough to make it estimable.

Finally, date-driven work is a clear candidate for a schedule-managed project. The release of a new software game for the holidays, an update to the corporate website in time for the new product launch: These are clear examples. The team will work on the most important features for the game or website first, and get done as much as they can by the deadline. The most important features will be complete and can be in production on time, every time.

Summing up the agile project management approaches in the iron triangle

Holding one and only one of the triple constraints constant will help you gain control over your agile project by:

• Guiding you to communicate to management the project's most important factors.

• Keeping you focused on your goal of landing your project smoothly.

• Enabling you to manage with defined scope, or within the schedule or to the budget.

As we discussed previously: Agile was created as a product-development method, but it can be used as a project-execution method as long as its limitations are clearly understood. The triple constraints from the traditional project management discipline can apply to agile projects if they are well understood. Use the following table as a guide:

  Best fit Limiters Communicate

Scope management
  • Regulatory
  • Business mandates
  • Well-understood scope
  • Required feature list
  • Schedule and budget are variable.
  • Track and report schedule and budget closely.
  • Scope additions will be part of the product backlog, not part of the project.

Budget management
  • Pure R&D
  • Noncritical
  • Exploratory
  • Total budget
  • Burn/time
  • Tightly coupled with schedule management.
  • Scope additions will be addressed as long as there's budget for them. If not, they go into the product backlog.

Schedule management
  • Product kickoff
  • Ambiguous scope
  • Date-driven
    • Holidays
    • Seasonal
    • Fiscal year
  • Schedule
  • Specific dates or timelines
  • Scope additions will be addressed if we can get to them in the schedule. If not, they will go into the product backlog.
  • When it's over, it's over.
  • Value will be delivered.
  • Manage sponsors' expectations.
  • All the items identified may not get done.
  • Budget isn't being managed actively, but is reported accurately.

So, what about the customizable reporting website project that we talked about previously? What was the problem with that project? It was misidentified as a fixed-scope project, when the company would have been better served if it had been identified as a fixed-schedule project. Changing it to a fixed-schedule project would have been a major improvement, essentially replacing the old product. The product would have continued to be developed and enhanced over time as well. The initial release completed, the project would have been shut down and all the remaining scope ideas would have been used for future product enhancements. Live and learn.

Let us know what you think about the story; email Christina Torode, News Director. More enterprise agile project management resources are at the author's Whitewater Projects blog.

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: