Author: Karl Wiegers

In the first article in this series I described five dimensions of a software project: features, quality, schedule, staff, and cost. Each of these dimensions can be a project constraint, a driver, or a degree of freedom. A way to classify each dimension into one of the three categories is to think of the amount of flexibility the project leader has with respect to that dimension. A constraint gives the project leader virtually no flexibility, a driver has low flexibility, and a degree of freedom provides wider latitude to balance that dimension against the other four.

Flexibility Diagrams

A graphical way to depict the degree of flexibility is with a Kiviat diagram, also called a radar chart or a spider chart (Figure 1). In a Kiviat diagram, you show the five dimensions around a circle and draw a separate axis for each dimension coming out from a common origin point in the center. All the axes are the same length and they are normalized to the same scale. Each axis represents how much flexibility the project manager has in the corresponding dimension, so I call these pictures “flexibility diagrams.” I use a relative scale from zero to ten for flexibility. Zero is not shown at the exact center of the origin just for convenience in drawing the plot.

Figure 1. Flexibility diagram for a corporate information system.

Plotting a point at zero indicates that the dimension for that axis is a constraint with no flexibility. If you plot a point fairly low on the axis, between zero and two or thereabouts, that represents a driver. It shows that the project manager has a small amount of flexibility in that dimension. Any dimension plotted at a higher level on its axis represents a degree of freedom having more latitude for adjustment. If you connect the five points for the five dimensions that you plotted, you get an irregularly shaped pentagon that visualizes one profile of the project’s characteristics.

Figure 1 shows the flexibility diagram for an information system my team once developed. This project was constrained to a fixed staff size, so the value plotted on the staff axis is zero. The project was aiming for a desired, but not critical, delivery date, so the point on the schedule axis also has a low value. The project had varying amounts of flexibility around the features that would be incorporated into the initial release, the product quality, and the latitude for cost overruns. Therefore, the values for these degrees of freedom are plotted higher on their axes.

Note that this is not a high-resolution or quantitative tool. We’re not going to calculate the area of the pentagon or anything like that. But the size of the pentagon does provide a rough indication of how much flexibility the project manager has to work with. If the pentagon is small, that means that you have numerous constraints or drivers, which will make it more difficult for the project manager to steer a path to success.

Different types of projects will lead to flexibility diagrams having very different shapes. Figure 2 illustrates a flexibility diagram for a hypothetical project for which quality is a driver and the schedule shows the greatest latitude. This is what you might see for a product intended for use in a higher-risk environment. Note that this diagram does not show any constraints; none of the axes are plotted at the zero value. That’s fine. In contrast, the profile for a commercial software product in a highly competitive environment might look like Figure 3, in which a specified feature set must be included (a constraint), the schedule is constrained to a specified ship date, and the quality is just whatever it turns out to be.

Figure 2. Flexibility diagram for a quality driven application.

Figure 3. Flexibility diagram for a competitive commercial application.

The shapes of the pentagons in these examples visually indicate the important aspects of each project. If you push the point on one of the axes inward to reduce the amount of latitude the project leader has in one dimension, you’ll generally have to adjust the other dimensions to compensate. You can use this sort of analysis to make management aware of the tradeoffs and decisions they must make to meet a project’s key objectives, and to negotiate realistically achievable commitments on each project.

Flexibility Table

You can also document your project priorities in the form of a flexibility table, as illustrated in Figure 4. This example is simplified just to give you a flavor of how this works. For each project constraint, state the limits the project manager must work within. For each success driver, described the goal you’re intending to achieve. For each degree of freedom, describe the tolerance or latitude that the project manager has available.

Figure 4. Sample flexibility table

The table in Figure 4 is for the project whose flexibility diagram appears in Figure 1. Recall that staff was a constraint. We had just five full-time team members available for the duration of this project. Schedule was a driver. We wanted to have the first release delivered within four to five months, but there was no fixed delivery date. The other three dimensions had more flexibility. Because the project was essential, the project manager could overrun the initial budget by a reasonable margin before anyone would get upset. We did have a core set of high priority features that we needed to have delivered in the first release, but other than that, we could defer some requirements if necessary.

