The Top 10 BA Skills for 2012

Posted on by

Taken from http://www.batimes.com/angela-wick/the-top-10-ba-skills-for-2012.html

Written by Angela Wick

I like to think of the BA role as a broker of information, getting big picture and details from many different people, groups, executives, subject matter experts, vendors, technical resources, etc . . . what the BA does with all this information and how it gets communicated and repurposed for each audience is opportunity for a BA.

Today’s trends are pointing towards the following themes for BAs:
- Business Agility
- Innovation
- Engagement of stakeholders to drive agility and innovation

The needed skills to meet these trends in 2012:

1) Conceptual Modeling Skills
Engage your stakeholders with more meaningful dialog!  Conceptual Modeling of the business view of the solution has always been a critical tool to help bring business, technology, and delivery groups together in defining solution scope.  I have had many BAs tell me that they do this and show me their conceptual models.  What I find when reviewing the models is more of a technical architecture or data context diagrams.  Technical architecture and data context diagrams have their place, but the critical skill I am seeing as a gap in BA skill sets is the business view (vs. technical view) of the solution scope, this will be critical to engaging stakeholders and setting the stage for innovation

2) Communicating Details and Concepts
Similar to the conceptual modeling skills is communicating various levels of detail appropriate to the audience.  This can be especially difficult when you have various stakeholder needs on the team or in the meeting, and many times multiple views is needed to ensure the right message is communicated to all audience needs.  Where I see the gap today is details are not organized to be digestible and understandable to many audiences and there may be a lack of conceptual and context to accompany the details.  Without the concept and context information, the details - even when well organized - may not be understood or thought of in with the frame of mind that the BA needs from the stakeholders.  Rethink requirements packaging, does the same document need to go out to everyone?  Or, can each audience be given a guide as to which pages/sections are most pertinent to them?  Just a few ideas to help stakeholders consume what is important to them.

3) Curiosity
How curious are you as a BA?  This has always been a critical skill for BAs.   Ensuring curiosity in finding the root cause of the problem or opportunity, getting the  right audience, usage, context, purpose for requirements requires a strong level of curiosity in BA work.  Curiosity will go far in 2012 for BAs wanting to build competency and skills in the world of mobile apps, cloud computing, and continuing agile trends.  Curiosity will make some of the unknowns of today easier to work within, a curious mindset will take BAs into communicating the unknown and help organizations innovate.

4) Decomposing the Abstract into Details
I have to call this out separately from Conceptual Modeling and Communicating Details and Concepts.  The same themes are in play, but yet executed a bit differently and in different scenarios.  Decomposing the abstract into details is also referred to as ”critical thinking” and sometimes “system thinking”; taking something large, ambiguous, and abstract and breaking into smaller pieces, patterns, and views.  It is about helping others see the details and big picture from different perspectives, helping stakeholders with varying points of view and priorities see where their details and others fit into the bigger picture.  It will also help BAs better estimate and work with PMs on the status and risk of requirements.

5) Mentoring and Coaching
As the BA role becomes increasingly more valued in organizations, two things will happen:  1) Organizations will need a career path for Sr. BAs, and 2) Organizations will need to develop internal strategies to develop more talent in the BA role and Sr. level skill set.  Mentoring and coaching skills are key for Sr. BAs in both of these strategies.  Mentoring and coaching done by Sr. BAs will develop leadership competencies in the Sr. BAs while developing BA competencies in new or more inexperienced BAs in the organization.  Sr. BAs who have the opportunity to mentor and coach will develop further leadership competencies needed to elevate the competencies of the BA team as a whole.

6) Communicating Risks
Project Managers focus on risks to the project budget, schedule and scope.  A BA needs to focus on risks to the business value of the solution and communicating the risk.  BAs are in a prime position to see the details and big picture view; this includes seeing the risks to the project, delivering a solution that does not maximize business value.  I find that BAs have an intuitive sense of this, but often struggle to communicate the risk in a way that gets leadership attention.  In order to get leadership attention to the business value at risk, BAs will need to develop skills in communicating the true business impact of the risk.  This means going beyond communicating in terms of the features and functionalities of the process or software, and going beyond that, there is not enough time for requirements to be done right. It means communicating the impact it will have on the business operation or strategy.  For example, when the functionality of a point of sale application has a requirements conflict in the process of accepting payment from customers, the focus needs to turn to the impact of the conflict on the customer service representative’s ability to serve the customers and the customer experience vs. the technical details at risk of the requirement.  In the heat of requirements and design details, we often let the details drive risk discussions and never get to the bottom line impacts that can really propel leaders to make the right decisions.

