Many requirements packages contain Constraints, Assumptions and Dependencies (CAD). These are often defined at the start of the project—and ignored until the BA needs to defend against allegations of poor requirements. Instead of creating a defensive repository to redirect blame (“You signed off on this!”), restate CADs in actionable forms by translating them into non-functional requirements or risks. Since projects usually have processes to manage risks and requirements, this leads to fewer surprises and less churn.

Translation starts with understanding the definition of each term (‘condition’ refers to an event or circumstance).

-          Constraint: A condition that limits the project or solution, is outside the control of the project team, and needs to be managed around (see http://en.wikipedia.org/wiki/Theory_of_Constraints#Constraints).

-          Assumption: A condition not certain to happen, outside the control of the project team, and necessary for the project or solution to be successful.

-          Dependency: A relationship between conditions where one cannot start or finish until another starts or finishes (see http://en.wikipedia.org/wiki/Dependency_(project_management).

-          Risk: A probable condition that will impact the project or solution if it happens. There are four ways to manage a risk: Avoid, Control, Accept or Transfer (ACAT)
(see http://en.wikipedia.org/wiki/Risk_management#Potential_risk_treatments).

-          Non-Functional Requirement: A condition under which the solution must remain effective; a quality the solution must have. Non-functional requirements often describe ways to avoid or control organizational risks.

To begin the translation, establish the primary impacts of the CAD to the solution (how the business operates) and the project (changing how the business operates).

-          For each solution impact, reframe the CAD as a non-functional requirement. The assumption “ATM data schema can be loaded by mainframe” would impact the solution if false. Elicit details associated with the condition from SMEs and document them as measurable requirements.

-          For each project impact, reframe the CAD as a project risk. The dependency “resources available to test code when needed” would impact the project if broken. Assess the probability and impact, and propose a method to manage the risk. The PM is accountable for risk management, but you can offer options.

One CAD may have a mix of multiple project and solution impacts, and be translated into risks and requirements.

This technique takes practice, but it’s worth the effort. PMs and business people appreciate your ability to speak their language—the language of risk—while designers and testers benefit from a more complete understanding of the business needs.

Practitioners who think process mapping can be completed in a two-hour session with a group of subject matter experts, a white board and some sticky notes are likely to end up with a nice piece of paper with a bunch of squares and diamonds. This is because process mapping is not for wimps. Creating a process map that tells a full, data-based story requires a decent amount of time and effort by those individuals involved in the process.

Gathering Information

A great process map should show, with certainty, where improvements can be made, where cycle time delays exist and where smooth handoffs are not taking place. Creating a process, or value stream, map should be the first act a company performs when seeking to make process improvements. If they start more advanced process improvement methodologies without completing a value stream map first, organizations may make a slower start on their road to improvement. Of course, practitioners should not avoid these advanced methodologies. But they will benefit from beginning with a process map, which can make an immediate impact – immediate in the sense of less than three months.

Again, process mapping is not an easy undertaking. It is the perfect combination of business acumen and art. It takes special talent to interview individuals and get them to explain exactly what they do in their job every day, as well as share their pains and express their wants. In fact, it takes the ability to connect with many different types of people and personalities, the know-how to ask questions that will effectively prompt the interviewee and the listening skills to understand what a person is saying – without judgment or prejudice.

A skilled practitioner may ask some of the following questions during an interview to capture process owners’ pains and wants:

• What parts of the process do you seek to eliminate, and why?
• Where do you spend most of your time, and why?
• Where in the process do you repeat work? How often, and why?
• What does your manager think happens in the process? What really happens?
• When pressed for time, what steps in the process do you skip or work around?

But what about the data-based story component? Well, to perform a true value stream mapping exercise, data must be collected in conjunction and concurrently with the interviews. Questions to collect this data may include:

• Where do cycle time delays exist?
• Where do handoffs take place?
• Do people actually hand something off, or is it submitted to a system with the assumption that it is handed off?
• What data points are put into systems? What data points are taken out?
• What pains does the process cause? What do people want or desire from the process?

Gathering data is the real power of performing process mapping. The master plot, the final map with all the details, is great for showing people the process, but the juicy stuff is in the data that is collected.

One of the practitioner’s challenges is to identify exactly how many handoffs there are in the process, and how many inputs go into a system but never get taken out. However, the absolute biggest benefit comes from taking steps out of the process. Once changes have been made, practitioners can calculate a return on investment and assign value to each step in the process.

Five Key Tips

The following are some tips and tricks for process mapping any process in an organization:

• Scope the process: Clearly define a start and stop in the process.
• Identify metrics of importance: To give the effort value, practitioners should determine what they want to eliminate from the process – process steps that generate cycle time, steps where individuals seek approvals, steps where individuals perform manual effort and so on. These will become the steps to color code as action items.
• Select a map collection method: Process mapping can be performed using sticky notes, a spreadsheet or technical drawing software program, or paper and pen. Practitioners should select the method that works best for them and their organization.
• Validate the process maps: After completing a first round of interviews, practitioners should have someone within the organization who is familiar with the process read the maps. This person should check for clarity, content and continuity. The practitioner can review the feedback with the original interviewee for confirmation.
• Minimal interviewees at one time: Practitioners should not attempt to create process maps with large groups. It is best to interview one or two people at a time, therefore reducing social conversation and the desire to correct the process during the mapping session.

About the Author: Joy Taylor is a Master Black Belt and the president of Taygan Consulting Inc. She has worked with clients such as NRG Energy Inc., Merck & Co and Avid Technologies Inc. Taylor started her career at GE Americom Comunications, a GE Capital Business. She is based in Yardley, Pa., USA, and can be reached at joy@tayganconsulting.com.

By Michael Ohler

In problem-solving methodologies, identifying potential causes is a crucial step between process mapping and data collection and analysis. It involves the best available process knowledge, as well as creativity. Creativity and team management tools, more often employed for solution finding than for root cause finding, can generate deep understanding of the process mechanics and help the team prepare for the distilling and data-based validation of the “essential few” root causes of a problem.

Problem-solving teams can increase their chances of success by using a consistent methodology for identifying a problem’s origins. Such a methodology must be based on the very nature of root cause analysis. This form of analysis:

• Is a process that needs to be understood from the “bigger picture.”
• Is a team exercise that focuses on people and on meeting facilitation.
• Uses brainstorming to combine best expert knowledge with out-of-the-box thinking.
• Delivers measurable factors and a data-collection plan.
• Uses data to derive potential causes.

In the light of one specific example, it is possible to see how creativity and team management tools can be used to look deeper into the first four elements of root cause analysis. Using data to distill significant causes, both from a statistical and then from a practical point of view, is typically covered in Lean Six Sigma training classes. The example considered here is a delivery process where lead time had recently degraded with respect to customer expectations.

Working Through the Process

After carefully describing their problem, the team started the analysis by mapping out the delivery process. Then they brainstormed for potential causes for variation in lead time. To validate those causes, they collected and analyzed data. At first, only a small share of the total variation could be explained with these factors. The team then further elaborated the process map for the steps estimated most critical and revisited the cause-and-effect analysis to collect data for more potential factors by using the 5 Why’s analysis technique to drill down further.

Preparing the Team

To understand the observed variation in delivery time, the team mapped out the delivery process in greater detail. The team interviewed customers to determine their requirements and the rationale behind those requirements. They also analyzed how the process interfaces with suppliers; for several team members this was the first time they perceived the “big picture” of the process they were working in. Such first victories set the team on track for the next steps.

In preparation for the brainstorming meeting to identify potential causes, the team leader carefully:

• Conveyed a high sense of urgency and made participants feel “pain and pleasure:” Competitors had taken market share in line with their lead in delivery speed. A smooth flow of the process would also free up resources and reduce overtime work. Management actively supported the initiative.
• Secured creative diversity: Included process and business experts and people with different personal styles.
• Made the team curious about “creativity tools” to be used: He also checked with experienced team members to find out which tools might be best suited for the specific team.
• Removed barriers to a free flow of ideas: The facilitator ensured that rules about inter-department finger pointing was clarified offline. He also verified that stakeholders were analyzed and approached accordingly.

Brainstorming Potential Causes

Like any other brainstorming activity, identifying potential influence factors is a team-thinking process. At the beginning of the meeting, management aligned the participants behind the business criticality of the process through a short intervention. The team also agreed on a schedule and ground rules. Then they went through the process map again, printed on an sheet of paper, which served throughout the meeting.

To capture the team’s experience on what might influence delivery time, the facilitator asked participants to write their thoughts on sticky notes and paste these on a flip chart. As people saw their peers’ contributions, they eventually generated new ideas. The walking and talking involved in the brainstorming set a relaxed atmosphere. Even so, after about 20 minutes, the team reached its first dead point, the time in brainstorming sessions when the team momentarily runs out of ideas. To keep the momentum alive, the facilitator decided to use a fishbone diagram. The facilitator asked participants to come to the flipchart and cluster the different potential causes into major groups.

The facilitator steered the team around a common trap that can arise when using fishbone diagrams. The team had started by writing the defect (“Delivery is slow”) at the “head” of the fish. This would have reduced the continuous variable delivery time into pass/fail information. Doing so would also have generated repercussions when capturing potential causes. A statement such as “insufficient headcount causes slow delivery” can lead a team in a different direction than a study of the influence of allocated work hours on delivery time. Thus, the team investigated the primary metric, “delivery time.”

This clarification, as well as clustering the ideas into major groups, helped generate discussions about the relations between different potential factors, which again generated new ideas. Participants also translated their original statements on “roadblocks to success” into “tunable factors,” imagined as “steering wheels to influence delivery speed”

The clustering exercise generated several major groups of factors. The team sensed some of these were underrepresented because they comprised only one or two potential factors. A quick re-brainstorming made these groups more complete. Then, the facilitator used printouts of traditional Ishikawa diagrams, the basis for fishbone diagrams, which helped them realize that price aspects had been overlooked and could now be collected through another round of posted ideas.

The facilitator decided not to have the team rearrange the posted notes into any of the traditional Ishikawa diagrams. This would helped the team consider the collected potential causes from still another angle, revealing other relations between factors, and generating new ideas. However, with the team dynamics that had unfolded, the facilitator sensed such an additional exercise as a drain to people’s creativity. Note that if this rearrangement does take place, the original state should first be documented with a camera.

The facilitator used a dead point to take a short break to prepare a creativity boosting game. These games often kick people out of their thinking box by first kicking them out of their seats. Typically, human resources departments can help in selecting creativity games. Searching the Internet also delivers many leads.

A short wrap-up of the game helped understand what defined the borders of the current thinking box: policies (written and unwritten), experiential boundaries (“At the current maturity of our logistics system, improvements must be the result of major investments”), firm convictions nobody knew the foundation of (“We will only find things we have seen in the past”) and several other limitations to creative thinking. It was the first time the team had seen the boundaries of their own thinking explicitly on a white board. They decided to creatively challenge some of these boundaries to discover new factors, such as “If we had no performance reporting to management, the delivery time might depend a lot on the affinity of the personnel for a given customer.”

Delivering Measurable Factors

The brainstorming resulted in 47 potential influence factors on delivery time. Green dots, on which the source was noted, were glued on the sticky notes of the factors where data was already available. Yellow dots stood for factors where data could be made available with some effort. Factors with no measurement system in place were marked with red dots. The result turned out to be a surprise: Data was easily available for only for a few factors. The team conducted a vote, in which each participant had five votes, to decide which of the red factors’ measurement systems were high priority.

The team then drafted a data collection plan: determine factor, (potential) data source and owner. They placed sample size determination, operational definition of the measurement and capability assessments of the underlying measurement systems as action items.

Wrapping Up

After agreeing on a follow-up procedure, the facilitator closed the meeting with a wrap up and a short feedback round among the participants. The team felt that the somewhat-fuzzy objective to identify root causes to their problem had been transformed into operational tasks. The use of creativity tools and a game had also made this work more fun. The facilitator added: Facilitating root cause identification is an art that can best be learned by exercising it.

About the Author:

Michael Ohler is Master Black Belt with experience in several industries and a controlling, quality and project management background. He also has Lean and Six Sigma training experience at the Yellow, Green and Black Belt levels and holds a doctorate in experimental physics. Dr. Ohler has been teaching university courses in France and Brazil. Contact Michael Ohler at ohlermichael (at) googlemail.com

A first step in defining the measurement system must be establishing formalized processes for resource planning. Practitioners should gather and analyze the business requirements within the process to determine deficiency input points. This can be done using process flow diagrams of both current, or “as is,” and modified, or “to be,” processes.

Next, practitioners should determine critical-to-quality (CTQ) requirements for project task deliverables. Metrics for evaluating resource planning processes consider these CTQs. Once CTQ characteristics are identified, the cost of poor quality (COPQ) can be determined. A project skills matrix and a failure mode and effects analysis (FMEA) for resource planning can be used to capture data for measurement. Then practitioners can identify the defects per million opportunities (DPMO), a number that can be converted to a sigma level. The sigma level will focus on measuring and eliminating defects in core resource planning processes.  

Six Sigma can be used to define process capability in order to identify metrics for evaluating the outcome of CTQ requirements.

Identifying CTQ Variables

Within the variance model framework, a resource manager should construct a CTQ FMEA template that is applicable to staffing requirements outlined in the Define phase. The CTQ specifications should be stated, and measures devised. Variables can be associated with defect opportunities (Table 1).

The conversion of actual defects in task delivery to DPMO will derive a sigma value denoting either organizational excellence, satisfactory performance or unfavorable results. Practitioners can compare sigma values at the start and end of the project to determine improvement gains. A sample of a CTQ measurement is illustrated in Table 2.

Quantifying COPQ in Resource Planning Processes

The calculation of COPQ uses weighted risk for potential failures. It considers an estimation of four components:

1. Probability of occurrence for each failure
2. Potential severity of each failure
3. Current detection provisions
4. Resolution cost of a single failure

The connection of COPQ to DPMO means that poor quality costs are proportional to sigma levels. The yield should be compared to the cost of quality in the finished project deliverable. The sigma level correlation to DPMO and cost of quality is stated as percentage of revenue (Table 5).

Control System Benefits

In a service organization, the most efficient method for cutting waste is to attack anything and everything that is not done right the first time. This concept, known as first time right, involves making sure that all activities are carried out in the right manner the first time and every time. Examples include a customer not needing to repeat their order at a take out restaurant and a bank executive handing the customer the correct form the first time. Completing all services right the first time is not easy, but doing so can be an effective way for businesses to begin their Lean journey.

Tracking First Time Right Encounters

The first step to completing service processes right the first time is to measure the current level of performance. Practitioners can begin by measuring the number of transactions that meet this goal and comparing this to the total number of transactions. Any process that receives input from another internal process should be measured. With this data, practitioners can approach the problem in a logical manner and find the reasons for poor performance. Sheer measurement of first time right processes usually helps earn the required buy-in and attention from the stakeholders.

Measuring the first time right performance of service personnel might be a change for many organizations. For example, bank managers may be used to judging their staff by the time it takes them to resolve a customer query. However, staff may not always provide complete information to customers, which can result in repeat complaints. Thus, it is essential to link an employee’s performance or output with the transactions that are completed correctly the first time.

Improving Performance

At the transaction level, organizations need to ensure that processes are well understood by the people performing them. Many transactions are not first time right simply because there are no clear guidelines and the staff has not been properly trained. A documented process will go a long way in ensuring this. For example, creating a standard operating procedure for filling out a loan application form will reduce the number of cases rejected at the next step in the loan process.

Simple techniques such as checklists and highlighted boxes for signatures help to ensure things are done right the first time. In a restaurant, for instance, all default silverware can be kept in stands or bins so that the waiter simply has to pick up one from each bin to ensure that all the tools are served correctly. Or, if a fast food restaurant distributes an order form while the customer is in line, the customer can check the items required and hand the form to the billing clerk, thus avoiding any error in ordering and reducing billing time.

Cutting Out Waste

First time right also helps address the seven wastes of Lean. By religiously following this spirit of making things right the first time, each of the forms of waste can be reduced, as explained here:

1. Defects – The simplest and most direct waste addressed by first time right. Any service rendered to a customer that is not first time right – wrong delivery, data entry or diagnosis in a hospital – is a defect. Services do not have the luxury of rework; any defect remains a defect. However hard an organization tries, customers will not be completely satisfied after a bad service experience. The same is not true in manufacturing, where the customer may not even be aware of rework if it happens prior to product delivery. For example, the wrong order served in a restaurant will leave a bad taste with the customer even after the mistake is corrected; however, the rework on a car engine has no impact on the customer as long as the final product meets the specifications.

2. Overproduction – Services have a tendency to overproduce to make up for transactions that do not go first time right. Any rework is overproduction, and takes up effort that should be going into a fresh transaction. For example, a package misdelivered results in an extra pick up and delivery to the correct destination.

3. Processing – In services industries, a lot of processing takes place to prevent defects from reaching the customer. For example, in a bank, employees may check an account-opening form at multiple points during the process before generating the new account number. Inspection is a pure non-value-adding activity. Hence, inspection needs to be performed only when absolutely necessary and should not be used as a filtering process to hide the inefficiency of the input. If a customer address is not captured accurately on a majority of applications, it is better to devote time and effort on correctly capturing the information the first time rather than deploying someone to check and rectify all the applications.

4. Waiting – Any difference between the processing turnaround time and customer demand results in customer waiting time. In many cases, the processing turnaround time increases due to rework for activities that have not happened correctly the first time. For any kind of rework, there is waiting involved – usually on the part of the customer. Any hotel room not made up properly results in customer waiting, and a loan application not completed properly will delay the disbursement to the customer.

5. Inventory – The traditional manufacturing concept of inventory does not exist in services; services cannot be stored for future delivery. A hotel room left vacant for a night is lost business forever – it can never be recovered. However, in certain situations, services do maintain an inventory in the form of capacity. Call centers can reduce the staff on board if they ensure first time resolution of the customer’s complaint so that the customer does not need to call again for the same reason. If sufficient focus and effort is applied to improving billing accuracy, organizations need not use part of its capacity for making corrections.

6. Motion and 7. Transportation – Services incur motion and transportation in the form of various handoffs that take place at stages of service delivery. Any rework results in more of these handoffs. For example, a loan that has been rejected due to incorrect income calculations goes thorough multiple handoffs and approvals before it is corrected. This could be avoided if the calculations were done correctly the first time.

About the Author: Sharad Sharma is employed with Reliance Money Ltd. in New Delhi, India. He is an engineering graduate with a master’s in business administration from the National Institute of Industrial Engineering, Mumbai. He has extensive experience in deploying quality initiatives across the manufacturing, business process outsourcing and financial services sectors. He can be reached at sharad.sharma1@yahoo.com

Taken from “Choosing & Using Consultants & Advisers: A Best Practice Guide to Making the Right Decision and Getting Good Value”
by Harold Lewis

THIS IS WHAT CLIENTS SAY

When business managers are asked why they use consultants, their replies typically point to three factors

• the expertise that consultants offer;

• their independent viewpoint;

• the resources they provide.

Expertise	Independence	Resources
Specialist skills External competencies Breadth of experience Depth of insight Focus and direction Awareness of best practice Facilitating change Identifying and diagnosing problems Adding value through knowledge transfer Lateral thinking Creativity and new ideas Access to research data	Detached viewpoint Impartiality Unbiased analysis Bridge between interests Professional judgement as technical collateral Legal requirement for independent advice	Outsourcing Meeting workload pressures Freeing up management time Fulfilling management roles Cost-effective response to occasional or short-term needs Opportunity for cost savings

Expertise

Maybe it was that southern drawl.

Or maybe it was because I got mad.

I’m not sure why I still remember this moment so clearly, but I do.  It happened when I was at Spyglass, over ten years ago.  Several of us developers were in a meeting with Steve Stone, then recently-hired as director of the Champaign office.  We were talking about a possible new feature.  Steve, in his Alabama accent, asked,

“So is that a requirement?”

A couple years later, I realized that I misunderstood the question.  I didn’t have enough project management background to know the particular way that he was using the word “requirement”.  For me at the time, the word “requirement” had connotations of absolute necessity.  So when Steve asked the question, here is what I heard:

“So is this feature something that absolutely must be in the next release of the product?”

On top of that, I’ll confess I was sort of generally crabby at that point in my life, especially with respect to Steve Stone.  Instead of promoting me or one of the other lead developers to run the Champaign office, Spyglass had hired Steve from the outside.  In fact, Spyglass asked me to interview Steve, but only after the interview did they tell me I had actually been interviewing my new boss.

Anyway, I was in a generally foul mood when I misunderstood this question.  I suppose that’s why I answered Steve by saying something like this:

“How the @%$* should I know if this feature has to be in the product or not?  You’re new here, so let me explain how things go.  Management moved the headquarters to Chicago after years of promising that they never would.  Here in Champaign, nobody tells us anything.  We’ve got no marketing people except the team who spent 3 months deciding which Pantone color is the right shade of red for our company logo, which nobody ever sees because our product is an OEM component.  The only way we ever know that a feature absolutely must be in the product is when one of our Sales Guys calls up and tells us that he already promised it.”

Steve was a very patient man.  I assume anybody who lived in Alabama would have to be.    He just smiled as he listened to my rant (footnote 1).

But my career with Spyglass didn’t last too much longer after that.  A few months later, in a moment when I was ready to throw another tantrum, I decided to just quit instead.

And I went out on my own and founded SourceGear.  We started out doing contracting projects.  One of our first clients asked me for a Software Requirements Specification (SRS) and a Traceability Matrix.  That wasn’t a very good day.

But not long after that, I learned what the word “requirement” means when used in the context of software project management.

And I learned what Steve Stone had really meant when he asked that infuriating question.  When Steve said:

“So is that a requirement?”

What he was really asking was:

“So it sounds like we just identified something that should become part of our spec.  You guys have a spec around here somewhere, right?  Who is responsible for updating that spec to capture this new item?”

What is a Requirement?

I define a requirement as “one piece of a spec”.  Is that definition complete and immune to attack?  No, but I think it’s the simplest definition that works.

Of course, it relies on the definition of a “spec”, so let’s go there.

What is a Spec?

A spec is short for “specification”.  A spec is something that describes what a piece of software should do.

For the moment I am being deliberately broad and inclusive.  If you are experienced in software project management, you probably have something very specific in mind when think of the words “spec” or “requirement”.  In fact, it is possible that you are not willing to acknowledge that something is a spec unless it matches up fairly well with your image of same.  That’s okay.  Just stay with me.

For now, I’m saying that anything that is a “description of what a piece of software should do” can be considered a spec.  This may include:

• A document
• A bunch of 3×5 note cards
• A spreadsheet containing a list of features

I am currently involved in a project where my role is “The Walking Spec”.  In other words, I am the person who mostly knows everything about how this piece of software should mostly behave.  When people need a spec, they ask me a question (footnote 2).  I’m not saying that I am a good spec, but I don’t think I’m the worst spec I have ever seen, and I am certainly better that no spec at all. 

Seriously, a spec needs to be in a form which is accessible to more than one person.  It needs to be written down, either in a computer or on paper.

But how?

Document or Database?

There is a constant tension over the form of a spec.  Should it be a document or a database?

I’m using the words “document” and “database” as names for the two extremes which create this tension. 

• When a spec is more like a document, it looks like a bunch of paragraphs and prose and pictures. 
• When a spec is more like a database, it looks like a bunch of bullets and lists and outlines.

When a spec is being written, it wants to be a document.  It’s easier to describe what a piece of software should do when we can use paragraphs and prose and formatting.

Maybe this is because the primary content of a spec is usually coming from someone other than a developer.  We developers sometimes write apps for ourselves, but that’s not the common case.  More often, we’re writing software that somebody else wants.  We don’t know how the software should behave.  They do.  In order for the software to be born, they need to express to us everything they know about what the software should do.  That expression is a spec.

And in all likelihood, that expression is more naturally going to be like a document and less like a database.  The person will want to tell stories and give examples and rationale.  They may want to include pictures or video to explain.

But right after a spec is written, a document is usually the wrong form.  It started out as a document only because that form was most convenient for the author.  But a document is not the most convenient form for the people who are reading or using the spec, and those people have the author outnumbered.  Most of those readers/users want that spec to be a database instead of a document.

They want the spec to be logically broken up into a bunch of little pieces.  Each piece should be a self-contained statement about one single detail of how the software should behave.

Breaking a spec into little pieces allows us to use that spec more effectively.  We can more easily divide the software construction tasks across a team by assigning different pieces to different people.  We can then print the pieces as a list, put boxes to the left of each one and use it as a checklist to make sure we’re getting everything done.

So, let’s return to the original question.  What is a “requirement”?

A requirement is a piece of a spec.  When we take a spec and put it into its more useful form by breaking it into bite-sized pieces, each of those pieces is a requirement.

Corollary

If you are in the habit of ignoring specs, you can ignore requirements in exactly the same way.  They’re no different. 

Writing Requirements

“Dad, where do products come from?”

“Well, son, when a company and a market segment really love each other, they…”

Every software product starts out as a gleam in the eye of some guy who wants to make money.  He sees a bunch of people who have money.  He pauses to reflect upon how much nicer life would be if that money were moved from their wallets into his own.

So, he pursues a process which involves the following two steps:

1. Find an idea for a product
2. Build that product

Things usually fall apart between steps 1 and 2, mostly because these two steps are done by different people.  The product is not being built by the same person who had the idea and the gleam.  Step 1 is usually somebody in marketing.  Step 2 is a team of developers.

So, in order for the developers to know what product to build and how, we need to describe it to them (via a spec) with lots of details (requirements).

Construction and Testing

With a well-written requirements spec, the development of a software project is easy.

Let’s assume the project starts out with a spec that is:

• Complete.  The spec describes everything the product needs to do.  Nothing was forgotten.
• Stable.  The spec isn’t in flux.  It’s not going to change along the way.
• List-oriented.  The spec is like a database; each item being a self-contained requirement.  All the prose has been appropriately broken up into little pieces.

This is the dream scenario for a development manager.  Translate all the requirements into a set of tasks.  Divide up all the tasks between the developers on the team.  How hard can that be?

Similarly, the testing lead has a very straightforward path with this kind of a requirements spec.  For every requirement, create one or more tests that can be used to verify that the software meets that requirement.  Automate as many of those tests as possible.  Every time the developers create a new build, run the tests and report what happened.  Easy, right?

Unfortunately, projects don’t always work that way.

In fact, projects almost never work that way, because most requirements specs are badly written.

Bad Requirements

A bad requirements spec is considerably more likely than a perfect one.  Certain kinds of problems are common.

For example, let’s suppose we are building a game which is designed to be played by middle school girls in a library.  The following examples show some typical problems with requirements:

Missing Requirements

Very often, the spec simply isn’t complete.  Somebody forgot to include an important detail.

For example, since we know the game is supposed to be played in libraries, users will need to turn the sound down or off.  So we need the game to be playable without sound.  If we forget to mention this requirement specifically, there’s a decent chance the dev team will create a game where sound is important to game play.

Unclear Requirements

Sometimes requirements are ambiguous.  Here’s an unclear requirement:

·        The game must be compatible with DirectX.

Which version?  Can we use DirectX 10, thus requiring Windows Vista?  Or should we target DirectX 9 and stay compatible with Windows XP?  It’s not clear.

Non-prioritized Requirements

A good requirements spec contains priority information to help the dev team make the right tradeoffs.  If some requirements are more important than others, the spec should say so.

Consider these two requirements:

·        The user must be allowed to save a game in progress and resume it later.

·        The main character in the game must resemble Dakota Fanning without looking exactly like her.

The schedule is getting tight.  Only one of these two features is going to make it.  Do you want to leave this choice entirely up to the dev team?  Or do you want to make it clear that save/load is a more important feature than making the main character resemble a certain child actress? (footnote 3)

Missing Anti-Requirements

Sometimes the problem is that the development team tries to go above and beyond the call of duty and sneak something in that wasn’t part of the spec.  This can be a good thing, but it can also be a bad thing.  A good requirements spec will contain “anti-requirements”, explicitly spelling out things that should not be done.  For example:

·        This game must not have a grenade launcher.

Believe me, if you leave too much latitude on a game project like this, we developers will turn it into a first person shooter.  Yes, we can see from the spec that the target customer is a 12 year old girl playing in a library.  But still, our intuition is that all games need a grenade launcher, so you’re gonna get one if you don’t explicitly tell us otherwise.

Changing Requirements

If a project gets all the way to completion with bad requirements, the likelihood is that the software will be disappointing.  When this happens, the resulting assignment-of-blame exercise can be fun to watch.  From a safe distance.

More often, during the project somebody notices a problem with the requirements and changes them along the way.

Marketing:              By the way, I forgot to mention that the application has to be compatible with Windows 95.

Development:         Windows 95?  You’re kidding, right?  People stopped using Win95 over a decade ago!

Marketing:              Oh, and Mac OS 7.6 too.

Development:         What?  We’re building this app with .NET 3.0 and we’re already 40% done!

Marketing:              You’re half done?  That’s great!  Oh, and I forgot to mention we need compatibility with the Atari ST.

Development:         Why didn’t you tell us this before we started?

Marketing:              Sorry.  I forgot.  It’s no problem to change it now, right?

Changing requirements mid-project can be expensive and painful.

However, it is very rare to have a project where all the requirements are known and properly expressed before development begins.  So, it behooves us to prepare for changes.  If we choose a development process which rigidly requires a perfect spec before construction can begin, we are just setting ourselves up for pain.  We need to be a bit more agile.

Agile

I lament the loss of the word “agile”.

A minute ago when I used the word “agile”, most readers immediately thought I was talking about Agile software development practices such as Scrum or Extreme Programming.  That means your reaction was probably polarized toward one of the following two extremes:

• Oh, great!  I’m five pages into this article and suddenly I find out Eric Sink is one of those Extreme Programming fanatics?  I guess that’s 15 minutes of my life I’ll never get back.  Sorry, I don’t mind visiting once in a while like on Christmas or Easter, but I’m just not interested in having somebody tell me how to live my life.  And I don’t want some Agile priest telling me that I’m not a true believer just because we don’t do pair programming.
• Oh, great!  Here’s Eric Sink trying to pretend like he’s a believer when everybody knows he’s not.  Actually I guess I should check the Central Membership Roll just to be sure.  Nope, I was right.  He’s not.  Even if he was, we would have to excommunicate him anyway.  Anybody who reads the drivel on his blog knows darn well that his doctrine is seriously screwed up.

I just want to use the word “agile” without all those connotations.  My copy of Merriam Webster’s Tenth Edition says that “agile” means “marked by ready ability to move with quick easy grace”.  At a high level, that’s all I’m trying to say.  Sometimes requirements change.  Be ready.

In more practical terms, I’ll admit that the body of wisdom literature produced by the Agile movement has some very good stuff in it.  But Agile is no different from any other major religion like Christianity or Buddhism.  You can learn some great principles and practices there, but formally becoming a member is a decision that should not be made lightly.

Traceability

I’ve tried to write this article at a fairly high level, focusing more on principles than practices, staying inclusive of the broad range of viable methods for getting projects done.  However, the truth is that the word “requirement” is usually associated with stricter and more formal ways of doing things.

We developers say that we don’t like formality and strictness, but I think we’re confused.

We don’t like being told what to do.  We don’t like stupid rules that don’t make sense.  We don’t like working for some stupid pointy-haired-boss who draws arbitrary boundaries that we’re not allowed to cross.

But we spend our entire day using a compiler, and compilers are very formal and strict.  In C, if we type primtf instead of printf, the compiler will let us go no further until we stop and fix it.  In C#, if we try to use an uninitialized local variable, our compiler will scold us for stepping outside the boundaries.

Do we go out after work and gripe about our compiler?

“I am sick and tired of that stupid compiler!  When I do something right it never says a word, but if I do the slightest little thing wrong, it throws a fit.  Why does it have to nitpick about every little mistake I make?”

Nope.  Actually, we like compilers.  We like the formality and strictness.  We know having a compiler to catch our mistakes is a good thing because it allows us to go faster.  It’s safe to sit down and crank out a thousand lines of code as fast as we can because we know the compiler will find a lot of the little errors that happen.

Wouldn’t it be great if every phase of the software development process had a compiler?

• I want a piece of software that tells me if I forget to implement one of the requirements.
• When my requirements conflict with each other, my “spec compiler” should output an error.
• When one of my requirements isn’t being verified by anything in the test suite, some piece of software should tell me.

The compiler I want doesn’t exist today, but there are things we can do to approximate that style of work.  For example, code coverage can be used to help verify that things are getting tested.  Automated testing can help catch bugs that slip in.

The concept which may eventually get us the compiler I want is called “traceability”.  The idea is that everything should be traceable back to something else.

• Every piece of code in the project should exist because it helps meet one or more requirements.  Traceability should allow us to ask, “Which requirement motivates this piece of code?”  If the answer is “none”, then that piece of code should be excised.
• Every requirement needs to be tested.  Traceability should allow us to ask, “Which tests verify that this requirement is being met?”  If the answer is “none”, then we need to write some more tests.

Lacking my super-duper application lifecycle compiler that verifies that everything is traceable, we can keep track of some of this stuff using a traceability matrix.

When it functions more like a compiler than a pointy-haired-boss, a little extra formality and strictness can be very helpful.

Requirements Management Software

Naturally, we want to use software to manage our requirements.  Many folks do this with a general-purpose tool like a word processor or a spreadsheet.  That works fine.

Some people track requirements in a bug-tracking system.  This can work, but it’s not a perfect solution.  Requirements and bugs are different.  For example, requirements don’t change status from Open to Closed to Verified.

Another approach is to use something which is specifically designed to track requirements.  Application Lifecycle Management (ALM) software often contains features for managing and tracking requirements.  The ALM solutions from companies like IBM Rational, Serena and Borland are examples, but it should be noted that these solutions are very expensive and designed for large enterprise environments.

My own company will soon be releasing an ALM solution which is designed specifically for smaller teams.  We call it SourceGear Fortress.  However, the 1.0 release will not have any features specifically designed for tracking requirements.  We do intend to include this and other features in the future as we evolve Fortress into a mature and complete ALM solution.

Microsoft made a similar choice with Visual Studio Team System.  However, since their product is enterprise-focused, it has been criticized for not having any requirements features in the first release (footnote 4).  I suspect that this is a hole they plan to plug at some point in the future.

Additional Reading

This short article barely scratches the surface of a very complex topic.  For additional information, I recommend the book Software Requirements by Karl E. Wiegers.

Footnotes

(1)           I have no hard feelings toward my old boss at Spyglass.  I lost touch with Steve Stone, but I understand he later left the company and joined Microsoft.  A little searching with Google reveals that he is currently the CEO of a startup company called InfoFlows.  Steve, if you are reading this article, best regards.

(2)           Rest assured that this project is not one of SourceGear’s products.  It’s a revision to one of our internal systems.

(3)           Hypothetically, the reason this save feature might be so important is to ensure that when the hypothetical father of the hypothetical middle school girl arrives at the hypothetical library to pick her up, she can save her game and go promptly so her Dad doesn’t have to wait.  Hypothetically.

 (4)          Third-party products are available to add requirements management features to VSTS.

Process maps are good for streamlining work activities and telling new people, as well as internal and external customers, “what we do around here.” They also can help in the effort to reduce cycle time, avoid rework, eliminate some inspections or quality control steps, and prevent errors.

Once a process map is completed, the team that put it together will analyze it. There has probably never been a process map developed where someone has not said, “Do we still do that?” or “Why does X happen there?” or “Why are we doing it that way?” or “I did not realize….”

The analysis is no more than considering the process activities and flow by:

A. Looking at each process step for:

• Bottlenecks
• Sources of delay
• Errors being fixed instead of prevented (rework)
• Role ambiguity (we didn’t know who…)
• Duplications
• Unnecessary steps
• Cycle time

B: Looking at each decision for:

• Authority ambiguity (two or more people get to decide…)
• Are the decisions needed at this point?

C: Looking at each rework loop for:

• Possibly eliminating the step(s) or doing in less time, or trying to prevent

D: Using the customer’s point of view

• Value-added vs. non-value-added steps (from the customer’s point of view)

Below is a chart which provides a checklist of things to Be On the LookOut for when mapping and analyzing any process. Items on the list are, of course, called BOLOs, for short. 

About the Author

Michael Lee Smith is a director of process improvement at ETS in New Jersey. In his current position he is part of a team implementing Six Sigma. He instructs, provides support and manages projects. He is a certified Six Sigma Black Belt and is working toward Master Black Belt certification. Mr. Smith has more than 35 years experience in human resources and process improvement in the telecommunications, engineering and business services industries. He has a bachelor’s degree in psychology and an MBA in human resources management. He can be reached at ms@mikesmith-hr.com

Taken from www.processimpact.com

Customers are never thrilled to find out they can’t get all the features they want in release 1.0 of a new software product (at least, not if they want the features to work). However, if the development team cannot deliver every requirement by the scheduled initial delivery date, the project stakeholders must agree on which subset to implement first. Any project with resource limitations has to establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions.

Why Prioritize Requirements?

One characteristic of excellent requirements is that they are explicitly prioritized. When customer expectations are high, timelines are short, and resources are limited, you want to make sure the product contains the most essential functions. Establishing each chunk of functionality’s relative importance lets you sequence construction to provide the greatest product value at the lowest cost. Customers and developers must collaborate on requirements prioritization. Developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements.

A project manager has to balance the project scope against the constraints of schedule, budget, staff resources, and quality goals. One balancing strategy is to drop or defer low priority requirements to a later release when you accept new, higher priority requirements or other project conditions change. If customers don’t differentiate their requirements by importance and urgency, the project manager must make these trade-off decisions. Because customers may not agree with the project manager’s decisions, they must indicate which requirements are critical and which can wait. Establish priorities early in the project, while you have more options available for achieving a successful project outcome.

It’s difficult enough to get one customer to decide which of his or her requirements are most important; gaining agreement among multiple customers with diverse expectations is even more challenging. People naturally have their own interests at heart and they aren’t always willing to compromise their needs for someone else’s benefit. However, making such priority decisions is one of the customer’s responsibilities in the customer-developer partnership.

Customers prioritize requirements initially from the perspective of how valuable each one is to them. Once a developer points out the cost, technical risk, or other trade-offs associated with a specific requirement, though, the customers might decide it isn’t as essential as they thought. The developers might also determine that certain lower priority functions should be implemented early on because of their impact on the product architecture. When setting priorities, you need to balance the business benefit that each function provides against its cost and any implications it has for the product’s architectural foundation future evolution.

Games People Play with Priorities

The knee-jerk response to a request for customers to set priorities is, “I need all of these features. Just make it happen somehow.” This doesn’t help. It can be difficult to persuade customers to set priorities if they know that you may never be implement low priority requirements. A developer once told me that priorities are unnecessary, because if we wrote something in the software requirements specification (SRS), we intend to build it. However, that doesn’t consider the issue of when you should implement each function. Developers may not wish to bother with priorities, because that conflicts with the “we can do it all” attitude they want to convey to their customers and managers.

The reality is that some features are more essential than others. This becomes apparent during the all-too-common “rapid descoping phase” late in the project, when lower priority features are jettisoned to ensure the product is shipped on schedule. Setting priorities early in the project helps you make those trade-off decisions along the way, rather than in emergency mode at the end. Getting a feature half-developed before you determine that it’s low priority is wasteful and frustrating.

If left to their own devices, customers will set perhaps 85% of the requirements at high priority, 10% at medium, and 5% at low priority. This doesn’t give the project manager much to work with. Steve McConnell identified requirements scrubbing—eliminating those that are not essential and simplifying any that are unnecessarily complicated—as a best practice for rapid software development (see Rapid Development, Microsoft Press. 1996).

On one project I know of, the management steering team became impatient when the analyst insisted on prioritizing the requirements. The managers pointed out that they could often do without one feature, but another feature may need to be beefed up to make up for the omitted requirements. They reasoned that if they deferred too many requirements, the resulting system wouldn’t achieve the revenue that the business plan promised. When you evaluate priorities, look at the connections and interrelationships among different requirements and their alignment with the business requirements.

Prioritization Scales

A common approach to prioritization is to group requirements into three priority categories. Table 1 shows two typical three-level scales. All such scales are subjective and imprecise, so everyone involved must agree on the meaning of each level in the scale they use. Priority is a key attribute of each requirement that should be included in the SRS or requirements database. Establish a convention for your SRS so the reader knows whether the priority assigned to a higher-level requirement is inherited by all of its subordinate or derived requirements, or whether every individual requirement should have its own priority attribute.

Another issue is the granularity at which you prioritize requirements. Even a medium-sized project can have hundreds or thousands of detailed functional requirements, too many to classify analytically and consistently. You need to choose an appropriate level of abstraction for the prioritization. This could be at the use case level, the feature level, or the detailed functional requirement level, whichever makes logical sense for your situation.

Table 1.

Two requirements prioritization scales.

Keep the prioritization as simple as possible to help you make the necessary development choices. You may decide to do an initial prioritization at the feature level and then prioritize the functional requirements within a specific high-priority feature separately. This will help you distinguish the core functionality that must be present for that feature to work at all from refinements you could add in a later release. Include even the low-priority requirements in the SRS. Their priority may change over time and knowing about them now will help you plan ahead for future enhancements.

Prioritization Based on Value, Cost, and Risk

On a small project, the stakeholders can probably agree on requirement priorities informally. Larger or more contentious projects need a more structured approach, which removes some of the emotion, politics, and guesswork from prioritization.

Industry analysts have proposed several techniques that involve estimating the relative value and relative cost of each requirement, such that the highest priority requirements provide the largest fraction of the total product value at the smallest fraction of the total cost. In essence, you’re trying to identify those requirements that will maximize the product value within the existing cost constraints. Subjectively estimating the cost and value by pair-wise comparisons of all the requirements is impractical for anything more than a couple dozen requirements.

Another alternative, Quality Function Deployment (QFD), provides a robust and comprehensive method for relating customer value to the proposed product features. A third approach, based on Total Quality Management (TQM), rates each requirement against several specific, weighted project success criteria and computes a score to rank the priority of the requirements. However, in my experience few software organizations are willing to undertake the rigor of QFD or TQM.

In this article I describe a semi-quantitative analytical approach to requirements prioritization. As an example, we’ll consider a product called the Chemical Tracking System. The Chemical Tracking System will let research scientists request containers of chemicals to be supplied by the company’s chemical stockroom or by commercial chemical vendors. The system will store the location of every chemical container within the company, the quantity of material remaining in it, and the complete history of each container’s locations and usage. The Chemical Tracking System must also comply with federal and state government regulations that require quarterly chemical usage, storage, and disposal reports.

Table 2 illustrates a simple spreadsheet model to help you estimate the relative priorities for a set of product features such as those from the Chemical Tracking System. You can download this Excel spreadsheet from www.processimpact.com/goodies.shtml. This approach distributes a set of estimated priorities across a continuum, rather than grouping them into just a few priority levels. You can apply this model just as well to prioritize use cases or individual functional requirements. This prioritization scheme borrows from the QFD concept of customer value depending on both the customer benefit provided if a specific product feature is present and the penalty paid if that feature is absent. A feature’s attractiveness is directly proportional to the value it provides and inversely proportional to its cost and the technical risk associated with implementing it. All other things being equal, those features that have the highest risk-adjusted value/cost ratio should have the highest priority. Of course, these are not the only factors that affect prioritization, so don’t use this scheme as your only method for setting priorities.

Apply this prioritization scheme only to negotiable features, those that are not in the top priority category. For example, you wouldn’t include items in this priority analysis that implement the core business functions of the product, that you view as key product differentiators, or that are required for compliance with government regulations. You’re going to include those features no matter what. Once you’ve identified those features that absolutely must be included for the product to be shippable, scale the relative priorities of the remaining features using the model.

The typical participants in the prioritization process include:

• The project manager, who leads the process, arbitrates conflicts, and adjusts inputs from the other participants if necessary
• Key customer representatives, who supply the benefit and penalty ratings
• Development representatives, such as team technical leads, who supply the cost and risk ratings.

Follow eight steps to use this prioritization model.

Step 1. List all of the requirements, features, or use cases that you wish to prioritize in a spreadsheet; we’ll use features in this example. All of the items must be at the same level of abstraction. For example, don’t mix individual requirements with product features. If certain features are logically linked (that is, you would only implement feature B if feature A were included as well), include only the driving feature in the analysis. This model will work with up to several dozen features before it becomes unwieldy. If you have more items than that, abstract related features together to create a more manageable initial list. You can do a second round of analysis at a finer granularity of requirements detail if you need to.

Step 2. Estimate the relative benefit that each feature provides to the customer or the business on a scale from 1 to 9, with 1 indicating very little benefit and 9 being the maximum possible benefit. These benefits indicate alignment with the product’s business requirements. Your customer representatives are the best people to judge these benefits.

Step 3. Estimate the relative penalty the customer or business would suffer if the feature is not included. Again, use a scale from 1 to 9, where 1 means essentially no penalty and 9 indicates a very serious downside. For example, failing to comply with a government regulation could incur a high penalty even if the customer benefit is low, as would omitting a feature that any reasonable customer would expect, whether or not they explicitly requested it. Requirements that have both a low benefit and a low penalty add cost but little value; they may be instances of gold plating.

Step 4. The Total Value column is the sum of the relative benefit and penalty. By default, benefit and penalty are weighted equally. As a refinement, you can change the weights for these two factors. In Table 2, all benefit ratings are weighted twice as heavily as the penalty ratings. The spreadsheet totals the feature values and calculates the percentage of the total product value provided by these features that is attributable to each feature.

Step 5. Estimate the relative cost of implementing each feature, again on a scale ranging from a low of 1 to a high of 9. The spreadsheet will calculate the percentage of total cost for each feature. Developers estimate the cost ratings based on factors such as the requirement complexity, the extent of user interface work required, the potential ability to reuse existing designs or code, and the levels of testing and documentation needed.

Step 6. Developers estimate the relative degree of technical or other risk associated with each feature on a scale from 1 to 9. An estimate of 1 means you can program it in your sleep, while 9 indicates serious concerns about feasibility, the availability of staff with the needed expertise, or the use of unproven or unfamiliar tools and technologies. The spreadsheet will calculate the percentage of the total risk that comes from each feature.

By default, cost and risk are weighted equally, and each carries the same weight as the benefit and penalty terms. You can adjust the cost and risk weightings in the spreadsheet. In Table 2, risk has one-half the weight of the cost factor, which has the same weight as the penalty term. If you don’t want to consider risk in the model, set the risk weighting value to zero.

Step 7. Once you enter the estimates into the spreadsheet, it calculates a priority number for each feature. The formula for the Priority column is: priority = value %/ (cost % * cost weight + risk % * risk weight).

Step 8. Sort the list of features in descending order by calculated priority. The features at the top of the list have the most favorable balance of value, cost, and risk, and thus should have higher implementation priority. The key customer and developer representatives should review the completed spreadsheet to agree on the ratings and the resulting sequence.

This semi-quantitative method is not mathematically rigorous, and it is limited by your ability to estimate the benefit, penalty, cost, and risk for each item. Therefore, use the calculated priority sequence only as a guideline. It will take you awhile to calibrate your rating scales for a set of requirements, so iterate through the list after rating all the requirements and make any necessary adjustments. Calibrate this model for your own use with a set of completed requirements or features from a previous product. Adjust the weighting factors until the calculate priority sequence agrees with your after-the-fact evaluation of how important the requirements in your test set really were.

This model can also help you make trade-off decisions when you’re evaluating proposed new requirements. Estimate their priority using the model to tell you how they match up against existing requirements, so you can choose an appropriate implementation sequence. Any actions you can take to move requirements prioritization from the political arena into an objective and analytical one will improve the project’s ability to deliver the most important functionality in the most appropriate sequence.

[This paper was originally published in Software Development, September 1999. It is reprinted (with modifications) with permission from Software Development magazine.]