Tag: Assessment

How to BUSINESS Analyze Stakeholder Requirements

Written by Marcos Ferrer on September 3, 2013. Posted in Articles.

Many BAs ask me where to get the business requirements when no one has done Enterprise Analysis or even a simple “Business Knead”. “That stuff is above my pay grade”, they say, “and even if it weren’t nobody gives us enough time or information about what is really going on. We barely have time to clean up today’s mess, never mind tomorrow’s.”

“Me three” is my reply. My experience and certification don’t change basic human nature. Even when I am invited to high-level meetings, no one thinks of me as a “business owner” or manager. The checks are written above my head, and many command structures still insist on top down flow only.

Stick with us (thanks to my anonymous class, who inspired months of blogs) as we transcend BABOK by explaining how (and why) to get something from nothing , and in the process raise your pay grade*.

Last month we tried to use ordinary analysis to break down stakeholder requirements driven by the need to cut costs, resulting in something like:

1. Internal Service Costs

Total Costs of Internal Service by Organizational Structure
1. Costs by Service Provider Department
  1. Costs by Service Provider Team
    1. Costs by Service Provider (???time/effort)
    2. ???Other incidental costs (overhead/supplies)
  2. ???
2. ???Costs by Service Recipient Department
  1. ???Costs by Service Recipient Team
    1. ???Costs by Service Recipient (time/effort)
    2. ???Other incidental costs (overhead/supplies)
  2. ???
3. Costs by Service Type
  1. ??? On boarding
  2. ??? Annual Training
  3. ??? IT Help Desk
  4. ??? HR Guidance
  5. ??? More…
4. Costs by Chances to Save Resources
  1. ???
  2. ???
5. More ???Cost Views…
  1. ???
  2. ???

2. ???Internal Service Benefits

???Etc.
???Left as an exercise for the reader, similar to above yet different.

I was so tempted to expand this list of trees**, but I decided to take a peek at the forest instead. Why?

Although we have tried to expand the original stakeholder requirement, it is still unclear what is or isn’t a priority. The focus so far seems to be on WHO DID WHAT. The BABOK says that BAs have general business knowledge. What do you know about measuring or enhancing employee performance? What are the impacts of singling persons or departments out? Short term? Long term?

It is not clear how knowing how much internal service is being done by whom for where will change costs or improve the business. At best we could decide to re-train (or fire) the lowest performers, and we will discover that (by definition) there aren’t many of those, and once fired, someone else will take their place. There might be a few VERY high performers, but they will not be reproducible as a general rule.

How many Michelangelos does it take to screw in a light bulb? How many non-Michelangelos does it take to paint a masterpiece? It is quite likely that most employees are doing the best they can in the circumstances, with statistical fluctuations over time, but no significant performance differences.

Blaming (even identifying) the workers to reduce costs is an organizational dead end. Many great leaders reject the use of the “Theory X” approach” (workers are lazy thieves who are best motivated by whippings and emotional abuse). These include Robert Townsend of Avis (“Up the Organization” remains relevant to this day), Douglas McGregor of MIT, and especially Edward Deming (“brought to you by the nice people who made your nice car that you can rely on”) among MANY other quality triumphs. Deming showed that in most cases job performance is randomly distributed among employees over time, once inputs, policies and tools are established.

Another high-level concept worth knowing is that the tyranny of numbers is a risk in any project (“Hey, we are paying $10 per bug found!”). Cutting costs is not a business goal by itself. If it were, the best approach would be to cease operations entirely, achieving zero costs. Finance mavens will recognize that investing zero has “opportunity costs”, and there is no way out – figure out how best to use resources, or stick them in your mattress to rot.

This makes us realize that the stakeholder requirements are not remotely robust or useful as imagined. They represent a literal attempt to monitor internal service costs, perhaps in an attempt to “be fair” and “spread the pain”, with no clue how these costs relate to the business success.

