Tag Archive for: business requirements

Tag Archive for: business requirements

Defining Project Scope

Every product development team talks about project scope and team members often complain about unending scope creep. The vision and scope document (often including a use case diagram and a context diagram), otherwise known as the MRD (marketing requirements document) or business case, is a key deliverable in defending against scope creep. You don’t necessarily need a standalone vision and scope document for a small project. Any project of any size, though, will benefit from such strategic guidance, even if it’s just a paragraph or two at the beginning of the requirements specification. 

Vision and Project Scope

defining project and use case diagrams-1

Both the vision and the scope are components of the project’s business requirements. I think in terms of the product vision and the project scope. I define the product vision as: “A long-term strategic concept of the ultimate purpose and form of a new system.” The product vision could also describe the product’s positioning among its competition and in its market or operating environment. 

A well-defined scope sets expectations among the project stakeholders. It identifies the external interfaces between the system and the rest of the world. The scope definition helps the project manager assess the resources needed to implement the project and make realistic commitments. The scope statement defines the boundary of the project manager’s responsibilities. 

Your scope definition also should include a list of specific limitations or exclusions—what’s out. Obviously, you can’t list everything that’s out of scope because that would include every detail in the universe except for the tiny sliver that is in scope for your project. Instead, the limitations should identify capabilities that a reader might expect to be included in the project, but which are not included. I know of a project to build a Web site for a national sports team that included the following exclusions for the initial release: 

  • There will be no virtual or fantasy games via the Web. 
  • There will be no ticketing facilities on the site. 
  • There will be no betting facilities available. 
  • The demographic details for newsletters will not be collected. 
  • Message boards are out of scope for phase 1. 

Some stakeholders involved with this project might have expected these capabilities to be included. Itemizing them as exclusions makes it clear that they won’t be. This is a form of expectation management, an important contributor to project success. 

Related: Project Management Best Practices  

Context Diagram

The venerable context diagram dates from the structured analysis revolution of the 1970s. Despite its antiquity, the context diagram remains a useful way to depict the environment in which a software system exists. Figure 1 illustrates a partial context diagram for a hypothetical corporate cafeteria ordering system. The context diagram shows the name of the system or product of interest in a circle. The circumference of the circle represents the system boundary. Rectangles outside the circle represent external entities, also called terminators. External entities could be user classes, actors, organizations, other software systems to which this one connects, or hardware devices that interface to the system. 

The interfaces between the system and these external entities are shown with labeled arrows, called flows. If the “system” is strictly an electronic system involving software and perhaps hardware components, flows will represent data or control signals. However, if the “system” includes both a software application and manual operations, flows could also represent the movement of physical objects. Two-headed flows indicate update operations involving the data object on the flow. 

defining project and use case diagrams-2

The context diagram depicts the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals: no information about functionality, architecture, or look-and-feel. Nor does it explicitly identify which features or functionality are in scope and which are not. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities. Even the flows are labeled at a high level of abstraction, just to keep the diagram’s complexity manageable. 

Despite the limited view that the high level of abstraction imposes, the context diagram is a helpful representation of scope. It serves as a tool to help the project stakeholders communicate about what lies outside the system boundary. 

RELATED: High Cost of Poor Requirements Management

Use Case Diagram

Use cases are a powerful technique for exploring user requirements. The Unified Modeling Language (UML) includes a use case diagram notation. Figure 2 shows a partial use case diagram for our cafeteria ordering system. The rectangular box represents the system boundary, analogous to the circle in a context diagram. The stick figures outside the box represent actors, entities that reside outside the system’s context but interact with the system in some way. The actors correspond approximately (exactly, in this example) to the external entities shown in rectangles on the context diagram. 

defining project and use case diagrams-3

Unlike the context diagram, the use case diagram does provide some visibility into the system. Each oval inside the system boundary box represents a use case. The use case diagram shows the interactions of the system with its users and some connections between internal system operations, albeit at a high level of abstraction. 

The arrows on the use case diagram indicate which actors participate in each use case. In Figure 2, the arrow from the Patron to the oval labeled “Submit Feedback” means that the patron actor can initiate the Submit Feedback use case. The arrow from Submit Feedback to the Menu Manager actor indicates that the Menu Manager participates somehow in the execution of Submit Feedback. Arrows on the use case diagram do not indicate data flows as they do on the context diagram. In addition to showing these connections to external actors, a use case diagram could depict logical relationships and dependencies between use cases. 

RELATED: Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)

The use case diagram provides a richer scope representation than the context diagram because it provides a high-level look at the system’s capabilities, not just at its external interfaces. There is a practical limitation, though. Any sizable software system will have dozens of use cases, with many connections among them and between use cases and actors. Attempting to show all those objects inside a single system boundary box quickly becomes unwieldy. Therefore, the analyst needs to model groups of related use cases as packages or to create multiple use case diagrams. 

Many analysts have found the context diagram and use case diagram to be helpful ways to represent and communicate a shared understanding of a project’s scope. In Part 2 of this series, I’ll describe two other techniques for defining scope, feature levels and system events. 

Check out Part 2, Defining Project Scope: Feature Levels and System Events 

Check out Part 3, Defining Project Scope: Managing Scope Creep 

Download our eBook, Best Practices Guide for Requirements and Requirements Management, to learn the fundamentals of requirements and how effective requirements management can keep your projects on time and on budget.

READ THE EBOOK

This is an updated version of a 2014 article by Karl Wiegers. You can read the archived original here https://www.jamasoftware.com/blog/context-and-usecase-diagrams-defining-scope/.


requirements management plan

Developers often want to freeze software requirements following some initial work and then proceed with development, unencumbered by those pesky changes. This is the classic waterfall paradigm. It doesn’t work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline.

What is a Requirements Baseline?

A requirements baseline is a snapshot in time that represents an agreed-upon, reviewed, and approved set of requirements that have been committed to a specific product release.

That “release” could be a complete delivered product or any interim development increment of the product. When stakeholders “sign off” on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).

Once the project team establishes a requirements baseline, the team should follow a pragmatic change control process to make good business and technical decisions about adding newly-requested functionality and altering or deleting existing requirements.

