Taken from the Business Analyst Times (http://www.batimes.com/articles/seven-common-mistakes-with-the-daily-stand-up-meeting.html)
Written by Greg Smith
The daily stand-up meeting, also known as the daily scrum, may be the best of all of the agile practices. Why? Because it meets three criteria:
1. It’s easy to start using
2. It can often be used without other agile practices
3. It provides great value
Stand-ups can be interjected into waterfall teams and they can be used without converting to iterations or other common agile practices. From an adoption perspective, the resistance to using stand-ups is low. From a value perspective, teams quickly see the how the stand-up identifies risks and issues early. The stand-up gives them more time to react and still hit their goals.
As good as the stand-up meeting is, if done incorrectly it can do more harm than good. As an agile coach I have found I often skimp on stand-up training because it seems so simple. But this skimping has come back to bite me several times. How have I been bitten? By the seven common stand-up mistakes below.
Mistake # 1 – Not Standing (the daily sit down)
Teams usually stand when they first start doing the daily stand-up because they have just came out of agile training and they were taught to stand. But as time progresses it is common for some teams to assume standing is a formality and they start sitting more and more. This especially common if the meeting is in a conference room where chairs are available.
Standing is not a formality but rather a key success factor in establishing collaboration and keeping the meeting short and effective. How can you keep the team standing? Here are some tips that usually help:
Try to do the stand-up where chairs are not available.
Keep the team focused on the three key questions: What did you do since we last met? What will you do between now and the next meeting? Do you have any blockers or constraints that are impeding your progress? It is common for team members to explain their impediments in detail, and for a dialogue to start up between a few team members on how to resolve the impediment. This is fine if a solution is agreed to in a few seconds, but usually this a long conversation that ties up the whole team when only a few team members are needed. So as a Scrum Master, coach, or team member, get select team members to work impediments together after the stand-up.
Use a physical status wall (covered in mistake # 5 below).
Mistake # 2 – Team Members Not Showing Up On Time
Many teams struggle with team members drifting into the stand-up, often 5 to 10 minutes late. This contributes to the issue noted above, not standing, but also demonstrates a lack of personal discipline. Here are some tips for addressing the late arrival issue.
Pick a time of day that the team all agrees to, to have the stand-up. Sometimes management will ask the Scrum Master to have the team meet at a certain time, but I have found it is better to meet when everyone has arrived at work, and at a time the team all agrees to.
Get support from line managers. Agile is about team self-management and self-discipline, but everyone does not arrive at this state at the same time. If you are a Scrum Master, work with all of the managers who team members work for, and get agreement that the daily stand-up is important, and that punctuality is important. Line managers can emphasize these values when they do one on ones with their team members.
Provide a buffer between meetings that occur before the stand-up. If there is another meeting that precedes the stand-up, make sure the stand-up is not scheduled when the other meeting ends. Instead add a buffer of 10 to 15 minutes so that the stand-up is not impacted by any upstream meetings that runs over.
Mistake # 3 – Allowing Distractions
Daily stand-ups are ineffective if the team is not focused during the stand-up. Here are some tips for keeping the focus:
Location, location, location. If you do your standup meeting in the wrong location the team will get interrupted by passers by, or be distracted by eye candy such as the street below. Pick a location without chairs, some level of isolation, and if possible no windows.
Set a team norm of no cell phones or laptops during the standup.
Focus on good meeting etiquette – no side conversations or whispering.
Mistake # 4 – Updating the Project Management Tool During the Stand-up
Are you using an online tool to track project status? Maybe Mingle, Rally, or VersionOne? Many times the team will stand idle while someone is updating the tool during the stand-up. Try to avoid this at all costs. Have someone take hard copy notes and update the tool later, or even better, use a physical status board and have team members physically update their tasks during the daily stand-up. Remember that the tool serves the team, the team does not serve the tool.
Mistake # 5 – Not Using a Physical Status Wall
I love electronic project management tools. They let me consolidate information and do reports across a portfolio of projects. But the tools can impede collaboration during the daily stand-up. If one person is projecting the virtual status wall from an electronic tool, and discussing it with the team, the team often becomes an audience and just listens. However, if you have a physical wall with task cards, team members move and update their physical cards during or before the stand-up, which leads to much richer discussion and interaction. You can use an electronic tool in parallel (most of my clients do). It may be a little redundant, but the value a physical wall provides offsets maintaining 2 tools. And it will lead to a better stand-up meeting.
Mistake # 6 – Not Having a Dedicated Team Room
You may be wondering why you need a dedicated team room for a stand-up. You do not need a dedicated team room for the stand-up meeting, but you do need one for a good stand-up meeting. Confused? Here is the scoop. If your team is distributed all over your campus, and they come together physically each day for 15 minutes, do you think you can get them to only discuss status? I have not been successful in doing this. Developers and testers will want to get into testing details during the stand-up, user experience wants to talk to developers about screen details, and so on. If you have a dedicated team room, team members can talk about the construction details all day long, and they will not need to deviate from the stand-up status/impediment discussion.
Mistake# 7 – Not Using a Stand-up for Distributed Teams
Most companies I work with have team members in the United States, India, and China. These teams will often tell me they cannot do stand-ups because everyone is in different time zones. I understand this issue but I also understand that we undertake a lot of risk if we do not communicate daily. To get around this issue I have teams do the following:
Do a stand-up meeting at each location. At a minimum get team members synchronized at each site
Have one team member from each team work a staggered schedule. These team members on staggered schedules can do a video call or audio call to synchronize each day, and then take that information back to their local teams.
Use electronic tools to share status details. Electronic tools really show their value with distributed teams. Everyone can see the status information around the world, as soon as it is entered.
Follow these steps and you will establish a sound daily stand-up process, which will provide a great foundation for all of the agile practices you use with your team.
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
- 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.
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.
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.
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
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.
(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.
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)
- 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.
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.
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 email@example.com.
By Michael Ohler
In problem-solving methodologies, identifying potential causes is a crucial step between process mapping and data collection and analysis. It involves the best available process knowledge, as well as creativity. Creativity and team management tools, more often employed for solution finding than for root cause finding, can generate deep understanding of the process mechanics and help the team prepare for the distilling and data-based validation of the “essential few” root causes of a problem.
Problem-solving teams can increase their chances of success by using a consistent methodology for identifying a problem’s origins. Such a methodology must be based on the very nature of root cause analysis. This form of analysis:
- Is a process that needs to be understood from the “bigger picture.”
- Is a team exercise that focuses on people and on meeting facilitation.
- Uses brainstorming to combine best expert knowledge with out-of-the-box thinking.
- Delivers measurable factors and a data-collection plan.
- Uses data to derive potential causes.
In the light of one specific example, it is possible to see how creativity and team management tools can be used to look deeper into the first four elements of root cause analysis. Using data to distill significant causes, both from a statistical and then from a practical point of view, is typically covered in Lean Six Sigma training classes. The example considered here is a delivery process where lead time had recently degraded with respect to customer expectations.
Working Through the Process
After carefully describing their problem, the team started the analysis by mapping out the delivery process. Then they brainstormed for potential causes for variation in lead time. To validate those causes, they collected and analyzed data. At first, only a small share of the total variation could be explained with these factors. The team then further elaborated the process map for the steps estimated most critical and revisited the cause-and-effect analysis to collect data for more potential factors by using the 5 Why’s analysis technique to drill down further.
Preparing the Team
To understand the observed variation in delivery time, the team mapped out the delivery process in greater detail. The team interviewed customers to determine their requirements and the rationale behind those requirements. They also analyzed how the process interfaces with suppliers; for several team members this was the first time they perceived the “big picture” of the process they were working in. Such first victories set the team on track for the next steps.
In preparation for the brainstorming meeting to identify potential causes, the team leader carefully:
- Conveyed a high sense of urgency and made participants feel “pain and pleasure:” Competitors had taken market share in line with their lead in delivery speed. A smooth flow of the process would also free up resources and reduce overtime work. Management actively supported the initiative.
- Secured creative diversity: Included process and business experts and people with different personal styles.
- Made the team curious about “creativity tools” to be used: He also checked with experienced team members to find out which tools might be best suited for the specific team.
- Removed barriers to a free flow of ideas: The facilitator ensured that rules about inter-department finger pointing was clarified offline. He also verified that stakeholders were analyzed and approached accordingly.
Brainstorming Potential Causes
Like any other brainstorming activity, identifying potential influence factors is a team-thinking process. At the beginning of the meeting, management aligned the participants behind the business criticality of the process through a short intervention. The team also agreed on a schedule and ground rules. Then they went through the process map again, printed on an sheet of paper, which served throughout the meeting.
To capture the team’s experience on what might influence delivery time, the facilitator asked participants to write their thoughts on sticky notes and paste these on a flip chart. As people saw their peers’ contributions, they eventually generated new ideas. The walking and talking involved in the brainstorming set a relaxed atmosphere. Even so, after about 20 minutes, the team reached its first dead point, the time in brainstorming sessions when the team momentarily runs out of ideas. To keep the momentum alive, the facilitator decided to use a fishbone diagram. The facilitator asked participants to come to the flipchart and cluster the different potential causes into major groups.
The facilitator steered the team around a common trap that can arise when using fishbone diagrams. The team had started by writing the defect (“Delivery is slow”) at the “head” of the fish. This would have reduced the continuous variable delivery time into pass/fail information. Doing so would also have generated repercussions when capturing potential causes. A statement such as “insufficient headcount causes slow delivery” can lead a team in a different direction than a study of the influence of allocated work hours on delivery time. Thus, the team investigated the primary metric, “delivery time.”
This clarification, as well as clustering the ideas into major groups, helped generate discussions about the relations between different potential factors, which again generated new ideas. Participants also translated their original statements on “roadblocks to success” into “tunable factors,” imagined as “steering wheels to influence delivery speed”
The clustering exercise generated several major groups of factors. The team sensed some of these were underrepresented because they comprised only one or two potential factors. A quick re-brainstorming made these groups more complete. Then, the facilitator used printouts of traditional Ishikawa diagrams, the basis for fishbone diagrams, which helped them realize that price aspects had been overlooked and could now be collected through another round of posted ideas.
The facilitator decided not to have the team rearrange the posted notes into any of the traditional Ishikawa diagrams. This would helped the team consider the collected potential causes from still another angle, revealing other relations between factors, and generating new ideas. However, with the team dynamics that had unfolded, the facilitator sensed such an additional exercise as a drain to people’s creativity. Note that if this rearrangement does take place, the original state should first be documented with a camera.
The facilitator used a dead point to take a short break to prepare a creativity boosting game. These games often kick people out of their thinking box by first kicking them out of their seats. Typically, human resources departments can help in selecting creativity games. Searching the Internet also delivers many leads.
A short wrap-up of the game helped understand what defined the borders of the current thinking box: policies (written and unwritten), experiential boundaries (“At the current maturity of our logistics system, improvements must be the result of major investments”), firm convictions nobody knew the foundation of (“We will only find things we have seen in the past”) and several other limitations to creative thinking. It was the first time the team had seen the boundaries of their own thinking explicitly on a white board. They decided to creatively challenge some of these boundaries to discover new factors, such as “If we had no performance reporting to management, the delivery time might depend a lot on the affinity of the personnel for a given customer.”
Delivering Measurable Factors
The brainstorming resulted in 47 potential influence factors on delivery time. Green dots, on which the source was noted, were glued on the sticky notes of the factors where data was already available. Yellow dots stood for factors where data could be made available with some effort. Factors with no measurement system in place were marked with red dots. The result turned out to be a surprise: Data was easily available for only for a few factors. The team conducted a vote, in which each participant had five votes, to decide which of the red factors’ measurement systems were high priority.
The team then drafted a data collection plan: determine factor, (potential) data source and owner. They placed sample size determination, operational definition of the measurement and capability assessments of the underlying measurement systems as action items.
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