Level: Introductory Mark Lines, President, XRC Consulting
15 Feb 2005 from The Rational Edge: Steering committees that make major project funding and governance decisions about software development projects are often unfamiliar with iterative development practices. This article explains what these committees should know and what questions they should ask to administer an iterative project effectively.  For many years, I have been teaching and mentoring project teams on how to be successful using the iterative methodology embodied in IBM® Rational Unified Process,® or RUP.® I have found that knowledgeable and motivated teams can be far more productive and focused when they use RUP rather than a conventional waterfall methodology.
However, in such teams' organizations, the steering committees that make major project funding and governance decisions are often not familiar with iterative methodologies. They do not ask the right questions to gauge project progress, and they are ill-equipped to provide appropriate management guidance.
This article outlines some of the practices that managers and steering committees need to adopt in order to successfully direct iterative software development. By doing so, they can optimize the value of scarce IT dollars and concentrate efforts on developing software features that provide the greatest business benefit.
Fund smaller projects on a continual basis to keep up with changing requirements
In many organizations, there is an annual ritual of budgeting and prioritizing software application initiatives for different departments, and often decisions are based on highly subjective business cases, with questionable cost estimates and intangible benefits. Strangely enough, these organizations often approve the large projects, even though history shows that large projects have the highest likelihood of failure. This means that some departments go for years without sufficient funding to build a new application that addresses their backlog of business change requirements. When that department's year for funding finally comes up, 'the tendency is not only to request application features that address their requirements backlog, but also to "dream up" features they think they might require over the next five years -- until their funding time rolls around again. We call this phenomenon "software bloat": the tendency to load an application with features that have questionable business value. This tendency is also common when organizations migrate an existing application to a new technology.
Better than the "big project every five years" approach to building departmental applications is to use a release strategy similar to the one that many product companies use to build their software. This entails continually improving software incrementally over a number of releases, adding new functionality gradually over a period of time.
Business practices continually change, so applications need to continually evolve. Therefore, a budget of $200 thousand every year is better than $1 million every five years. There are many advantages to this release approach:
- Scope negotiation is easier.
- Since stakeholders know that there is always another release, they
are more willing to defer scope that is not essential or critical to a
future release.
- Software bloat is easier to avoid.
- Stakeholders tend to approve only those features that will deliver the
highest business benefit.
- Requirements elicitation is continuous.
- You can capture stakeholder requests as they arise; you don't have to
ask users to explain their business all over again -- perhaps to a different
person -- every one to four years.
- Resources can remain in place.
- With a smaller ongoing project, you can leave resources intact and become
a more productive team. Studies have shown that smaller teams are more
productive than larger ones.
- You can leverage process improvements over a long period of time.
- In the initial stages of a new project, productivity is typically poor
until the team establishes a regular rhythm.
- In a small but ongoing project, you can improve all aspects of the project
incrementally, based on iteration assessments.
- You can maximize tooling investments.
- You can reap the real benefits of lifecycle management tools over time,
as you develop a baseline of metrics and other project data, such as architectural
blueprints, patterns, and mechanisms.
I encourage organizations to change their annual budgeting ritual. Instead of making departments fight for IT budget based on questionable business cases, I suggest:
-
Allot regular funding to most departments.
-
Adjust the level of funding every year, based on benefits delivered the previous year.
This approach encourages projects to use funds efficiently so they don't jeopardize funding levels for subsequent years. Every year, stakeholders have to justify what they have done, not fantasize about what they will do.
By looking at real business benefits achieved, you can quickly find the departments that would benefit most from additional automation and increase their funding to appropriate levels. Demanding continuous accountability for IT investments allows you to optimize your budget allocations. Of course, it is prudent to reserve at least a portion of your IT budget for larger initiatives that can address major business issues or changes.
Set firm timelines, but leave features flexible
I often tell people that my projects are always on time and within budget. What I don't always explain is that the features these projects actually deliver typically vary from the stakeholders' original expectations. Those in our industry understand how difficult it is to accurately determine up front the exact scope, cost, or duration of a significant project. The scope invariably changes because of uncertainties related to requirements, resourcing, and technology. Changing either resources, technology, or deadlines is typically more disruptive to a project than adjusting its scope.
In a RUP project, the lifecycle consists of four distinct phases: Inception, Elaboration, Construction, and Transition. Although we begin building software very early and continuously throughout the project, our emphasis changes as we move through these phases. In Inception, we are concerned with doing the minimal amount of work required to determine our high-level scope and deciding whether it makes sense to proceed further with the project (a go / no go decision).
At this very early project stage we can lay out a Phase Plan, as a section in our Software Development Plan, that outlines the length of each phase and its iterations, with firm dates for every iteration up to and including the application release. (Each phase in a RUP project may contain multiple iterations.) What we don't know is exactly what functionality will be delivered in each iteration.
In the next phase, Elaboration, we can focus on elaborating requirements and building software against those requirements to reduce uncertainties regarding technology, schedule, and resourcing. As we move through Elaboration, we fill in details of our Phase Plan, committing to features to deliver in each remaining project iteration, based on what we learned in the previous iteration. At the end of Elaboration, with most of our uncertainties (risks) mitigated, we can negotiate and make firm commitments about the application's scope. If we have adopted a regular release approach to building our applications, scope negotiation becomes much easier, as there is a place to defer scope to!
With the detailed scope now baselined at the end of Elaboration, we move into the Construction Phase. The focus shifts to building the rest of the functionality, based on the revised agreement on scope. We should now feel comfortable with our ability to deliver this scope according to our original timeline outlined very early in the project.
Evolve requirements through collaboration
Being successful with RUP requires a new kind of collaboration between project teams and stakeholders. In the past, IT assigned the risk of properly defining requirements to business stakeholders but assumed the risk of delivering software based on those requirements. IT managed risk by having users sign off on a requirements document, and then controlling changes to those requirements. IT charged users for making changes, and justified schedule and cost overruns by padding original estimates in response to changes and then claiming that the project was still "on time and within budget." These practices resulted in mistrust and bad feelings between stakeholders and IT.
A collaborative approach is a far better alternative: Both stakeholders and the project team acknowledge that it is virtually impossible to properly define requirements at the beginning of a project, so it is also unreasonable to expect the project team to commit to fixed costs and a definite schedule based on uncertain requirements, resources, and technologies.
In projects that adopt the "spirit of RUP," stakeholders and project team members understand that requirements can and should change and evolve as they learn more and more. It would be unwise for the project team to make precise commitments until they remove most of the uncertainty from the project. The project manager should address uncertainties as quickly as possible so that the delivery team can make firm commitments regarding scope for delivery.
Teams often ask, "How long should my Elaboration phase be?" The answer is, long enough for the project team to mitigate known risks and enable the project manager to make firm commitments regarding the project's schedule, cost, and scope. On a typical project, this may mean building 20 percent of the functionality, or enough to prove that the architecture can support all the requirements.
At the end of the Elaboration phase, when teams have mitigated most of the uncertainty related to schedule, functionality, technology, and resources, they can then baseline the requirements and subject future requirements changes to normal change control procedures.
Move maintenance staff members onto development teams
Most organizations treat new application development differently from support for existing applications. Often, they call in external consultants to build new applications based on new technology, but once the applications are deployed, they turn them over to internal maintenance staff for support. This is demotivating for the staff: It is not very satisfying to support applications that someone else built, especially if you seldom get to work with the newest technologies. Also, it can be difficult to maintain an application effectively if you don't know what decisions were behind the original development. If you use this approach, you must supply the maintenance staff with extensive documentation, which increases system costs.
In an iterative development environment, it makes far more sense to move maintenance staff members onto development teams and make them responsible for both maintaining existing releases, and developing new features for future releases. This promotes continuous engagement with the system's underlying business goals and features, which staff members can help improve incrementally. Ultimately, it results in a more productive and happy development team, and a reduced documentation burden.
Ask appropriate questions and demand incremental functionality demos
How does an iterative development approach affect the way the steering committee should manage meetings with project managers? First, managers must make sure the committee understands how the project changes as it moves through the different RUP phases. Only then will the committee be able to ask meaningful questions and adjust funding levels during the various phases. For instance, in Elaboration, they should ask the project managers for regular updates of the Risk List, to determine whether risks will be mitigated by the end of the phase.
The focus on reducing risks and uncertainties early in a project is one of the key advantages of using RUP over other iterative methodologies. The method for reducing risk entails building software in the Elaboration phase that addresses the most significant uncertainties. Many risks relate to architectural concerns. Although customer stakeholders may exert pressure to build what they consider to be the key functionality first, it should be the architect -- not the customer -- who sets priorities in the Elaboration phase. The steering committee must understand this; at the end of Elaboration, when the greatest uncertainties have been resolved and the project is ready to move into the Construction phase, then the priority setting can be more customer driven.
In some situations, it may make sense to build key functionality early in order to mitigate risks related to requirements or workflow uncertainties. However, if the functionality is straightforward and does not address any outstanding uncertainties, then the team should defer that coding until Construction. Remember: The goal is to get through Elaboration as quickly as possible so that you can firm up commitments to stakeholders and move into Construction.
Steering committees should also demand demonstrations of key use case scenarios on a baselined architecture (with real working software, not prototypes!). In fact, they may consider installing a projector in their meeting room to facilitate frequent software demonstrations. This represents a fairly radical departure from waterfall projects. Rather than incremental demonstrations of functionality, steering committees typically see a demo only when the entire application is ready for production. In addition, they typically measure progress using Gantt charts that indicate the project is 33 percent complete, 66 percent complete, and so forth. Or, they may ask whether managers have signed off on the requirements or design documents. First and foremost, project managers need to educate steering committee members about how to measure progress: The only meaningful way is to look at working software, not signed-off documents.
Steering committees should also begin asking questions about quality early in the project lifecycle. We cannot measure progress based simply on what has been built, only to discover too late that the quality is poor, and we have underestimated the testing effort required. With an iterative approach, we get early indications of defect rates and required testing efforts, but the steering committee may not know enough about these efforts to begin asking questions about quality early in the project. As a consequence, junior RUP project managers may not follow RUP guidelines and fail to do thorough testing early on. Unfortunately, many such managers say they are using RUP for a project, but they revert to waterfall techniques. Often they group their task plans for RUP phases but don't really follow iterative practices, especially in the testing domain. Steering committees should check to ensure that the project manager has resourced a tester early in the project and assigned tasks that test the implemented use case scenarios.
In summary, the committee should make the following requests to the project team:
- Show us proof of project progress through demos:
- How many use case scenarios have you implemented?
- What functionality did you create in this iteration?
- What functionality will you create in the next iteration?
- Show us proof of the quality of what you've built:
- What is the defect count, and what is the severity of those defects?
- What are the defect trends (discovery and resolution rates)?
Eliminate unnecessary sign-offs
A challenging aspect of introducing RUP into a traditional waterfall environment is that it urges far less reliance on sign-offs. People are reluctant to sign off on documents unless they are sure they are complete and accurate. So they tend to sit on them and delay decision making, which slows the project down and wastes money. As an alternative, RUP acknowledges what we all know from past experience: Documents are seldom complete and accurate under any circumstances. So RUP guidelines urge us to accept that everything will change, and move on.
Prevailing wisdom in software development circles is that you get 80 percent of the job done with 20 percent of the effort. So, that means it takes 80 percent of your effort to complete the last 20 percent of the work. Logically, therefore, it is best to get the first 80 percent done, and then flush out the other 20 percent naturally, as you move through the project iterations. Agile and iterative development is all about getting to "good enough," and understanding that you will fix and refactor your work as you go. Continuous, daily collaboration between stakeholders and the project team is a far superior way to ensure project progress than the intermittent production and sign-off of formal documents.
However, I continue to ask for sign-offs on key project artifacts, such as the Vision Document and Software Development Plan at the end of Inception, and again at the end of Elaboration. Often, significant changes in plans occur at the end of Elaboration, when the project team has a deeper understanding of the requirements. Although my preference is to adjust scope and keep both budget and schedule fixed, sometimes it makes sense to replan the remaining Construction iterations if you cannot reduce the scope, or to introduce another Elaboration iteration if there is still too much project uncertainty to make delivery commitments.
Constantly adjust planning and expectations
I have often said that managing a waterfall or conventional project is quite straightforward and fun for the first 80 percent of the project. Until then, the tasks are quite linear, and you can focus on one discipline (such as requirements) at a time. However, when integration and testing starts, you invariably discover that either the modules don't integrate, testing will require a huge effort, the architecture is flawed, performance is poor, or the users say the application is not what they asked for. If you are managing a waterfall project, you will want an excuse to transfer the project to some other poor guy when coding is nearing completion!
Managing a RUP project can be more challenging in the early phases, since we have to work on all disciplines in parallel, including requirements, coding, and testing. However, with continuous, informal communication and good lifecycle management tool support, the complexities can be much more manageable.
The most difficult time for RUP project managers is often the end of Elaboration, when they may discover that the scope, budget, and schedule don't add up. Then they need to make hard decisions and perhaps replan a portion of the project. The good news is that this happens early in the project, so there is time to adjust stakeholders' expectations about what is possible.
At the end of the project, although we may not have met stakeholders' original expectations, we should have met those that were negotiated at the end of Elaboration. Conditioning stakeholders to expect firm commitments at the end of Elaboration, not upfront, is key to being a successful RUP project manager.
I hope I have shown that adopting an incremental release strategy for building departmental software applications can have a profoundly beneficial effect on IT investments. RUP provides excellent guidance for this approach, and I encourage your organization to consider it. If you do decide to create an iterative software development environment, then it is important to educate stakeholders about the collaborative nature of RUP projects. The way in which your steering committee governs your application development initiatives will be crucial to your success at using your IT budget effectively and avoiding the flawed practices of a conventional waterfall methodology.
Good luck!
Acknowledgements
My thanks to Philippe Kruchten and Joshua Barnes for their valuable input into this article.
About the author  | 
| | Mark Lines is President of XRC Consulting Inc. He has been building object-oriented software for many years, and is an expert on the IBM Rational Unified Process. In addition to providing mentoring services on IBM Rational Best Practices and teaching IBM Rational courses, he facilitates discussions for the RUP and Software Lifecycle forums on IBM developerWorks. He can be reached at Mark.Lines@XRCconsulting.com |
Rate this page
| 
