Tag: Stakeholder

Innovation and Business Analysis

Written by David Morris on January 22, 2013. Posted in Articles. 3 Comments on Innovation and Business Analysis

How can I use the concepts of ‘innovation’ and ‘business analysis’ in the same phrase?

While, to some, this might sound oxymoronic (like the term ‘deafening silence’), or at least moronic (and those who know me would expect nothing less); I would argue that innovation contributes to business analysis, and business analysis contributes to innovation.

What does this mean and how do we make it happen?

We don’t need to be innovative, though, do we?
Business analysis practitioners can provide an excellent service as we work through the project process, asking questions, applying techniques, creating documents and presentations, and clarifying how to implement the approved solution. Like any discipline involved in business change, done well, business analysis can make the difference between a successful and a struggling project.

Where we can add real value, is in providing creative analysis – enabling stakeholders to think outside the box, encouraging them to behave like their project was their own business so that they care about the outcomes, and providing thought leadership from the project space to the organisation.

How innovation contributes to effective business analysis
An essential purpose of business analysis is to “recommend solutions that enable the organisation to achieve its goals” (p3, BABOK v2, 2009). Sometimes this will involve helping organisations to ‘invent’ something new, although more often it will be to ‘innovate’ – to improve something already in use.

However, with business analysis typically practiced within the confines of a project, under the direction of a project manager, we risk adopting convergent thinking approaches. By following the ‘correct’ process to document requirements for sign-off, we can be seen to add little value in the process – that is, we become a requirements clerk gathering requirements.

Of course, we are more effective where we plan and manage our own business analysis activities, identifying the stakeholders and negotiating the scope, so that we can elicit, analyse, document, and communicate what is needed.

We add even more value where we apply divergent thinking too; this is where innovation is key to business analysis.

What does this mean? We need to push our stakeholders outside their comfort zones, to think laterally, to challenge them beyond an assumed solution and find out why they want something – so that we can be clear about what they really need and guide them to selecting the optimum solution, not just the one they first thought of; that is, let’s not make a bad process faster, let’s design the right process and work out how that needs to be supported.

How do we do this? At its simplest, this requires two things: to develop our underlying competencies (in areas like creative thinking, problem solving, and facilitation), and to have the courage to push back (suggesting that there could be alternative solutions, challenging to ensure that the underlying causes or needs are identified).

How business analysis contributes to effective innovation
Business analysis also has much to offer to how an organisation approaches its innovation processes, that is, well before there is a project.

Innovation in the pre-project stage
Most organisations will go through some form of scoping and business case stage before a project is initiated. While this is often undertaken by a project manager; mature organisations and PMOs recognise that it is a better fit for the BA to build the case for a project, or at least support the business owner in doing that. (Indeed, some would argue that you cannot assign a project manager until you have a project to manage, however there is always business to analyse).

Now, you might contend that building a business case is not showing innovation, it is simply taking the information that is available then researching and analysing it enough to understand the likely costs, revenue, duration, return on investment, risks, etc.

However, to develop a strong business case, we are required to explore alternatives, and can often uncover unexpected options or combinations that were not in the mind of the customer or requestor. More examples of divergent thinking.

How do we do this? If BAs in your organisation do not currently work at this level, find a small project that cannot yet proceed because it needs a business case, then volunteer to ‘have a go’. Even if it still doesn’t get the go ahead, you can learn from the experience and interact with stakeholders in a slightly different role.

Innovation in ideation
Further upstream (in the new product development process), before an idea has even been approved to be scoped and have a business case developed, business owners are busy working with sales performance data, customer satisfaction feedback, market research, and blue-sky thinking – divining answers that will result in a new or improved product, give a jolt to sales, or eventually withdraw a product from the market.

Equipped with our divergent, lateral-thinking, and facilitation skills, we can really enable an organisation to make the most of smaller investments to determine if an idea makes sense, before anyone even thinks of writing a business case. Working at this fuzzy front-end is also very rewarding; as well as being very focused on good business outcomes, you definitely get a sense of play, and interact with senior management.

How do we do this? Opportunities for these sorts of roles are rare, and are often promoted internally rather than advertised. The best way to attract these is to be seen to perform well in the pre-project space, and if there are ever any moves to revise the solution delivery lifecycle, governance, and/or new product development process, volunteer to be involved – from there you can agitate for a role like this and position yourself as the ideal candidate.

Conclusion
I’ve shown that irrespective of where we work in an organisation, and the development process stage, business analysis has much to offer in terms of helping foster innovation in our organisations. Do you agree?

