Let’s Pretend We’re Secret Agents

July 26th, 2011

Taken from the article http://www.batimes.com/articles/business-analyst-says-lets-pretend-were-secret-agents.html

Written by Teri McIntyre

“Please don’t call me by my real name, it destroys the reality I’m trying to create.”
–Wallace Ritchie, “The Man Who Knew Too Little”

Back in 2009, I presented at an education conference that had as its theme “CIA — The Not So Secret Service.” All presenters were to incorporate a spy story or approach within their presentations to support the theme. My topic — an introduction to business process mapping — was by request so I welcomed a little extra inspiration to heighten my own interest.

While most people went the route of James Bond or Jason Bourne or the like, I was drawn to a favorite, little-known 1997 movie “The Man Who Knew Too Little.” In this movie, the lead character, Wallace Ritchie (played by Bill Murray), flies to England to spend his birthday with his brother James. James, however, has a business engagement is not too keen to have his brother involved with it. Instead, he signs Wallace up to participate in the “Theatre of Life,” a role-playing exercise that promises to treat the participant as a character in a crime drama.

Things go off the rails early when Wallace answers a phone call intended for a hit man, and he is mistaken for a real spy. Wallace becomes tangled up in a plot to kill Russian and British dignitaries on the eve of the signing of an important peace agreement between the nations. For Wallace it’s all an elaborate act; to the men who want a second World Cold War, Wallace is public enemy number one.

While I found the film entertaining, I also found it informative in respect to how I conceive of my business analyst dealings. I often feel like a secret agent when embarking on a new project or rather a new stage within the “Theatre of Life.” Walking onto a new stage means coming into contact with a new configuration of players, some of whom have been patrons of that particular theatre for many, many, many years. It means entering an evolving story, one that has characters entering and exiting stage left and right, up, down and center. It is our challenge as business analysts to infiltrate this story, flush out the secrets and motivations of the characters, survey the stage for dangers and allies, and ultimately fulfill our mission.

In a nutshell, we are secret agents.

Literature and cinema have schooled us well that all secret agents are governed by two sets of rules of engagement: those laid out by the boss and those learned on the job. I recently re-watched this movie and found myself yet again inspired by its entertaining and informative applications to my business analyst career. So I decided to start sketching out some of the various rules of engagement I have learned thus far on my secret agent missions. Presented here is a sampling of these rules, as identified in collaboration with this particular movie.

Play the role that fits the situation
There is no law that a business analyst must play the same role in every situation. Thank goodness! One key characteristic that separates good business analysts from great ones is the ability to assess a situation and take on the role required. You are always ‘you,’ but sometimes a little play-acting is necessary to get done what needs to get done.

Wallace: You’ve got a great accent, are you from here?

Wear the appropriate uniform
Pretty simple rule — match your attire to the role and to the situation. If you are working in an environment that is t-shirts and jeans, don’t show up in a suit and tie. And vice versa. You are revealing your status as a secret agent otherwise! Respect the situation and it will respect you.

Lori: Do you think I look silly in this outfit? I could take it off if you like.

Always carry the right tools
You need a solid set of tools for whenever you enter a new stage. Be selective with what you choose to put in your toolbox; you can always pick up other items along the way. I always have a white board pen, a little squeezeable toy and a rotation of three favorite necklaces. These items become my indispensible project assets. The pen lets me draw/write things down almost everywhere (all you need is a glass surface), the toy helps me alleviate frustration and the necklaces, well, just make me feel good.

Wallace: Conveniently found a mallet outside but I’m gonna swap it for this one, ok?

Never give up on you
Being a business analyst is hard, dirty, exhausting work. Don’t try to tell me anything different; I know of what I speak. Expect some bruises, some scarring on your missions. But don’t just give up when things get tough. Giving up on yourself is to allow external forces to become more powerful than your own will. Draw on your strengths even more readily to push through the negative, and remain confident that you can achieve success no matter the obstacles being faced.

Wallace: Hang on Bill, clench your buttocks.