Note that each of the five dimensions takes on only one characteristic. For example, schedule is either a constraint, a driver, or a degree of freedom, not two of these or all three. You wouldn’t have entries for the same dimension in more than one column in a flexibility table.

Applying the Five Dimensions

The point of this analysis is to help the project manager make decisions as to how to respond to changing conditions or realities on the project. You can use the five-dimension model to renegotiate when the world changes. Suppose staff is constrained as it is in Figure 1. If new requirements come along that simply must be included, the only parameters that can change are quality, cost, or schedule. Nothing is free. Ask management which dimensions to adjust to accommodate this request. The specific answer is less important than the discussion that is triggered when project managers react to unexpected changes in any of these five dimensions. Customers and managers have to understand the impact of such changes on the other project dimensions so they can make the right decisions.

One characteristic of a healthy software engineering culture is that project expectations and commitments are established through negotiation. To avoid unpleasant surprises late in a project’s life cycle, the stakeholders all have to understand and agree on their objectives and priorities. Not everyone might be happy with the outcome of the negotiations, but people can commit to realistic schedules and deliverables only if all the parameters are discussed honestly. A group with a culture in which people are afraid to say no or to discuss problem areas openly will always fall short of expectations. Tools like the flexibility diagram can facilitate these frank, and often difficult, negotiations.

Don’t forget to leave your comments below.

Perhaps you’ve seen a sign at a car repair shop that asked, “What do you want: good, fast, or cheap? Pick two.” While humorous, the sign is also wise: it acknowledges the reality of tradeoffs. You generally cannot optimize every desired outcome of a given situation.

People often apply this so-called “iron triangle” or “triple constraint” to software projects. The problem is that I have seen numerous representations of the triangle with various parameters on the triangle’s vertices—size, cost, time, or scope—and various assumptions made about what is being held constant, such as quality or functionality. I’ve also seen diagrams that show four project dimensions. So, in my view, the “triple constraint” is wrong, although the concept is valid.

The Five Dimensions

I think in terms of five dimensions we have to manage on a software project (Figure 1, adapted from my book Creating a Software Engineering Culture). First, of course, there are the features (aka scope), which itemize the product’s functional capabilities. But it’s important to distinguish quality from scope. I can write software very fast if it doesn’t have to work correctly. The other three dimensions are the time we have available before delivery (schedule), the budget for the project (cost), and the staff available to work on the project. We shouldn’t lump staff and budget together and just call the combination “resources” as is often done. Most of the project cost is indeed staff salaries. I’ve seen situations, though, where a team had adequate funding but could not hire additional staff. In this case, perhaps the project manager can use the available money in different ways, such as outsourcing some work, buying automated test tools, or bringing in consultants.

For each project, we need to decide which dimensions are most critical and how to balance the others so we can achieve the key project objectives. The tradeoffs among these five dimensions are not simple or linear. For example, if you add staff, the schedule might be shortened (although not necessarily) and the cost could well increase. A common, but unfortunate, tradeoff is to shorten the schedule or add features while sacrificing quality. Anyone who has been the victim of buggy software questions these kinds of tradeoff decisions, but they do take place.

Each of these five dimensions can take one of three roles on any given project: a constraint, a driver, or a degree of freedom. Constraints define restrictions within which the project manager must operate. The project manager has no flexibility around a constraint dimension. If a team of immutably fixed size is assigned to a project, staff becomes a constraint. Cost is a constraint on a project being done under a fixed-price contract (at least from the client’s perspective). Quality will be a constraint for a project that develops software for a medical device. Y2K projects were schedule-constrained.

A driver is a key objective or success criterion for the project. For a product with a desired marketing window of opportunity, schedule is a driver. Commercial desktop applications often have features as a driver. The project manager has a little flexibility around the drivers. A specified feature set might be the primary driver of the project, but features are a constraint if the feature set is not negotiable.

