Tag: Tips

The Broken Telephone Game of Defining Software and UI Requirements

Written by Martin Crisp on October 9, 2012. Posted in Articles.

The broken telephone game is played all over the world. According to Wikipedia, the game is played as follows: “one person whispers a message to another, which is passed through a line of people until the last player announces the message to the entire group. Errors typically accumulate in the retellings, so the statement announced by the last player differs significantly, and often amusingly, from the one uttered by the first.”

This game is also played inadvertently by a large number of organizations seeking to define software and UI requirements by using information passed from customers to business analysts to UI/UX designers and then to developers and testers.

Here’s a typical example:

The BA or product owner elicits requirements from a customer and writes them down, often as a feature list and use cases.
The use cases are interpreted by the UI/UX team to develop UI mockups and storyboards.
Testing interprets the storyboards, mockups, and use cases to develop test cases.
The developers then interpret the use cases, mockups and storyboards to write the code.

As with the broken telephone game, information is altered with each handoff. The resulting approach includes a lot of rework and escalating project costs due to combinations of the following:

Use cases don’t properly represent customer requirements.
UI/UX design is not consistent with the use cases.
Incorrect test cases create false bugs.
Missed test cases result in undiscovered bugs.
Developers build features that don’t meet customer needs.

The further down the broken telephone line the original requirements get, the more distorted they become. For this reason, UI storyboards, test cases and code typically require a lot of reworking as requirements are misunderstood or improperly translated by the time they get to the UI and testing teams.

How Can We Reduce the Broken Telephone Effect?

The good news is that there are some reasonably simple changes to processes and deliverables that will decrease the broken telephone effect. The following techniques share the goal of reducing handoffs and translations.

Interview the customer with cross-discipline teams

One method is to involve the BA, UI/UX and quality assurance people directly in the elicitation process with the customer. You can even make a case to include the lead developer as well. Having all disciplines represented during the interview process lets each party hear requirements directly from the customer, reducing the reliance on BA documents alone. An equally important benefit is that each discipline brings a different perspective, which can lead the interview process down different paths of conversation and requirement gathering.

For example, the QA resource may ask more questions about the requirements related to edge or error conditions than the BA or UI/UX resource. Putting a UI/UX member in front of the customer will provide a chance to understand features that are frequently used to manage the cognitive load of the end user.

Combine and evolve use cases, UI mockups, and UI storyboards into an integrated deliverable

Another approach to reduce the broken telephone effect is to avoid creating use cases, mockups and storyboards as separate deliverables by combining them into one “integrated deliverable.” To create an integrated deliverable, start with the use case and attach UI mockups to each step. This automatically creates a UI storyboard that has the same steps (including main and alternate flows) as the use case, and means they don’t get out of sync. Also, since the UI mockups are attached to each step, you know they will be consistent with the purpose and requirements outlined in the step.

Often, new requirements or changes to existing requirements emerge, and if your storyboards and mockups are separate from the use cases, the original use cases are not updated. This creates confusion for your developers, testers and stakeholders. Combining your use cases, mockups and storyboards into one integrated deliverable makes it much easier to keep all three in sync, dramatically reducing the potential for conflicting requirements.

The integrated deliverable approach encourages collaborative and combined authoring and review of use cases and UI/UX design by your BA and UI/UX teams, resulting in more accurately defined and understood requirements.

To bring this concept to life, here’s an example that starts with the use case defined by the BA or product manager, without any mention of UI-specific requirements.

Use Case: ATM Cash Withdraw

The steps with the Y-shaped symbol are steps with alternate flows.

Alternate Flows

When the UI/UX team starts attaching UI mockups to each of the steps, a UI storyboard is created that uses the same exact main flow and alternate flows as the use case. A UI storyboard expressed in terms of a main flow and alternate flows has the benefit of reducing the number of traditional linear storyboards. If you were to create traditional UI storyboards for each of the unique paths through the use case above, you’d have 11 in total, with duplicated steps across them. UI storyboards with main flows and alternate flows reduce rework and errors that pop up in linear UI storyboards.

You can do this in Word by inserting UI mockup images created in a different UI mockup tool, but keeping the UI mockups up to date in the will become time-consuming and error-prone. Products such as PowerStory (a plugin for PowerPoint) make this easier by enabling you to combine use case steps with UI mockups to create UI Storyboards.

In the following screen shot you will see that PowerStory adds a panel specifically designed for creating main flows and alternate flows of use cases, and associates the steps in these flows with typical slides in PowerPoint.

As before, the steps with the Y-shaped symbol beside them indicate an alternate flow. When you hover over the icon you can view and enter the alternate flows associated with that step.

PowerPoint is an extremely powerful tool for creating UI Mockups that can support more UI design ideas than typical wireframe mockup tools, especially with plugins like PowerMockup and Microsoft’s upcoming storyboarding plugin.