A change control process is not about stifling change; it’s about providing decision-makers with the information that will let them make timely and appropriate decisions to modify the planned functionality. That planned functionality is the baseline.

Typically, a baseline is also given a unique name so that all the project participants can refer to it unambiguously. And good configuration management practices allow the team to reconstruct accurately any previous baseline and all its components.

Implementing a Requirements Baseline

Whereas the scope definition distinguishes what’s in from what’s out, the requirements baseline explicitly identifies only those requirement specifications that the project will implement. A baseline is not a tangible item but rather a defined list of items. One possible storage location is a software requirements specification (SRS) document.

If that SRS document contains only—and all—the requirements for a specific product release, the SRS constitutes the requirements baseline for the release. However, the SRS document might include additional, lower-priority requirements that are intended for a later release.

Conversely, a large project might need several software, hardware, and interface requirement specifications to fully define the baseline’s components. The goal is to provide the project stakeholders with a clear understanding of exactly what is intended to go into the upcoming release.

Perhaps you’re storing your requirements in a requirements management solution, rather than in documents. In that case, you can define a baseline as a specific subset of the requirements stored in the database that are planned for a given release.

RELATED: The Gap Between the Increasing Complexity of Products and Requirements Management

Storing requirements in a solution allows you to maintain an aggregated set of both currently committed requirements and planned future requirements. Some commercial requirements management tools include a baselining function to distinguish those requirements (perhaps even down to the specific version of each requirement) that belong to a certain baseline.

Alternatively, you could define a requirement attribute in the solution to hold the release number or another baseline identifier. Moving a requirement from one baseline to another is then a simple matter of changing the value for that requirement attribute.

The attribute approach will work when each requirement belongs to only a single baseline. However, you might well allocate the same requirement (or different versions of the same requirement) to several baselines if you’re concurrently developing multiple versions of your product, such as home and professional versions. Tool support is essential for such complex baseline management.

When following an incremental or iterative development life cycle, the baseline for each iteration will represent just a fraction of the overall system’s functionality.

A small project my team once worked on took this approach. This project worked in three-week release cycles. For each cycle, the BA specified the software requirements that were to be designed, coded, integrated, and verified during the next three weeks. Each requirements baseline was therefore quite small. In a classic agile approach, the product grew incrementally toward full functionality as the developer periodically released useful versions to the users.

RELATED: How to Perform Better Impact Analysis on Upstream and Downstream Relationships

When to Perform a Requirements Baseline

Business analysts sometimes struggle with exactly when to define a requirements baseline. It’s an important decision because establishing the baseline has the following implications:

Formal change control begins. Change requests are made against an established baseline. The baseline. therefore, provides the point of reference for each proposed change. Make sure your change control process and players are in place before you define any project baselines.

Project managers determine the staffing levels and budgets needed. There are five dimensions to a software project that must be managed: features, quality, schedule, staff, and budget. Once the features and quality goals are defined in the baseline, the project manager adjusts the other three dimensions to accomplish the project’s objectives. It can work the other way, too. If staff, budget, and/or schedule are pre-established by external forces, the baseline composition is necessarily constrained to fit inside the project box bounded by those limits.

RELATED: Getting the Most from a Requirements Management Tool

Project managers make schedule commitments. Prior to baselining, requirements are still volatile and uncertain, so estimates are similarly volatile and uncertain. Once a baseline is established, the contents of the release should be sufficiently well understood so that managers can make realistically achievable commitments. The managers still need to anticipate requirements’ growth (per their requirements management plan) by including sensible contingency buffers in their committed schedules.

Baselining requirements too early can push your change process into overdrive. In fact, receiving a storm of change requests after defining a baseline could be a clue that your requirements elicitation activities were incomplete and perhaps ineffective. On the other hand, waiting too long to establish a baseline could be a sign of analysis paralysis:  perhaps the BA is trying too hard to perfect the set of requirements before handing them to the development team.

Keep in mind that requirements elicitation attempts to define a set of requirements that is good enough to let the team proceed with construction at an acceptable level of risk. Use the checklist in Table 1 to judge when you’re ready to define a requirements baseline as a solid foundation for continuing the development effort.

Table 1. Factors to Consider Before Defining a Requirements Baseline

Business Rules Determine whether you’ve identified the business rules that affect the system and whether you’ve specified functionality to enforce or comply with those rules.
Change Control Make sure a practical change control process is in place for dealing with requirement changes and that the change control board is assembled and chartered. Ensure that the change control tool you plan to use is in place and configured and that the tool users have been trained.
Customer
Perspective		 Check back with your key customer representatives to see whether their needs have changed since you last spoke. Have new business rules come into play? Have existing rules been modified? Have priorities changed? Have new customers with different needs been identified?
Interfaces See if functionality has been defined to handle all identified external interfaces to users, other software systems, hardware components, and communications services.
Model Validation Examine any analysis models with the user representatives, perhaps by walking through test cases, to see if a system based on those models would let the users perform their necessary activities.
Prototypes If you created any prototypes, did appropriate customers evaluate them? Did the BA use the knowledge gained to revise the SRS?
Alignment Check to see if the defined set of requirements would likely achieve the project’s business objectives. Look for alignment between the business requirements, user requirements, and functional requirements.
Reviews Have several downstream consumers of the requirements review them. These consumers include designers, programmers, testers, documentation and help writers, human factors specialists, and anyone else who will base their own work on the requirements.
Scope Confirm that all requirements being considered for the baseline are within the project scope as it is currently defined. The scope might have changed since it was originally defined early in the project.
TBDs Scan the documents for TBDs (details yet to be determined). The TBDs represent requirements development work remaining to be done.
Templates Make sure that each section of the SRS document template has been populated. Alternatively, look for an indication that certain sections do not apply to this project. Common oversights are quality requirements, constraints, and assumptions.
User Classes See whether you’ve received input from appropriate representatives of all the user classes you’ve identified for the product.
Verifiability Determine how you would judge whether each requirement was properly implemented. User acceptance criteria are helpful for this.

 

RELATED POST: 8 Do’s and Don’ts for Writing Requirements

You’re never going to get perfect, complete requirements. The BA and project manager must judge whether the requirements are converging toward a product description that will satisfy some defined portion of customer needs and is achievable within the known project constraints.