7) Leveraging the “parking lot”
Are you running your meetings or are meetings and stakeholders running you?  Many BAs get into tough situations in requirements meetings and feel that other agendas and personalities are driving their meetings astray.  Using a “parking lot” (simple visual list of items that do not fit into the meeting agenda to be followed up on or scheduled into another meeting) to manage and control the meeting agenda, content, level of detail and difficult personalities is a key strategy.  Most importantly, make sure that the parking lot is visible to everyone in the meeting.  Having the parking lot in your notebook or on your laptop does not show others that you have their ideas and concerns captured to discuss at a later time.  Be empowered to take control of your meetings!

8. Change Management
Embracing the BA role as an agent of change will continue to show the value the organization the value the BA role brings to the organization. Projects are about business change; the BA role is about bringing the most value possible in a solution to address the business change.  The role of a change agent in the BA is critical to ensuring all impacted parties are ready for the changes needed to accept the solution.  Understanding how changes and solutions impact the stakeholders operations, processes, attitudes and behaviors is a key skill in maximizing the success of the new solution and the business value it brings.

9) Asking WHY?
I love the word “Why”, but hate to use it.  My challenge to readers of this blog is to help one another find ways to ask “Why”.  Many times using the word “Why” can come across wrong to the other person, it can seem defensive and the other may wonder why (no pun intended) you are asking.  Finding different ways to ask “why” can alleviate this dilemma.  My favorite ways to ask “Why?”:  Tell me more about what is behind the need for abc?  What does success look like?  What would happen if this project does not get implemented? What are yours?

10) Impromptu Whiteboard Drawing
In 2012 when innovation, agility, and engagement are the trends, being able to spontaneously draw will lead to stakeholders to a deeper level of engagement.  Getting up to draw shakes up the flow of boring meetings, engages others to focus back in on the discussion, and brings out humor - let humor be a friend. You don’t have to be an artist to draw concepts on whiteboards that generate great dialog, discussion, creativity and innovation.  It also does not have to be you that does the drawing; ask someone else to draw what they are thinking and your meeting will benefit in many of the same ways.  When the drawing yields powerful and meaningful discussion, be sure someone takes a picture with their phone.

No matter that type of BA, no matter what the industry, these skills in 2012 will set your projects up for deeper engagement, innovation and agility.

The Kaizen Business Analyst

Posted on by

Taken from http://www.batimes.com/articles/the-kaizen-business-analyst.html

Written by JARETT HAILES

As Business Analysts, we are often focused on helping our stakeholders improve their processes and operations. We have worked to understand their current state, identify requirements, and engage others to help deliver innovative solutions that set up our customers for success. Most Business Analysts I’ve met get a great deal of satisfaction in finding ways to help people or companies do their jobs more effectively. Sometimes we become so outwardly focused that it can be easy to forget that it is important to take the time to work on improving our own processes. By finding ways to make our own practices better, we can increase the value we deliver to our organizations and stakeholders.

When looking to improve ourselves professionally, we can identify and try to implement changes big and small. Big, sweeping changes are often the most difficult to achieve, regardless of whether you are a 10,000-person organization or a single individual. Big changes are met with fear, doubt, inertia, laziness, and many other barriers. Our initial enthusiasm can dwindle if we don’t start to see immediate results, and in the end we consciously or unconsciously decide to abandon the change. This is why so many of us fail our New Year’s resolutions; often they are big visionary statements that involve a large amount of change.

