A software project involves many stakeholders with competing interests, including bosses, developers, end-users, customers, and maintainers. Theory-W provides a project-management framework for reconciling competing interests. It is based on making an explicit effort to understand what the different stakeholders need in order to "win," negotiating conflicts among the stakeholders' win conditions, and then structuring the project so that everyone realizes their win conditions. Theory-W produces its schedule savings through improved efficiency of working relationships, improved progress visibility, and reduced risk.
Efficacy
Potential reduction from nominal schedule: | None |
Improvement in progress visibility: | Very Good |
Effect on schedule risk: | Decreased Risk |
Chance of first-time success: | Excellent |
Chance of long-term success: | Excellent |
Major Risks
None
Major Interactions and Trade-Offs
Designed to be combined with the Spiral Lifecycle Model
Particularly effective during schedule negotiations
Relies on the use of the Principled Negotiation practice
One practical management approach that supports rapid development is called Chapter 37 (Boehm and Ross 1989). Theory-W takes its name from its most important principle: Make everyone a Winner.
Most software projects begin with a group of project stakeholders who have competing objectives. Table 37-1 shows the stakeholders and their typical objectives.
Table 37-1. Project Stakeholders and Their Objectives
Customers | Bosses | Developers | End-Users | Maintainers |
|---|---|---|---|---|
Quick schedule | No overruns | Interesting design work | Lots of features | No defects |
Low budget | No surprises | Exploration of new technical areas | User-friendly software | Good documentation |
Successful project | Fast software | Easy modifiabiltiy | ||
No grunt work | Robust software | |||
Home life | ||||
| Source: Adapted from "Theory-W Software Project Management: Principles and Examples" (Boehm and Ross 1989). | ||||
As you can see from the table, many of the objectives conflict. The end-users' goal of "lots of features" might easily be in conflict with the customers' goals of "quick schedule" and "low budget." The developers' goal of "interesting design work" could be in conflict with the customers' goals of "quick schedule," and their goal of "no grunt work" might be in conflict with the maintainers' goal of "good documentation."
Most project teams don't do a good job of reconciling these objectives. The result is that a project can seem sometimes like a turtle on Valium to the customer at the same time it seems like a rapid-development death march to the developers.
Theory-W software-project management argues that making winners of all the stakeholders in a software process is both a necessary and a sufficient condition for running a successful software project. Projects that set up win-lose or lose-lose scenarios will be unsuccessful.
Theory-W Management supports rapid development by putting all the stakeholders on the same side of the negotiating table. Conflicts between these groups are at the root of most software-project management problems and affect your ability to set goals, define delivery dates, prioritize assignments, and adapt to changes.
Specifically, Theory-W Management supports rapid development in the following ways.
Clearer project objectives. Because a Theory-W project begins by identifying each of the stakeholders' "win" conditions, the project's objectives are clear from the start. The negotiation that takes place at the beginning of the project reinforces and documents the project's objectives. Setting clear objectives is probably the most important key to motivating developers, and motivating developers is probably the most important key to rapid development.
CROSS-REFERENCE
For more on the importance of clear objectives, see Goal setting in Using the Top Five Motivation Factors.
Better customer relations. Many projects are set up to provide a win for the customer and a loss for the developers, or vice versa. It's hard to maintain good relations when one of the parties is losing. Theory-W projects by their very nature improve relations between developers and customers because everyone stands to gain.
CROSS-REFERENCE
For details on using customer relations to improve development speed, see Chapter 10, Chapter 10.
Several development-speed savings arise from improved customer relations:
Efficiency improves as a result of better communication and better customer understanding of the customer role in the project.
The amount of rework drops because you do a better job of analyzing requirements. Negotiations over feature details take less time because everyone is aligned on the main goals they want to achieve.
Early goal-setting produces realistic schedule expectations, which improves the perceived development speed and eliminates problems associated with overly optimistic schedules.
Reduced customer-related risk. Many risks arise from the customer side of a development relationship, including feature creep, slow communication, and micro-management. Establishing a Theory-W relationship with your customer helps to minimize or eliminate such risks. It helps you to manage the remaining risks because you can keep a close eye on customer-related risks and get early warnings about them.
When you use the Theory-W Management practice, you have everyone sit down at the beginning of the project and identify their win conditions. Then everyone negotiates to create a projectwide set of win conditions that you can reasonably achieve. Project management for the rest of the project consists of monitoring the project to ensure that each stakeholder continues to win. If one of the stakeholders starts to slide into a lose condition, you adjust the project accordingly.
The best work in developing win-win situations has been done in the field of negotiating. Here is the outline of a general process you can use to set up a win-win situation from "getting to yes" (Fisher and Ury 1981):
CROSS-REFERENCE
For more on negotiating and the four steps of Getting to Yes, see Beating Schedule Pressure, Beating Schedule Pressure.
Separate people from the problem.
Focus on interests rather than positions.
Invent options for mutual gain.
Insist on using objective criteria.
Table 37-2 provides a summary of how these win-win steps apply to Theory-W Management.
Table 37-2. Steps in Theory-W Project Management
|
|
|
Source: Adapted from "Theory-W Software Project Management: Principles and Examples" (Boehm and Ross 1989). |
The steps in Table 37-2 are described in the following sections.
In Theory-W, the first step you take is to establish objectives for the project that will allow everyone to win. The word "preconditions" in this case is used to mean "entrance criteria": if you can't figure out how to make everyone a winner, don't even begin the project.
To complete step 1, you need to understand how people want to win, establish reasonable expectations on the parts of all stakeholders, match people's tasks to their win conditions, and provide a supportive environment.
Understand how people want to win. Before you try to understand how people want to win, be sure to identify all the key people. Projects have failed because a key stakeholder—subcontractor, marketing department, user group, or product-support group—was not included.
Put yourself into other stakeholders' shoes to understand what they need to win. Understand that what your customers, marketers, and end-users need is likely to be different from what you need. Of these groups, the group that's arguably the most important to understand—and the one that's often the most under-represented—is your customers. Work extra hard to understand your customers' win conditions.
Theory-W works well even if one of the stakeholders is an S.O.B. who is determined to take advantage of you or the other stakeholders. The purpose of Theory-W is to make everyone a winner. If you can't structure the project so that everyone wins, you don't do the project at all. If you can get a win with the S.O.B. involved, fine. If not, don't do the project—there's no point in doing it if you're going to emerge a loser. When you use Theory-W with an S.O.B. on the other side of the bargaining table, you might come out a little worse than you would if Mr. Rogers were on the other side of the table. The S.O.B. might get more than his or her fair share, but that's OK as long as the rest of you can still meet your win conditions.
Establish reasonable expectations. The second sub-step in establishing win-win preconditions is to establish reasonable expectations. There's not much you can do to set up a win-win project if your customer wants the moon and wants it in 6 weeks.
If you find that some parties have unreasonable expectations, bring the stakeholders together to identify expectations and resolve mismatches. If the customer insists on a delivered product within 6 weeks and the developers are convinced that they can't do it in less than 6 months, you have a mismatch. Unless you can align the customers' and developers' expectations, one of those parties will emerge from the project as a loser, and the project itself will fail.
CROSS-REFERENCE
For tips on negotiating mismatches in schedule expectations, see Beating Schedule Pressure, Beating Schedule Pressure.
Here are some ways you can help to bring people's expectations into line with reality:
CROSS-REFERENCE
For tables of the shortest possible schedules for projects of various sizes and kinds, see Estimate Refinement, Ballpark Schedule Estimates.
Have people look at issues from one another's viewpoints.
Relate people's expectations to experience. Refer to historical benchmarks or the judgment of experts to define what is realistic and what is not. If your customer or boss wants you to develop a product in less than the shortest time that your organization has ever developed a similar size product, that expectation is probably unrealistic. If they want you to develop a product in less time than anyone in your industry has ever developed a product of that size before, that's definitely unrealistic. Use historical benchmarks to reign in unrealistic expectations for schedule, functionality, cost, and other product or project attributes.
Relate people's expectations to well-calibrated models. If your organization hasn't collected data on its experience, or if people don't take that data seriously, refer to the results of a software-estimation model. This can be especially effective because it allows the stakeholders to adjust the parameters of the project in real time and see how it's likely to affect the outcome of the project.
Match people's tasks to their win conditions. Many times people have no influence over the aspects of the project that will allow them to win. That's demotivating and sets the project up to fail.
Instead, assign people's tasks so that they can achieve their own win conditions. Here are some examples of how you could do that:
Make the people who will maintain the code responsible for reviewing and approving it during its initial development.
Put developers in charge of estimating the time required for tasks they will ultimately perform.
Put end-users in charge of reviewing early storyboards or prototypes of the software for usability issues.
Give developers the explicit goal of creating designs that they can implement quickly and reliably.
Put customers in charge of identifying features to include and features to exclude in order to make the schedule as short as possible.
Put customers in charge of tracking project status.
The common theme here is that you need to search for creative win-win situations. Some of those situations will require you to structure the project in unusual ways, but that's fine. Your project will be all the more successful for it.
Provide an environment that supports the project's goals. The kind of environment that you'll need will depend on each stakeholder's point of view. For developers, it usually means providing training, modern hardware, and modern software tools. For customers, it might require training in modern programming practices and using a lifecycle model that provides tangible signs of progress.
The second main step in Theory-W is to create a software process that will make everyone a winner. To do that, you need to establish a realistic process plan, use the plan to control the project, identify and manage your win-lose or lose-lose risks, and keep people involved.
Establish a realistic plan. Planning is key to the success of the Theory-W approach. The plan maps out the road to achieving win-win results. It records the mutual commitment of the project stakeholders to a set of win-win conditions and to all the implications of agreeing to achieve them.
If you completed Step 1, you will have established reasonable expectations. Remember that the establishment of reasonable expectations is a precondition to starting the project. If you couldn't establish reasonable expectations, don't proceed with the project. Reasonable expectations make the job of planning immensely easier because you can create a realistic plan. You don't have to wrestle against unrealistic expectations in every paragraph and every sentence.
Use the plan to control the project. Once you've created the plan, it's imperative that you follow the plan. Too many plans become shelfware. If you find that you're not following the plan, either correct the project so that you are following the plan or revise the plan so that you can follow it. The plan provides a framework for detecting shortfalls from the win-win conditions and taking corrective action; if you don't follow the plan, you probably won't achieve a win-win outcome.
Identify and manage your win-lose and lose-lose risks. Risk management is a key aspect of the Theory-W approach, and the six basic risk-management steps from Chapter 5, Chapter 5, apply. For each of the stakeholders' win conditions, you should identify a risk of not achieving their win conditions. Then monitor that risk along with the other risks to your project.
Keep people involved. Theory-W is a people-oriented process, and it's important to keep all the stakeholders involved throughout the project. Stakeholders will care more about their own win conditions than anyone else will, and keeping the stakeholders involved in reviews, planning, progress monitoring, feature-change negotiations, and other activities will help to achieve a win-win outcome.
In addition to structuring the process for success, Theory-W has you structure the product for success. This includes both the external aspects of the product, which will be visible to end-users, and the internal aspects of the product, which will be visible to developers and maintainers. From the end-user's point of view, the product will be a success if it's easy to learn, easy to use, and reliable. From the maintainer's point of view, the product should be well-documented, programmed with good style, and easily modifiable.
Although Theory-W Management is most useful when you apply it from the start of a project, you can begin to apply it during any phase. If you've experienced difficult relations with a customer, you might conduct a win-win analysis to uncover the potential win-lose or lose-lose conditions that are the source of the difficulties. Theory-W can help you to keep a successful project running smoothly, and it can help to rescue a project that's in trouble.
Theory-W works best when it's championed by an upper-level manager or someone high enough to use it with customers and all other stakeholders. If it's not possible to obtain upper-level support, you can still use it at the technical-lead or individual-developer level to provide insight into why the other stakeholders in the project act the way they do.
There is no limit to the size or kind of project that can use Theory-W. It does not require much overhead, so it's suitable for small projects. Larger projects will have more stakeholders and more complicated win conditions, and identifying and creating the win-win conditions on those projects becomes all the more important. Theory-W is as well-suited to maintenance as it is to new development, and it is as well-suited to shrink-wrap software as it is to business or systems software. The specific stakeholders change, but the value of meeting their win conditions does not.
The manager's role in Theory-W is different from the manager's role in some other management theories. In other theories, the manager plays a role of boss, coach, or facilitator. In Theory-W, the manager manages more than his or her direct reports: he or she also manages stakeholder relationships and goals. In this schema, the manager is a negotiator with responsibility for creating project solutions that make everyone a winner.
Beyond that, the manager is also a goal-setter and a monitor of progress toward goals. On an ongoing basis, the manager seeks out day-to-day win-lose or lose-lose conflicts, confronts them, and changes them into win-win situations.