Establishing a baseline at that point establishes a mutual agreement and expectation among the project stakeholders regarding the product they’re going to have when they’re done. Without such an agreed-upon baseline, there’s a good chance someone will be surprised by the outcome of the project.

And software surprises are rarely good news.

To learn more about how to write requirements in a way that all stakeholders have a clear understanding of development needs, download our eBook, Best Practices for Writing Requirements.

READ THE EBOOK

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at ProcessImpact.com. 


deploying software, software adoption

At a conference I attended recently, I listened to teams discuss the challenges they faced in deploying software in their organizations. The consensus was that the software is easy; the people are hard. That is to say, getting up to speed with a new software solution itself is relatively easy compared to getting people to change their behavior and successfully adopt new software. 

ROI Requires that Teams Actually Use the Solution  

One of the speakers said something that really stuck with me. This person said, “There is no return on investment without adoption, and there is no adoption without user acceptance.” And while that may seem obvious, many times the end user of the software is forgotten. Other priorities — like budget, schedule, and various agendas — put a lot of pressure on the deployment plan. The human aspect, as important as it is, gets lost. 

Gaining Acceptance Later in the Implementation Will Cost You 

When implementing a new solution, it’s imperative that you get your team on board from the get-go – and not just for the purpose of keeping them happy. Just as it’s more costly to identify inaccurate requirements late in the product delivery lifecycle, the same principle holds true for user acceptance. Resistance from users identified late is always going to be more costly than adoption issues identified and addressed early.  

While implementing a new solution may be a top–down decision, it’s important to remember that the users are the ones who will need to adapt to the change. The primary impacted stakeholders (i.e. the end–users) will be more receptive to a major change if they are participating in the process, rather than being told that they must adopt a new tool.  

Change is difficult, and without a full understanding of the benefits of a new solution, teams may feel frustrated or resistant. One way to preemptively combat resistance is by identifying long- and short-term goals for each team member and encouraging users to be involved in the implementation process. 

The Key to User Adoption is People  

Having worked in professional services for over a decade, I have come to see just how valuable it is to understand the people side of deployments. In my years as a business analyst, I’ve seen from the inside just how difficult it can be to get people on board with new solutions, particularly those that also come with process changes, and how to make those changes stick. 

My interest in this topic goes even deeper. A few years ago, I completed a master’s program in psychology where I studied human behavior and why people do or do not change. I’ve found that what I learned during my study of psychology has translated quite well to the consulting world. 

In this post I won’t be able to outline the perfect adoption plan for your organization; this would be futile as no two companies have the same needs or challenges. But I will discuss the approach we recommend when planning for a solution rollout that maximizes adoption. 

If You’re Taking a Trip, Bring the Whole Team Along 

 I’m going to start with an analogy:  

Let’s say you’ve pretty much determined that everyone on your team could benefit from a vacation. You’ve even heard people say so. You’ve had some good conversations about what people want and need, and with that knowledge you pick out a destination that’s going to recharge everyone. 

Next, you have to figure out what kind of transportation you’re going to use to get everyone to the identified location. You’ve gone online and talked to some others about what kind of vehicle works best for teams like yours.  

So, with the information you have, you go ahead and buy the perfect car for this trip. It has all the things you need.  

In case you haven’t figured out how the pieces of my analogy fit into the rollout of a new solution, here it is:  

  • The people are those who would benefit from a new process and solution to meet their business objectives 
  • The “destination” is that ultimate goal, where the benefits are realized 
  • The “car” is the new software solution that gets you to that ultimate goal

But here’s something you have to consider before you embark on this journey: You have to figure out where everyone lives, what kind of baggage they’re bringing with them, and how you’re going to organize picking them all up so you can all be in the car at the same time, happily enjoying the journey to your destination. More on that in a bit.  

Key Factors in Planning a Successful Software Deployment 

If you’ve ever actually planned an out-of-town experience with coworkers (or family, for that matter), you know it’s impossible to make everyone happy all the time. Introducing a new way of working to your teams can be even more difficult. Why? 

Before I answer that, remember that these are the main things to keep top-of-mind when planning a successful deployment: 

  • Bringing new teams into a new solution, with new processes, is not simply a functional or technical issue; it is a people-centric change. 
  • Benefits that require that people adopt the solution inherently require that those people change behavior. 
  • The longer adoption problems go unaddressed the more difficult and expensive they are to address.

New data for 2019 reveals the growing gap between product complexity and requirements management. Find out more by downloading our report. 

Design Your Approach Based on the Specific Needs of Your Team  

Change is hard – especially when people are involved. You can put up your pie chart or line graph with anticipated benefits and have everyone nodding their heads in agreement, and you can find the perfect “car” to get you there. But you cannot assume that pointing at that amazing vacation spot on a map or showing off your awesome new vehicle will translate to motivation and acceptance for the people who must be on board in the end.  

Of course, some will be on board immediately, so make sure you identify those people and train them to evangelize for the effort. These advocates are a great asset as you complete your rollout to the rest of the organization. Successful organizations often pair these early adopters with new users to help them get up to speed with the new process.   

Others may need more attention, and you must pay careful attention to their fears and objections and speak to them early and often. 

Consider the Delta Between Where Your Team is Today and Where You Want to Be 

You must consider the maturity of your organization and teams. Of course, it doesn’t have anything to do with the emotional maturity of the individuals (though that could come into play), but the maturity of their processes and toolset and how they’re accustomed to getting their work done today. In my experience as a consultant, I find that team maturity ranges widely, especially when it comes to requirements management processes and supporting tools.  

Knowing where teams are — or their level of maturity — is important for a number of reasons, not least of which is anticipating resistance. Think about the person who is currently using a Word doc that they keep somewhere on their laptop to manage the requirements for a really complex product. This might be considered a pretty basic level of maturity. 

Now, before bringing this person into a new solution, it is important to think about the degree of change being asked of this person. What does a single-source collaborative system feel like to a person coming from Word files on their computer? What resistance can you anticipate and what will be your approach? Again, communication early and often is going to be key to getting this person on board with a new solution.  

Learn more about best practices for change impact analysis by reading our blog post. 

Engage with People to Counteract Resistance 

