Optimizing Constraints

Environmental challenges can be overwhelming. When presented collectively, these challenges can paralyze a teamas proved by the large number of projects that fail (e.g., the Standish Group reported that in the year 2003, only 34 percent of 30,000 application development projects succeeded, while 15 percent failed and 51 percent were challenged).^[1] A team should distill these challenges into constraints that can be addressed by the solution delivery process as well as project governance. Although MSF does not provide a prescriptive means of identifying constraints, a few good published methods do (e.g., Theory of Constraints).^[2],^[3] Constraints need to be thoughtfully balanced throughout a project so that as impacting events occur, a team understands how to navigate calmly and rationally through each event. In addition, constraints are used to define and prioritize project trade-offs. Because multiple projects potentially are needed to realize a solution, solution constraints also need to be defined, prioritized, and decomposed into subordinate project constraints. Successful teams quickly and continually optimize project constraints. Listed here are a few common constraint categories:

^[1] The Standish Group International, "10th Annual (2003) CHAOS Report," CHAOS Chronicles 3 (2003): 406.

^[2] E. M. Goldratt, What Is This Thing Called the Theory of Constraints? (Croton-on-Hudson, NY: North River Press, 1990).

^[3] H. W. Dettmer, Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement (Milwaukee, WI: ASQC Quality Press, 1997).

• Costs

• Process

• Tools

• Schedule

• Quality

• Scope

• Legacy solutions

• Risk

• Technology

Costs

Typically, the biggest cost to a project is labor. As such, it is very important to determine: a cost-effective blend of required skills and capabilities to deliver a solution; how to organize a team to achieve optimal skill balance and team chemistry; and which processes and procedures are optimal to maximize team throughput and minimize unnecessary rework.

Process

A team should use just enough process to be repeatable and effective. Too much burdens a team. Too little makes for an inefficient team. Many times a team does not realize it has too little process until something extraordinary occurs. It is easy to have "good" process in "good" times. The true test of a process is whether it helps teams navigate out of troubled waters.

Tools

Everyone gets caught up in the allure of time-saving tools. Remember that one of the tenants of MSF (and life) is "keep it simple." Only use a tool if team members have positive and productive experiences with it. Otherwise, the tool(s) might be doing more harm than good to a project.

Schedule

Many "trade-off triangles" are commonly used (e.g., good, fast, or cheap). Regardless of which is used, time is always a factor. Time to delivery is most often driven by external considerations.

Quality

A tough challenge is to figure out the right level of quality for a solution as a whole and for each of its subcomponents. Too little quality might enable a team to churn solutions out faster but will cost an organization in many well-quantified ways, such as increased customer support and decreased customer satisfaction. Compromising quality classically defers costs rather than removes them. On the other hand, too much quality has well-quantified downfalls, too, such as increased project costs and being slower to market.

Scope

Typically, you should consider two areas when assessing project scope, including requirements and features. First, how much and how well should a team document? It takes time to capture as well as to maintain the scope. So what is the right level? A team should document just enough to communicate adequately and clearly. This might mean that different subteams have different levels of documentation. Please note that team members are likely to come and go. Therefore, the lowest level at which to communicate might be at the level of a future team member. Few teams have time or resources to go back and add more detail.

The second area to consider is that solutions with broader scope typically take longer to deliver. Because requirements usually have a short half-life (i.e., documented requirements quickly tend to get out of sync with sponsor needs and expectations), keep the number of requirements per release as low as possible.

Legacy Solutions

Is it better to integrate with legacy solutions or replace them? The answer to this question often involves many business and technical factors and perspectives.

Risk

As discussed in detail in Chapter 5, "Managing Project Risks," risk is the quantified potential of unplanned activities and events that could adversely affect a project. Although managing risk is a regular part of running a project, and so is not a constraint to optimize, two common influences on how a project team manages risk are constraints to optimize: namely, (1) tolerance to risk, and (2) how much effort should be spent proactively addressing risk.

Each organization and each project have an explicit or implicit tolerance to risk. It is much harder for a project team to balance their constraints when their tolerance is implicit. One means of quantifying an organization's tolerance to risk is to understand where it is on Moore's Technology Adoption Life Cycle,^[4] described and depicted as follows (see Figure 2-2).

^[4] G. A. Moore, Crossing the Chasm (New York: HarperBusiness, 1991), 15.

• Innovators "Willing to take a risk on a good idea"; risk explorers who use new or prerelease technology, often to gain a strategic advantage

• Early Adopters "Waits to hear a few good anecdotes"; risk visionaries who see potential inherent in new technology but who are more practical in trying to use it for a competitive advantage

• Early Majority "Needs solid anecdotal evidence"; risk-cautious people who perceive new technology as an enabler but who are unwilling to assume too much risk

• Late Majority "Wants to see three good case studies at similar organizations"; riskadverse people who are willing to consider new technology (at least new to them, but not new to the market) but who are not willing to adopt it until proven examples and case studies of others achieving return on investment (ROI) exist

• Laggards "Wants solid proof that something works"; risk avoiders who are risk intolerant and often are "forced" to adopt technology because of external reasons (e.g., Sarbanes-Oxley compliance)

Figure 2-2. Quantifying risk using Moore's Technology Adoption Life Cycle

The second influence on how risk is managed on a project relates to how proactively a team addresses risk. If a team proactively addresses risk, they often avoid risks and lessen the impact of those that are realized. However, tangible work needs to be included into project plans to proactively avoid what might or might not be realized. How a team addresses risk is therefore a constraint that is project specific and one that needs to be reasoned out. For example, consider a risk of work stoppage caused by a blizzard. A team can mitigate this risk by enabling remote access so team members are able to work from home. A project being run in colder climates might consider adopting this mitigation, whereas a project being run from warmer climates might consider it too administratively expensive. It all comes down to a balance of how tolerant a project team is to unplanned activities or events versus how much time and effort it takes the team to manage risks.

Technology

Should a team proceed with proven technology, or should they try to take advantage of "new and improved" technology to gain some advantage (e.g., better tools for faster development)? Answering this question typically relates to how much risk a project can handle and how much support is available for a project team and for an operations team once a solution is deployed (e.g., obsolete technology typically has support but at a premium cost). Typically, a project uses a mix of technologies on the maturity continuum to maximize benefits while managing risks. The following terms and definitions are taken from Wikipedia, and considered a common means of classifying technology maturity:

• Bleeding edge Any technology that shows high potential but hasn't demonstrated its value or settled down into any kind of consensus. Early adopters may win big or may be stuck with a white elephant.

• Leading edge A technology that has proven itself in the marketplace but is still new enough that it may be difficult to find knowledgeable personnel to implement or support it.

• State of the art When everyone agrees that a particular technology is the right solution.

• Dated Still useful, still sometimes implemented, but a replacement leading edge technology is readily available.

• Obsolete Has been superseded by state-of-the-art technology, rarely implemented anymore.^[5]

  ^[5] Wikipedia (http://en.wikipedia.org/wiki/Technology_lifecycle).