I’ve said it’s rare for us to work outside the project space. Is this your experience?

What steps can we take to convince our organisations to allow us to play in this more creative space?

Don’t forget to leave your comments below.

A Business Analyst’s Lucky 13 Best Friends

Written by Angela Wick on January 8, 2013. Posted in Articles. 1 Comment on A Business Analyst’s Lucky 13 Best Friends

Who are a Business Analyst’s best friends? Who would like to be and Why?

Who are the people we interact with most on the job?

What is it that makes these relationships work and serve our end goal of providing value to the organization?

As Business Analysts we face changing project situations that challenge our skills and relationships with many stakeholders. He have an opportunity to serve our stakeholders and team members in many ways to add value to the solution being delivered.

We are often labeled as the ones that gather and document requirements. In reality, we are the critical link in the middle of a complex group of interrelated people, roles, and processes. Our role is in the prime position to ensure all these pieces are connected and aligned to maximize value to the organization.

How are we viewed by all of these people we work with? How do we want them to view us?

I would like to start a series about the “best friends” of BAs – all the major roles that BAs interact with. The roles I am currently targeting for this series are:

CIO – Chief Information Officer
BA Manager
Project Manager
Product Manager
QA & QA Lead
Developers
Tech Lead
IT Application Managers
Business Sponsor (Director/VP Level)
Business Subject Matter Expert or Domain Expert
Business Manager
Administrative Assistant
Project Controller

With each role (and more with your ideas), I would like to start a series in 2013 about:

How does each of these roles benefits from the BA role
What makes a top notch BA from their perspective
What frustrates these roles most from a BA
How to say “no” to these roles
How to influence these roles to give you what you need
How to communicate the value of the BA to these role

To start us off, here is a brief summary of each stakeholders needs from a BA, as we move through 2013 we will visit each in detail with the questions above.

CIO – Chief Information Officer
CIOs need a lot from BAs, one thing I will focus on is the need for BAs to collaborate and build great relationships with the project team and stakeholders so that the right requirements, solutions, priorities and risks are identified to maximize the value of the solution to the organization.
BA Manager
BA Managers not only need BAs to serve clients and projects in maximizing solution value, but also need BAs to work together with peer BAs to share best practices, lessons learned, risks, cross functional impacts and risks. They need BAs to be continuous learners of their field, mentor each other, and help grow the BA talent in the organization.
Project Manager
PMs needs BAs to collaborate on scope, planning, risks, and stakeholder communications. Scope creep arguably the biggest fear PMs have of a BAs work. Risks and stakeholder communications and collaborating on these is cortical to a PM managing the scope, cost, and schedule.
Product Manager
Product Managers are focused on marketing and product usage and development. Some focus on one more than the other. They need BAs to help understand markets, users, provide options and alternatives, and collaborate to truly understand the product features that they are looking at implementing.
QA & QA Lead
QA teams need to understand the details and big picture requirements. They need BAs to provide understandable requirements with context. Context is key to QA teams planning their test approach to maximize risk and the value of the QA process.
Developers
Developers typically have two concerns about requirements from BAs: Requirements are too vague or they are too detailed. What gives? Too detailed means that BAs are not providing enough context and/or are providing too much design details without looking at options and alternatives. Too vague means that requirements are lacking critical details about the Who, When, and Why.
Tech Lead
Context and non-functional requirements are king for Tech Leads, they are looking at architectural options to effectively produce potential designs to meet the need. Tech Leads are also looking for capability driven requirements statements to ensure that they can leverage existing technologies.
IT Application Managers
Context and options/alternatives are important to these Managers. They are looking to know what pieces of the solution requirements will their teams need to be potentially involved with.
Business Sponsor (Director/VP Level)
These executives need high level pictures and visuals about the solution and impacted areas, people, external players, data and processes. Also knowing key risks are critical to their needs.
Business Subject Matter Expert or Domain Expert
SMEs need to know where their detailed knowledge fits in and where there are still gaps that they can fill in. They are full of detailed knowledge but don’t always know when to give what knowledge. So a framework with context to help determine where detail goes is very helpful.
Business Manager
Business Managers want to know the big picture and how it will impact their teams. WIIFM – What is in it for me? How will this help my team, impact my team or change my team. With this focus they can better participate and collaborate on requirements.
Administrative Assistant
Admin Assistants of the executives you are working with need to know why your meetings are important to the executive they are supporting. Why do you need the executive in the room? This helps them determine the level of importance the meeting has compared to other meetings the executive is scheduled into that day and time.
Project Controller
Project controllers need to understand your true status towards milestones on the project plan, your risks and any insight into the project risks you can provide as well is issue resolution paths and ideas. They are trying to manage a lot of details, often without much context. Your view into estimates, timelines, risks, and issues helps them manage them and help you collaborate with the PM better.

