Author: Angela Wick

Six Effective Elicitation Questions to Ask Your Stakeholders

Written by Angela Wick on October 1, 2012. Posted in Articles. 90 Comments on Six Effective Elicitation Questions to Ask Your Stakeholders

Asking questions during interviews or as part of a structured requirements workshop is commonplace. However, the most important question is one you should be asking yourself:

Am I asking the RIGHT questions?

Here are a few of my favorite elicitation questions and what they might reveal about your project.

1. What are the biggest challenges in your role?

A key part of any BAs role is to understand the context of the project: where does this project “sit” within the larger organization.
Having stakeholders describe the challenges in their role prompts both leaders and doers to share information that moves “outside the box” of the project.

Especially in an interview setting, this question allows the collection of “stories” that will elaborate and cement the value of the project and its required capabilities. These “stories” are concrete examples of the business need that will communicate the value of the project to sponsors, vendors, testers, developers, etc. throughout the project lifecycle.

Though you want to be cautious to avoid scope creep, briefly stepping outside the confines of the project can also help you identify:

Organizational risks
Missing stakeholders
Requirement gaps

2. What does success look like?

As I noted in my May article, “The Top 5 Mistakes in Requirements Practices and Documentation”, many project teams spend too much time focusing on the as-is current state.

Asking stakeholders to define success is a perfect way to move workshop or brainstorming discussions from the current state into the future state.

In the initial stages of elicitation, this question will help gather a clear overview of what capabilities are required for the project. The output of this question to can be used to create high-level conceptual models of the future state.

This question can also be used in beginning to elicit requirements for very specific features and capabilities. The challenge will be keeping stakeholders focused on the “what”: users, processes, rules, events and data. The discussion migrating to technology, systems and solution may risk that the true needs go undiscovered.

Perhaps most importantly, focusing on success frames the discussion in a positive light, emphasizes benefits, and gets stakeholders excited about the value the project will provide to their organization.

3. Who do you think is impacted (positive and negative) by the project and how?

We have all seen that even small projects can create a ripple effect that touches many parts of an organization. All of the people touched by the project’s ripples are potential stakeholders. Identifying and categorizing the roles of various stakeholders is key to successful elicitation.

In the initial phases of business analysis, understanding who is affected by the project will help you refine the scope of the solution and build your core team of stakeholders.

Asking this question throughout the project lifecycle will also help you:

Identify new stakeholders
Identify and mitigate risks/constraints
Redefine needs or identify new needs
Elaborate requirements
Prioritize requirements

4. What would happen if we don’t change the way things are done today?

Use this question as an alternative to: “Why are we doing this project?” or “Why is this project important?”

As you may know, I love the question “Why?” but I hate to use it. “Why” questions tend to put people in a defensive position and can inhibit open and honest communication.

Also, framing the discussion in terms of “no changes”, is essentially asking stakeholders to define the current state. However, this phrasing will limit the “as-is” discussion to the processes and events that need to change.

Stakeholders will help you understand the key opportunities, risks of dormancy, the benefits of change — all-important inputs for successful elicitation.

5. What other changes are happening within the organization that may impact this project?

Most organizations function in a state of constant change. To avoid being blindsided, find stakeholders that understand how new strategies, policies, regulations, processes, and technology, might impact our projects.

Many project teams tend to isolate themselves within the silo of their business unit—often in an effort to stay focused. However, too much isolation can lead to missed opportunities for:

Collaboration
Integration
Sharing of best practices

Keeping attuned to organizational changes can help to:

Mitigate risks
Estimate project deliverable dates
Manage scope
Identify constraints
Understand interdependencies

6. How would you describe the process?

This is really a technique, with multiple questions, that I use frequently with SMEs in one-on-one interviews or in small groups. This technique is most effective when delving into the details of specific processes or events. Here’s what I do:

I ask the SME/s to describe the process for me.
Then, I draw the process out with them—on notebook paper, presentation paper, whiteboard, or using software.
As they explain the process I ask, “What parts of the process would you improve and why?”
I also ask, “What ideas do you and your teammates talk about as ways to improve the process?”

At the end of this exercise, I leave the room with a validated visual of the current state of the process and a list of opportunities to add value to the organization.

Let me know if these questions will help you or share your favorite elicitation questions below.

Don’t forget to leave your comments below.

Project and Solution Scope – The Importance of Both!

Written by Angela Wick on August 14, 2012. Posted in Articles.

Some big news in my life, I got married in July! In the process of getting married and planning a wedding I found the analogy of the wedding process similar to project and solution scope.

Project Scope and Solution scope – How to explain the difference?
I will get to the PMI and IIBA definitions in a moment, but first I want to throw an analogy out there for everyone to react to.

For a little conceptual fun . . .
Engagement is to Project like Marriage is to Product/Solution

The wedding is the “go live” date and implementation of the marriage, the engagement is the temporary endeavor to create the marriage, the marriage is what lives on.

The marriage proposal is the project charter, likely talked and thought about for months, and finally funded with an engagement ring or other cultural token. A commitment made by key stakeholders to create a marriage.
The planning begins . . . a budget is created for the wedding, negotiation between the couple and parents on budget, timeline, and scope of the wedding. Meanwhile the couple begins planning their marriage, requirements of their lives together and visions of what the future will hold. They work on planning the details of their finances, a home, children and family relationships, spirituality, lifestyle, etc. . . . Most discussed at a conceptual level before, but now they look at the details, it is reality now. All features of a life together, some need to be ready for the wedding with high priority and some more conceptual and will evolve as time goes on.

A plan is created with all of the tasks needed, timelines, who is involved and budget. Some parts of the plan are task driven and others are key activities to create the marriage.

A wedding coordinator is hired to manage the plan and make sure everything gets done.