Any project dimension that is neither a driver nor a constraint is a degree of freedom. This is a factor that the project manager can adjust within certain limits. The manager’s challenge, then, is to adjust the degrees of freedom to make the project succeed in meeting its success drivers within the limits imposed by the constraints. Suppose that on some corporate information system project the drivers are features and quality and staff is a constraint, so the degrees of freedom become schedule and cost. The implication for this profile is that the features demanded by the customers will all be included, but the delivery time for the product may be later than desirable and the project might cost more than planned.

Here’s a little safety tip: all five dimensions can’t be constraints and they can’t all be drivers! Something has to give to be able to meet the key objectives. If the project is over-constrained, with no degrees of freedom, then you will almost certainly fail. The first added requirement, the first team member who gets the flu, the first risk that materializes will trash the schedule because the project manager has no flexibility to respond to these changes. A student in a project management class I taught once said, “Our project has a fixed budget, we can’t add any people, all of the features are critical, there can’t be any defects, and we have to finish on time.” This project isn’t likely to succeed.

Negotiating Priorities

An important aspect of this model is not which of the five dimensions turn out to be drivers or constraints on any given project, but that the relative priorities of the dimensions be negotiated in advance by the project team, the customers, and management. This negotiation process helps to define the rules and bounds of the project. For instance, schedule is often presented as a constraint when in fact it is a driver. The way to tell the difference is to ask, “Okay, you want this delivered on June 30. What happens if it’s not delivered until, say, July 14?” If the answer is to forget the whole thing because it won’t be useful to us or we’ll be socked with penalties from the government or our client then, yes, schedule truly is a constraint. But if the answer is, “Well, we’d sure like it by June 30, but I guess we’ll live if it’s not available for two more weeks,” then schedule is a driver. If there is some flexibility around a dimension, then it is not a constraint. A little bit of flexibility makes it a driver, and a lot of flexibility makes it a degree of freedom.

Let me illustrate how this five-dimension idea works in practice. Once I heard a discussion between a senior manager and a project manager about a new project. The senior manager asked, “How long will this take?” The project manager replied, “Two years.” “That’s too long,” said the senior manager. “I need it in six months.” So what did the project manager say? He said, “Okay.” Now what changed in those few seconds? Nothing at all! The project didn’t shrink by a factor of four, the team didn’t get four times bigger, and the team didn’t magically become four times as productive. The project manager simply said what the senior manager wanted to hear. (The project took more than two years to complete, incidentally.)

What are some other ways the project manager could have responded instead of simply saying okay? Let’s look at the five dimensions. Maybe he could have asked what portion of the product absolutely must be available within six months. That is, can we cut back on the features intended for the initial release? The project manager could question the schedule, asking, “What’s so vital about six months?” Perhaps this system is replacing a legacy system that runs on an antique computer and they’re removing that computer from the building in six months. Okay, that’s a good reason. Or maybe there’s nothing magic about six months, but we understand there’s a strong desire to get the system operational quickly. In that case the target date of six months is a driver, not a constraint.

You can continue this analysis down the list of the five attributes. Can I get more people or more money? Does the software have to work? Some organizations deliver something on the scheduled release date, but it is severely crippled in functionality and full of bugs. Nonetheless,  they declare victory and claim they shipped on schedule, even if what they shipped wasn’t useful. It’s just a little game they play.

Contemplating these five dimensions is a better way to understand your project priorities instead of just assuming that every aspect of the project is both critical and non-negotiable. In part two of this series, I’ll describe two ways to represent the information about a project’s constraints, drivers and degrees of freedom and show you some examples.

Don’t forget to leave your comments below.

The first article in this series described the critical role of the business analyst in bridging the communication gap between business and IT, understanding project scope, and asking meaningful questions during requirements elicitation. This concluding article explores several additional contributions that BAs make to a software project.