When change is introduced, the initial reaction from most is to resist. This isn’t necessarily a bad thing, as not all change is good. But if you don’t address resistance, it can lead to rigidity, causing teams to dig their heels in and get stuck.   

When you are bringing on a new team into your deployment effort, don’t just set up training on how to use the tool. You’ll want to engage with your people at a personal level so you can uncover their anxieties and address them. You’ll need to anticipate their questions and welcome their concerns. When you know their concerns, you can address them; it’s the concerns you don’t know about that can manifest very late and cause problems for the whole deployment.  

For example: Consider a person who has yet to log into the software even a month after deployment. What did we not know about this person that let them slip through the cracks? A quick way to find out is to simply ask them. 

Remember that unanswered questions today turn into resistance tomorrow. Provide opportunities for people to voice their questions early so you can address them. Consider establishing clear channels for communication with users.  

Explore product development strategies for systems engineers by downloading our whitepaper. 

Adopt a Change Management Model to Give Your Project Structure 

There are many change management models out there, and I recommend researching these until you find one that make sense for the size of your company, its culture, and your strategic goals. I personally like the ADKAR model from Prosci. 

The five parts of this specific change management model fit well with how we’ve been discussing bringing on teams to improve adoption: 

  • Awareness of the need for change. 
  • Desire to participate and support the change. 
  • Knowledge on how to change. 
  • Ability to implement required skills and behaviors.
  • Reinforcement to sustain the change. 

 We’ve also seen great success from teams who have read this book: “Change Management: The People Side of Change,” by Jeffrey M. Hiatt and Timothy J. Creasey.  

A good change management model, like ADKAR, will help you consider the approach you want to take as you get started on your deployment plan. You’ll want to think about:   

  • How you will build awareness, not just of new processes and solutions, but also why you’re taking on this initiative and what you hope it will do for your organization. 
  • How you will communicate the benefits of using the solution, particularly the “what’s in it for me” for each individual or each team. 
  • How you will build knowledge about how the solution works, relative to the current tool, and how to get the most of it. 
  • How will you ensure people gain the ability to use the solution with the proper training for their position, in a style that will help them feel empowered and not burdened through the learning curve. 
  • What kind of reinforcements you can use to ensure that the process change sticks and the initiative’s objectives are met. 

These are just a few examples of how to use the ADKAR model but the key is to engage with this line of thinking early and be open to adjusting as you learn more.

To learn more, watch our webinar to learn about other best practices for implementing new technologies.  

As Karl Wiegers accurately states in his paper on writing better requirements, “quality is in the eye of the reader … No matter how fine the author thinks the requirements are, the ultimate arbiters are those who must base their own work on those requirements.”

Avoiding ambiguity when writing requirements is essential to building the product you want built. In our recent post, “Five Ways Ambiguous Language Will Ruin Your Requirements,” we shared examples of ambiguity in requirements writing and gave expert tips to help clarify.

Here are four more sources of ambiguity, plus additional best practices to save your requirements — and your product.

Negative Requirements

Negative or inverse requirements create a lot of unnecessary ambiguity. Positive requirements in active voice are much easier to understand. Here are some before and after examples of increased clarity when moving from negative to positive.

Negative Requirements Create Ambiguity

Abbreviations i.e. and e.g.

Some readers might misconstrue the use of i.e. and e.g. The abbreviation i.e. stands for the Latin phrase id est, which means “that is.” The abbreviation e.g. stands for the Latin phrase exempli gratia, which means “for example.”

These two abbreviations are so commonly confused — either on the part of the writer or the reader — that they are best avoided altogether in favor of explicitly saying what you mean.

A/B Construct

Some requirements writers use the A/B construct, as in, “data should be recorded in an audit/history table.” This construct is rarely used in formal writing because it is so vague it could be interpreted in a variety of ways. Some examples include:

  • A is the same as B. In this case, they are synonyms and you should stick to one term consistently.
  • Both A and B. In this case, use the explicit conjunction “and.”
  • A or B. In this case, use the explicit conjunction “or.”

Adverbs

Words that end in -ly often are ambiguous. They might describe some desirable property of the product, but exactly what is desired is left to each reader’s interpretation. Here are a few examples:

  • “Allows the user to edit his interests and possibly search results …” Should the user be able edit the search results or not?
  • “Optimize upload and download to perform quickly.” Is five seconds considered quick?
  • “Offer significantly better download times.” State exactly how much better or give a range for precisely what the download time should be.
  • “Subscribers who are changing content selection (effectively a subset of the currently subscribed subscribers) …” Are they a subset or not?
  • “Exposing information appropriately …” What’s considered appropriate?

Be specific when describing the intended product’s characteristics so all readers share a common vision of the desired result when they’re done.

Read Karl Wiegers’ paper, “Writing High-Quality Requirements,” to learn what else goes into crafting successful requirements.

When a requirement can be interpreted in more than one way, problems ensue. In his paper, “Writing High-Quality Requirements,” expert Karl Wiegers gives examples of ambiguity issues in requirements and best practices to successfully clarify them. Here are five sources of ambiguity and tips to overcome. 

Complex Logic

Boolean logic offers many opportunities for ambiguities and missing requirements. Try using a decision tree to reveal gaps and ensure clarity.
Use A Decision Tree To Remove Ambiguity From Complex Logic

Omissions

When requirements lack important pieces of information, it’s unlikely that all readers will interpret them in the same way unless they make precisely the same assumptions. Be sure to include trigger causes that lead to the behavior and indicate what is required to happen because of or after the behavior. Further, specify the action as well as the reverse operation as part of the requirement. For example:

“The system shall display the user’s defined bookmarks in a collapsible hierarchical tree structure.”

Changes to:

“The system shall display the user’s defined bookmarks in a collapsible and expandable hierarchical tree structure.”

Boundaries

Boundary values in numerical ranges are common sources of ambiguity, and they are a good place to look for missing requirements. One easy way to resolve boundary confusion is to show the information in a table. If you see a number represented in two ranges, you know something needs fixing. Conversely, if there is no value in one of the table’s cells, you can quickly identify the missing requirement.
Use Tables To Remove Ambiguity In Boundary Values

Synonyms

