Business Analysis and Successful Outcomes

From the Building the Foundation: The BOK on BA Blog
by , , ,
A new collaborative blog featuring the contributions from the core team members of PMI's Foundational Standard in Business Analysis. This blog will provide the community with insight into PMI's development of the standard to generate professional discussions about the content in advance of the scheduled reviews.

About this Blog

RSS

View Posts By:

Laura Paton
Joy Beatty
Cheryl Lee
Sue Burk

Recent Posts

PMI's Newest BA Standard and the PMI-PBA Credential

An Update On PMI's Consensus Based BA Standard: The Final Phase

The Link Between Business Analysis and Project Management Processes

Party Like a Business Analysis Rock Star!

PMI’s Business Analysis Standard – What You Have to Gain


Categories: Business Analysis


In my previous post, I talked about the need for executive buy-in on business analysis activities and some ideas on how to grab their attention. And as I mentioned in that post, they are not our target audience for PMI’s foundational standard on business analysis so we need to find other ways to win their support. In this post, I’ll explore another avenue to attract executive attention—­delivering successful outcomes.

Executives care about the business outcomes they are funding with their projects. As business analysts, we have to show the link between our analysis and the project’s success. First, we need to measure whether we’ve met project goals or delivered successful outcomes.

But how do we measure that? What should we even be measuring? Should we measure a reduction in missed requirements? Or whether our business analysis deliverables are done on time? No! (Well, at least not for the purpose of getting your executive team to buy into the value of the business analysis role.)

A phrase I love to say quite often: remember, requirements are just a means to an end.

At the end of the day, doing good business analysis work or producing perfect requirements is not actually useful if it doesn’t lead to successful outcomes. Launching successful products is a worthy end goal. Delivering business outcomes is a worthy end goal. Delivering the desired business value is a worthy end goal. Business analysis, I’m sorry to say, is not actually a worthy end goal.

That said, business analysis helps identify the business problems that need to be solved or the opportunities that can be capitalized on. Business analysis helps elicit the objectives the team is striving to deliver. We help identify the risks that will keep us from being successful, the assumptions about our objectives that might derail us, and the requirements that help ensure we construct the solution that delivers success. We work in lockstep with our business stakeholders and IT stakeholders every day to enable alignment between the organizations, so that the solutions delivered solve the business problems. (The Needs Assessment chapter of the Business Analysis for Practitioners: A Practice Guide describes identifying problems and opportunities in more detail.)

So the good news is that business analysis is 100% necessary to deliver those aforementioned worthy end goals. And while executives don’t all value business analysis yet, they do in fact value business outcomes. And therein lies the key to their hearts … or minds at least! If we can help deliver successful projects, then we can be reassured that the business analysis we perform is successful, which hopefully leads to executives supporting our cause.

Some takeaway points to think about:

  • Define measurable business objectives: Do you have these defined for every project you work on? The only way you can deliver successful business outcomes is to understand what success actually is. Business Analysis for Practitioners: A Practice Guide describes Goal Models and Business Objective Models as mechanisms to capture these in chapter 4.
  • Plan to measure: Surprisingly, most organizations don’t come back to measure objectives after the fact, so plan for how measurement will happen (including building in features to support measuring success if needed).
  • Go back and measure: When its time, measure whether the objectives or success metrics were achieved. Failure is OK as long as you grow from it. And you can’t grow if you don’t know you even failed, so don’t be afraid to measure this.
  • Report on success (or lack thereof): Summarize the results and make sure they are reported to executives.

I’d love to hear what others’ experiences are with defining success measures and actually measuring them. I think this is one of the hardest things we do as business analysts, so please share with us your successes, failures, funny stories, horror stories, or questions you want to pose!

If you are interested in learning more about performance measurement, you'll want to take a look at PMI's Foundational Standard on Business Analysis when it comes out for public review in 2017!

Posted by Joy Beatty on: May 06, 2016 11:35 AM | Permalink

Comments (5)

Please login or join to subscribe to this item
Thank you for sharing. Sorry if I missunderstood but one thing I believe we need to avoid is to talk about "IT stakeholders". That is an old definition of business analysis that changed after the first BABOK version. We work with stakeholders at any level in the organization and belonging to any layer inside the organizational architecture (sometimes there is not an IT component inside the solution). About success, there is a lot of debate outside there. I think we need to clear understand the different items we need to take into account. Solution is equal to "the thing" (product/service/result) to be created and "the process" (project) to create it will be defined from the solution. And the solution is the mean to achieve business objectives. But when you analyze some project success metrics you will find that belongs to the solution and would not be assigned to the process.

Thanks Sergio, so I agree we need to look at both IT and business stakeholders. OFTEN though CIOs are the ones funding business analysis, so that's why I think of them first.

To your second point, I agree you might have project success metrics too. But at the end of the day, if your project didn't successfully implement the product, then arguably the project wasn't succesful.

Thank you very much for your time. I would say that I do not agree about CIOs are the ones funding business analysis but to be honest I can say this based on my personal experience and that is not enough. Besides that I hope that CIOs will not be the ones funding business analysis. In my personal experience I have the opportunity to teach the CIOs because they took the business analyst role at high level. About the product implementation, I think we need to make a distinction. Project manager is accountable for the activities to implement the product if that activities exist inside the project plan. So, if all related activities are performed as planned and some project metrics have been defined to meassure that then the project can not be unsuccesful at least in this point. Each time project success metrics are defined the project manager must be take careful and not assign product success metrics as project success metrics.

I second Sergio: CIOs are often funding BAs, but these are more BAs supporting IT products. Many (bigger) companies I came across are now more and more placing BAs in business deparments - and therefore BAs are becoming funded by business not IT. Smaller companies contract consultants as BAs - also more and more from business side. This is because business gets more self-confident in looking for solutions. Some IT departments offer BA work as service to business departments - especially in smaller companies where there's not enough work to to to employ BA's in business departments.

I second Sergio: CIOs are often funding BAs, but these are more BAs supporting IT products. Many (bigger) companies I came across are now more and more placing BAs in business deparments - and therefore BAs are becoming funded by business not IT. Smaller companies contract consultants as BAs - also more and more from business side. This is because business gets more self-confident in looking for solutions. Some IT departments offer BA work as service to business departments - especially in smaller companies where there's not enough work to to to employ BA's in business departments.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"It is a waste of energy to be angry with a man who behaves badly, just as it is to be angry with a car that won't go."

- Bertrand Russell

ADVERTISEMENT

Sponsors