Write use cases and UI storyboards with testing in mind

Test cases typically include a “user action” followed by an “expected result.” If you spend a little more up-front time defining which steps are “user actions” and which steps are “expected results” when creating your use cases and UI storyboards, you can save your testing team time. Use cases are well suited for this approach by defining the principle actor for each step. Any step where the actor is a system should be classified as an “expected result” step for the test case, and any step where the actor is an end user should be labeled “user action.”

One of the test cases derived from the combined use case defined above is shown below, following the rule that a step with an end user actor is an action and a step that has a system actor is an expected result.

Automate the creation of your test cases directly from your use cases

Using tools that will automatically generate test cases from your use cases and UI storyboards will save you a significant amount of time and money typically spent by your testing team creating manual test cases. In the context of this article, it also eliminates a handoff and thus mitigates the broken telephone effect. When QA teams interpret requirements and translate them into test cases, they might misunderstand requirements and create faulty test cases and/or miss requirements and their corresponding test cases.

Key Points to Take Away

Developing software requirements, UI designs, and test cases can mirror the broken telephone game we all played as kids. Every time we pass information on, it gets changed and misinterpreted, leading to increased project costs and the delivery of the wrong solutions to your customers. Following the steps outlined above, you can reduce the broken telephone effect and follow a more streamlined process to clear and lucid product development.

Don’t forget to leave your comments below.

The Top 5 Mistakes in Requirements Practices and Documentation

Written by Angela Wick on May 28, 2012. Posted in Articles.

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.

1) Lack of collaboration and review of requirements

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.

2) Not differentiating between capabilities, rules, project tasks, and design

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.

3) Lack of context and visuals

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.

4) Too much focus on the as-is current state

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.

5) Allocating requirements too early to the applications they will be implemented in

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.

The Top 10 Business Analysis Skills for 2012

Written by Angela Wick on May 14, 2012. Posted in Articles. 1 Comment on The Top 10 Business Analysis Skills for 2012

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.

Don’t forget to leave your comments below

The Structure of Business Analysis Documents

Written by Sergey Korban on May 7, 2012. Posted in Articles. 74 Comments on The Structure of Business Analysis Documents

The structure of business analysis documents isn’t a commonly discussed topic. This article will show what documents are produced by a BA and the main sections they contain.

These are the main documents produced by a BA over the course of a project:

Current state analysis document
Project vision document
Solution vision document
Business requirements document
Business process design document
Use case model document
Use case specification document
System-wide requirements document
Solution glossary

The diagram below shows the attributes common to all documents:

Current State Analysis

Once a project has been mandated and the Project Initiation document (PID) is drafted, a business analyst can start to work on requirements gathering. In my experience the best way to tackle this task is to start from current state analysis. It helps understand the business need, primary pain points, business processes affected, the stakeholders involved in these processes, and so on.

The area of the current state analysis is illustrated below:

The main purpose of the analysis is to present the “AS IS” state: the existing business context, background, business functions and existing business processes, and finally stakeholders involved in these business processes. Depending on the project nature, some components of the underlying infrastructure can be included in the document as well.

A Current State Analysis document lists the key pain points within the identified business processes and tasks within them, and highlights the areas where a change is expected.

The last section of the document is about presenting recommendations. It recaps the key findings and lists the key changes expected. Any caveats should be presented here as well.

The content structure of the Current State Analysis document is presented below:

This document serves as a foundation or a reference point for other artifacts produced by a business analyst. The other documents will be discussed in the following articles.

Project Vision

The Project Vision is a document which is shared by a project manager and business analyst. They work together to outline the problem statement, determine the desired state, describe the criteria of business acceptance of the deliverables and how project success will be measured. The document contains a section with stakeholder analysis which shows all the parties involved along with their responsibilities and needs:

The business analyst adds the high level requirements which are within the scope of the project, and marks each requirement as compulsory or optional. To clearly define the project scope and avoid ambiguity, all out-of-scope requirements are also listed at the end of the section.

Based on the results of the current state analysis the business analyst describes the current business context, the key business processes and services used to support them. After that the required changes are mapped to the current business context. It can be a good idea to present this mapping as a diagram for easy communication of the proposed changes to the business stakeholders.

Solution Vision

Once the Project Vision document is approved, the preparation of the Solution Vision document starts.

First, the business analyst recaps the problem statement from the Project Vision artifact. The solution statement describes the target audience of the solution, what will be satisfied by the solution and what the key benefits will be. The statement of differentiation of the solution from possible alternative options is added as a conclusive point in positioning of the solution.

The document describes stakeholders within the target audience along with their roles using a RACI matrix.

The main part of a Solution Vision is a detailed section devoted to the solution capabilities comprised of both functional and non-functional features, with priorities given by the business stakeholders.