Using synonyms to describe the same thing across different requirements unnecessarily introduces ambiguity. Will the reader automatically know you mean the same thing or might they assume them to be different? If they are truly identical, use the same word consistently. If there are differences, even subtle ones, place such definitions in a shared glossary so team members understand the terms and use them consistently.

Pronouns

Pronouns can be a source of headaches in a requirements specification. Be certain that the antecedent is crystal clear whenever you employ a pronoun. If you use a word such as this or that, there should be no confusion in the reader’s mind about what you’re referring to.

Learn more requirements best practices from expert Karl Wiegers. In his paper, “Writing High-Quality Requirements,” he explains they begin with proper grammar, well-constructed sentences and a logical organization.

In today’s hyper-competitive marketplace, companies are releasing products faster than ever before. However, that increased emphasis on time to market doesn’t change the expectations: producing quality products while, when necessary, conforming to all relevant safety and quality standards.

Finding that critical balance between speed and quality is essential for product teams, which is where requirements management comes into play. Unfortunately, a lot of teams don’t take the time to flesh out requirement details – or they have the opposite problem and provide too many details, and confuse requirements with design specifications. Here are some examples and recommendations to make sure you’re getting the most value from your requirements.

Scenario 1: I need more details!

In this situation, teams fall into a trap of not taking the time to define requirements. For example, a marketing team — which tend to think more strategically — will often give high-level problem statements directly to an engineering team, which typically thrive on details.

What happens next is either:

    1. Engineering team builds a product that doesn’t solve the high-level problem

or

  1. Engineering team will bombard the marketing team with requests for additional information until both sides are frustrated and late on delivery

Neither scenario results in a smooth development process, and both can breed mistrust between teams whose ultimate goal is the same, in spite of their differing roles.

Well-formed and reviewed requirements clear the path for a quality product that meets market needs and expectations.

They ensure each team member is on the same page, and that everyone involved knows exactly what they’re building and why.

Scenario 2: Too many details – I can’t innovate!

In this case, the team members responsible for authoring requirements can sometimes cram too many design details into the requirements themselves. For example, I once saw a requirement that read: “the button shall be red and shall be located in the top-right corner of the console.”

First off, that’s actually two requirement statements – but either way – it’s describing implementation detail and, taken on it’s own, I have no idea of “what” the button should do or “why.” Is this supposed to dispense a soda from a vending machine or fire a missile from a battleship?!?

Requirements like these create friction within engineering teams, limiting their ability to innovate while getting bogged down with overly specific instructions.

Engineering teams should ideally be free to iterate and innovate the design rather than simply doing what they’re told. The requirements should focus on the need and keep teams aligned on “what” is needed and “why” while engineering experts figure out “how” to implement.

Recommendation: Establish a Common Taxonomy and Trace Model

An important step in striking the right level of detail in your requirements is establishing common terms in your product development process.

Many teams use different terms to refer to the same thing (e.g. “specification” – this term means so many different things across different teams).

Having a glossary or standard that clearly delineates important terms and deliverables facilitates clarity throughout the development process and reduces the confusion referenced above.

Using a traceability model establishes appropriate hierarchy and helps break down high-level problems to detailed requirement needs. It also can facilitate test coverage of requirements. This clarity is especially important when dealing with life-critical systems, such as medical devices or autonomous vehicle systems. In these cases, missing requirements or inadequate design and testing can quite literally cost  lives.

Finally, teams should be able to differentiate Requirements from Design. In other words, the “Need” vs the “How.” Bundling both together inside requirements can lead to added complexity, unnecessarily constrained design, and friction between teams.

Quickly bringing a quality, safe product to market is a challenge. Requirements and design are both key elements to doing so. Making sure teams strike the right level of detail in the requirements is critical in avoiding confusion and reducing friction in the process.

For a deeper dive on separating requirements and design specifications, check our this webinar, “Best Practices for Writing Requirements.” Jama also offers Requirements 101 workshops – please inquire if you’re interested in improving the requirements process in your organization!

QA2

The next time you feel like your professional life has gotten too complicated, get some face time with a seasoned Quality Assurance pro. The job? Easy stuff such as exposing the production flaws in embedded systems, integrated systems and connected devices.

What seems like a negative focus requires positive determination to straddle the line between the ideal and the real. Terminology that would terrify mere mortals such as “safety-critical,” “guaranteed compliance” and “life-and-economy critical” govern every QA action. Once the benchmark is set, QA is the muscle and willpower that keeps it in place.

And when your job is ensuring that only high-quality products make it to market, unwavering commitment to QA principles is required because your work is so demanding:

Tall tasks:

  • Trying to guarantee consistent product quality by developing, validating and enforcing reliable automated testing practices.

Pressure points:

  • Lacking visibility into changing requirements.
  • Lacking appropriate, comprehensive test coverage.
  • Struggling to capture and track all related defects.
  • Being the last to know when obstacles arise.

Burning desires:

  • To establish a clear workflow of requirements, be able to understand impacts when requirements change, and to ultimately ensure proper and meaningful test coverage.

With Jama, Quality Assurance Leads can turn wayward “Lost in Space” episodes into navigable “Star Trek” epics.

How so? You’re able to…

  • Speed up the test planning process.
  • Enable and ensure dependable test coverage for all requirements and defects.
  • Create and execute test cases using one platform.
  • Capture and track all related defects using one platform.
  • Easily integrate Jama with defect tracking and test automation tools you’re already using.
  • Communicate easily with the entire project team to get clarification on questions asked and decisions made, regardless of location.

Read Quality Products Deserve a Fighting Chance to see how Jama helps Quality Assurance teams make sure that only high-quality products make it to market.

Check out other ways Jama helps business and engineering teams get and stay aligned:

How Jama Helps VPs of Sales

How Jama Helps VPs of Product

How Jama Helps Systems Engineers

How Jama Helps Project Managers

How Jama Helps Business Analysts

How Jama Helps Product Managers

analyzing_risks-01

In the first part of this two-part series I described the value of managing risks formally on a software project and listed numerous common risks in various categories. This article describes the various activities associated with the practice of risk management and recommends specific information you should record about each risk you identify.

Risk Management Components

As with other project activities, begin risk management by developing a plan, perhaps using the risk management plan template available at www.ProjectInitiation.com. Small projects can include a concise risk management plan as a section within the overall project plan. Risk management consists of the activities illustrated in Figure 1 and described below.

