Tag Archive for: business requirements

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.

[raw]

To read the updated version of this article, visit www.jamasoftware.com/blog/defining-project-scope-context-use-case-diagrams/.

[/raw]
Every software team talks about project scope and team members often complain about unending scope creep. Unfortunately, the software industry lacks uniform definitions of these terms, and the requirements literature is short on clear guidance regarding how to even represent scope. I confront scope head-on in this series of three articles, adapted from my book More about Software Requirements (Microsoft Press, 2006). I’ll present some definitions, describe four techniques for defining project scope, and offer some tips for managing scope creep.

Vision and Scope

defining project and use case diagrams-1

I regard the vision and scope document is a key software project deliverable. You can find a suggested template for this document at http://www.processimpact.com/goodies.shtml. Other terms for this type of guiding document are a project charter, market (or marketing) requirements document, and business case. 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 software requirements specification.

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. Chapter 5 of my book Software Requirements, 2nd Edition describes how to write a concise vision statement using a simple keyword template.

I’ll define project scope as: “The portion of the ultimate product vision that the current project or iteration will address. The scope draws the boundary between what’s in and what’s out for the project.” The second part of the project scope definition is most important. The scope identifies what the product is and is not, what it will and won’t do, what it will and won’t contain.

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. In essence, 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.

The rest of this article describes two techniques I’ve found useful for depicting project scope, the context diagram and the use case diagram. In part 2 of the series, I’ll describe two additional techniques, feature levels and system events.

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. The business analyst can decompose these data flows into individual data elements in the project’s data dictionary or data model. Corresponding data inputs and outputs imply the types of operations the system will perform, but these aren’t shown explicitly in the context diagram.

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. A BA in a requirements class I once taught showed me a context diagram for her current project. She had shown this diagram to the project manager. The manager had pointed out that one of the external entities shown on the context diagram, another information system, was now going to be part of the new system. With respect to Figure 1, this would be like moving the Payroll System inside the project circle. That is, the scope of the project just got larger than the BA expected. She had expected that external system to be someone else’s responsibility, but now it was her problem.

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. Some analysts simply draw lines instead of arrows on the use case diagram to avoid any confusion with data flow. In addition to showing these connections to external actors, a use case diagram could depict logical relationships and dependencies between use cases.

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 sizeable 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


Learn how product development teams can leverage analytics to improve efficiency and quality in “The Essential Guide to Software Development Team Metrics.”

change-impact-analysis-01[1]

The need for performing impact analysis is obvious for major enhancements. However, unexpected complications can work below the surface of even minor change requests. A consulting client of mine once had to change the text of a single error message in its product. What could be simpler? The product was available in both English and German language versions. There were no problems in English, but in German the new message exceeded the maximum character length allocated for error message displays in both the message box and a database. Coping with this apparently simple change request turned out to be much more work than the developer had anticipated when he promised a quick turnaround.

Impact analysis is a key aspect of responsible requirements management. It provides accurate understanding of the implications of a proposed change, which helps the team make informed business decisions about which proposals to approve. The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change. Skipping impact analysis doesn’t change the size of the task. It just turns the size into a surprise. Software surprises are rarely good news. Before a developer says, “Sure, no problem” in response to a change request, he or she should spend a little time on impact analysis. This article, adapted from my book Software Requirements, 2nd Edition (Microsoft Press, 2003), describes how the impact analysis activities might work.

Impact Analysis Procedure

The chairperson of the change control board will typically ask a knowledgeable developer to perform the impact analysis for a specific change proposal. Impact analysis has three aspects:

  1. Understand the possible implications of making the change. Change often produces a large ripple effect. Stuffing too much functionality into a product can reduce its performance to unacceptable levels, as when a system that runs daily requires more than 24 hours to complete a single execution.
  2. Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
  3. Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.