Stand by your principles
Adapt to the situation but do not adopt it. Be authentic. Do what is right and not what you are told is right. Comprising your principles is akin to sacrificing your arm. You risk the quality level of your produced work and of not being seen as standing for anything.

Wallace: And I want a stairmaster, I want a juice master, I want a thigh master, and I want a butt master. And if you can’t give it to me, then I’m going back to Des Moines.

Don’t get boxed in
Believe it or not, you are paid to be creative, to think outside the box, to even blow up the box if need be! Being analytical does not mean following every prescribed rule or template out there. It means learning from these entities and assessing how best to apply them to the box so that you can do your absolute best. There may not be an ideal solution for any given situation; you need to be innovative and individualistic and creative enough to when/where/how to deploy your skills to the greatest effect.

Wallace: It’s for allergies — actually, it’s a powerful agent that sharpens my senses, yet deadens my emotions.

Know what works
Textbooks, training courses, templates, etc., are great starting points when embarking on a new mission, but that is all they are: starting points. Don’t be brainwashed into believing that there is a single right way of doing anything or that the same approach is applicable to every situation. Wrong! Learn the methodology and methods but always assess each unique situation to determine what will work and won’t work.

Wallace: They pay all your expenses, you’re licensed to kill, but there’s a downside. Torture.

Take the shot
You will encounter people who throw roadblocks your way occasionally; accept this. But if the roadblocks are not constructive or serve to satisfy individual agendas or hamper your work in any way, be direct as to the potential damage the blocks may be inflicting on the project. Be as polite as possible, but don’t be afraid to exercise some strategic confrontation in order to set up the tactical shots.

Wallace: Yo matey, you just stabbed me with your pen.

Question those in charge
In theory, a business analyst needs to question everyone and everything. What often happens though is that access to the higher end of reporting channels is blocked from your reach. Don’t accept this if you know or even suspect that the answers you seek are behind that block. You need to get at agendas and biases earlier rather than later. Continuously seek more answers for your questions rather than settle for the ones received.

Wallace: Time out. Uh, I hate to break out of character, but, you cannot shout into a person’s ear. It does damage. The spitting I don’t mind…

Team does so have an “I”
Yes, yes it does. Being on a team does not negate your individuality, nor does expressing your individuality within a team equate to being an egoist. You still need to look after you; it is just that now you need to figure out a way to translate that need constructively into the team narrative. You have uniqueness, a distinctiveness that should not be stripped or hidden away in the name of achieving a false ideal of what it means to be part of a “team.” It should be privileged, maybe even exploited a little.

Wallace: Well what about our story? Are we just a doomed couple, do we have to be Bonnie and Clyde? Can it be like The Getaway, couldn’t it be like that?

Have a signature drink
Or dessert. I much prefer the idea of a signature dessert.

Now your turn: what secret agent rules have you discovered through your missions?

Don’t forget to leave your comments HERE.
—————————————————————————

Teri A McIntyre, MA, CBAP, is a principal at Charann Consulting, providing business analysis and project management services to public and private industry. She is a Libra/Tiger, which scares and pleases her and her clients simultaneously. She adores analytical work and getting in front of the clients but rebels against putting a pre-conceived box around how such activities should be completed. Personal philosophy: “Why should a painter paint if he is not transformed by his own painting? – Michel Foucault

Posted in Business Analysis | Comments Off

Common Mistakes Made By Business Analysts Playing the Role of Facilitator

July 26th, 2011

Taken from http://www.batimes.com/articles/common-mistakes-made-by-business-analysts-playing-the-role-of-facilitator.html.

Written by Steve Blash

In Agile projects, the business analyst can elicit the business requirements more effectively by facilitating the meeting rather than interviewing stakeholders individually. Here are some of the common problems that a BA can encounter.

Problems in the Meeting
Failure to Relate to Participants: This is the most commonly mistake made by the facilitator and is usually caused when the facilitator has not prepared for the meeting by reviewing the background of the participants and categorizing them. Each participant has a different background and different characteristics. The facilitator cannot treat the participants the same or as a generic person.