Risk Assessment

Risk assessment is the process of examining a project to identify areas of potential risk. Risk identification can be facilitated with the help of a checklist of common risk areas for software projects, as I described in the first article in this series. Risk analysis examines how project outcomes might change with modification of risk input variables. In other words, just how could the risk harm your project.

Screen Shot 2014-04-02 at 10.25.39 AM

Figure 2: Risk exposure is a function of probability and potential loss.

Risk prioritization helps the project focus on its most severe risks by assessing the risk exposure. Exposure is the product of the probability of incurring a loss due to the risk and the potential magnitude of that loss. I usually estimate the probability from 0.1 (highly unlikely) to 1.0 (certain to happen), and the loss (also called impact) on a relative scale of 1 (no problem) to 10 (deep tapioca). Multiplying these factors together provides an estimate of the risk exposure due to each item, which can run from 0.1 (don’t give it another thought) through 10 (stand back, here it comes!). It’s simpler to estimate both probability and loss as High, Medium, or Low. Figure 2 shows how you can estimate the risk exposure level as High, Medium, or Low by combining the probability and loss estimates.

Risk Avoidance

Risk avoidance is one way to deal with a risk: don’t do the risky thing! You might avoid risks by not undertaking certain projects, or by relying on proven rather than cutting-edge technologies when possible. You might be able to transfer a risk to some other party, such as a subcontractor.

Risk Control

Risk control is the process of managing risks to achieve the desired outcomes. Risk management planning produces a plan for dealing with each significant risk, including mitigation approaches, owners, and timelines. Risk resolution entails executing the plans for dealing with each risk. That’s when you actually control the risk. Finally, risk monitoring involves tracking your progress toward resolving each risk item.

Let’s look at an example of risk management planning. Suppose the “project” is to take a hike through a swamp in a nature preserve. You’ve heard the swamp might contain quicksand, so the risk is that we might step in quicksand and be injured or even die. One strategy to mitigate this risk is to reduce the probability of the risk actually becoming a problem. A second option is to consider actions that could reduce the impact of the risk if it does in fact become a problem. So, to reduce the probability of stepping in the quicksand, we might look for signs of quicksand as we walk and draw a map so we can avoid these areas on future walks. To reduce the impact if someone does step in quicksand, the members of the tour group could rope themselves together. That way if someone does encounter some quicksand the others could quickly pull him to safety.

Even better, is there some way to prevent the risk from becoming a problem under any circumstances? Maybe we build a boardwalk as we go so we avoid the quicksand. That will slow us down and cost some money. But, we don’t have to worry about quicksand any more. The very best strategy is to eliminate the root cause of the risk entirely. Perhaps we should drain the swamp, but then it wouldn’t be a very interesting nature walk. By taking too aggressive a risk approach, you can eliminate the factors that make a project attractive in the first place.

Documenting Risks

Simply identifying the risks facing a project is not enough. We need to write them down in a way that lets us communicate the nature and status of risks throughout the affected stakeholder community over the duration of the project. Figure 3 shows a form I’ve found to be convenient for documenting risks. It’s a good idea to keep the risk list itself separate from the risk management plan, as you’ll be updating the risk list frequently throughout the project. You can download an alternative template for your risk list from www.ProjectInitiation.com. This format includes essentially the same information that’s in Figure 3, but it’s laid out in a way that’s amenable to storing in a spreadsheet or as a table in a word-processing document.

ID: <sequence number or a more meaningful label>
Description: <List each major risk facing the project. Describe each risk in the form “condition – consequence.”>
Probability: <What’s the likelihood of this risk becoming a problem?> Loss: <What’s the damage if the risk does become a problem?> Exposure: <Multiply Probability times Loss.>
First Indicator: <Describe the earliest indicator or trigger condition that might indicate that the risk is turning into a problem.>
Mitigation Approaches: <State one or more approaches to control, avoid, minimize, or otherwise mitigate the risk.>
Owner: <Assign each risk mitigation action to an individual for resolution.> Date Due: <State a date by which the mitigation approach is to be implemented.>

Figure 3: A risk documentation form.

Use a condition–consequence format when documenting risk statements. That is, state the risk situation (the condition) that you are concerned about, followed by at least one potential adverse outcome (the consequence) if that risk should turn into a problem. Often, people suggesting risks state only the condition—“The customers don’t agree on the product requirements”—or the consequence—“We can only satisfy one of our major customers.” Pull those together into the condition-consequence structure: “The customers don’t agree on the product requirements, so we’ll only be able to satisfy one of our major customers.” This statement doesn’t describe a certain future, just a possible outcome that could harm the project if the condition isn’t addressed.

Keep the items with high risk exposures at the top of your priority list to focus your risk-control energy. Set goals for determining when each risk item has been satisfactorily controlled. Your mitigation approaches for some items may focus on reducing the probability, whereas the approach for other risks could emphasize reducing the potential loss or impact. With any luck, some of your mitigation strategies will help you control multiple risk factors.

Risk Tracking

As with other project management activities, you need to get into a rhythm of periodic monitoring. You may wish to appoint a risk manager for the project. The risk manager is responsible for staying on top of the things that could go wrong, just as the project manager stays on top of the activities leading to project completion. It’s a good idea to have someone other than the project manager serve as the risk manager. The project manager is focused on what he has to do to make a project succeed. The risk manager, in contrast, is identifying factors that might prevent the project from succeeding. In other words, the risk manager is looking for the black cloud around the silver lining that the project manager sees. Asking the same person to take these two opposing views of the project can lead to cognitive dissonance; in an extreme case, his brain can explode.

Keep the top ten risks highly visible and track the effectiveness of your mitigation approaches regularly. New risks might float up into the top ten as you gradually beat the initial list of top priority items into submission. You can drop a risk off your radar when your mitigation approaches have reduced the risk exposure from that item to an acceptable level. Don’t conclude that a risk is controlled simply because the selected mitigation action has been completed. Controlling a risk might require you to change the risk control strategy if you conclude it isn’t working.