Family gatherings are abundant to figure out design of the wedding, and in all of the heated discussion it is easy to lose sight that it is more important to plan the marriage than the wedding . . . so much focus on one day and yet we need to be focused on what lives on after that day. The bride and groom try to find time among the chaos to discuss the details of their life together.

An hour-by-hour schedule is created for the wedding day and everyone has his or her part to play, including the rehearsal.

And . . . then there are the vows, the go-live!!!!

What lives on forever is the marriage . . . and just like a project, if requirements change, are missed, or the stakeholders, needs, and context changes the marriage is at risk. The marriage must be adaptable and prove value to those impacted to be considered successful.

The Bride and Groom need to be BAs in their own right and ensure that they are thinking about the future and an enduring life together vs. being all consumed by the wedding.

The scope of the engagement and wedding is all of the tasks leading up to the wedding day to make the wedding happen. I compare this to Project Scope.

The scope of the marriage is what lives on and the qualities, features, and capabilities that make it successful. I compare this to Solution/Product scope.

Project Scope “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.”
PMI PMBOK 4th Edition

Product Scope “The features and functions that characterize a product, service, or result.”
PMI PMBOK 4th Edition

Solution Scope “The set of capabilities a solution must deliver in order to meet a business need.”
IIBA BABOK v2

Some practicality of this for your projects:
– Documenting both the project scope and the product/solution scope is critical to the success and business value of the project.
– PMs are typically responsible for the project scope
– BAs are typically responsible for the product/solution scope
– It is critical to success for BAs to define solution scope, even if it is not defined or well defined when you join the project.
– Solution/Product scope statements are the features and capabilities of the solution/product that live on after go-live; they are not the tasks that need to be done to deliver the solution.
– Project scope alone (task driven) is dangerous to the project success as there is no common alignment and documentation on what should live on once it is implemented.
– Use a Scope/Context Diagram to accompany a Solution/Project scope statement. The IIBA newsletter had a great 5 part series on context modeling by By Meilir Page-Jones. The series started in the Feb 2011 Newsletter.

Happy solution scoping and happy marriage making!

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

Is a Systems Analyst a Business Analyst?

Written by Angela Wick on April 10, 2012. Posted in Articles.

I hear this question and debate all the time! Here are some thoughts for both sides of this epic question of our time in our industry.

It is important to call out that titles and disciplines are different, and any title likely requires performing in multiple disciplines. Systems analyst and business analyst are job titles. Business analysis is a discipline.

It is also important to call out that systems analyst and business analyst as job titles are different from organization to organization and team to team. The variance in how these jobs are defined in job descriptions tells this story well. Given the variety of definitions, Systems Analyst roles fall into one or more of the following themes:

Focus on supporting specific applications/systems.
Focus on helping project teams understand the possible technologies that are feasible for given business or solution requirements.
Focus on analyzing solution requirements to design and specify the functional and/or technical design of a solution.
Focus on being functional and/or technical experts on a specific application and/ or usage of an application by user groups.
Focus on a deep understanding of interactions between systems.

No, that’s not a BA:
Everything is about technology for a systems analyst and a business analyst focuses on a broader scope than just technology applications. Business analysis is about understanding business needs, the context around them and facilitating the change or solution (technical or not) to solve the business need. Technology applications may be a part of this, but they are not always the focus.

Yes, that’s a BA:
Systems analysts are solving business needs through technology and using many of the same tasks and techniques in the business analysis discipline to perform their role.

Other Considerations:
I believe that many systems analysts are performing business analysis as a discipline to varying degrees, at varying levels of detail and with varying levels of success depending on many internal and external factors.

Business analysis as a discipline is about analyzing and facilitating business change, which may or may not impact technology, though most business change efforts impact technology to some extent in today’s environment. Given this, most efforts involve systems analysis, so the question remains, who is performing business analysis and who is performing systems analysis? These roles must be performed, it is a question of title, and each organization structures work and resources differently to execute on delivering solutions.

I also believe that the answer to this depends on the approach taken towards the work effort. For example:

When identifying user needs as a systems analyst, is the focus on what the system should do, look like and how it should function? A business analysis approach is more focused on why the user has the need, what options there are to solve for it, and what impacts are systematically and non-systematically (people, process, context, etc . . .) part of the solution?
When documenting requirements as a systems analyst, is the focus on the system screens, fields, and files or on the process, rules, data, stakeholders and capabilities of the solution? A business analysis approach focuses on ensuring the capabilities and context (capabilities, process, rules, data) are understood and all stakeholders are heard from as a path to solving business needs.
When facilitating requirements meetings to elicit requirements as a systems analyst, is the focus on gathering and collecting requirements for an application or system, or understanding the business needs, drivers for change, current pain points, vision, internal and external factors, and impacts of the business change at hand. A business analysis approach focuses on eliciting what is behind and underneath stated requirements rather than collecting and gathering requirements.
When modelling the process as a systems analyst, is the process solely focused on what the system is doing? A business analysis approach is focused on the human interaction points, capabilities of what the users and system are doing (inputs, transformation, outputs) and system capabilities.
Would someone outside of the organization understand the requirements documentation? A business analysis approach favours understandable documentation to technical and non-technical audiences internal and external to the organization.

The more the approach uses a business analysis approach, the more likely business analysis techniques and discipline are used, and a higher percentage of business analysis is being done.

I believe that most systems analysts are doing business analysis, but the percentage of their work in the discipline varies by organization, team, and skill set. Given this, there are also many business analysts who fit the above descriptions of a systems Analyst. And this doesn’t even mention the common title of business systems analyst!

My conclusion regarding the question “Are systems analysts actually business analysts?”

Yes, if they are using business analysis tasks and techniques to facilitate business change through their work with systems.

Don’t forget to leave your comments below.