Prioritize Early and Often

Requirements development is an iterative and incremental process, proceeding from fuzzy notions to detailed specifications a layer at a time. If you’re facilitating an elicitation workshop, keep the discussion focused on the right level of abstraction for that day’s objectives. Don’t let the participants get bogged down in excessive detail or premature design. It can be valuable to sketch out possible user interface screens or build prototypes to clarify requirements. However, diving deeply into design too early can lead to a system that fails to meet the user’s actual needs.

It’s discouraging to realize at crunch time that everything the team has left to do is essential, while they’ve already implemented some features that weren’t really that important. BAs must work with customers to define the priorities for requested product features, so the team can build the most critical functionality in the early iterations. Your job as a BA includes facilitating negotiation between the various stakeholders to ensure that the team makes sensible priority decisions.

Early in the project, identify the various user classes that might contribute requirements. You’ll need to understand which user classes are favored, which (if any) are disfavored, and which groups of users won’t have input to the product’s requirements. The favored user classes typically take precedence if you encounter conflicts in the requirements or priorities presented by different user classes.

Next, work with appropriate representatives of each user class to identify their major use cases. Performing a first-cut prioritization on the use cases will help you determine which ones to explore in detail early on. The top priority use cases are those that are the most important (capabilities the users really need) and the most urgent (capabilities the users need right away). The users might elect to implement only core portions of certain use cases in the initial release or iteration, leaving enhancements for later. Alternatively, they might opt to initially implement the full functionality of a small set of use cases. Understanding the logical dependencies among the requirements will let you determine whether some high-priority requirements should be delayed. Sometimes architectural constraints demand that certain functionality be implemented first.

Create a Collaborative Environment

Software development sometimes is characterized by strained relationships among developers, users, managers, and marketing. The parties may not trust each other’s motivations or appreciate each other’s needs and constraints. In reality, though, the producers and customers of a software product share some common objectives. For information systems development, all parties work for the same company and benefit from improvements to the corporate bottom line. For commercial products, developers and marketing should strive to meet the purchasing customers’ needs, so they will buy more products and rave to their friends. And contract developers should try to make the client happy to get repeat business. A win/win/win outcome means customers are delighted with the product, the developing organization is happy with the business outcomes, and the development team members are proud of the good work they did.

Achieving such a positive outcome requires honesty. Sharing all relevant information among the stakeholders and telling the truth without blame or judgment promotes free and informed choices. I realize that it isn’t always possible to achieve such a ideal environment. In fact, none of my suggestions are likely to work if you’re dealing with truly unreasonable people.

Defining business requirements early in the project will clarify the prospective benefits for both customers and the developing organization. The participants also need to be honest about functionality costs and project constraints. If you think the customer’s cost or schedule expectations are unrealistic, say so and explain your reasoning. Considering the costs will help the stakeholders make sensible business decisions to achieve the maximum value within the existing resource, time, and technology constraints.

It’s not unusual for a BA to solicit input from users only to hear, “I don’t have time to talk to you. You should know what I need. Call me when you’re done.” However, software success is most likely when the BA can forge a collaborative relationship with key stakeholder representatives. Users might hesitate to participate in requirements exploration until they know exactly what you expect from them. Tell your customer collaborators what you need from them so they know why their input is so vital. A vision and scope document will help you identify the right users to talk to and will give them a clear understanding of what the project is trying to achieve.

Insufficient user involvement is well established as a leading cause of software project failure. Point this out to users or managers who don’t want to spend time on requirements discussions. Remind your customers of problems they’ve experienced on previous projects that you can trace back to inadequate user involvement. You can’t afford to keep rebuilding or discarding systems that don’t measure up because the user needs weren’t sufficiently understood. If customers won’t commit to reaching a shared understanding of their requirements, the development organization might be better off avoiding the project. Otherwise, the outcome might well be lose/lose.

Hone Your Skills