A student in a seminar once asked, “What should you do if you have the same top five risks week after week?” A static risk list suggests that your risk mitigation actions aren’t working. Effective mitigation actions should lower the risk exposure as the probability, the loss, or both decrease over time. If your risk list isn’t changing, check to see whether the planned mitigation actions have been carried out and whether they had the desired effect.

Also, look for new risks that might arise during the course of the project. Conditions can change, assumptions can prove to be wrong, and other factors might lead to risks that weren’t apparent or perhaps did not even exist at the beginning of the project. Escalate risks that aren’t being controlled to the attention of senior managers or other stakeholders. They can then either stimulate corrective actions or else make a conscious business decision to proceed in spite of the risks.

Learning from the Past

We can’t predict exactly which of the many threats to our projects might come to pass. However, most of us can do a better job of learning from previous experiences to avoid the same pain and suffering on future projects. As you begin to implement risk management approaches, record your actions and results for future reference. The risks are out there. Find them before they find you.

Also read Knowing Your Enemy: An Introduction to Risk Management, Part 1

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

 

estimating-balance-01

In part one and part two of this series, adapted from my book Practical Project Initiation, I’ve described fifteen practices the project manager can apply to lay the foundation for a successful project, plan the project, and estimate the work to be done. In this final article I share two additional estimation practices, three good practices for tracking your progress throughout the project, and one practice for learning how to execute your future projects more successfully.

Estimating the Work (continued)

Practice #16: Use estimation tools. Many commercial tools are available to help project managers estimate entire projects. Based on equations derived from large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. They’ll also help you avoid the “impossible region,” combinations of product size, effort, and schedule where no known project has been successful. The tools incorporate a number of “cost drivers” you can adjust to make the tool more accurately model your project, based on the technologies used, the team’s experience, and other factors. You can compare the estimates from the tools with the bottom-up estimates generated from a work breakdown structure. Reconcile any major disconnects so you can generate the most realistic overall estimate.

Practice #17: Plan contingency buffers. Projects never go precisely as planned. The prudent project manager incorporates budget and schedule contingency buffers at the end of phases, dependent task sequences, or iterations to accommodate the unforeseen. Use your project risk analysis to estimate the possible schedule impact if several of the risks materialize, then build that projected risk exposure into your schedule as a contingency buffer. An even more sophisticated approach is critical chain analysis, a technique that pools the uncertainties in estimates and risks into a rational overall contingency buffer. Chapter 10 of Practical Project Initiation is all about contingency buffers.

Your manager or customer might view these contingency buffers as padding, rather than as the sensible acknowledgment of reality that they are. To help persuade skeptics, point to unpleasant surprises on previous projects as a rationale for your foresight. If a manager elects to discard contingency buffers, he has tacitly absorbed all the risks that fed into the buffer and assumed that all estimates are perfect, no scope growth will occur, and no unexpected events will take place. Sound realistic to you? Of course not. I’d rather see us deal with reality—however unattractive—than to live in Fantasyland.

Tracking Your Progress

Practice #18: Record actuals and estimates. Unless you record the actual effort or time spent on each project task and compare them to the estimates, your estimates will forever remain guesses. Someone once asked me where to get historical data to improve her ability to estimate future work. My answer was, “If you write down what actually happened today, that becomes historical data tomorrow.” It’s really not more complicated than that. Each individual can begin recording estimates and actuals, and the project manager should track these important data items on a project task or milestone basis. In addition to effort and schedule, you could estimate and track the size of the product, in terms of requirements, user stories, lines of code, function points, GUI screens, or other units that make sense for your project.

Practice #19: Count tasks as complete only when they’re one hundred percent complete. We give ourselves a lot of partial credit for tasks we’ve begun but not yet fully completed: “I thought about the algorithm for that module in the shower this morning, and the algorithm is the hard part, so I’m probably about sixty percent done.” It’s difficult to accurately assess what fraction of a sizable task has actually been finished at a given moment.