If we pursue such requirements, we are likely to create a system to track internal service costs that has little or no impact on the quality of decision-making. Worse, it might have too much impact on the quantity of decision-making (“look, department D is giving too much internal service this month, let’s dock their pay to re-motivate them to reduce the service”).

SO, what is the real business need? Cost control obviously matters, but how does that “high level abstract not quite a requirement as stated” relate to possible actual requirements? Let’s use a “MOST” analysis (Missions, Objectives, Strategies, Tactics) and see if it helps:

Let’s agree (for this blog) that many organizations have “high-level” missions that are a little “generic”; something like:

Be Customer Driven
Make Quality Everyone’s Business
Practice Respect For All
Maximize Efficiency, Effectiveness and Profitability

This may seem fluffy and devoid of substance (it is** :)), but we can use it as a starting point to re-imagine the stakeholder requirements. It would seem that the mission to “Maximize Efficiency” is the primary mission in play. Leaving out “Profitability” is the easy to commit error. When I trace to this level some PMs (not you, not you, resemblance to real people is a coincidence) tell me “everyone already knows that, don’t waste your time.” In spite of any resistance, no one can forbid me to know the organization mission, and use the knowledge to add value to stakeholders.

This seems like pure “Root Cause” business need stuff. Root cause stuff can be sensitive to discuss, and requires tremendous diplomacy, facilitation and values (don’t blame people) to do well. That is a different essay for some other day. In an attempt to work with this group of “internal service” stakeholders we will pretend to analyze the reasons that internal service is TOO costly:Click image to view larger.

OOPS! Depending on the actual root cause analysis (mine is made up for the blog, can you spot the big error?) cutting internal services might hurt effectiveness and profitability.

What would you do? Don’t hold back, the future of the organization will be impacted one way or another.

Hmmm…is the problem the root cause analysis, or is there a deeper problem? What is the root cause of this rather un-useful root cause analysis? WHO CAN OFFER AN ANSWER? Will James marry Oneida or stay in Paraguay? Is anybody out there?

Have fun!

* Pay grade ≠ pay amount – negotiation is a key competency and worth a try :).

** Not ! 🙂

*** A higher quality mission statement might be “Balance efficiency, effectiveness and profitability”. Maximizing everything sounds good (and seems simple) yet is just as hard as “Balancing”. The word “Balancing” does not hide the deeper truth that tradeoffs are usually necessary and too much simplicity can mislead.

Don’t forget to leave your comments below.

Unidentified Flying Objectives (UFOs)

Written by Michelle Nefdt on June 25, 2013. Posted in Articles.

I was recently engaged on an initiative which was motivated by a moderately articulated business need. The opportunity promised enormous improvements to the company’s enterprise capability. However, after the initiative kicked off we were propelled into an unnecessary journey of continuous improvement towards an ambiguous and evolving concept. This initiative was weighed down by unidentified flying objectives (UFOs).

UFOs refer to strategic irregularities in the business-sphere, which hover, appear, or dissolve when scrutinised. They generally tend to appear after the launching of unplanned strategic initiatives. UFOs are not easily identifiable or definable, unless the use of instrumentation such as scope scanners or feasibility radars are applied by classified authorities called Business Analysts.

UFOs display the following characteristics: they are shallow (insufficient), disc-shaped or round (recurring), and are capable of displaying luminosity (radiance). They shape-shift or evolve moving at high speeds, often counter to the strategic initiative underway.

In some instances, trying to decipher where UFOs originate from can place the Business Analyst at the risk of painstakingly attending to ongoing marginalised and unresolved issues.

Quite the opposite, SMART objectives are specific, time-related and measurable targets that a person (or system) aims to achieve. These are basic tools that underlie all planning and strategic activities, and serve as the basis for evaluating business performance.

Why is it we often don’t get objectives right? Leaders conduct their general business, approving and kicking off initiatives with good intentions to make people, systems, structure and processes better. However, when it comes down to the setting of objectives we are often crippled during the latter stages by misalignment between objectives, deliverables and performance. The setting of objectives is also impeded by limited organisational readiness, change management, scope, economic drivers, time, and resources. Correspondingly, success tends to be emphasised by the “delivery on time and within budget” mantra.