The business analyst provides the essential function of bridging the understanding and perspective gap that lies between customers and developers. A competent BA must combine communication, facilitation and interpersonal skills with some technical and business domain knowledge. Even a dynamite programmer or a system-savvy user needs suitable preparation before serving as a BA. The following capabilities are particularly important:

• Facilitation techniques, to lead elicitation workshops.
• Interviewing techniques, to talk with individuals and groups about their needs.
• Listening skills, to understand what people say and to detect what they might be hesitant to say.
• Writing skills, to communicate information effectively to users, managers and technical staff.
• Organizational skills, to make sense of the vast array of information gathered during elicitation and analysis.
• Interpersonal skills, to help negotiate priorities and resolve conflicts among project stakeholders; domain knowledge, to have credibility with user representatives and converse effectively with them.
• Modeling skills, to represent requirements information in graphical forms that augment natural language text.

An effective BA has a rich toolkit of tools and techniques at his fingertips and knows when—and when not—to apply each. My book Software Requirements, Second Edition (Microsoft Press, 2003) describes more than forty “good practices” for requirements development and management.

There’s no substitute for experience, though. One of my consulting clients discovered that they could inspect requirements specifications written by experienced BAs twice as fast as those written by novices because they contained fewer defects. In contrast, another organization asked each developer to write the requirements for the system components for which he was responsible. The result was specifications having wildly divergent styles, organization, and quality. This made it hard for developers to review and use each other’s specifications. A third organization appointed as BAs several developers for whom English was not their native language, while yet another expected its users to write up their own requirements. It’s hard enough to write good requirements when you do it for a living, let alone if you do it just once in a while or in a language in which you aren’t completely proficient.

Requirements for a software product aren’t just lying around waiting for someone wearing a hat labeled “BA” to collect them. At best, requirements exist in the minds of users, visionaries, and developers, from which they must be gently extracted and massaged into a usable form. A talented BA can guide the process to help users understand what they really need to meet their business needs and help developers satisfy those needs. Few project roles are more difficult than that of the business analyst. Few are more critical.

Don’t forget to leave your comments below.

Software managers sometimes assume that every talented programmer is also proficient at interviewing customers and writing requirements, without any training, resources, or coaching. This isn’t a reasonable assumption. Like testing, estimation, and project management, requirements engineering has its own skill set and body of knowledge. Unfortunately, computer science curricula often emphasize programming-related knowledge over other software life cycle activities. Self-study and on-the-job learning likely neglect softer skills such as those needed in requirements engineering, unless you’re specifically studying in pursuit of a professional business analyst certification.

The role of the business analyst is critical to a software project. Many organizations expect developers or project managers to handle this vital function on their own. And even if a project team does include dedicated analysts, their skills might not be up to the task. Too often, I meet BAs who have had little training in how to perform their job and who have few books or tools available to help them. BAs who come from a user background may lack technical understanding, while those who migrated from the IT world might not understand the user’s business domain and terminology. A BA provides a specialized capability that can make the difference between a project that succeeds and one that struggles. In this two-part series, I describe several characteristics and practices of successful business analysts.

Bridge the Communication Gap

The BA is a communication middleman, bridging the gap between vague customer notions and clear specifications. The BA must first understand the user’s real needs and then define a set of functional requirements and quality goals that allow developers to build and testers to verify the system. To be an effective BA, become proficient in all forms of communication, including listening, speaking, and writing. As you interact with executive project sponsors, marketing, and user representatives, understand their objectives for the proposed system and their concerns about the business and the application. Use the vocabulary of the application domain, rather than forcing your customers to understand computer jargon.

Take the time to learn about your customer collaborators and understand how they prefer to communicate. Watch for assumptions that underlie either the users’ expression of needs or your own thinking. Avoid imposing your personal filter of understanding on what you hear the customers say. Keep one of my axioms of software development—and life, for that matter—in mind: The customer is not always right, but the customer always has a point. You must understand and respect those points, so they can be appropriately addressed in the product.