One benefit of using inch-pebbles (see Practice #6 in Part 2 of this series) for task planning is that you can break a large activity into a number of small tasks (inch-pebbles) and classify each small task as either done or not done—nothing in between. Project status tracking is then based on the fraction of the tasks that are completed and their size, not the percentage completion of each task. If someone asks you whether a specific task is complete and your reply is, “It’s all done except…,” then it’s not done! Don’t let people “round up” their task completion status. Instead, use explicit criteria to determine whether an activity truly is completed.

Practice #20: Track project status openly and honestly. An old riddle asks, “How does a software project become six months late?” The rueful answer is, “One day at a time.” The painful problems arise when the project manager doesn’t know just how far behind (or, occasionally, ahead) of plan the project really is. Surprise, surprise, surprise.

If you’re the PM, create a climate in which team members feel it is safe for them to report project status accurately. Run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that can arise from the fear of reporting bad news. Use project status information and metrics data to take corrective actions when necessary and to celebrate when you can. You can only manage a project effectively when you really know what’s done and what isn’t, what tasks are falling behind their estimates and why, and what problems, issues, and risks remain to be tackled.

The five major areas of software measurement are size, effort, time, quality, and status. It’s a good idea to define a few metrics in each of these categories. Instilling a measurement culture into an organization is not trivial. Some people resent having to collect data about the work they do, often because they’re afraid of how managers might use the measurements. The cardinal rule of software metrics is that management must never use the data collected to either reward or punish the individuals who did the work. The first time you do this will be the last time you can count on getting accurate data from the team members.

Learning for the Future

Practice #21: Conduct project retrospectives. Retrospectives (also called postmortems and post-project reviews) provide an opportunity for the team to reflect on how the last project, phase, or iteration went and to capture lessons learned that will help enhance your future performance. During such a review, identify the things that went well, so you can create an environment that enables you to repeat those success contributors. Also look for things that didn’t go so well, so you can change your approaches and prevent those problems in the future. In addition, think of events that surprised you. These might be risk factors to look for on the next project. Finally, ask yourself what you still don’t understand about the project, so you can try to learn how to execute future work better.

It’s important to conduct retrospectives in a constructive and honest atmosphere. Don’t make them an opportunity to assign blame for previous problems. Chapter 15 of Practical Project Initiation describes the project retrospective process and provides a worksheet to help you plan your next retrospective. It’s a good idea to capture the lessons learned from each retrospective exploration and share them with the entire team and organization. This is a way to help all team members, present and future, benefit from your experience.

The twenty-one project management best practices I’ve described in this series of articles won’t guarantee your project a great outcome. They will, however, help you get a solid handle on your project and ensure that you’re doing all you can to make it succeed in an unpredictable world.

Also read Project Management Best Practices, Part 1
Also read Project Management Best Practices, Part 2

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

project-management-2-01

In Part 1 of this series, adapted from my book Practical Project Initiation, I shared four best practices that can help you lay the foundation for a successful project and two practices that are useful for project planning. This article continues the series by describing additional project planning best practices and several practices for estimating the work needed to complete the project.

Planning the Project 

Practice #7: Develop planning worksheets for common large tasks. If your team frequently undertakes certain common tasks—such as implementing a new class, executing a system test cycle, or performing a product build—develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he must tackle. People work in different ways and no single person will think of all the necessary tasks, so engage multiple team members in developing the worksheets. Tailor the worksheets to meet the specific needs of individual projects. I’ve used such worksheets when creating eLearning versions of my training courses. They helped me avoid overlooking an important step in my rush to finish the project.

Practice #8: Plan to do rework after a quality control activity. I’ve seen project plans that assumed every test will be a success that lets you move on to the next development activity. However, almost all quality control activities, such as testing and peer reviews, find defects or other improvement opportunities. Your project schedule should include rework as a discrete task after every quality control task. Base your estimates of rework time on previous experience. If you collect a bit of data, you can calculate the average expected rework effort to correct defects found in various types of work products. And if you don’t have to do any rework after performing a test, great; you’re ahead of schedule on that task. This is permitted in all fifty states and in many other countries. Don’t count on it, though.

Practice #9: Manage project risks. If you don’t identify and control project risks, they’ll control you. A risk is a potential problem that could affect the success of your project. It’s a problem that hasn’t happened yet—and you’d like to keep it that way. Simply identifying the possible risk factors isn’t enough. You also have to evaluate the relative threat each one poses so you can focus your energy where it will do the most good.

Risk exposure is a combination of the probability that a specific risk could materialize into a problem and the negative consequences for the project if it does. To manage each risk, select mitigation actions to reduce either the probability or the impact. You might also identify contingency plans that will kick in if your risk control activities aren’t as effective as you hope.

A simple risk list doesn’t replace a plan for how you will identify, prioritize, control, and track risks. Incorporate risk tracking into your routine project status tracking. See Chapter 6 of Practical Project Initiation for an overview of software risk management.

Practice #10: Plan time for process improvement. Your team members are already swamped with their current project assignments. If you want the group to rise to a higher plane of software development capability, though, you’ll have to invest in process improvement. This means you’ll need to set aside some time from your project schedule for improvement activities. Don’t allocate one hundred percent of your team’s available time to project tasks and then wonder why they don’t make any progress on the improvement initiative.

Some process changes can begin to pay off immediately, but you won’t reap the full benefit from other improvements until the next project. Process improvement is a strategic investment in the organization. I liken process improvement to highway construction: It slows everyone down a little bit for a time, but after the work is done, the road is a lot smoother and the throughput is greater.

Practice #11: Respect the learning curve. The time and money you spend on training, self-study, consultants, and developing improved processes are part of the investment your organization makes in sustained project success. Recognize that you’ll pay a price in terms of a short-term productivity loss—the learning curve—when you first try to apply new processes, tools, or technologies. Don’t expect to get fabulous benefits on the first try, no matter what the tool vendor or the consultant claims. Make sure your managers and customers understand the learning curve as an inescapable consequence of working in a rapidly changing, high-technology field.

Estimating the Work

Practice #12: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time. I prefer to estimate the effort (in labor-hours) associated with a task, and then translate the effort into a calendar-time estimate. A twenty-hour task might take 2.5 calendar days of nominal full-time effort, or two exhausting days. However, it could also take a week if you have to wait for critical information from a customer or stay home with a sick child for two days. I base the translation of effort into calendar time on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.

If you track how you actually spend your time at work, you’ll know how many effective weekly project hours you have available on average. Tracking time like this is illuminating. Typically, the effective project time is only perhaps fifty to sixty percent of the nominal time team members spend at work, far less than the assumed one hundred percent effective time on which so many project schedules are planned.

Practice #13: Don’t over-schedule multitasking people. The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Excessive multitasking introduces communication and thought process inefficiencies that reduce individual productivity. I once heard a manager say that someone on his team had spent an average of eight hours per week on a particular activity, so therefore she could do five of them at once. Forty hours per week divided by eight is five, right? In reality, she’ll be lucky if she can handle three or four such tasks. There’s just too much friction associated with multitasking.

Some people multitask more efficiently than others, even thriving on it. But if certain of your team members thrash when working on too many tasks at once, set clear priorities and help them do well by focusing on just one or two objectives at a time.

Practice #14: Build training time into the schedule. Estimate how much time your team members spend on training activities each year and subtract that from the time available for them to work on project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way.

Recognize that the high-tech field of software development demands that all practitioners devote time to ongoing education, both on their own time and on the company’s time. Arrange just-in-time training when you can schedule it, as the half-life of new technical knowledge is short unless the student puts the knowledge to use promptly. Attending a training seminar can be a team-building experience, as project team members and other stakeholders hear the same story about how to apply improved practices to their common challenges.

Practice #15: Record estimates and how you derived them. When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary. It will also help you improve your estimation process. Train the team in estimation methods, rather than assuming that every software developer and project leader is naturally skilled at predicting the future. Develop estimation procedures and checklists that people throughout your organization can use.

The Wideband Delphi method is an effective group estimation technique. This technique asks a small team of experts to anonymously generate individual estimates from a problem description and reach consensus on a final set of estimates through iteration. Participation by multiple estimators and the use of anonymous estimates to prevent one participant from biasing another make the Wideband Delphi method more reliable than simply asking a single individual for his best guess. Chapter 11 of Practical Project Initiation presents a tutorial on the Wideband Delphi estimation method.

The final article in this series will describe two additional estimation tips, along with several good practices for tracking your progress and learning how to plan and manage future projects more effectively.

Also read Project Management Best Practices, Part 1
Also read Project Management Best Practices, Part 3

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.