Big Data

Keeping your iterative projects on track

Frequent software releases bring in more customer feedback, but more feedback also means more ways to derail your project. This gantthead article shows how to make sure your first iterative project isn't your last.


By Geoff Choo

The iterative approach to delivering software releases makes a very convincing value proposition: delivering hard and visible results as often as you can to your customers by breaking up and releasing your big software project in a series of small, working versions in incremental stages throughout the lifetime of the project.

When done properly, the iterative approach gives your customers a high-level look at the state of progress and provides them with plenty of opportunities to give feedback and improve features and functionality. But there’s a dark side to all this: The more often you put functioning software into your customers' hands, the more opportunities they’ll have to request changes that risk taking your project off its original track.

I recently asked experienced software professionals Thaddeus Neal and Brian Lanham for their advice and perspectives on managing change request and customer feedback in iterative projects. Here's what they said.

Watch out for scope creep
"The biggest problem with the iterative process is scope creep," says Thaddeus Neal, who is an e-business consultant with Maverick Technologies, LLC. His expertise is enterprise resource planning (ERP) implementation and enhancement design for supply chain solutions, primarily in procurement, logistics, and distribution streamlining efforts. Thad also serves as an adjunct professor of project management at Webster University in St. Louis.

"A project manager has to make sure that each release is not seen as an opportunity to add more and more functionality," Neal continues. "The most successful tool to limit scope creep is to take the time to get a solid statement of work circulated and signed off on by as many members of executive management as possible."

For example, when scoping out a distribution project, Neal suggests taking a holistic view of the entire supply chain and sitting down with a subject matter expert (SME) from each area to walk through a draft of the Statement of Work (SOW). By using the SME, Neal says the SOW you craft should be able to mitigate surprises during requirements gathering and detailed design and keep scope creep to a minimum.

Use a project dashboard to communicate the vision
Crafting a communications plan based on the SOW ensures that there is a "crystal-clear" understanding of the project's vision.

"I find that teams and customers both like to know what is going on with a project at any given time," says Neal.

For that reason, he creates a "dashboard" communication tool for each project and makes it easily accessible to everyone. A project dashboard serves two major functions:
  • It lets someone look into the inner workings of the project without them having to sit through status meetings every couple of days.
  • This dashboard should ferret out any baseline concerns that can be highlighted in detail during status meetings.

The project manager will have the responsibility to determine if an issue can fit into the existing project, or if it’s best left for further enhancements. The project dashboard will let upper management view these issues during the project lifecycle and then address them specifically during project closure.

Managing customer feedback
"Sooner or later, you'll learn the hard way that the more often a customer can offer feedback, the more easily the project can get off the track, and the iterative release approach allows customers to give a lot of feedback," says Brian Lanham, a senior application development consultant at Virtual IT Inc., a technology consulting firm. Prior to that he was a software engineer at Concurrent Technologies Corporation, a government and private industry contactor based in Johnstown, PA.

"A team that is very willing to please may be tempted to offer the customer whatever is requested. Smart project managers know how to avoid this temptation," says Lanham.

A good way to keep your projects on track is to develop a roadmap with the stakeholders. A roadmap defines the project at a high level while providing project direction. Conduct roadmap review sessions periodically (at each release) to make sure everyone is on the same page and the project is on track.

"I am often guilty of seeing a 'need' that is not defined in a scope of work document. The customer can also request a change that may seem logical at the time but could put the project off track at a later release," says Lanham. "The roadmap provides high-level direction and lets everyone see the current state of the project. Don't forget to hold regular meetings and keep the roadmap updated."

Another technique that Lanham likes to offer is alternatives. He never likes to say, "No." Instead, he would say, "Okay, but that's going to cause this change in deliverables or that change in schedule." Experienced project managers should be able to look at a change request in the context of the system and see how the system might be affected by that change in the future. It then becomes a matter of conveying concerns about potential problems to the customer. This approach puts the onus on the customer to prioritize his or her needs.

You need a process, not an application
"Change management is a process and not an application," says Lanham. "Applications only support processes. It does not matter whether you use a simple spreadsheet or a top-of-the-line, more comprehensive (and expensive) change management package. All that really counts is that your process allows you to track all changes and that you have the ability to trace one release to the previous release or to a requirement."

Your change management process should also include a change review board (CRB). This CRB should involve the project manager and project technical leader, stakeholder(s), business analysts, and user-base representatives. The CRB will review all change requests and either approve, disapprove, approve with modification, place on hold, or request clarification on each.

A CRB helps the development manage change requests in two ways:
  • The system is not changed in any way without the approval of stakeholders and the user community.
  • It allows you to better understand the impact of change requests by involving a broader range of people, including stakeholders, management team, user community, and third parties involved or affected by the project.

More on gantthead.com
Related content: Related downloads: Note: Items in bold are available only to gantthead premium members.

Manage user expectations smartly
"It is absolutely critical to properly manage user expectations when delivering your software project in small releases," says Lanham. Educating all parties involved about the process used to build software and the scope of each release can alleviate the confusion about what goes into each release.

A problem with an iterative approach is that what a customer thinks he or she is getting may differ from what the development team thinks they're giving. Often the customer gets a taste of the final product before it’s ready for production. It’s important to make sure the customer knows that the system is still a work in progress. If your organization has a white paper describing the software development process used, give a copy to the customer. Provide a seminar on the process or even a management brief summarizing the process.

"In order to build effective software for the customer, you have to know a lot about their business processes," Lanham says. "Perhaps they should take the time to know something about your business processes, too."

Originally published on gantthead.com May 20, 2002.

Geoff Choo is a project manager for an Italian interactive media agency, and a freelance business and technology writer.

Editor's Picks