Try to understand the users’ implicit expectations about the system’s characteristics, such as performance, usability, efficiency, and reliability. Companies sometimes make products that fully meet the functional needs, only to discover that users hate it because it doesn’t work like they expect. When users declare that the system must be “user-friendly,” they have a mental image of what that means to them. As a BA, your job is to understand the intent behind each such expectation, so you can translate something vague and subjective like “user-friendly” into goals the developer can satisfy. One technique is to ask users what would constitute unacceptable performance, usability, or reliability.

Requirements development should lead to an understanding, shared by the various stakeholders, of the system that will address the customer’s problem. The BA is responsible for writing requirements that clearly express this shared understanding. Writing documents that customer representatives can understand and verify, while unambiguously conveying precise functional and nonfunctional requirements to the developers, is a tightrope walk. A single requirements specification might not meet both needs.

In requirements discussions, users often bring up fragments of functionality (“I need to be able to sort the list alphabetically”), quality characteristics (“this system has to be a lot more reliable than the old one”), or solution ideas (“then I select the state where I want to send the package from a drop-down list”). Don’t discard these bits of information, because they convey part of what the user has in mind. However, I prefer to focus the early requirements discussions on the tasks users need to accomplish with the system: their use cases or (as is popular in agile development) user stories. This usage-centric approach helps you understand why the functionality or characteristics customers describe are important. An understanding of user goals leads to the necessary functional requirements, which then leads to detailed user interface design.

Because use cases describe a user view of the system, users should understand them. However, use cases alone rarely convey enough detail to developers. One important BA task is to derive from each use case the specific functional requirements that, when implemented, will let users perform the tasks described in the use case. This means you must be able to communicate effectively in both directions: with users (the task view) and with developers (the technical view). To make sure you’ve been understood, have user representatives, developers, and testers review your documents.

Color Inside the Lines

Begin your exploration of a new system’s requirements by defining the ultimate vision of what the product or application will be and do. Talk with the funding sponsor, marketing manager, or product visionary early on to define the project’s business objectives. This information helps you answer this critical question whenever someone suggests a new product feature: “Is this feature in scope?”

Teams rarely implement the ultimate solution in one pass. Instead, define the scope of the first release or iteration as a subset of the final product. Describe a growth path from the initial release toward realizing the ultimate vision through a series of staged releases or iterations. Also, document any known limitations or functionality that you don’t intend to build but which some stakeholder might expect to find. Expectation management is an important strategy.

Ask Revealing Questions

When working as a BA, you’ll need to actively facilitate discussions with users to pull out information that might otherwise go unstated. Ask questions to identify possible alternative ways a user might want to perform some task and to surface related tasks that the user representatives didn’t mention initially. If a user says “the default should be …”, he’s probably describing the normal flow for a use case. The phrase “but I should also have the option to …” suggests an alternative flow for that use case.

Users naturally focus on the system’s normal, expected behaviors. However, developers write much code to handle exceptions, so you should also search for possible error conditions that could arise and decide how the system should respond. If you don’t describe exceptions during requirements elicitation, either the developers will make their best guess at how to handle them, or the system will simply fail when a user hits the error condition. It’s a safe bet that system crashes aren’t in the user’s plans.

A BA isn’t just a scribe, recording whatever customers say they want. A creative BA can suggest ideas and alternatives during elicitation. When users truly can’t express what they need, watch them work and suggest ways to automate appropriate portions of the job. BAs can often think out of the box that limits the creativity of people who are too close to the problem being solved. Be careful to avoid gold-plating, adding extra functionality that just seems cool or somehow desirable. An effective BA must be able to think at multiple levels of abstraction. You should be able to generalize from a specific need expressed by one user to define a set of related needs that will satisfy many members of that individual’s user class.

The second article in this series will look at some of the other habits that help skilled BAs contribute to building great systems, including prioritizing requirements and creating a collaborative environment.

Don’t forget to leave your comments below.