Failure to focus on the Meeting Content: When too much information is being exchanged during the dialogue of the group, it becomes difficult to direct the participants to focus on the key point of the discussion. The facilitator must identify key words for each point as a summary of the content to help visualize the discussion. If this is not done the team may become frustrated, especially if the discussion is going around and around resulting in a state of confusion. The facilitator must identify each point, capture it, organize it, synthesize it and clearly document it. People expect the meeting process to be well managed and these steps will help meet that expectation.

Failure to Use Group Memory: People can only tolerate so much pure discussion without having something written down. If the facilitator encourages discussion and listening without writing anything down, participants may begin to feel that this is a just an informal discussion. Facilitators must create or reference visual memory at least every fifteen minutes. As the meeting proceeds, the amount of written documentation will continue to grow. It is also important to make use of any support materials before, during or after the meeting. Remember that written words, and diagrams, are more memorable than spoken words.

Problems with Participants
There may be minor problems with some of the participants during a session. However, there may be some serious problems with an individual participant that can impact the entire team. So let me explain what I have encountered.

Blue-Sky: Blue-Sky participants are progressive and optimistic people who believe they can accomplish complex tasks. They tend to view their objective as part of the group as a mission to seek out new information, to discover new ways of doing business and to venture where no other team has ventured before. This type of person wants to take on as much as possible, to change as much as possible and to totally re?engineer the business often using new and advanced technology. The problem is that the organization may not be ready for such drastic changes. The intent of this type of participants is good but the facilitator must rein in this person by directing questions to all of the other participants. The facilitator should determine if the ideas in the discussion are realistic and achievable within the boundaries and the budget of the project scope. The facilitator should involve the team in determining the direction of the conversation rather than trying to cut off the discussion point.

Snowball: This type of participants likes to continually add one more item to the discussion. They usually say, “While we are doing that, let’s also do this…” The difference between a blue sky and a snow ball participant is that the blue sky participant will talk about doing everything at once, while the snow ball participant adds one thing at a time. This technique can add quite a bit to the discussion points over the course of the meeting. The facilitator needs to recognize that the added item identified in this manner is not directly part of the effort. The facilitator should validate with the group if the discussion point is within the team’s scope and a part of the team’s objectives.

Wanderers: This type of participant likes to meander during their discussion point or talk about something that is not related to the topic nor follows the dialogue that was in progress. Wanderers enjoy tangents and digressions. They tend to begin to speak before they have thought out their ideas. The facilitator must stop the wanderer before too much time has been wasted and/or as soon as the facilitator recognizes that the discussion point is not relevant to the topic. The facilitator should consider if it is a digression or not in order to get back to the topic. Often these points can be put on a “parking lot” to stop the discussion and return to the points at hand.

Philosophers: This type of participant likes to inject academics into each discussion topic. This person’s language skills are advanced and often speak using a large vocabulary of difficult and often unrecognizable words. Participants who are more practical will find it difficult to work with the philosopher. The facilitator will need to rephrase, or summarize, what the philosopher has said in order for all the participants to comprehend the discussion point. The facilitator needs to verify with the group if the ideas expressed in the discussion point are practical and feasible for the organization. The facilitator must not allow the philosopher to carry?on without the idea being documented in the group memory.

Conversers: These participants are usually more social and tend to seek out other participants who share the same characteristics. Most of the ideas they express are not related directly to the topic, although it may appear that way as they begin their discussion. They are similar to the wanderer, who also like tangents and digressions. However, they are not as far off from the topics as the wanderers are. The facilitator needs to listen to the converser’s idea, assess if it relates to the topic and limit that person’s time to speak. The facilitator should determine their ideas are a part of the topic or relate to something else. The facilitator must monitor this person’s contributions more closely than others in order to keep the other participants from becoming frustrated with what appears to be unnecessary and time wasting discussions.

Devil’s Advocates: This person is always negative when expressing their ideas. They tend to state that things will never work, that things can’t be done or that the technology is too complex. These pessimistic people can become a real downer to the other participants because they will be viewed as being against the rest of the team. The facilitator must request that this person keeps an open mind to the ideas that are expressed and only when there is a negative aspect that others haven’t identified, should they point this aspect out. This type of person can become very harmful to the overall team’s motivation. Too much negativism can turn the meeting process into a frustrating experience for all participants.