The strategy, objectives and measurement approach is vital for business analysis and delivery success. It is imperative to justify Why we are doing it, closely reinforced with the What, Where, Who, How and When (5W’s & H).

I have persevered by taking business leaders on a very simple journey to optimise their business initiative objectives and assure success using the following 5 steps:

Clarify what is driving the initiative. Is it a Problem, Opportunity or Need?
Translate the Problem, Opportunity or Need into Goals
Evaluate each Goal against SMART objectives and the 5W’s & H principles
Transform each Goal into a SMART objective
Identify how your SMART objective can be evaluated and re-evaluated to become SMARTER

The benefit of using this approach for business leaders is self-assurance in setting a clear vision with reliable measures for performance; and traceability from strategy through to delivery. A good alignment between SMART objectives, solutions and benefits will empower business leaders to make informed decisions and measure performance with confidence.

The Business Analyst is instrumental in aligning objectives to requirements and solutions for traceability management. For the Business Analyst, developing clarity of the objective(s) enables and adds value to business analysis delivery.

So travel forth at the speed of light and unlock those UFOs if you sense or observe them in your business activities. Leave behind a legacy and impart the above simple approach for business leaders to define, translate and transform UFOs into SMART objectives.

Which intuitive instruments do you use to sense, observe and investigate UFOs in your close encounters with the third kind?

How do you manage those UFOs into SMART objectives?

Don’t forget to leave your comments below.

A Business Analyst’s Best Friends: The QA Lead and their Team

Written by Angela Wick on February 19, 2013. Posted in Articles.

Successful BAs position themselves in the eye of the project storm. They are the calm, center point of a complex group of interrelated people, roles, and processes. BAs are in a prime position to ensure—when the project storm settles—that all pieces are connected and aligned to maximize value to the organization. In order to do this, BAs rely on strong relationships with many friends.

In January, I set the stage for a monthly series that describes the BA’s best friends. This month’s BA friends are the QA lead and their QA team.

How does QA benefit from a BA?

QA teams need BAs to provide clear requirements with context. QA teams need context in order to plan their testing strategy; by context I am referring to the set of circumstances, environment, and facts that surround a particular project, requirement, and/or solution

The QA Lead and their team members want to understand context for the project and for the requirements:

Why is the project important?
How does the project fit into the big picture of the organization?
How does the requirement fit into existing business processes?
What business scenarios trigger a requirement?

For example, BAs might provide a requirement to add a new button to a system screen, a screen mock up, or a lengthy list of outlined text requirements. The QA team cannot test these requirements properly unless they understand why/when a user would update the button and what events should be triggered by the new button, what capability does the button provide? What is the acceptance criteria for the requirement/story/design? How/When and in what situations will we know it is working?

What makes a top-notch BA from the QA team’s perspective?

Obviously, the tactical BA requirement skills are critical, but top-notch BAs bring a variety of soft skills to the project environment. The QA Lead appreciates BAs with these top-notch soft skills:

Effective Communicator
A BA with effective communication skills increases the efficiency of the QA Lead. If the QA Lead trusts the BA to communicate delays, issues, requirement changes, priority changes, etc., then the QA Lead can focus on testing resources and doesn’t need to waste time trying to chase down the BA or PM for project updates.

Excellent Organizer
BAs are responsible for creation and maintenance of the requirements package. Obviously, requirements are the primary input for test plans and test cases. QA teams want access to the most recent requirements. They do not want to get lost in the chaos of version control issues. They want to know when requirements change and where/how changes are documented. They want to know when and how outstanding requirement issues are resolved.

Respected and Knowledgeable Partner of Subject Matter Experts/Business Users
The QA Lead and the QA team members rely on the relationships the BA has with business users and SMEs. The BAs knowledge and partnerships are critical when QA teams need quick decisions about priorities, issues, and defects.