Figure 1 presents a checklist of questions designed to help the impact analyst understand the implications of accepting a proposed change. (You can download the checklists and templates described in this article from http://www.processimpact.com/goodies.shtml.) The checklist in Figure 2 contains prompting questions to help identify all of the software elements that the change might affect. Traceability data that links the affected requirement to other downstream deliverables helps greatly with impact analysis. As you gain experience using these checklists, modify them to suit your own projects.

Checklist of possible implications of a proposed change.

Checklist of possible implications of a proposed change.

Checklist of possible software elements affected by a proposed change.

Checklist of possible software elements affected by a proposed change.

Following is a simple procedure for evaluating the impact of a proposed requirement change. Many estimation problems arise because the estimator doesn’t think of all the work required to complete an activity. Therefore, this impact analysis approach emphasizes comprehensive task identification. For substantial changes, use a small team—not just one developer—to do the analysis and effort estimation to avoid overlooking important tasks.

  1. Work through the checklist in Figure 1.
  2. Work through the checklist in Figure 2, using available traceability information. Some requirements management tools include an impact analysis report that follows traceability links and finds the system elements that depend on the requirements affected by a change proposal.
  3. Use the worksheet in Figure 3 to estimate the effort required for the anticipated tasks. Most change requests will require only a portion of the tasks on the worksheet, but some could involve additional tasks.
  4. Total the effort estimates.
  5. Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.
  6. Determine whether the change is on the project’s critical path. If a task on the critical path slips, the project’s completion date will slip. Every change consumes resources, but if you can plan a change to avoid affecting tasks that are currently on the critical path, the change won’t cause the entire project to slip.
  7. Estimate the impact of the proposed change on the project’s schedule and cost.
  8. Evaluate the change’s priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.
  9. Report the impact analysis results to the CCB so that they can use the information to help them decide whether to approve or reject the change request.

In most cases, this procedure shouldn’t take more than a couple of hours to complete. This may seem like a lot of time to a busy developer, but it’s a small investment in making sure the project wisely invests its limited resources. If you can adequately assess the impact of a change without such a systematic evaluation, go right ahead; just make sure you aren’t stepping into quicksand. To improve your ability to estimate the impacts of future changes, compare the actual effort needed to implement each change with the estimated effort. Understand the reasons for any differences, and modify the impact estimation checklists and worksheet accordingly.

Estimating effort for a requirement change.

Estimating effort for a requirement change.

Money Down the Drain

Here’s a true story about what can happen if you don’t take the time to perform impact analysis before diving into implementing a significant change request. Two developers at the A. Datum Corporation estimated that it would take four weeks to add an enhancement to one of their information systems. The customer approved the estimate, and the developers set to work. After two months, the enhancement was only about half done and the customer lost patience: “If I’d known how long this was really going to take and how much it was going to cost, I wouldn’t have approved it. Let’s forget the whole thing.” In the rush to gain approval and begin implementation, the developers didn’t do enough impact analysis to develop a reliable estimate that would let the customer make an appropriate business decision. Consequently, the A. Datum Corporation wasted several hundred hours of work that could have been avoided by spending a few hours on an up-front impact analysis.

Impact Analysis Report Template

Figure 4 suggests a template for reporting the results from analyzing the potential impact of each requirement change. Using a standard template makes it easier for the CCB members to find the information they need to make good decisions. The people who will implement the change will need the analysis details and the effort planning worksheet, but the CCB needs only the summary of analysis results. As with all templates, try it and then adjust it to meet your project needs.

Impact analysis report template

Impact analysis report template

Requirements change is a reality for all software projects, but disciplined change-management practices can reduce the disruption that changes can cause. Improved requirements elicitation techniques can reduce the number of requirements changes, and effective requirements management will improve your ability to deliver on project commitments.

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.

measuring-requirements-1-illustration-01-01

Disciplined software organizations collect a focused set of metrics about each of their projects. These metrics provide insight into the size of the product; the effort, time, and money that the project or individual tasks consumed; the project status; and the product’s quality. Because requirements are an essential project component, you should measure several aspects of your requirements engineering activities. This two-part series, adapted from my book More about Software Requirements, describes several meaningful metrics related to requirements activities on your projects. Enjoy these free requirements management resources.

Product Size

The most fundamental metric is the number of requirements in a body of work. Your project might represent requirements by using a mix of use cases, functional requirements, user stories, feature descriptions, event-response tables, and analysis models. However, the team ultimately implements functional requirements, descriptions of how the system should behave under specific conditions.

Begin your requirements measurement by simply counting the individual functional requirements that are allocated to the baseline for a given product release or development iteration. If different team members can’t count the requirements and get the same answer, you have to wonder what other sorts of ambiguities and misunderstandings they’ll experience. Knowing how many requirements are going into a release will help you judge how the team is progressing toward completion because you can monitor the backlog of work remaining to be done. If you don’t know how many requirements you need to work on, how will you know when you’re done?

Of course, not all functional requirements will consume the same implementation and testing effort. If you’re going to count functional requirements as an indicator of system size, your analysts will need to write them at a consistent level of granularity. One guideline is to decompose high-level requirements until the child requirements are all individually testable. That is, a tester can design a few logically related tests to verify whether a requirement was correctly implemented. Count the total number of child requirements, because those are what developers will implement and testers will test. Alternative requirements sizing techniques include use case points and story points. All of these methods involve estimating the relative effort to implement a defined chunk of functionality.

Functional requirements aren’t the whole story, of course. Stringent nonfunctional requirements can consume considerable design and implementation effort. Some functionality is derived from specified nonfunctional requirements, such as security requirements, so those would be incorporated appropriately into the functional requirement size estimate. But not all nonfunctional requirements will be reflected in this size estimate. Be sure to consider the impact of nonfunctional requirements upon your effort estimate. Consider the following situations:

  • If the user must have multiple ways to access specific functions to improve usability, it will take more development effort than if only one access mechanism is needed.
  • Imposed design and implementation constraints, such as multiple external interfaces to achieve compatibility with an existing operating environment, can lead to a lot of interface work even though you aren’t providing additional new product functionality.
  • Strict performance requirements might demand extensive algorithm and database design work to optimize response times.
  • Rigorous availability and reliability requirements can imply significant work to build in failover and data recovery mechanisms, as well as having implications for the system architecture you select.

You’ll also find it informative to track the growth in requirements as a function of time, no matter what requirements size metric you use. One of my clients found that their projects typically grew in size by about twenty-five percent before delivery. Amazingly, they also ran about twenty-five percent over the planned schedule on most of their projects. Coincidence? I think not.

Requirements Quality

Consider collecting some data regarding the quality of your requirements. Inspections of requirements specifications are a good source of this information. Count the requirements defects you discover and classify them into various categories: missing requirements, erroneous requirements, unnecessary requirements, incompleteness, ambiguities, and so forth. Use defect type frequencies and root-cause analysis to tune up your requirements processes so the team makes fewer of these types of errors in the future. For instance, if you find that missing requirements are a common problem, your elicitation approaches need some adjustments. Perhaps your business analysts aren’t asking enough questions or the right questions, or maybe you need to engage more appropriate user representatives in the requirements development process.

If the team members don’t think they have time to inspect all their requirements documentation, try inspecting a sample of just a few pages. Then calculate the average defect density—the number of defects found per specification page—for the sample. Assuming that the sample was representative of the entire document (a big assumption), you can multiply the number of uninspected pages by this defect density to estimate the number of undiscovered defects that could still lurk in the specification. Less experienced inspectors might discover only, say, half the defects that actually are present, so use this estimated number of undiscovered defects as a lower bound. Inspection sampling can let you assess the document’s quality so that you can determine whether it’s cost effective to inspect the rest of the requirements specification. The answer will almost certainly be yes.

Also, keep records of requirements defects that are identified after the requirements are baselined, such as requirements-related problems discovered during design, coding, and testing. These represent errors that leaked through your quality control filters during requirements development. Calculate the percentage of the total number of requirements errors that the team caught at the requirements stage. Removing requirements defects early is far cheaper than correcting them after the team has already designed, coded, and tested the wrong requirements.

Two informative metrics to calculate from inspection data are efficiency and effectiveness. Efficiency refers to the average number of defects discovered per labor hour of inspection effort. Effectiveness refers to the percentage of the defects originally present in a work product that was discovered by inspection. Effectiveness will tell you how well your inspections (or other requirements quality techniques) are working. Efficiency will tell you what it costs you, on average, to discover a defect through inspection. You can compare that cost with the cost of dealing with requirements defects found later in the project or after delivery to judge whether improving the quality of your requirements is cost effective.

The second article in this series will address metrics related to requirements status, change requests, and the effort expended on requirements development and management activities.

Also read Measuring Requirements: Status and Requests for Changes.

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.

Note: The following is an excerpt from our Forrester Consulting commissioned report, The State of Modern Product Delivery. Read the full report for key insights on the current trends and challenges in product delivery.

Diversity of opinion is good, except when it gets in the way. Differing priorities compound the difficulties of product development when they lead to conflicting signals. Product development teams often find themselves caught in the middle, negotiating uneasy compromises between parties that see the customer problem differently. As with most forms of counseling, getting the issues on the table and clearly communicating goals goes a long way toward resolving conflicts.

forrester-the-state-of-modern-product-delivery_forrester-thought-leadership-paper-11

  • The customer often lacks a consistent voice. Different functional groups will see the customer problem in different ways. None is completely correct, yet often each group sees its issues as the most important. The reality is that no product is complete until all perspectives are fairly represented. Getting the issues on the table to make the choices clear helps defuse the conflict and create healthy discussion.
  • Executive leadership may need to arbitrate. One of the benefits of active executive participation in product development is that misalignments, once spotted, can be quickly resolved. Differing priorities are often the result of organizational misalignments that are beyond the scope of the typical product team. Engaging executives, on the right level and the right time, can resolve the conflict before it affects product delivery.
  • Confused priorities lead to confusing products. Customers become frustrated with inconsistent solutions. When services or support offerings don’t align with the product they have purchased, dissatisfaction sets in. Ensuring a consistent customer experience goes far beyond the product itself.

Read the full Forrester Consulting report on The State of Modern Product Delivery complete with key recommendations. 

This article continues the exploration of requirements-related metrics that I began in Part 1, which looked at measuring product size and requirements quality.

Requirements Status

Track the status of each requirement over time to monitor overall project status, perhaps defining a requirement attribute to store this information. Status tracking can help you avoid the pervasive “ninety percent done” problem of software project tracking. Each requirement will have one of the following statuses at any time.

  • Proposed (someone suggested it)
  • Approved (it was allocated to a baseline)
  • Implemented (the code was designed, written, and unit tested)
  • Verified (the requirement passed its tests after integration into the product)
  • Deferred (the requirement will be implemented in a future release)
  • Deleted (you decided not to implement it at all)
  • Rejected (the idea was never approved)

Other status options are possible, of course. Some organizations use a status of “Reviewed” because they want to confirm that a requirement is of high quality before allocating it to a baseline. Other organizations use “Delivered to Customer” to indicate that a requirement has actually been released.

When you ask a developer how he is coming along, he might say, “Of the eighty-seven requirements allocated to this subsystem, sixty-one of them are verified, nine are implemented but not yet verified, and seventeen aren’t yet completely implemented.” There’s a good chance that not all these requirements are the same size, will consume the same amount of implementation effort, or will deliver the same customer value. If I were a project manager, though, I’d feel that we had a good handle on the size of that subsystem and how close we were to completion. This is far more informative than, “I’m about ninety percent done. Lookin’ good!”

Requests for Changes

Much of requirements management involves handling requirement additions, modifications, and deletions. Therefore, track the status and impact of your requirements change requests. The data you collect should let your team answer questions such as the following:

  • How many change requests were submitted in a given time period?
  • How many of these requests are open, and how many are closed?
  • How many requests were approved, and how many were rejected?
  • How much effort did the team spend implementing each approved change?
  • How long have the requests been open on average?
  • On average, how many individual requirements or other artifacts are affected by each submitted change request?

Monitor how many changes are incorporated throughout development after you baselined the requirements for a specific release. Note that a single change request potentially can affect multiple requirements of different levels and types (user requirements, functional requirements, nonfunctional requirements). To calculate requirements volatility over a given time period, divide the number of changes by the total number of requirements at the beginning of the period (for example, at the time a baseline was defined):

The intent is not to try to eliminate requirements volatility. There are often good reasons to change requirements. However, we need to ensure that the project can manage the degree of requirements changes and still meet its commitments. Changes become more expensive as the product nears completion, and a sustained high level of approved change requests makes it difficult to know when you can ship the product. Most projects should become more resistant to making changes as development progresses, meaning the trend of accepted changes should approach zero as you near the planned completion date for a given release. An iterative development approach gives the team multiple opportunities to incorporate changes into subsequent iterations, while still keeping each iteration on schedule.

If you receive many change requests, that suggests that elicitation overlooked many requirements or that new ideas keep coming in as the project drags along month after month. Record where the change requests come from: marketing, users, sales, management, developers, and so on. The change request origins will tell you who to work with to reduce the number of overlooked, modified, and misunderstood requirements.

Change requests that remain unresolved for a long time suggest that your change management process isn’t working well. I once visited a company where a manager wryly admitted that they had enhancement requests that were several years old and still pending. This team should allocate certain of their open requests to specific planned maintenance releases and convert other long-term deferred change requests to a status of rejected. This would help the project manager focus the team’s energy on the most important and most urgent items in the change backlog.

Effort

Finally, I recommend that you  record the time your team spends on requirements engineering activities. These activities include both requirements development (getting and writing good requirements) and requirements management (dealing with change, tracking status, recording traceability data, and so on).

I’m frequently asked how much time and effort a project should allocate to these functions. The answer depends enormously on the type and size of project, the developing team and organization, and the application domain. If you track your own team’s investment in these critical project activities, you can better estimate how much effort to plan for future projects.

Suppose that on one previous project, your team expended ten percent of its effort on requirements activities. In retrospect, you conclude that the requirements were too poorly defined and the project would have benefited from additional investment in developing quality requirements. The next time your team tackles a similar project, the project manager would be wise to allocate more than ten percent of the total project effort to the requirements work.

As you accumulate data, correlate the project development effort with some measure of product size. The documented requirements should give you an indication of size. You could correlate effort with the count of individually testable requirements, use case points, function points, or something else that is proportional to product size. As Figure 1 illustrates, such correlations provide a measure of your development team’s productivity, which will help you estimate and scope individual release contents. If you collect some product size data and track the corresponding implementation effort, you’ll be in a better position to create meaningful estimates for similar projects in the future.

Figure 1. Correlating requirements size with project effort gives a measure of team productivity. Each point represents a separate project.

Some people are afraid that launching a software measurement effort will consume too much time, time they feel should be spent doing “real work.” My experience, though, is that a sensible and focused metrics program doesn’t take much time or effort at all. It’s mostly a matter of developing a simple infrastructure for collecting and analyzing the data, and getting team members in the habit of recording some key bits of data about their work. Once you’ve developed a measurement culture in your organization, you’ll be surprised how much you can learn from the data.

Also read Measuring Requirements, 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.

 

Disciplined software organizations collect a focused set of metrics about each of their projects. These metrics provide insight into the size of the product; the effort, time, and money that the project or individual tasks consumed; the project status; and the product’s quality. Because requirements are an essential project component, you should measure several aspects of your requirements engineering activities. This two-part series, adapted from my book More about Software Requirements, describes several meaningful metrics related to requirements activities on your projects.

Product Size

The most fundamental metric is the number of requirements in a body of work. Your project might represent requirements by using a mix of use cases, functional requirements, user stories, feature descriptions, event-response tables, and analysis models. However, the team ultimately implements functional requirements, descriptions of how the system should behave under specific conditions.

Begin your requirements measurement by simply counting the individual functional requirements that are allocated to the baseline for a given product release or development iteration. If different team members can’t count the requirements and get the same answer, you have to wonder what other sorts of ambiguities and misunderstandings they’ll experience. Knowing how many requirements are going into a release will help you judge how the team is progressing toward completion because you can monitor the backlog of work remaining to be done. If you don’t know how many requirements you need to work on, how will you know when you’re done?

Of course, not all functional requirements will consume the same implementation and testing effort. If you’re going to count functional requirements as an indicator of system size, your analysts will need to write them at a consistent level of granularity. One guideline is to decompose high-level requirements until the child requirements are all individually testable. That is, a tester can design a few logically related tests to verify whether a requirement was correctly implemented. Count the total number of child requirements, because those are what developers will implement and testers will test. Alternative requirements sizing techniques include use case points and story points. All of these methods involve estimating the relative effort to implement a defined chunk of functionality.

Functional requirements aren’t the whole story, of course. Stringent nonfunctional requirements can consume considerable design and implementation effort. Some functionality is derived from specified nonfunctional requirements, such as security requirements, so those would be incorporated appropriately into the functional requirement size estimate. But not all nonfunctional requirements will be reflected in this size estimate. Be sure to consider the impact of nonfunctional requirements upon your effort estimate. Consider the following situations:

  • If the user must have multiple ways to access specific functions to improve usability, it will take more development effort than if only one access mechanism is needed.
  • Imposed design and implementation constraints, such as multiple external interfaces to achieve compatibility with an existing operating environment, can lead to a lot of interface work even though you aren’t providing additional new product functionality.
  • Strict performance requirements might demand extensive algorithm and database design work to optimize response times.
  • Rigorous availability and reliability requirements can imply significant work to build in failover and data recovery mechanisms, as well as having implications for the system architecture you select.

You’ll also find it informative to track the growth in requirements as a function of time, no matter what requirements size metric you use. One of my clients found that their projects typically grew in size by about twenty-five percent before delivery. Amazingly, they also ran about twenty-five percent over the planned schedule on most of their projects. Coincidence? I think not.

Requirements Quality

Consider collecting some data regarding the quality of your requirements. Inspections of requirements specifications are a good source of this information. Count the requirements defects you discover and classify them into various categories: missing requirements, erroneous requirements, unnecessary requirements, incompleteness, ambiguities, and so forth. Use defect type frequencies and root-cause analysis to tune up your requirements processes so the team makes fewer of these types of errors in the future. For instance, if you find that missing requirements are a common problem, your elicitation approaches need some adjustments. Perhaps your business analysts aren’t asking enough questions or the right questions, or maybe you need to engage more appropriate user representatives in the requirements development process.

If the team members don’t think they have time to inspect all their requirements documentation, try inspecting a sample of just a few pages. Then calculate the average defect density—the number of defects found per specification page—for the sample. Assuming that the sample was representative of the entire document (a big assumption), you can multiply the number of uninspected pages by this defect density to estimate the number of undiscovered defects that could still lurk in the specification. Less experienced inspectors might discover only, say, half the defects that actually are present, so use this estimated number of undiscovered defects as a lower bound. Inspection sampling can let you assess the document’s quality so that you can determine whether it’s cost effective to inspect the rest of the requirements specification. The answer will almost certainly be yes.

Also, keep records of requirements defects that are identified after the requirements are baselined, such as requirements-related problems discovered during design, coding, and testing. These represent errors that leaked through your quality control filters during requirements development. Calculate the percentage of the total number of requirements errors that the team caught at the requirements stage. Removing requirements defects early is far cheaper than correcting them after the team has already designed, coded, and tested the wrong requirements.

Two informative metrics to calculate from inspection data are efficiency and effectiveness. Efficiency refers to the average number of defects discovered per labor hour of inspection effort. Effectiveness refers to the percentage of the defects originally present in a work product that was discovered by inspection. Effectiveness will tell you how well your inspections (or other requirements quality techniques) are working. Efficiency will tell you what it costs you, on average, to discover a defect through inspection. You can compare that cost with the cost of dealing with requirements defects found later in the project or after delivery to judge whether improving the quality of your requirements is cost effective.

The second article in this series will address metrics related to requirements status, change requests, and the effort expended on requirements development and management activities.

Also read Measuring Requirements, 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.

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.

Loss
Probability Low Medium High
Low

Low

Low

Medium
Medium

Low

Medium

High
High

Medium

High

High

 

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 Know 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.

 

 

Software engineers are eternal optimists. When planning software projects, we usually assume that everything will go exactly as planned. Or, we take the other extreme position: the creative nature of software development means we can never predict what’s going to happen, so what’s the point of making detailed plans? Both of these perspectives can lead to software surprises, when unexpected things happen that throw the project off track. In my experience, software surprises are never good news.

Risk management has become recognized as a best practice in the software industry for reducing the surprise factor. Although we can never predict the future with certainty, we can apply risk management practices to peek over the horizon at the traps that might be looming. Then we can take actions to minimize the likelihood or impact of these potential problems. Risk management means dealing with a concern before it becomes a crisis. This improves the chance of successful project completion and reduces the consequences of those risks that cannot be avoided.

During project initiation take the time to do a first cut at identifying significant risks. It’s possible that the risks will outweigh the potential benefits of the project. More likely, getting an early glimpse of potential pitfalls will help you make more sensible projections of what it will take to execute this project successfully. Build time for risk identification and risk management planning into the early stages of your project. You’ll find that the time you spend assessing and controlling risks will be repaid many times over.

What Is Risk?

A “risk” is a problem that could cause some loss or threaten the success of your project, but which hasn’t happened yet. And you’d like to keep it that way. These potential problems might have an adverse impact on the cost, schedule, or technical success of the project, the quality of your products, or team morale. Risk management is the process of identifying, addressing, and controlling these potential problems before they can do any harm.

Whether we tackle them head-on or keep our heads in the sand, risks have a potentially huge impact on many aspects of our project. The tacit assumption that nothing unexpected will derail the project is simply not realistic. Estimates should incorporate our best judgment about the potentially scary things that could happen on each project, and managers need to respect the assessments we make. Risk management is about discarding the rose-colored glasses and confronting the very real potential of undesirable events conspiring to throw the project off track.

Why Manage Risks Formally?

A formal risk management process provides multiple benefits to both the project team and the development organization as a whole. First, it gives us a structured mechanism to provide visibility into threats to project success. By considering the potential impact of each risk item, we can focus on controlling the most severe risks first. We can marry risk assessment with project estimation to quantify possible schedule slippage if certain risks materialize into problems. This approach helps the project manager generate sensible contingency buffers. Sharing what does and does not work to control risks across multiple projects helps the team avoid repeating the mistakes of the past. Without a formal approach, we cannot ensure that our risk management actions will be initiated in a timely fashion, completed as planned, and effective.

Controlling risks has a cost. We must balance this cost against the potential loss we could incur if we don’t address the risk and it does indeed bite us. Suppose we’re concerned about the ability of a subcontractor to deliver an essential component on time. We could engage multiple subcontractors to increase the chance that at least one will come through on schedule. That’s an expensive remedy for a problem that might not even materialize. Is it worth it? It depends on the downside we incur if indeed the subcontractor dependency causes the project to miss its planned ship date. Only you can decide for each individual situation.

Typical Software Risks

The list of evil things that can befall a software project is depressingly long. The enlightened project manager will acquire lists of these risk categories to help the team uncover as many concerns as possible early in the planning process. Potential risks to consider can come from group brainstorming activities or from a risk factor chart accumulated from previous projects. In one of my groups, individual team members came up with descriptions of the risks they perceived, which I edited together and we then reviewed as a team.

Following are several typical risk categories and some specific risks that might threaten your project. Have any of these things have happened to you? If so, add them to your master risk checklist to remind future project managers to consider if it could happen to them, too. There are no magic solutions to any of these risk factors. We need to rely on past experience and a strong knowledge of software engineering and management practices to control those risks that concern us the most.

Dependencies

Some risks arise because of dependencies our project has on outside agencies or factors. We cannot usually control these external dependencies. Mitigation strategies could involve contingency plans to acquire a necessary component from a second source, or working with the source of the dependency to maintain good visibility into status and detect any looming problems. Following are some typical dependency-related risk factors:

  • Customer-furnished items or information.
  • Internal and external subcontractor relationships.
  • Inter-component or inter-group dependencies.
  • Availability of trained and experienced people.
  • Reuse from one project to the next.

Requirements Issues

Many projects face uncertainty and turmoil around the product’s requirements. Some uncertainty is tolerable in the early stages, but the threat increases if such issues remain unresolved as the project progresses. If we don’t control requirements-related risks we might build the wrong product or build the right product badly. Either outcome results in unpleasant surprises and unhappy customers. Watch out for these risk factors:

  • Lack of a clear product vision.
  • Lack of agreement on product requirements.
  • Inadequate customer involvement in the requirements process.
  • Unprioritized requirements.
  • New market with uncertain needs.
  • Rapidly changing requirements.
  • Ineffective requirements change management process.
  • Inadequate impact analysis of requirements changes.

Management Issues

Although management shortcomings affect many projects, don’t be surprised if your risk management plan doesn’t list too many of these. The project manager often leads the risk identification effort, and most people don’t wish to air their own weaknesses (assuming they even recognize them) in public. Nonetheless, issues like those listed here can make it harder for projects to succeed. If you don’t confront such touchy issues, don’t be surprised if they bite you at some point. Defined project tracking processes and clear project roles and responsibilities can address some of these conditions.

  • Inadequate planning and task identification.
  • Inadequate visibility into project status.
  • Unclear project ownership and decision making.
  • Unrealistic commitments made, sometimes for the wrong reasons.
  • Managers or customers with unrealistic expectations.
  • Staff personality conflicts.

Lack of Knowledge

Software technologies change rapidly and it can be difficult to find suitably skilled staff. As a result, our project teams might lack the skills we need. The key is to recognize the risk areas early enough so we can take appropriate preventive actions, such as obtaining training, hiring consultants, and bringing the right people together on the project team. Consider whether the following factors apply to your team:

  • Lack of training.
  • Inadequate understanding of methods, tools, and techniques.
  • Insufficient application domain experience.
  • New technologies or development methods.
  • Ineffective, poorly documented, or ignored processes.
  • Technical approaches that might not work.

Outsourcing

Outsourcing development work to another organization, possibly in another country, poses a whole new set of risks. Some of these are attributable to the acquiring organization, others to the supplier, and still others are mutual risks. If you are outsourcing part of your project work, watch out for the following risks:

  • Acquirer’s requirements are vague, ambiguous, incorrect, or incomplete.
  • Acquirer does not provide complete and rapid answers to supplier’s questions or requests for information.
  • Supplier lacks appropriate software development and management processes.
  • Supplier does not deliver components of acceptable quality on contracted schedule.
  • Supplier is acquired by another company, has financial difficulties, or goes out of business.
  • Supplier makes unachievable promises in order to get the contract.
  • Supplier does not provide accurate and timely visibility into actual project status.
  • Disputes arise about scope boundaries based on the contract.
  • Import/export laws or restrictions pose a problem.

The second article in this series will describe the various activities associated with the practice of risk management and recommend the specific bits of information you should record about each risk you identify.

Also read Know Your Enemy: An Introduction to Risk Management, 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.

In the previous two articles in 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.