Instead of trying to make big changes, we can focus on implementing a personal development process that allows us to improve our services continually with small but meaningful changes. The Japanese term Kaizen means ‘continuous improvement,’ and methodologies have been developed to implement Kaizen in small, incremental, and purposeful steps to yield dramatic changes over time. Kaizen has been used in lean manufacturing methods at companies such as Toyota, Intel, and Lockheed Martin. While this methodology has been used mainly in manufacturing, it is focused on helping individuals and small teams become as efficient and effective as possible at the job they do.

Some of the main principles of a Kaizen approach to continuous improvement are:

  • Think of ways to make something happen, as opposed to reasons why something can’t be done.
  • Do not seek perfection; start change right away and build on that change over time.
  • When something doesn’t work as expected, take the time to understand the root causes of why things went wrong.
  • When faced with hardship, take the wisdom gained and look to apply it to your next task.
  • Measure your successes and failures so you can actually tell if you are improving.
  • This approach not only works for teams, but also for individuals. We can use the principles of Kaizen to ensure that we are always finding ways to make our work better, which in turn improves the lives of our customers.

Here are some steps to becoming a Kaizen Business Analyst:

  • Develop your mindset: when you first arrive at work, take 30 seconds to remind yourself that today is an opportunity to find ways to do your work better. Review what you will be doing today and your plan to get things done.
  • Document your performance: while you are working, take the time to quickly jot down how long things take you to get done. For tasks that are part of a bigger multi-day goal (for example, having requirements reviewed), build a very simple spreadsheet or leverage your organization’s timesheet to track your total time on an activity. Aside from time spent on a task, find other relevant measures given the type of work you do; for example, how many rounds of review are required prior to requirements being signed off? Think of the relevant performance measures for your analysis activities and track them over time.
  • Reflect on your activities: at the end of the day, take a quick review of the work you did and reflect on what went well and what didn’t go as ideal. Make some quick notes and associate them with the relevant tasks they belong to. For areas that didn’t go as well, write down one to two things that could have been done differently that would have improved the outcome. Take a look at your tasks for the next day, and with your history of ideas for improvement in hand, identify what you will try differently tomorrow. If you have identified ways that you could improve but need outside assistance to make them happen, plan who you will connect with to help get the ball rolling on implementing those changes.
  • Experiment with new ideas: find interesting things that you think will help improve the quality or efficiency of your work and try them out. Whether it’s a new elicitation technique, a new conflict resolution approach for those two stakeholders who don’t get along, or a simplified model for your complicated business processes that you can share with executives, find an opportunity to test out your ideas. Make sure you record the results and compare them, both in terms of time spent and whether the desired outcome occurred.
  • Share with others: this gives you a chance to contribute to the development of other Business Analysts while learning new ways to improve yourself. If you have a Community of Practice or a Centre of Excellence at your organization, there are usually opportunities for such collaboration. If your organization does not have such groups, start meeting with your peers informally; I’ve found BAs often like to talk shop and swap ideas over lunch every week or two. If you are the lone Business Analyst at your organization, find a local IIBA chapter or other Business Analyst community in your area to meet with colleagues. Various online Business Analyst communities have active forums that give you a chance to learn and share as well.

Having big goals can be an incredible motivator to help us achieve our potential and become successful. Sometimes it can be so easy to visualize what we want to accomplish that we attempt to make huge changes in order to reach our goal as fast as possible. However, as an old Chinese proverb reminds us, “It is better to take many small steps in the right direction than to make a great leap forward only to stumble backward.” Having a Kaizen approach to becoming a better Business Analyst gives us an opportunity to make small but purposeful changes each day that will make us key to our organization’s success and future.

Let’s Pretend We’re Secret Agents

Posted on by

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

Common Mistakes Made By Business Analysts Playing the Role of Facilitator

Posted on by

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.

Three Ways to Make Requirements-Gathering More Effective

Posted on by

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

Reduce Churn: Restate Constraints, Assumptions & Dependencies

Posted on by

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.

Building Valuable Process Maps Takes Skill and Time

Posted on by

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.

Teamwork and Creativity Help to Identify Root Causes

Posted on by

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

Six Sigma Aids in IT Employee Resource Planning

Posted on by

By Celia B. Banks, Ph.D. 

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.

 

Lean Services: Doing Transactions Right the First Time

Posted on by

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