Don’t forget to leave your comments below.

B-A-elzebub’s Glossary

Written by Marcos Ferrer on November 13, 2012. Posted in Articles.

(Thanks to Paula Tarvin and James P Bell and, of course, Ambrose Bierce):

This month we offer a little inside humor for BAs – no QA Managers, PMs, or non-BA Stakeholders allowed. Enter at your own risk, and share your thoughts in comments so that more shall be revealed 🙂

Analysis: Thought.

Business Analysis: Somehow different from analysis.

C: The letter C, as in the acronym CDCTCX. Also used in the acronyms CZSG and CSZG, among others.

Domain SME: The box we need to “think out of”, as long as the BA is responsible.

Elicitation: Interrogation. Often used where threats and espionage have failed.

Functional Requirements: Necessary and feasible solution behaviors, based on sound knowledge of existing processes and a reasonable degree of consensus on business changes to come. “Necessary” means any behavior required for the success of the solution. Functional requirements are typically characterized as “externally visible” in actor and system actions. Non-functional requirements (see below) such as performance are those which would not be apparent to the user, and most users would agree that they don’t see performance by their systems. Functional requirements are usually ignored in favor of features hallucinated on a golf course (see MBA).

Glossary: An attempt to explain words and acronyms that nobody understands by using words and acronyms that nobody understands. This project risk is mitigated by the fact that no one will ever read, or even be able to find, the glossary. Example: “I put the glossary on the share drive.”

Heck: A prioritization technique, as in “What the heck”. Often used in place of birth control at the last possible moment.

Ity-Bili Requirements: See “non-functional requirements.” Examples: Usability, Reliability, Performability, Response-ability.

JAD: Acronymystic technique, best used when other acronyms have failed.

