Follow this advice at your own risk, AND, YES, I have seen it work!
AND:
Q: How many BAs does it take to screw in a light bulb?
A: “Tell me MORE about this light bulb.”
If you liked it let us know!
Don’t forget to leave your comments below.
In my work with dozens of organizations improving business analysis practices, the following are the most common themes I see hindering the great value that good business analysis practices can provide.
Collaboration and review of requirements should be an ongoing process of meeting, discovering, and collaborating to share information and context. Verifying that requirements met the needs of others to guide further work and validating that the requirements will add value to the business are critical pieces to this review and collaboration.
The mistakes I typically see in this area are teams that “gather” and “collect” requirements from stakeholders rather than using proven successful elicitation, discovery, and validation techniques. Following a “gather” and “collect” mindset sets a team up to jump to the solution too quickly before truly understanding the business needs and value required by the stakeholders.
The BA is often assigned to the project after business needs and values have already been discussed and the stakeholders pressure the BA to just move forward. This is the most important time for a BA to use powerful collaboration techniques that help the stakeholders feel that they are not restating the same information but are improving the business value proposition the project is set out to achieve.
Some teams see requirements reviews as sufficient collaboration. With requirements reviews I often see the following:
• Lack of review
• Reviewed, but missing critical stakeholders and consumers of requirements
• Reviewed but as a formality, and stakeholders struggle to truly understand requirements documentation
Ideally for requirements reviews to be successful, those using and signing off on requirements need to be fully engaged in reviewing requirements, verifying they are understandable, cohesive, and usable for the further work to be done, and validating the business value and intent of the requirements. To achieve this, BAs need to ensure that documents are presented and communicated in ways that are understandable to all audiences and the review process engages all audiences to fully participate in the review.
Many requirements documents that I see in a large number and variety of organizations are missing the essence of what requirements are. The mistake I see is requirements documents lifting project tasks, detailed technical design, and business rules without listing the context and capabilities needed. This sets the project and solution up for a multitude of missed requirements and missed value to stakeholders. Business and solution requirements are capabilities needed by a solution to achieve a desired change in the business. They are not project tasks lists, technical design details, or bullet lists of business logic. Focusing on the true requirements instead of the project tasks and design will shorten the requirements timeline.
Project tasks need to be in a project plan of some sort, and design should be happening progressively as requirements are discovered and must account for feasibility and alternatives. Design needs to be differentiated from what the requirements are, and this can occur in a separate document or not, but it needs to be differentiated. It is no fun to manage requirements change when the requirements document is really tasks and design; this will cause more change management administration than needed. Requirements change becomes much more manageable when it is truly business and solution requirements that are changing. Changing design details and project tasks is likely to happen with more frequency and may not impact the end result, and a failure to differentiate can cause costly rework and unneeded administrative tasks.
Business rules are critical to successful requirements, but I often see requirements only in the context of business rules, and sometimes up to 90% of a requirements document is a listing of business rules. Business rules listings without the context of processes, people, data definitions, sets, projects up for missed requirements, inefficient and inconsistent implementation of business rules. Understanding the business rule outside of technology enablement is crucial to improving the consistency and efficiency of business rules. Differentiating business rules from requirements is critical to understanding and analyzing the capabilities needed to implement the rules.
Context and visuals provide our requirements readers with brain candy. Many studies show that visuals are consumed by the brain much faster than text and help depict relationships, whereas text is processed in a more linear fashion in our brains. Cognitively, visuals are proven to be more effective than text at increasing a reader’s comprehension and retention. On the other side, visuals without text can be too ambiguous. So, why do so many requirements documents lack visuals and context that would help readers comprehend and retain the very information BAs are asking them to approve? As Bas, visuals are sometimes present but often are too complex to engage our readers and need to be simplified. Sometimes our visuals as BAs are design oriented rather than intended to help readers understand context, interactions, and relationships.
Great requirements are documented in a way that allows the reader to choose the level of detail they would like to consume, provide visuals and context of varying levels of detail needed to guide further work, and provide text that clearly traces the visual and context representing the text.
Projects and business analysis work is about changing the way organizations operate. It amazes me how much time is spent on documenting the as-is; I am not advocating ignoring the as-is or current state, because it is needed to understand the gaps that must be crossed to get to the future desired state. The challenge and mistake I see teams making is never getting to defining the gaps and future state. And, sometimes all of the context and visuals are about the current state with nothing showing the context or visuals for the future state.
Our requirements need to understand the current state, but the requirements themselves should represent the gaps and future state. We are not asking our stakeholders to approve the current state. Instead, they are asking us to help them change, hence we need to define the future state. Our requirements need to answer the questions: Why are we spending money on this solution? What value will the solution bring?
There are many statistics out there about the percentage of functionality in current systems that is not used; the numbers typically range between 60-80%. This raises the question of why we would document requirements for the future the way the system works today when 60-80% is not even used today? After all, today’s system was likely designed 10, 20, or even 30 years ago and we can’t possibly compete in todays business environment by developing solutions based on functionality designed for business years ago. After all, how will this take the organization into the future?
Great requirements practices and documents show how the current state is going to change, what the future state is, and the gaps to get there. There are many areas of solutions where the current rules, process, and technology will be leveraged in the future state, and this is where we need to ensure we are focused on the future by defining what pieces will move forward, and we shouldn’t spend too much effort on current state items that will not carry forward. This is done by identifying the current state at a higher level and questioning if this piece will continue to add value in the future state vision. At that point, a BA should only go into details if the value is justified.
When evaluating business analysis practices and how they align with software development processes, I often see that the requirements are being allocated to software applications before the requirement itself has much context or elaboration. Understanding the requirement and business need is needed before we can specify what system or application will be changed or built to implement the requirement. The practice of assigning the technology to a requirement before the BA is assigned or before the requirement is vetted defeats the purpose of business analysis in many ways. This practice also makes requirements change a huge challenge. As we discover and elaborate requirements, we often find that the initial idea on implementation is not feasible or optimal. If the requirements process has already allocated the requirement, it takes a change request to change that in some organizations. This is where the process hinders good business analysis. Many times this practice is not in the control of a BA, but I do believe that a BA can collaborate with others, and elicit and document requirements in a technology-agnostic manner to facilitate the discovery of other ways to implement requirements.
Great requirements practices focus on the user, process, rules, events, data, and non-functional needs before deciding which exact implementation technology will be used. This allows the team to discover the true business need and explore options and alternatives that may not have been previously thought of. It also helps ensure feasibility prior to committing to a specific solution design.
Let me know your thoughts on the common mistakes in requirements practices and your challenges in these areas.
Don’t forget to leave your comments below.
OK, before you think we have gone crazy…we recommend more SHORT, FOCUSED meetings. As project managers and business analysts we often find ourselves with pressing deadlines, frantic team members who are juggling many tasks with little time, and senior stakeholders who place increasingly challenging demands upon us. At the same time, we face unchanging statistics showing that communications issues are at the core of project failures. How do you manage these two imposing situations? Have MORE meetings, but make them count, and do them quickly. Let’s examine why we need these frequent, focused meetings, and how to best conduct them.
The type of meetings we are discussing here are usually no more than 15 minutes; on rare occasion they may take half an hour. Often they are run as daily “stand-up” meetings, in conference rooms with the chairs removed or pushed to the side of the room. This is optional, however, for some the “stand up” aspect of these meetings help keep the attendees focused. These quick meetings are usually first thing in the morning to prepare for the upcoming day, or they are the final thing done at the end of the day, to prepare for activities that will take place early the next business day. So, given this, why are more frequent meetings a useful tool?
1. Your team needs as much efficient heads down time as is possible
Rarely do any projects allow team members to operate in a vacuum. Conditions change, problems and unexpected circumstances surface. Communication from the project’s various stakeholders is virtually constant. Team members need to a) know what their mission is on the project and b) have the information they need to get their tasks accomplished in the best way possible. With this constant flow of needed data, the forum to communicate all of this information requires frequency and efficiency. The short, focused, and regularly scheduled meeting can accomplish this. The project manager can also receive information from team members relative to status, risk management and issue information in an efficient fashion as well.
2. Team members need to know about dependent tasks, and required interactions
In our formal project management training, we spend considerable time (appropriately) on risk management. Classical risk management talks about potential events that may affect the project, the completion of project tasks, or the project mission as a whole. In the fast paced, increasingly technical area of product development, it is just as important that we treat information about dependent tasks and other potential interactions with other team members, major stakeholders or vendors, like we do for risks. We need to recognize these interactions, plan what we need to do to address them, and be prepared if the interaction event takes place. These interaction events can cause us to have to review data, review status, alter our approach, or in the most significant instances, re-plan how we are accomplishing our tasks. Only through interaction with our peers and leaders, and obtaining timely information from stakeholders can this be accomplished efficiently and effectively. We don’t need extensive ‘interaction management plans” to do this; however we do need to interact frequently about the potential, so we can be prepared for upcoming project situations.
So, given these meetings are so important, how do we make them effective in both maximizing team members’ “heads down time” and preparing them for these potential “interaction events?”
1. Don’t make them mandatory – make them “conditional” and you control and communicate the attendance conditions.
The legitimate complaint that most people have about meetings is that they are a waste of time. They go too long, and they aren’t useful. We get into the habit of inviting the “standard team set” to every meeting. When your team is crazy-busy, we need to step to the plate as leaders and make the effort to determine WHO needs to be at our short, focused meetings. So, set the conditions for your team members as to who should attend, communicate those expectations, and share the conditions before every meeting so those that don’t need to be there won’t need to attend. When you first start this technique, fail on the side of conservatism and have people attend. As time progresses, and you get feedback on the usefulness of the meeting, you can fine tune your attendance condition setting. The key to this is simple…if YOU can’t identify the critical piece of information they will take away from the meeting, then they do not need to be there. If YOU need a piece of information from a team member – collect that at the very start of the meeting. Carl Pritchard’s “Wall Walk Protocol” is a great approach to doing this for larger project teams.
2. Hold more than one daily meeting – with different attendees
This might not be as efficient for you as the project manager or the lead business analyst, but this isn’t about you. It is about the productivity, effectiveness and efficiency of the team. If you do this well, and your team feels you are conducting effective meetings that are worthwhile and they get the information they need, you will benefit from a) not having to chase people down to get or share information and b) they will work with better data, which will reduce the issues that you will have to deal with. This usually saves you more time than you will spend on setting attendance conditions and holding separate meetings. Holding separate meetings – and doing this well – avoids the biggest time waster in meetings…that of having to listen to someone drone on about something that isn’t meaningful to them. Divide your team into sub-teams of people that work together often, and have separate daily meetings. To maintain “a whole team” consider having the entire team attend one of the daily meetings each week. Set the agenda for that team meeting be things of relevance to the entire team.
3. Take the meetings seriously, but don’t force yourself and your team to be serious
Efficiency not only comes from getting and giving information effectively and in a manner that is valued by team members. Efficiency also comes from team members that know and understand each other in more than a professional capacity. Take time to recognize birthdays, significant accomplishments, not so significant accomplishments, and times when you acted as a team. Bring cookies or breakfast to the weekly whole team meeting – be human yourself as the leader and encourage your team members to do the same.
4. Talk about the “elephant in the room”.
Because the group of people will be small, take advantage of the intimate size. Cut to the chase and bring up topics that might be “taboo” in a larger group situation. The more open and forthright about providing information you are, the more the team will feel comfortable doing the same. Information is key to our success and the earlier people open up to share “bits of vital information” the better positioned the project will be for success.
Don’t forget to leave comments below.
I am not here to comment on the leadership ability or motivational prowess of one of the greatest leaders of our time, Vince Lombardi. I am here to dissect one of his famous quotes; “Some of us will do our jobs well and some will not, but we will all be judged by only one thing: the result.” What is the result Vince Lombardi is talking about? This can easily be interpreted to judging each person by their individual results. That interpretation is where I find the flaw in the quote. If the result is solely based on individual actions, when is the individual judged by the result of the whole? In sports are individuals judged by the team winning their sports championship or just judged on how well they did in their own position?
The same questions need to be applied to business analysis professionals. In an early blog post, No One Wants to Work with a Jerk, I touched on this concept. Teams are not effective when one or more people are solely focused on their results at the detriment to the results of the team. Does this mean individuals should not be rewarded for individual results? Absolutely they should. They should be rewarded when their results bring the team closer to the overall result.
In the development world you are probably well aware of situations when a developer thinks about their results over the results of the project. This is often referred to as “Gold Plating”. This is when a developer adds features to a system that were not needed or requested for the project. That addition is all about the individual, not the team. The same applies to business analysts and how you spend your time. Are you spending your time on activities that make you look good or activities that make the project team look good?
When business analysts are rewarded their behaviors should be taken into account. Should a BA be rewarded for the strong relationship that they have with the business stakeholder when they disregard the relationship with their project team? In the end individuals need to be rewarded for their efforts that work towards team results. That’s why I like this Lombardi quote the best; “The achievements of an organization are the results of the combined effort of each individual.”
To the Results,
Kupe
Don’t forget to leave your comments below.
Do you ever have those days when go you off on philosophical tangents? You know, those cold, gloomy mornings when you stare out the window, coffee mug in hand, wondering, “Does a fish know what water is?”, “Is the colour red really universal?” or “Is Robert from marketing a real person?”
We’ve all been there. The truth is it’s hard for virtual project groups to bond on a personal level with other group members…partly (well, mostly) because we may not even know what the other person looks like! Without bonding, the results could be dangerous. The University of California, San Francisco, lists some of the common symptoms of a disengaged team:
And there’s more:
And there’s still more! A 2009 article from the Occupational and Environmental Medicine showed that a lack of team spirit can even cause employee depression…But don’t panic!
Before you scurry off to Google, furiously searching “how to engage virtual project groups” — take a breath. We’ve done the work for you. Here are some innovative games that are sure to have your team amused and engaged in no time.
1) Virtual Charades – Charades is a great game that builds group spirit, whether in a traditional workplace or a virtual one. If your company usually sets up video conferences for meetings, this is definitely a game that will have everyone working together, solving problems and having fun along the way. If you’re unfamiliar with the game, Charades requires the player to mime or imitate a certain action or subject that the rest of the team has to figure out. For more information on how to play, click here .
For those who use voice chat instead of video chat, there’s a fun alternative for you too — Voice Charades. For Voice Charades, create a secret list of objects, animals or famous people. To decide who will go first, enter all team member names onto a site such as Random.org and choose the first name that shows up. Email or send an individual/private instant message to this team member letting them know what they will be acting out. Remember to keep the clues work-appropriate and respectful of others. Have fun guessing what/who the person is imitating. Some entertaining suggestions are:
2) Spin a Tale – This fun game fosters creativity and helps team members think on their feet. During a meeting, make up the first line of a story. Then ask team members to take turns and add each subsequent line until a whole plot develops! Let the story go along on its own path and deviations. This is the fun part of the game; you never know what perils or fortunes can occur next! The best thing is, even though your team may develop favourite start tags, the story will never end up the same! In other words, you learn how to think innovatively. Here are some ways you can start your tale:
3) Situation Puzzles – Situation puzzles are an exciting way to exercise creative problem-solving skills while also building team unity. In a situation puzzle, the team leader states one mysterious sentence such as, “a bell rings, a man dies, a bell rings”.* The rest of the team must now solve the situation by asking “Yes” or “No” questions. As each question unearths new information, the team can creatively build on each other’s thought patterns and ideas until all the loose ends are tied. A great reservoir of situation puzzles can be found here! *(Click here for the answer)
4) PowerPoint Game – You will never look at PowerPoint presentations in the same light after this game! This is a great way to get group members thinking on their feet while having loads of fun. To play the PowerPoint game, go online and find a series of complicated or extremely nonsensical PowerPoint presentations (try SlideShare). Then ask team members to improvise a presentation with the slides they’re using. Hilarity is bound to ensue! Go here for more information about the PowerPoint game.
5) 2-Minute LOL – This is another improvisation game that will get everyone thinking fast, learning about team members and literally laughing out loud. First, divide the team into smaller groups or partners. Then give each group a topic or let them choose one. Allow each team about five to ten minutes to create a set of jokes based on their topic. Make sure they have this discussion in a separate virtual conversation so that the rest of the team does not hear the punch lines beforehand. When everyone regroups, randomly choose a group to go first while timing their comedy improvisation for two minutes. Once again, remember to keep all jokes respectful and workplace-appropriate. Award the funniest team with a gift card or some other form of prize!
And there you have it — five amazing ways to engage your virtual project group! Try them out and let us know which game your team liked the best! And if five tips aren’t enough, here’s a whole book full of tips! Across the Hall, Around the World is the ultimate archive of virtual team-building tips that’s sure to get your team engaged!
Don’t forget to leave your comments below.
Claire Sookman is the driving force behind Virtual Team Builders, Claire brings to the table over a decade’s worth of corporate and public sector training experience, working with over 4,500 managers in the past three years. Specializing in virtual team building and communication strategies, Virtual Team Builders provides training that enables global teams to work more efficiently.