Followers: These people like to follow the lead of the others, especially others from their own department. They always align themselves with their manager or an influential person in the group. They are always in agreement with that person and are reluctant to express their personal view. This may be due to previous experiences when having been in meetings with their manager or this influential person. The facilitator needs to recognize that this person is continually repeating what others have said and should try to ask a specific question that will enable them to express what they really feel about the topic. The facilitator may need to stand between the follower and his/her manager to block his/her view.

Don’t forget to leave your comments HERE.
—————————————————————————
Steve Blash is an experienced IT professional consultant providing business and technology leadership, mentoring and vision. His areas of experience include business process improvement, business analysis, business intelligence, data analytics, project and IT management.

Posted in Agile, Business Analysis, Requirements Gathering | Comments Off

Three Ways to Make Requirements-Gathering More Effective

May 27th, 2011

(Taken from the Analysts Anonymous April publication http://www.certes.co.uk/aa-april-main)

Written by Judy Rees

Are your requirements-gathering interviews and workshops a pleasure, or a form of torture? When you make the process enjoyable for participants it becomes more effective – as well as making you more popular!

It has long been recognised that one of the leading causes of project failure is having poorly-defined requirements. Remember the old “project cartoon” with the different versions of a tree swing? The problem is still very much with us. up to you, as the analyst, to discover what they really want and how it will benefit the business. Do it well, and the users/customers will be delighted to be learning something they didn’t know they knew.

Here are three ideas which have worked well in many contexts. One analyst even claims they saved a €34.8m project from disaster, when they helped him discover that the two national banks driving the project had differing understandings of a key requirement
Systems keep on being delivered which just don’t do quite what the business needs them to do: the “real” requirement has been missed somewhere along the line.
It’s all about effective communication.

The most experienced and sought-after business analysts have highly-developed consulting skills, as well as technical domain knowledge. Employers increasingly recognise, and hire for, this kind of skill. And yet many analysts have not been taught interviewing and facilitation to even a basic level – these skills are supposed to be picked up along the way.

So, how can you improve your own approach?
It begins with your own attitude. Even if requirements capture may be seen as a relatively junior task in your organisation, the truth is that it’s absolutely crucial that it’s done well. It’s your job to capture the stakeholders’ interest and enthusiasm, and to keep them engaged in the process. If they experience the process as a grilling, in which they are made to feel inadequate by questions they can’t answer wrapped in layers of jargon, they aren’t going to enjoy it.

Don’t expect people to be able to describe, off the top of their head, exactly what they want or how it drives business value. People just aren’t made that way. It’s

1. Make sure you set a positive tone from the start. Plan a clear agenda with adequate comfort breaks – not everyone is used to concentrating hard for long periods
If you have any control over the environment, use it wisely. Research has shown that most people do their most effective “big picture” thinking in high-ceilinged spaces or outdoors, while they focus more effectively on details when they are in a small, low-ceilinged space. Hot drinks will help people feel “warm” towards you.
As the organiser, explain clearly what your expectations of the meeting are – don’t expect people to have read the paperwork! You might consider asking each person present to say what they want from the meeting too. The answers are often very revealing – but more to the point, the process helps people to feel that their desires are at least being acknowledged and considered.

2. Be genuinely curious about what the stakeholders have to say, and how they say it. This project may initially seem just like the last one you worked on – but the people are different, and so the project will be different. Listen to the words they use to describe things.

Language is a wonderfully flexible tool: it’s as if everyone thinks they’re like Humpty Dumpty, and can use words to mean whatever they choose them to mean! For example, if you ask two people to think of a tree, then check the details of the tree they thought of, you’ll discover that no two people’s trees are ever exactly the same. It’s not that one is right and one is wrong – it’s just that they are different. The more novel or complex the topic, the greater the scope for differences of meaning – even when you think terms have been carefully defined in a written project glossary.
If someone says something which surprises you, investigate with a question or two. It’s possible you misheard – but it’s also possible that you’ve just detected an important detail that might otherwise have been missed.

3. Use your participants’ language, jargon and metaphors throughout. You are probably well aware of the effect of unfamiliar technical jargon – it leaves people baffled, their eyes glazed over. The effect of paraphrasing is less well-known.
People’s own words are important to them: they capture unique shades of meaning. If you paraphrase, the original speaker may feel you have misunderstood
Two great questions to ask are:
• What kind of X (is that X)?
• Is there anything else about X?
»»Where the “X” represents one or more of the words they have used.
These questions are great for getting clarity about anything that’s been said. They don’t reveal your own opinion of what’s been said, so that the person doesn’t feel judged or criticised. And if necessary, they can conceal the fact you have no idea what the person is talking about!

Human communication is a vast subject, and I could go on with dozens more ideas. But I’m confident that using just these three tips will make a difference to the results you achieve, immediately.

Author, trainer and consultant Judy Rees is a former news journalist who became an expert in human communications and in particular, the questioning and listening technique Clean Language. She is the co-author (with Wendy Sullivan) of the category bestseller Clean Language: Revealing Metaphors and Opening Minds. She and her company X-Ray Listening (xraylistening.com) are based in Brentford, West London.

Posted in Business Analysis, Requirements Gathering | Comments Off

Reduce Churn: Restate Constraints, Assumptions & Dependencies

April 30th, 2010

Taken from the IIBA® Quick Tips for Better Business Analysis

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.

Posted in Business Analysis | Comments Off

Building Valuable Process Maps Takes Skill and Time

August 10th, 2009

Reproduced from http://www.isixsigma.com/library/content/c090810a.asp

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.

Posted in Business Process Management (BPM), Process Improvement | Comments Off

Teamwork and Creativity Help to Identify Root Causes

May 12th, 2009

Re-Produced from
http://www.realinnovation.com/content/c090511a.asp 

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

Posted in Root Cause Analysis, Uncategorized | Comments Off

Six Sigma Aids in IT Employee Resource Planning

May 7th, 2009

By Celia B. Banks, Ph.D. 

Reproduced from http://software.isixsigma.com/library/content/c090506b.asp  

Effective resource planning is an important part of any process improvement program. Formalizing processes and developing measurement systems helps to determine the value of internal projects from a human capital perspective. A measurement system for effective resource planning in implementing project goals may be particularly helpful for information technology (IT) divisions of companies.Developing a Measurement System 

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

In evaluating project resourcing planning, the earned value management model can be used in defining CTQ variables. In order to evaluate performance, practitioners can use a general variance model, in which the actual resource cost is compared to the standard budget for a given project, to examine the cost of a resource in terms of hourly amount, hours utilized and scheduling. When actual utilization in terms of cost and scheduling exceeds the standard budget, it is deemed unfavorable.

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

Table 1: Example of CTQ Requirements
Requirement Variable Defect Threshold
Set up server hardware Resource skill Hardware malfunctions due to incorrect setup four times
Install and configure Oracle on server Resource skill in specialty area Incorrect settings in system global area four times
Post go-live application support Resource training relevant to skill Incorrectly diagnose problem as user training issue when in actuality it is an application bug three times

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.

Table 2: Sample CTQ Measurement
Define Measure Analyze Improve Control
CTQ: The customer will tolerate up to four hardware malfunctions due to incorrect setup Defects: Hardware malfunctions four times
Units: 196 (47 file servers x 4 setup errors)
Opportunities: 1 per file server
DPMO: 85,100
Process sigma: 2.81		 Two system engineer resources, A and B, are assigned to task: Resource A sets up 23 file servers over a period extending beyond the planned 10 workdays (13 workdays actual). Resource B sets up the remaining 24 file servers under the planned 10 workdays (9 workdays actual). Six file servers that Resource A sets up experience malfunctions due to incorrect setup. Resource A caused a cost and schedule variance and failed to meet CTQ requirements six times.
Defects: Hardware malfunctions six times
Units: 138 (23 file servers x 6 setup errors)
Opportunities: 1 per file server
DPMO: 260,900
Process sigma: 2.14		 Identify opportunities for Resource A to improve server set up ability through training or journeying.

 

Quantifying COPQ in Resource Planning Processes

There are many causes that affect COPQ: demand constraints, labor cost to fix problems, cost of lost opportunity, underutilization, loss of sale or revenue, and lower service level to customers. Table 3 describes these causes from a resource planning perspective.

Table 3: Poor Quality Causes in Resource Planning
Poor Quality Cause Description
1 Underutilization of resources is also termed spoilage in Six Sigma. It occurs when there is inconsistence or inefficient processes.
2 Reworking a deliverable due to wrong resources skill applied involves the labor to repqir the defect.
3 Additional resources includes any burden of consumption of resources in order to accommodate an unforseen step in project deliverables.
4 Lost opportunity is the loss in business of a failure. Included are the loss of margin and the capital to be invested for regaining lost revenue to offset the cumulative revenue loss.
5 Lost revenue due to poor quality considers the loss of new business due to defective quality in a deliverable.
6 Poor customer satisfaction is the sum total of all COPQ. Cost is compounded by losses customers suffer due to defective quality in a deliverable.

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
Table 4: Sample COPQ Measurement
Goal: Reduce Customer Dissatisfaction Incidents Due to Resource Related Project Failures by 75
No. Potential Resource Deficiency Risk Priority Number Effort Hours to Resolve Average Cost Per Hour Average Cost to Resolve RPN x ACR
1 Right skilled but underutilized in project task 30 10 $90.00 $900.00 $27,000.00
2 Wrong skill to repair defect 27 40 $48.00 $1,920.00 $51,840.00
3 Added resource due to scope creep 27 56 $240.00 $13,440.00 $362,880.00
4 Loss of business opportunity due to downtime (daily revenue = $10,000) 18 40 $416.67 $16,666.80 $300,002.40
5 Lost revenue due to resource incorrectly working project task 21 10 $4,166.70 $41,667.00 $875,007.00
  Total: 123       $1,616,729.40
Formula 1: Weighted average cost to resolve = (RPN x ACR)/RPN = 1,616,729.40/123 = $13,144.14
Formula 2: COPQ (annualized) = Weigted average cost to resolve x annual reduction in resource related project failures
13,144.14 x 75 = $985,810.50

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

Table 5: Sigma Level, Value, DPMO and Cost of Quality Percentage
Sigma Level Range Value Yield DPMO Cost of Quality Percentage
2 Unfavorable – 298,000 More than 40%
3 Satisfactory 93.3% 66,870 25%-40%
4 Satisfactory 99.8% 6,210 15%-25%
5 Organization excellence 99.977% 233 5%-15%
6 Organization excellence 99.99966% 3.4 Less than 1%

 

Control System Benefits

A performance measurement system enables management to plan and make decisions. The approach identified here provides a control system that aligns practical standards against ideal, or perfect, conditions. Standardization provides performance baselines for control efforts in budgeting and planning of resource allocation. From here, practitioners can devise a simple formula that compares actual costs in resource allocation against the baselines. Variances should be noted to determine the extent of favorable and unfavorable outcomes. The data used to derive costs can be maintained in the project management application for creating reports and scorecards.

About the Author: Celia B. Banks, Ph.D., is a certified Black Belt. As a management consultant, she defines project management office (PMO) processes and standards for governance in information technology and aligns best practices with Six Sigma metrics. She can be reached at celia@cyberneteks.com.

 

Tags:
Posted in Process Improvement | Comments Off

Lean Services: Doing Transactions Right the First Time

April 21st, 2009

The source of this article is http://www.isixsigma.com/library/content/c090406a.asp 

Written by Sharad Sharma

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

Tags: , , ,
Posted in Process Improvement | Comments Off

Why would I Want to Use Consultants?

March 5th, 2009

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.

Image from book

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
Image from book


Expertise

  • ‘We’re able to tap into skills and knowledge outside the competence of our own staff.’

  • ‘Because they are specialists in their field they focus directly on the work. That means they get results more efficiently than we could ourselves.’

  • ‘We faced a difficult business situation we hadn’t met before, and were unsure what to do. But it was something our management consultants had seen in a lot of other firms, and they knew the pros and cons of different approaches. We had the benefit of their broad experience.’

  • ‘In restructuring the firm, we had tried to sort things out for ourselves, but seemed to get nowhere. They saw we had been asking the wrong questions, and helped us get to the root of the problem. In the end we did find our own solution, but it was with their help.’

  • ‘We knew the business had to change, and we saw where we wanted to go; but we didn’t know the best way to get there.’

  • ‘The risks of making the wrong decisions about equipment and supplies were so enormous, we had to get informed advice from experts.’

  • ‘We had become set in our ways and needed a new vision to get us moving. The consultants played a key role in facilitating changes in our thinking and motivating our team.’

  • ‘They gave us an awareness of best practice across the computer industry. We were able to stop wasting time inventing wheels that had already been designed elsewhere.’

  • ‘Working alongside our people, they can help sharpen up our skills in specialist areas. There is a definite transfer of knowledge that takes place, and this is one way they add value to our business.’

  • ‘What we get are ideas we might not have thought of ourselves. I suppose you could call it lateral thinking or thinking out of the square or just creativity. They’re often ideas that can help us cut costs and bring in new income, ideas that hopefully will build up our business advantage.’

  • ‘Technologies move fast in the renewable energy sector. Our consultants keep us up to speed with new processes and new areas of development.’

  • ‘To meet the requirements of our own clients, we needed to have quality accreditation. Specialist consultants guided us successfully through the procedure.’

  • ‘Putting in planning applications, lodging appeals and acting for us in planning inquiries–these are areas where we need expert advice.’

  • ‘We needed to obtain an environmental resource consent at an early stage in a development project. We were not sure what information we would have to provide, but our environmental consultants had been through the process many times before and they helped us submit a successful application.’

  • ‘We were impressed by the range of market research data the consultants had available. We would otherwise not have had access to that information.’

Independent viewpoint

  • ‘Sometimes we’re too close to a problem to see it in its true perspective, and we miss points that are obvious to everyone else. Consultants can help us think situations through and challenge the way we go about things. Looking in from outside, they can identify what we need to do to improve our business performance and service delivery.’

  • ‘They can take a more objective and impartial view of a situation than we can. They don’t bring with them any baggage of management self-interest.’

  • ‘Our relocation plans at times involve contentious issues and feelings run high. By using consultants we can obtain a neutral and dispassionate analysis of the options.’

  • ‘There is a valuable role that consultants can play in acting as a bridge between different and perhaps conflicting interests, a line of communication that doesn’t wear the label of one side or the other. People will speak more openly to them than they would to us.’

  • ‘Investors are unlikely to fund a project unless it has had its feasibility checked independently. So a consultant‘s judgement that a project can deliver an adequate return is an essential form of technical collateral.’

  • ‘Apart from due diligence concerns, our work on pension and investment schemes has to involve independent advisers: it’s a legal requirement.’

Resources

  • ‘Because of recent cuts, the pressures on our remaining staff have become particularly intense. We are so fully stretched on day-today work, we really cannot respond to sudden demands or unexpected problems. That is where consultants come in: they keep our workload afloat.’

  • ‘They free up our management to focus on strategic questions.’

  • ‘We have sometimes brought in consultants to fill management positions when things are too urgent to go through a recruitment process.’

  • ‘It is management policy: if an activity is not thought central to our operations it has to be outsourced.’

  • ‘I’m responsible for so much, I am just not able to focus full time on a single project at the cost of everything else. It makes better sense to call in consultants who can give it proper attention.’

  • ‘It is more cost-effective to use a consultant for work that is short-term, specialized and occasional than to keep an expert on the payroll.’

  • ‘We save money by using consultants. They will generally work for less, especially if their contract offers continuity, and we’re not saddled with the benefit costs of employees.’

Tags:
Posted in Uncategorized | Comments Off

Requirements Gathering

July 31st, 2008

(Taken from http://www.ericsink.com/articles/Requirements.html)

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.

Tags:
Posted in Requirements Gathering | Comments Off

« Older Entries