Knowledge Area: Approximately 0.45 square meter (references: http://en.wikipedia.org/wiki/Broadsheet and http://www.ascd.org/publications/books/104013/chapters/Meet-Your-Amazing-Brain.aspx. )

Liaison: A word that looks wrong even after spell checking.

MBA: “Monkey business” analysis, often practiced on golf courses.

Non-Functional Requirements: Requirements ignored in the belief that they do not impact functionality. (See “Ity Bili Requirements”).

O: 0. Or is it?

Project: To predict the future, with the usual result; To impose one’s own time and money reality onto factual requirements leading to 65% failure rates; An individual or collaborative enterprise planned and designed to achieve an aim, as in “Fire, Ready, Aim!”

Quality Analyst: Testiest of all. See Tester.

Requirement: Sez who?

Stakeholder: Anyone with time to meddle in a project.

Tester: Scapegoat.

User: General term that might apply to almost any stakeholder. Example: “The system has End Users and End Abusers.”

Vision: See MBA.

Why: First salvo of an intensely probing question. “Why” is extremely useful when you are tired of your current BA job. Examples of use include but are not limited to: “Why wouldn’t you want the accounting reports to be more accurate and complete?” and “Why am I even talking to you?”

Xylophone: Oh, like you know another “X” word?

Yes: No.

Zachman Framework: A business modeling technique using a high level matrix while depending heavily on unshared spreadsheets plus a shared understanding of domain terminology. See Glossary.

Don’t forget to leave your comments below.

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.

As a Project Sponsor, What is Your Documentation Risk Tolerance?

Written by Mark A. Monteleone on August 28, 2012. Posted in Articles. 2 Comments on As a Project Sponsor, What is Your Documentation Risk Tolerance?

To almost quote Shakespeare’s “Hamlet” – to document or not to document, that is a risk question. This article is a follow-up to the BATimes publication, “Verifying Requirements Documentation.” As author of the article, I took special note of a readers comment on providing organizations a continuous process improvement model on composing a business requirements document (BRD). The comment was:

“… I too found some things worth cutting and pasting into some training or checklist material. The post script was prophetic – the environment for BRD seems to be getting squeezed by those who find the whole process “too cumbersome” and not (lowercase) “agile enough”. I know of lots of orgs whose risk tolerance is so high that they could never see the ROI in it. I Think much of the great material here could be better digested by some organizations if one applied it as part of Continuous Process Improvement. As you find cause to question your BRD effectiveness, compare your process for creating brd documents to this model. While few organizations are willing to invest in all of this effort up front (and it can be appear to be oppressive), laying this out as the gold standard sets the bar for where you can go. When flaws are found or systems don’t meet expectations, the project closure efforts should certainly involve looking at the shortcomings, comparing to this list and considering what additional pieces should be included next time to avoid the flaws, increase acceptance, or implement a solution that’s more relevant to the customer….” #Tony 2012-01-25 22:20
This comment caused me to pause and wonder if one could construct a BRD risk tolerance model based on the contents of the BRD. In other words, what is the risk tolerance if only certain best practice components are included in the BRD? And can the BRD risk tolerance be represented as a sliding scale. The purpose of this article is to propose a risk tolerance model as a sliding scale based on what is included in the contents of the BRD.

What Makes a Project Sponsor Approve the Business Requirement Document?

Risk tolerance. The project sponsor signs-off the business requirement document when the document matches or surpasses the risk tolerance of the sponsor. Note risk tolerance is relative to the sponsor and changes depending on the risk of the project. For example depending on the size of the company, a $10M project motivates the sponsor to have a much lower risk tolerance than a $10K project. Project sponsors could cite several other reasons for variable risk tolerance such as project complexity, resources, etc. The follow-up question and point of this article is: Can portions of the BRD be equated to various levels of risk tolerance?

A Proposed Business Requirement Document Risk Tolerance Model

Below is a BRD Risk Tolerance model (Figure 1). It depicts a cumulative risk tolerance incline starting from a high-risk tolerance (lower left corner) to a low-risk tolerance (upper right corner). Supporting the risk incline are seven best practices for writing a BRD. Under each best practice are key words describing the practice; for details see “Verifying Requirements Documentation” (1). On top of each best practice is a cumulative risk tolerance percentage. This percentage represents the cumulative risk the project sponsor assumes when BRD components are missing. For example, a risk tolerance of 50% equates to signing-off a BRD with all the best practices above the percentage (data requirements, transitional requirements, and traceability) missing from the BRD. Note that for every missing BRD component the probability of defects increases in the deliverable.

Figure 1. Business Requirements Document Tolerance Risk Model

First a Note on Project Risk

Before reading the below examples, note the percentages on the model are the sponsor risk tolerance for a project equated to “allowed” missing BRD components. As stated before, project risk depends on the characteristics of the project (i.e., size, complexity, cost/benefits, technology, resources, duration, etc.). The point here is that the project risk may well influence the project sponsor on what is an acceptable BRD.

BRD Risk Tolerance Model Examples

Below are examples of BRD risk tolerance using the model in Figure 1.

A project sponsor may well be justified assuming a high-risk tolerance with the BRD missing various components for a project entailing a small modification to an existing system (i.e., the cost of the BRD should not exceed the benefit of the modification).
A project sponsor could assume a low-risk tolerance missing any components in the BRD for a project providing a strategic new service for the business (i.e., product defects will have a major impact to the business).
If a project sponsor decides to accept a BRD with only process improvement targets and functional requirements documented, the sponsor assumes a risk tolerance of 70% (i.e., still assuming considerable risk of defects in the product or service).
And so on up and down the risk tolerance incline.

BRD Risk Tolerance Model Use

The business analyst can possibly use this model as a guide for management on the level of risk assumed when approving a BRD. On almost every project, there is a question on how much to document in the BRD. The answer lies within the range of the project sponsor’s BRD risk tolerance. Using this model, the business analyst can associate the BRD components with levels of risk tolerance. With this model plus the characteristics of the project, the project sponsor has enough information on the appropriate risk to assume.

Can This Model Be Used on an Agile Project?

Agile projects do not generate a formal BRD. User stories are the basis for iterative development. However, the product owner (sponsor) needs to consider risk tolerance when reviewing the product backlog and during the retrospective prior to approving the product release. Questions to consider:

Are process improvements targets addressed?
Are specific functional requirements present? Are they being addressed in business value order? Are dependencies considered?
Are nonfunctional requirements measured?
Are the business rules incorporated within the software decisions, access authorizations, and conditions?
Are data relationships and cardinalities present in the files?
If replacing a legacy system, are transitions planned?
Are the original scope features reflected in the user stories? Can cost/benefits be linked to the deliverables?

Summary

What is your opinion of the BRD Risk Tolerance model? I invite your comments. Perhaps you prefer a different component order or a different level of percentages on the Cumulative Risk Tolerance line. If you are a project sponsor needing to know what best practices should be used in a BRD, see the article cited in the reference.

References

Monteleone, Mark (2012), “Verifying Requirement Documentation,”

Don’t forget to leave your comments below.