What frustrates a QA team about the BA role?

The QA team wants testable requirements from the BA. This sounds simple and obvious, but how would you define “testable”? Here are some tips for producing testable requirements:

Invite QA to participate in the requirement process. Including the QA team early in the elicitation process will help them gather context and will ensure the requirements process meets their needs.
Be precise: Avoid pronouns like “it”.
Be specific: Avoid terms like “many” or “all” or “most”. BAs need to list groups that are applicable or not applicable.
Identify Links or Dependencies: Be sure that QA understands the dependencies between features or requirements – visual models are a huge piece of doing this right!
Break it down: Be sure the requirement has been decomposed…it’s not divisible…can’t be broken into smaller requirements.
Describe Scenarios: If a requirement is only true in a specific business scenario, then describe the scenario in the requirements for the purpose of testing or link requirements with specific job functions or processes.

How to say no to a QA Lead?

Points of tension between a BA and the QA Lead tend to center around changes that would impact resources and timelines. Too frequently, QA time is cut short because of delays in analysis, design, or development. Often requirements change or features are added when system testing is already underway.

Here are a few examples of why and how a BA might say no to a QA Lead:

QA wants final requirements, but they are not complete yet. Be sure to proactively communicate any delays. Help the QA lead understand the impact of moving forward without complete requirements. Help them understand which pieces are incomplete, what is likely to change, and if some testing can move forward without a complete requirements package.
QA needs more time to complete testing. If the deadlines are negotiable, then it might be appropriate for the BA to work with the QA Lead to advocate for more testing time. If the deadlines are firm, the BA can help the QA Lead prioritize test cases by business need and risk level.
QA wants to save time by doing a thorough system test but skipping integration and regression testing. In some project environments, this might be acceptable and even common. If it introduces too much risk in your project, then you need to help your QA Lead understand the risks. If the QA Lead is willing to accept the risk, then you may need to escalate your concerns to the project manager or project sponsor.

How to influence a QA Lead to get what you need?

To influence the QA Lead a BA needs to understand how the QA Lead defines success. If the BA can frame their needs within the QA Lead’s definition of success, then the BA will have a better chance of getting needs met.

QA Leads want a successful testing cycle. In most cases, this means nothing major breaks when the system goes live. Other components of success might include: meeting deadlines, quick issue resolution, quick and correct defect resolution, and effective workarounds for unresolved issues.

If a BA needs to add ten new requirements to the QA workload, the BA should be prepared to communicate the priority, risks, and dependencies of the new requirements. The BA should be prepared to discuss how the QA team can be successful despite the new requirements.

How to communicate the value of the BA role to a QA Lead?

When initiating a project with a QA Lead, discuss expectations. Ask them what success means. Let them know about the skills and experience you bring to the project…especially the soft skills that will help the QA process run smoothly:

Requirement prioritization
Issue resolution
Risk management
Defect Resolution
Relationship Management with business
Problem solving and critical thinking

What do you think?

BAs: How do you make sure your requirements are testable?
QA Team Members-What are the characteristics and skills that the best BAs bring to a project team?

Don’t forget to leave your comments below.

Quality BA, Quality Outcomes

Written by Marcos Ferrer on February 5, 2013. Posted in Articles. 2 Comments on Quality BA, Quality Outcomes

A QA manager once asked me “What does the BABOK® say about QA?”. My response was uninformed and correct at the same time. I was so excited to be asked I was practically jumping up and down as I said “The best way to get quality outcomes is to work with the BABOK! We should talk more.”

I went to my electronic copy of the BABOK and searched for “QA”. I got one hit in the “Practitioners Reviewer” section:

“Richard L. Neighbarger, CSQA, CSQE.”

It made sense that a software quality expert contributed to the BABOK, but where was the QA content?

I figured out I should search for “quality assurance” just like all my readers did when they read the prior paragraph, only slower than they did, as usual. I found many hits for quality, but only six for “quality assurance”. Here is the most relevant of six hits that I found (try it – it is fun), and the one I shared, still excited, with the QA manager:

“A business analyst is any person who performs…the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.”

“You’re a BA too!” I shared, in my usual reserved manner 🙂 “If you helped the BAs develop better business cases and requirements management and business use cases and iterative improvement you would know what to test and when!”.

To my surprise, the QA manager was not excited. “That’s not it”, she said. “Quality testing starts at the beginning, not at the end”. “Exactly”, I said. No product or software can receive quality by inspection – the quality is already there, or it isn’t. Every stage of the process needs quality. If we work together from the earliest vision requirements, through a quality business case, and thorough elicitation, analysis and validation, we are bound to get higher quality software outcomes” I waited for her agreement, but it never came.

“The BAs need to produce better requirements, ones that I can test.” I’m not going to do their job for them, but I will QA the job they do”, she finished, frustrated. “How do you know they are doing a bad job?” I asked. “We get all the complaints”, she replied. “The systems never do everything they are supposed to do.”

Inside, I am grinning, trying not to laugh from the ambiguity of contradictory statements. “How do you know what the systems are supposed to do?” She stopped to think, and finally said “I don’t have time for this”, and we never spoke again.

How do we know that our solution requirements [analyzed from business and stakeholder requirements] will be relevant? We can make them testable (and we do) and still we are missing requirements. There are at least two answers:

Nobody complains about a system that they aren’t using. Complaints are a sign of some success. Keep doing your job, and seek continuous improvement where possible, and sleep in peace.
Turning a “Vision” into a high quality business case, one that informs further requirements drill down.

Next month: How to turn a Vision into a high (higher) quality business case.

Until we meet, have fun!