The next section presents the business context in its future “to be” state. It’s a good idea to include a a diagram illustrating the key changes and additions to the existing state, as well as a brief narrative to clarify the proposed changes.

Similarly to the Project Vision document, the features that are out of scope are clearly listedin the last section to make sure everyone is on the same page with regards to what will be implemented.

Business Requirements

This document focuses on providing details about the current processes and gives enough information to describe the business problem and how it fits into the scope of the project. This section reiterates the findings of the Current State Analysis document, however here they are aligned with the project objectives.

The business requirements that are going to be fulfilled by the solution are listed in the “In Scope” section. Business rules that apply to the described requirements are presented in a separate section. This approach simplifies the confirmation of the rules with business stakeholders.
Any assumptions and dependencies identified in relation to the business requirements are to be listed in the appropriate section.
The proposed changes to stakeholder roles, new or modified business processes and business services that support them are presented in the last section.

Business Process Design

This document focuses on the scope of changes to business processes, providing details about the current business context, existing business processes, and stakeholders involved in these business processes.

It also describes the future state: the proposed business processes and the “to be” information environment. The new processes are accompanied with narratives to facilitate communication of the proposed changes to stakeholders and business end users. This “as is” section reiterates the findings of the Current State Analysis document, however here they are aligned with the changes to supporting business services.
Any assumptions and dependencies identified in relation to changes to the business processes are listed in the appropriate section.

Use Case Model

The Use Case Model lists all the scenarios for using the solution required by the business stakeholders. It is useful to describe the solution as a set of functional areas and group the scenarios per functional area. Such an approach allows to use this document more efficiently in communication with the business stakeholders as they can easily refer to the sections of their interest.

The model lists all possible scenarios in scope, their brief summary, actors involved in each scenario, frequency of use, triggering events and the two possible outcomes – success and failure.
One of the key attributes of the scenarios is a reference to the high-level requirements and required capabilities which allows to establish traceability.
Note: when making changes to Use Case Specifications, do not forget to update the Use Case Model document accordingly.

Use Case Specification

A Use Case Specification document presents more detailed information about the use cases in the Use Case Model document.

Each specification includes:

Brief use case overview
Reference to the functional area
Preconditions
Actors involved
Main flow
Alternative flows
Exception handling flows
Functional requirements for the solution
Traceability to the business requirements
Market or business rules applicable to the scenario
User interface, controls and data

System-Wide Requirements

This document is prepared when the Business Requirements, Use Case Model and Use Case Specifications are complete. The main purpose of the document is to present a “qualitative” side of the solution.

The “Load patterns” section is the most interesting as it illustrates how the solution is expected to be used during a business day. This information gives good insight into business requirements from the “non-functional” perspective and helps clarify the business requirements where required.As solutions are often based on information technology, some attention should be given to solution resilience. Disaster mitigation approaches and solution recovery requirements play a major role here.It is a rare case nowadays that a solution is completely new. The common practice is to integrate the solution into the existing business environment. The system-wide requirements document describes the interfaces with internal and external systems and solutions, the data flowing between them, its formats and data elements. Where the solution should interface with external systems, samples of data must be presented in appendices.Apart from business reporting capabilities, the solution must provide reporting capabilities for monitoring how the solution operates. These reports are listed in the last section of the document.

Solution Glossary

Business stakeholders often use terms and jargon in their communication. To get up to speed with this terminology (you can be quite new to it), the Solution Glossary document is used. It helps establish common terminology for the project team and key stakeholders, and for use within the solution. The structure of this document is simple:

It’s a good practice to divide the solution into functional areas. These functional areas serve as small knowledge domains for the stakeholders involved in the project. This document serves as a reference point for all the previously discussed documents.

Don’t forget to add your comments below.

The Best Virtual Meeting…EVER! Five Fun Games to Engage Your Virtual Project Group!

Written by Claire Sookman on March 26, 2012. Posted in Articles.

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:

Decreased productivity
Conflicts or hostility among staff members
Confusion about assignments, missed signals and unclear relationships
Decisions misunderstood or not carried through properly
Apathy and lack of involvement

And there’s more:

Lack of initiation, imagination, innovation; routine actions taken for solving complex problems
Complaints of discrimination or favouritism
Ineffective staff meetings, low participation, minimally effective decisions
Negative reactions to the manager
Complaints about quality of service

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:

Printer sound
Al Pacino impersonation
Star Wars Light saber
Monday traffic
Radio anchorman

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:

I woke up at 9am — that was when we were supposed to Skype in for the meeting…
Jared looked over the ledge of his balcony, wondering why the crowd had gathered…
The email had no subject line…I hate it when he does that…
Fifteen years, 15 days, 15 hours and finally the letter had come…
As Sophia hid behind the red SUV in the parking lot, she tried to remember how exactly she had gotten there…and why there was that giant scar on her arm…

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.