Don`t forget to leave your comments below.

How Business Analysts Can Help Failed Projects Succeed

Written by Jarett Hailes on January 8, 2013. Posted in Articles. 2 Comments on How Business Analysts Can Help Failed Projects Succeed

I recently completed a post-implementation review for an enterprise-wide project I managed that successfully achieved all its objectives. The client was very happy with the results and all stakeholders agreed the project was executed very efficiently and implemented with no negative impact on the organization’s regular operations. The best part? The project had been attempted twice before but had failed and been aborted both times. We were able to overcome the previous failures and deliver essential capabilities needed to prepare the organization for the future.

Overcoming previously failed projects (or ones that are near failure) can be challenging. If a project has been tried before and failed, a negative mindset towards the project can be established that presents a barrier for future success. Some companies may even convince themselves that they don’t really need what the project set out to accomplish. Luckily, business analysts can play an integral role in overcoming these challenges and ensuring the project is successful in its new incarnation. Below are the key areas where BAs can enhance the likelihood of success.

Understand the Reasons for Failure

As the often-used adage goes, “those who fail to learn from history are doomed to repeat it.” In order to avoid the same fate as the previous failures, you need to understand the reasons why they failed and learn what needs to change in order to succeed. Business analysts can perform root cause analyses on the previous failures and work with the project’s leadership and stakeholders to see what lessons can be learned. This can involve everything from document reviews to conducting interviews and assessing solutions currently in place. Some of the key areas to assess are:

Organizational: Did the project have the wrong people involved on the project from the leadership and the executive sponsor through to the project team’s personnel?
Cultural: Did the organization not have the right attitude towards the project or enough collective belief in its potential to succeed?
Technical: Did the project fail because the wrong technology was selected or built? Did the technology have insufficient capabilities to support what was needed?
Procedural: Did the projects not follow appropriate standards or methodologies to increase their likelihood of success? Were there critical errors in the execution or omission of certain tasks (for example, insufficient communications, ambiguous project planning or improper project change controls)?
Environmental: Was there something that occurred or was present in the organization’s market or political environment that made the project’s success untenable?
Iron Triangle Factors: Were the finances, scope and timelines originally set out reasonable, or were some of these factors inappropriate or too hopeful given other constraints?

Recognize What’s Changed

Once the root causes are identified, the business analyst can develop proposed approaches to avoid, eliminate or address the issues that caused the previous projects to fail. Part of this planning exercise should involve assessing and documenting which of the above factors have changed. For example, personnel changes with key stakeholder areas may have shifted the cultural attitude towards the project. Or perhaps the marketplace has changed and the need to accomplish the project’s objectives is more acute than ever.

For each item where there has been a material change, document whether the change has increased or decreased the likelihood of the project succeeding as well as if the project is now more or less needed as a result. Aggregate these results and use them to assess whether the time is right to go ahead with the project once again. Sometimes, not enough has changed to really improve the project’s chance of success. Provided the business analyst is involved in the new project’s early stages, this should be highlighted to management to help them decide if the project should be undertaken at this time.

Adjust the Framework

Review the scope and objectives of the previous projects and assess what components are still needed today. Where possible, remove items that are no longer necessary or that greatly increase the probability of failure. Some items may be able to be deferred for a future phase once the project has demonstrated that it can achieve some initial successes.

From a business analyst’s perspective, this can entail reviewing requirements, project charters, plans and close-out documents, and organizational strategic plans. The BA may also perform a current state assessment to determine if any of the previous project’s objectives are already met. Based on an assessment of what matters to the organization today, the project team can adjust the framework for the new project to increase the chances of success.

For my recent project, we removed all ‘nice to have’ elements from the scope to focus on the critical components that needed to be completed. This not only reduced the cost and timelines for the project, but also increased the ability for the project team to communicate the vision and nature of the project to the entire organization since the objectives were more concise. This in turn improved awareness and buy-in from all stakeholders.

Win Over Skeptics

Clearly communicating why this project’s outcome will be different than the previous failures will help address the natural tendency to be skeptical about resurrecting a failed project. Ideally, the project can be reframed in the current context so that it can be considered fresh in the minds of key stakeholders, while still demonstrating the lessons from previous failures will be used to make the new project successful. Stories are an excellent way to help convey this message in a simple but effective format.

For a previous project I needed to show the organization’s leadership why they should re-initiate a project after it had failed. I communicated to the organization’s leadership how critical the project was to future high-priority endeavours. There were over 15 initiatives they were interested in pursuing that all depended on the successful implementation of the failed project, which was easily communicated using a hub and spoke diagram. Additionally, the organization’s mandate had begun to shift, which increased the need to ensure the project was tackled again. I used analogies representing their typical customers to show why it was important to get this project completed. These helped the leaders see the need for the project and give it the green light.

Business analysts can also highlight the need for a project on the ground while they are performing their current state assessment. As pain points are identified, stakeholders often begin to realize the need for change.This can be reinforced when the pain points are summarized and communicated to all groups.

Get the Commitment Needed for Success

In order for projects to succeed, all the key players need to be committed to its success. This means that leadership needs to be active and visible throughout the project and are willing to put in the time needed to help guide the project through its lifecycle. Sufficient funding for people and technology needs to be in place as well. The people who will take the project’s outputs and ultimately realize the benefits of the project need to also be committed to working through the process even when challenges arise. Overall, a coalition must be built that will be responsible for working with less enthusiastic stakeholders to keep the project from losing its momentum.

Business analysts play a key role in this aspect throughout the project by maintaining an up-to-date and relevant stakeholder analysis. Sometimes the attitudes, influence and engagement of various stakeholders can change over time. When BAs interact with stakeholders, they can continually update their analysis and work with the project’s leaders to address changes that could negatively impact the project.

Achieving Success Through Business Analysis

Business analysts play a key role in helping previously failed or challenged projects reach the finish line. The ability to understand why something went wrong, what to address from the failure, how to adapt to changing circumstances and how to engage the right people and get them on board are methods that good BAs possess and can leverage in this situation. Instead of fearing a previously failed project, business analysts can look at the opportunity to use their skills to ultimately bring the project to a successful close.

Don’t forget to leave your comments below.