Tag: Business Analysis

Your Backlog Might Be Broken If…Part 1

Written by Angela Wick on October 13, 2015. Posted in Articles.

How does your team build and manage their backlog? Is your current process working well or does your backlog need a reboot?

One of the most overlooked factors of team success or failure is the health the backlog. Success or failure often hinges on the amount of love and attention an organization gives to their queue of needs, features, feedback, bugs, and enhancements.

I am concerned that teams and organizations continue to focus too much on getting items developed faster vs. developing the right items—the items that add the most value to the organization. Traditional and Agile teams alike are experiencing these challenges.

Poor backlog management yields inefficient and ineffective projects/iterations/sprints/releases, and ultimately less value delivered overall. If you neglect your backlog and let it wander off, unattended, into the crowded project circus, it will dart to and fro distracted by every bright shiny object. Your team’s sense of direction will suffer, objectives will be murky, requirements will churn and value will be lost.

Successful teams give their backlog lots of TLC. They approach their backlog with strategic purpose—continuously reevaluating what’s most important and shifting it to the front of the queue. The items in the queue shift and evolve, but the overall goals and objectives are clear, the process is transparent, and teams gain efficiency.

Strong backlog management practices:

Keep teams focused
Deliver value quickly
Inspire innovation and creativity
Mitigate negative risk

It can be quite difficult for organizations to assess objectively the health of their backlog management processes and even more difficult to implement changes. These processes are often unwritten and entrenched years of evolving organizational politics, culture, and values. But admitting you have a problem is always the first step, so I’ve identified a few indicators that might shine a light on your broken backlog. Read and ponder the first two indicators this month and I’ll give you a few more to think about in Part 2 next month!

Related Article: 7 Habits of Highly Effective Business Analysts

Your backlog might be broken if…it is not prioritized.

How does your backlog get prioritized? What criteria are used? A healthy backlog delivers only the right work at the right time to the team. The most important things need to slide to the top and should be prioritized by value to the organization.

Prioritizing the backlog in traditional and Agile environments entails elicitation, analysis, and decision-making. As BAs and PMs, we may be the one facilitating this process, or as Product Owners we may own the decisions on the priorities. Either way, it’s our job to keep the development stream clean! Only items that yield true value to the organization should flow into development. We use tried and true analysis and elicitation techniques to ensure that each item is understood from an end-user and organizational perspective so it can be effectively prioritized.

If you are like many organizations your backlog may be 100s if not 1000s of items long. That seems impossible to prioritize! So, how do you deal with a backlog that is simply too long? Here are a few ideas:

Make sure the backlog is not just something the technical team is managing; it needs to be aligned with the business. The right business drivers should guide the backlog prioritization.
The top 10 (or about 10) items should be known and rank prioritized by value
When an item hits the top 10, elaborate additional details and requirements
The rest of the backlog can be grouped into like categories. Please do not categorize them by technical application, component or task, but rather by feature, process, or something of tangible business value that is understandable to the business decision makers.
Revisit the top 10 as often as needed to always have a top 10 in place.
Track the time something has been in the backlog…. seriously consider deleting/archiving the item if it remains in the backlog and not making the top 10 for six months (or whatever timeframe seems appropriate).
Make sure everyone knows the top 10 ranked priorities and get everyone focused on #1!

Warning: If your team seems to be using FIFO (first in first out) or SWGG (squeaky wheel gets the grease) processes for backlog management, the team is at high risk for not delivering value and spending the organizations resources appropriately.

Your backlog might be broken if…it is inside out.

Does your backlog focus inside out (technology and technical tasks) or outside in (user and business point of view)?

Backlog items should be written from the user or business perspective, NOT from the perspective of the team or the technology components. A piece of technology, all by itself, does not typically provide value to the user, especially in our complex integrated environments.

To prioritize the backlog we need to understand the value each item provides by writing our backlog items in ways that express the value to the organization, end customer or end user.

When a user makes an online purchase, they do not see separate applications. They browse items, make a purchase, pay, and receive items. Users do not get value from the web page alone, the product database alone, or the payment processor alone — the user gets value from the integrated experience. If your backlog items have names like “code profile page” or “write SQL for DB call” or “map data for credit card validation,” your backlog might be broken.

Backlog items should express the WHO, WHAT, and WHY, in terms that the end customer understands and can be prioritized by business leaders.

Some ideas to transition poorly written backlog items:

Item 1: Add a SAVE button at the bottom of the screen.

Rewritten: Give the customers the ability to save an order mid-stream while entering all of the order data so that they do not risk losing information already entered if they step away or get interrupted while entering.

Item 2: Upgrade the database to the new version

Rewritten: For customers to be able to enter orders after Oct 1st, 2015 we need to upgrade the database to the new version so that the version works on the operating system.

Item 3: Code the server file to add the new volume properties

Rewritten: To serve our expanding customer volumes we need to update the server file to accommodate more users at one time.

Is your backlog broken?

As you evaluate your backlog this month, ask yourself these important questions:

• How are our priorities really being determined?
• Are the items on our backlog written in a way that makes it easy to understand value and identify priorities?

Our backlog health check will continue next month when I share a few more “broken backlog” indicators in part two of this article!

There must be 50 Ways to Write a Great User Story

Written by Judith Mary Khan on October 12, 2015. Posted in Articles. 1 Comment on There must be 50 Ways to Write a Great User Story

The user story is the center-point for the Agile business analyst to perform work. From the story, everything else can be facilitated, requirements definition and communication, development and QA tasks that will bring it to completion, tracking and reporting for the team, management, and even the customer, and even knowledge transfer for future team mates. All of this is possible with the well-written story.

During the time that I have worked as an Agile BA, I have seen stories used in a broad spectrum of manners, those that are completely cryptic in what their purpose is, those that read more like random defects recorded by IT and/or non-IT people, those that are largely dependent on tribal knowledge, and those that are concise, clear, and deliver all the important pieces to be truly useful to all the team, as well as non-scrum team stakeholders.

I recently decided that while the story can be used in numerous ways, a good story will have certain attributes. Check the list that follows and see if there are more ways to write a good story. In an Agile team, the flexibility will be built into it by doing what makes the most sense to your unique project and your unique team. The rigueur of waterfall methodologies will not limit the Agile BA to a strict set of requirements to fulfill in getting acceptance of the requirements documentation. It will also expand the BA’s capability to communicate across teams and simultaneously contribute to the library of project documentation.

Keep in mind, as the owner of the user story, seek to communicate efficiently, and with clarity. Do not bury the meanings, purposes, objectives in verbiage that is not readily accessible to the spectrum of stakeholders that will be the consumers of the story. In depth technical details, and even details of business process information can be included in the story, but as a subtask requirement, or an image or attachment to the story. Keep your headline reader ready! This applies to Developers and other technical team members to the business customer and executives. Make your handprint on the story by offering clarity, versus one that furthers confusion.

How you write a great story is up to your own project and style, but make sure it has these qualities.

Here are a few ideas:

A great headline reads like a story, not a puzzling technical paraphrase.
A description that cuts to the chase and is readable by all scrum team members.
Use story notes. If this is available, capture and describe aspects and details beyond the description.
Capture the tasks involved for specifying the requirements, the work of the Developers, and the criteria for QA activities. My current team makes this quick to grasp with prefixes to indicate which team member is responsible, such as ‘DEV’, ‘QA’, etc.
Clear acceptance points or criteria are written so that any business analyst can walk through the deliverable and give it a yes or no to pass for acceptance, or to pick up the workflow. It should be cross-team member ready.
A workflow that makes common sense and uses verbiage that can be readily understood. This workflow should be visible to all users, and permissions granted only for those who are in the appropriate role to select that workflow step.
The right screen shots should be attached, but only if needed.
Attachments can serve as directly related to fulfillment of the story, and become a powerful reference tool in future use when investigating the history of a feature or whatever was important to the story. Meaningful and supporting attachments can also guide the knowledge transfer when new team members join.
Comments should be direct, and to the point. This is all too often overused, for comments that do not need to be captured and reread. Valuable comments are readable, complete, and understandable. Any ‘next steps’ or action items that come out of a comment need to be clearly stated.
Use the story points to track, communicate, and reflect the best estimating available from the team. A lot of skill goes into good estimating and the various team members have a lot to offer. Make sure that all voices are heard, especially from QA and UAT.
Use your story to facilitate prioritization. Keep the ranking within the story itself. This can then be ready to use when reviewed, reported, analyzed for metrics. The PM, and the dashboards that can be created will thank you.
More… employ the elements that will make it valuable to your team and efforts. Agile allows options, and as the BA, you can facilitate it.
More as you can think of them!

All of these pieces work interdependently to define, communicate, and deliver requirements. The Agile BA is the one who ushers the story, facilitates the collection of story components, and gives it a consistent tone, style, and voice.

The Value of Business Analysis: Storytelling

Written by Aaron Whittenberger on October 6, 2015. Posted in Articles. 95 Comments on The Value of Business Analysis: Storytelling

One of the main duties of the IT Business Analyst, or Business Systems Analyst, is to document requirements for software development projects. Many organizations believe this is the only role of the IT Business Analyst and utilize them only in this very narrow scope of duties. Organizations that recognize the true strategic value that Business Analysts can bring to the organization will gain a competitive advantage in the marketplace.

However, even if the organization defines the role of the Business Systems Analyst very narrowly to requirements documentation, those Systems Analysts can put the word “business” back into their role and show the organization the value they can bring to the table. They can show management and the organization their value by going beyond documentation of requirements to telling the story of the project and its business solution. Document the requirements of the project as management and the organization expects you to, but then package those requirements into a story that will tell anyone, even those unfamiliar, all about the project. So how do you start?

Business Case

The business case for the project defines the business problem that the sponsor wishes to have resolved. It should define the benefits of the project and costs – thereby a cost-benefit-analysis, strategic alignment with organizational goals, business requirements, rough duration estimates, and if known at this time, alternative solutions. The document is the one that the organizational project approval board reviews to approve and prioritize projects. These approved and prioritized projects make up the project portfolio that needs to be managed to deliver the maximum value and competitive advantage to the organization. This is another value of business analysis, but that is a story for another day.

Define the True Business Need

Often, symptoms of the true business need or problem are included in the business case. They are often statements of business stakeholders, what they experience in their work, or their pain points. This is where the Business Analyst will ask “Why” to drive to the true business need. Once you get to that true business need, you should also define the contributing conditions that are causing this business need.

Scope

It is true that the Project Manager defines and manages project scope, but the Business Analyst defines and manages solution scope. Solution scope may be defined more narrowly, or more widely than project scope. There may be multiple components to the solution to a project; each component will have the scope of that solution. Solution scope may become wider than the project because the solution interacts with downstream systems. When you tell the story of a project, you must mention the scope of the project and the solution. These may be links to scope documentation, but should include more definition that is learned during the project.

Related Article: The Power of Story in Business Analysis

Requirements and Business Rules

Business rules are defined prior to project initiation. Define stakeholder, solution, transition requirements and business rules during the discovery phase of the project. These may be defined in multiple documents like a Business Requirements Document, Functional Requirements Document, System Design Specifications, or documents of other names. Include any assumptions, constraints and dependencies related to those requirements. Defining these requirements and business rules is the main duties of the Business Systems Analyst and should be included as the meat of the requirements package.

Business Glossary (Glossary of Terms)

An often missed part of a requirements package is a glossary of terms important to the project. These are often business terms for the business unit(s) for which the project is to deliver a solution. For product or software project, a technical team is assisting to deliver the solution to the business unit(s), and may not be familiar with the business terms of that business unit(s). As noted in the introduction of this article, the requirements package should tell the story of the project to those unfamiliar with the project; therefore a business glossary is necessary to ensure your audience understands the package.

Pictures

A picture is worth a thousand words. They also help the audience consume and understand content much quicker than text. This should start in the scope section with some type of scope diagram, such as a project functional decomposition or context diagram. There are several business analysis techniques that deliver a picture or diagram to its audience; these include business model canvas, data flow diagrams, data modeling, decision modeling, mind mapping, organizational modeling, state diagrams, process flows, and prototyping to name a few. Any picture, model or diagram developed during the project should be included in the requirements package.

Use Cases

Use cases are an effective business analysis technique to understand the interaction between an actor, or actors, and a system. Use cases can be used to highlight a specific process within the scope of the solution to help the audience understand the specifics and reasons for the process.

Lessons Learned

The project team learns a lot during the discovery phase of the project. Some organizations may call this the analysis and design phase(s) of the project. These lessons are usually learned after the creation of the business case and scope documents; and therefore, should be included in the requirements package.

Why?

Hopefully by now you are asking yourself “why would I create this one all-inclusive document in addition to all the other documentation created during a project?” It may even sound to you like duplication of effort or documentation, and I hope you don’t dismiss it as such. The value of creating this one package was outlined in the introduction to this article – to tell the story of the project. It should tell someone unfamiliar with the project, or business unit(s) involved, all about the project, its purpose, scope, business problem, requirements, and solution.

As a person unfamiliar with the project, how would you find out these things about the project? How would you know what documents to read? In what order would you read these documents? The requirements package wraps all this documentation into one neat package for easily readability and shows in the order that documentation of the project should be read in order to know what happened during the project. This is how you tell the story of the project and increase your value as a business analyst to the organization.

Simplicity – The Newest Craze in Agile

Written by Robert Galen on October 6, 2015. Posted in Articles.

My motivation for this article isn’t to slam or denigrate any of the scaling frameworks (and those that continue to emerge). Full disclosure, I’m a SAFE SPC, and I find significant value in leveraging some framework for Agile at scale.

That being said, I have a great concern that I want to share. I think we’re losing some of the original thinking and approaches from early instances of Agile. The methods grew out of small teams doing big things.

But as we’ve gone forward and introduced agility into larger instances (enterprises, large-scale companies, distributed projects, etc.), I’m afraid that we’re losing the very essence of agility that made it attractive in the first place. Things like:

Small teams
Simple, focused solutions
Just enough
Face-to-face collaboration
Working code
High-value delivery

These seem to have lost their attractiveness. I want to share a series of stories that I think (hope) might shine a light on returning to our Agile roots. Or at the very least, might get you to rethink some things.

First Story – Remember Wordstar?

I doubt whether many of the readers will recognize this program. But at one point, pre-Microsoft Word in the early to mid-1980s, Wordstar was the premier word processor on the planet. It was supported on something called CP/M and later on DOS.

What was amazing about Wordstar, at least to me, was that it fit into 64k of RAM. In fact, it fit into less than that because it had to share that space with the operating system. Imagine that, a simple, but full-function word processor fitting into less than 64k of RAM. Clearly the designers had to make incredibly tough choices as to what features were critical to the program. In today’s terminology, we call it an MMP or Minimal Marketable Product.

Did folks complain about missing features and capabilities? You bet! But that didn’t stop a whole generation of programmers from being able to use Wordstar to get the jobs done.

I reminisce about Wordstar and similar programs because I think today we’ve gotten a bit lazy. Since we have hardware resources to spare, we design bloated products just to prove that we can design 100 complex ways to do inherently simple things. It’s easier than thinking about simple designs and simple solutions to complex problems. When Agile came around, it placed a renewed focus on design simplicity, heck simplicity everywhere. Getting to the essence of a problem and solving…just it.

I think we could relearn something important by revisiting those software design goals from so long ago…

The Lesson: Wordstar had hardware limitations that forced the developers to minimize the product to an MMP feature set. Today we would do well to imagine that we had a small hardware footprint to encourage us to be creative, innovative, and frugal in our applications.

Related Article: Agile is Focused on Capacity Equalization

Second Story – Unix

The beginning of Unix is another one of those minimalist stories. It was developed by a handful of developers in the early 1970s at AT&T Bell Labs. While some of the early Unix contributors were considered super-programmers, nonetheless it’s another case where a small group did big things.

As Unix’s popularity grew, the software got bigger of course. However, I still remember the “erector set” nature of basic Unix commands and how you could “pipe them together” to do more complex tasks. The architecture itself was simple, yet elegant, and it remained that way as it historically expanded.

In the early 1990’s, Linus Torvalds famously released an Open Source version of Unix called Linux. In the beginning, it too was incredibly small. He initially worked on it himself and then with a small group of dedicated maintainers. Again, Linux has grown well beyond its original size constraints. But both systems are clear examples of elegantly designed small systems that had a huge impact on our technology.

The Lesson: Again simplicity, but not only that, the beginning of the realization that a small group of programmers could deliver big, useful things. It didn’t take a team the size of Montana to deliver meaningful products or applications.

Third Story – Bloatware and Pareto

I’ve been using a quote for quite a long time in my classes. I can’t remember where I’ve seen it before, but it goes like this:

Less than 20% of the features of Microsoft Word are actually used by human beings on the planet earth. So how did the other 80% of features get in there if they have no (lean) value?

Competitive pressures
Marketing checklists
Flat out guesses
Gold plating
Feature creep
Youthful enthusiasm

All probably contributed. But at the end of the day, the only determinant of value should be REAL customer usage. Now if only Microsoft would agree to trim Word down to size.

Here’s a supporting quote by Kelly Waters from a 2007 www.allaboutAgile.com blog post:

Anyway, back to my point about the 80/20 rule, Microsoft’s own research found that the average user of Word uses only *8%* of the functionality. That’s 8%! And I wouldn’t mind betting at least 80% of us use the same 8% too! [assertion]. If Microsoft had developed only the important 8% of Word, maybe they could still have captured the same market share? Maybe, maybe not; sadly we will never know.
http://www.allaboutAgile.com/Agile-principle-8-enough-is-enough/

The article also alludes to leveraging the Pareto Principle when it comes to mining for customer features that truly make a difference. Otherwise known as the 80/20 Rule, here’s an article I shared about Pareto in another context.

The Lesson: Pareto is alive and well and applicable in everything we do in software. We need to continue to look for the 20% of features that deliver 80% or more of the value to our clients. Then deliver that FIRST before we worry about the edge cases.

Fourth Story – Chrysler C3

The original Chrysler C3 Extreme Programming project was the inspiration behind the Extreme Programming Agile approach. I wasn’t part of the project, but my understanding is that it was a typical, large-scale, Waterfall project that failed. There were perhaps 50+ folks who were working on the effort for over a year.

When it was initially cancelled, the project had been a dismal failure. The story goes that Kent Beck made a case for a much smaller team to use a different approach to try and recover the project. The team was about 20% of the original team size.

As you can guess, the team recovered the project and delivered a workable HR system. But the project never met the overall goals and was ultimately cancelled again in 2000.

This was the project where Kent, Ron Jeffries, and several other famous Agilists earned their chops. It also inspired XP as a popular methodology and initiated the movement, as it exists today.

The majority of software projects today make use of XP practices even if they’re not Agile. Those early XP experiments in things like pair programming, refactoring, and continuous integration have proven to be incredibly sound ways to build software iteratively.

The lesson: A small group of focused technical folks can do big things IF they apply the principles and practices of the Agile manifesto. Bigger isn’t necessarily better.

Fifth Story – iContact vs. MailChimp

I worked at iContact from 2009 – 2012. iContact provided a SaaS email marketing application that competed primarily with Constant Contact and MailChimp. At the time, we mostly focused on MailChimp because of their phenomenal customer growth.

Beyond MailChimp being a direct competitor, we were both Agile shops. And I was at the time and still am enamored with the nimbleness of MailChimp.

In 2012, iContact had nearly 400 employees. Around the same time, MailChimp was reported to have approximately 80 employees. So they were 20% of our size. I just did a LinkedIn search for MailChimp and it showed 106 employees. So they are still relatively small and nimble.

What’s my point?

Well, to put it bluntly, MailChimp cleaned our clock! They kicked our butt when it came to head-to-head comparative measures of our SMB email marketing applications. They were quicker to deliver features. They were quicker to change and pivot directions. They were more creative, bringing out a freemium offering that drove tremendous growth A strategy that we tried to copy and failed.

I’m currently a MailChimp customer, and I’m amazed how insightful they are into the needs of their customers and how frequently they bring out new and, more importantly, useful features.

If you extrapolated from the numbers, we had about 100 people in technology. Mailchimp would have had 20-30 of the same folks developing, deploying and supporting their products.

I was at the time and still am envious of them. They were truly Agile in spirit and action. They had an incredibly small team that built and evolved a robust email platform that simply rocked in its market space.

The Lesson: We all seem to have a tendency to bring more people to bear on problems, under the impression that we’ll achieve our goals faster. However, that often doesn’t happen. Instead focusing a small, Agile team on thoughtful, high-impact client goals seems to be a winning strategy.

BTW: there are numerous other companies that are quite small, but that do incredible things. One historical example is 37 Signals the makers of Basecamp. Another is Menlo Innovations, who focuses on application development.

Final Story – ChannelAdvisor

Here is one final story just to finish whetting your appetite around my article themes.

This comes from my personal experience. During 2007 – 2009 I worked as an Agile coach and leader at a company called ChannelAdvisor here in Raleigh, North Carolina. As with iContact, ChannelAdvisor was an Agile shop (Scrum), and they built a SaaS application suite for eCommerce customers.

We had a large Scrum team that was focused on developing web search application extensions for our platform. The company was growing, and we were of the habit to grow our Scrum teams rather large before we would split them into two smaller teams. Our search team was approximately 12 in size.

A business priority change happened that caused us to split the search team in two – essentially making two Scrum teams of six members each. One continued to develop the search application, and the other was redirected to another component area.

What’s interesting about the story is that the search teams’ velocity didn’t change after we split them. They were averaging 25 points per sprint before the split and 24 points per sprint after the split.

I know what you’re thinking…that’s impossible. Well, no, this really happened. So what was going on here?

Simply put, the smaller team was more efficient in delivering software. There were fewer communications channels, fewer hand-offs, more collaboration, and better focus on their goals.

The Lesson: Try to solve your problems with as small a team as possible. Let them form and mature and achieve a steady velocity. Then “feed them” a prioritized backlog. You may just be surprised at how much they can get done IF you get out of their way.

Wrapping Up

I think that all of the scaling hoopla is just that. I don’t believe we have a distributed team problem or a scaling problem in today’s small or large-scale Agile contexts. And huge applications don’t need to be built by 10-50 Scrum teams.

We have an un-scaling problem. We have a boiling the ocean problem. We have a trying to throw too many people at it problem. We have a love of size and scope problem.

We’re looking at problems and creating the most complex solutions we can come up with. We are enamored with:

Distributed teams and/or large groups of teams
Way too complex architectures and designs
Solving problems with project management thinking
Management solving problems with “old thinking”
Building bloated software with features nobody uses
Not truly understanding our clients
Allowing business-facing folks to ask for everything
Scattershot vision hoping that we eventually hit the target

I can’t tell you how often I hear someone explain why his or her systems are complex. They reference the complexity as a badge of honor and a must have.

I would argue that there is no need for 100’s of developers to build systems. Small teams can do great things. That is if we allow them to do it.

That was the essence of agility in the beginning and it still is. I hope this article has inspired you to reduce your teams, break up your products, and take a new look at how you build your software and what you build.

Remember – a handful of Agile teams can do great things. And a handful of product visionaries can guide them towards just enough, lean, and wonderful software.

Stay Agile my friends,

Bob.

The Transformational Enterprise Business Analyst

Written by Kathleen B. Hass, PMP on September 25, 2015. Posted in Articles.

Why do we keep talking about the Enterprise Business Analyst (EBA)? Because it is quickly becoming the pivotal business/technology role of the future. The EBA is a business-driven strategic partner and integrator, an enabler of organizational change, and the driver of business success. As a strategic partner, the EBA often becomes an internal consultant – a business relationship manager at the top of the food chain of the BA profession.

Operating at the enterprise, strategic level, the EBA engages in radical collaboration, as the Stanford University Design School refers to it. The EBA understands that today’s complex projects demand an unprecedented amount of teamwork and cooperation among all key business and technology roles in a critical project. Indeed, shared project leadership is replacing old project management models. Perhaps the most valuable partnership when operating at the enterprise level is the one between the project manager and the business analyst.

The BA and PM work together to ensure projects are launched to bring about innovative solutions, value to the customer, and wealth to the bottom line. All decisions are made with the customer in mind. Changes that add value are not only welcomed but sought after.

THE RISE OF THE ENTERPRISE BUSINESS ANALYST

The rise of the EBA marks a significant departure from business-as-usual business analysis. The EBA is a strategic asset to decompose strategy into valuable change initiatives. The EBA plugs the gap conducting the burden of analysis that is too often missing from business/technology project prioritization and selection.

EBAs work up front and personal, in support of an investment framework based on business value. The EBA performs the due diligence that is so often missing during project initiation. This due diligence includes competitive analysis, problem/opportunity analysis, experimentation, creative brainstorming, early complexity assessment, and captures the results in the form of a business case to propose a new change initiative.

TRANSFORMATIONAL PRACTICES

The EBA employs transformational practices to bring about value-based decision making and project management practices.

TRANSFORMATIONAL ROLES

The EBA fulfills many strategic roles, essentially putting a finger in the dike for many areas that have been woefully inadequate in organizations today, from business relationship manager to internal strategic consultant.

Business Relationship Manager and Internal Consultant

As business relationship manager, EBAs fully understand the needs of the business, from vision and strategy to execution of operations. EBAs build executive level relationships as well as relationships with lower level managers and practitioners. They decompose strategy into valuable projects and programs. They lead creativity sessions to ensure we conceive the most innovative solutions. They create business cases to propose new initiatives. They conduct competitive analysis to understand where their industry is headed. They coach project teams to ensure the teams understand the business need and the value expected from the initiative.

Strategist

The EBA often has a seat at the table with the executive management team, participating in strategy sessions, facilitating the management team through problem analysis, alternative analysis, and opportunity analysis.

Innovator, Designer, and Architect

The EBA understands that creativity is a skill that can be learned. Understanding and using design principles enable EBAs to lead sessions to design the transformation prior to examining alternative solutions. Using architectural techniques, the EBA makes the future visible through models and rich pictures.

Business/Technology Optimizer

World-class EBAs stay ahead of trends within business analysis, technology-enabled business practices, and in the industry of their choosing. However, staying up with trends is a difficult undertaking because of the amount of information that is out there; it is voluminous and can be overwhelming. The trick is to concentrate on keeping abreast of business and technology trends at a high level, and go deep in a just-in-time learning manner. That is educate yourself on areas of interest at the time when you need to apply them to your current endeavors.

The EBA thinks holistically about the business, the ecosystem surrounding the business, and about the technology supporting the business. The EBA understands where the industry is headed globally, and how that will impact their organization. In addition, effective EBAs understand the current technology infrastructure, and trends that are emerging. Some of the contemporary areas of focus include:

Collaboration and productivity
Customer & operations support
Cyber Security
Digital, wireless, and mobile spheres
Software
Open technology
Internet of things
Compute
Networks
Social media

Leader, not Manager

In performing all of these roles, the EBA becomes a value-driven strategic resource for the organization. The EBA has mature influence skills, collaborating with project managers and other key change agents. The EBA understands how to build and sustain high-performing teams. In a given week, the EBA might serve as:

Strategy and Competitive Analyst
Strategy Executor
Value/Benefits Manager
Creativity and Innovation Enabler
Transformational Designer
Cultural Change Manager
Team Leader

Lead through Connections

The world is hyper-connected. EBAs leverage the collective intelligence that resides in the untapped knowledge of their network. EBAs can embrace the dynamic tension between creative disruption and operational efficiency. EBAs cultivate organizational creativity in an age of complexity.

TRANSFORMATIONAL PROJECT SUCCESS MODEL

The traditional measures of project success have been on time, cost, and scope. Even with advances in technology and the project management and business analysis professions, superior project performance remains elusive. The CHAOS Manifesto 2013 reveals that 61% of IT-enabled business projects continue to fail to meet project cost, schedule, and scope goals.

In the 21st century we need to achieve 90% of projects on time, cost and scope through smaller, incremental development of solutions. And at the same time, our focus needs to be on innovation and value. Companies that fail to innovate will get lost in the dust of agile, fast-moving competitors. So, our new project success model needs to look something like this:

Clearly, the business analysis profession needs to step up to the plate to close the gap in project performance, and the EBA is emerging as that transformational role. EBAs are drastically changing the way we manage projects. EBAs adopt a more holistic view of change initiatives so that we:

Focus on delivery of business value and innovation vs. requirements management,
View change initiatives holistically, understanding that critical projects will likely impact the entire business ecosystem of people, process, organizations, rules, data, applications, and technology
Embrace architecture and design to help temper complexity and uncertainty, and
Strike a balance between analysis and intuition, order, and disruptive change.

Look for us at the Building Business Capability Conference in Las Vegas in November.

ⁱ Leading Through Connections, Insights from the 2012 IBM Global CEO Study (www.ibm.com/services/us/en/c-suite/ceostudy2012/‎
ⁱⁱ THE STANDISH GROUP, “CHAOS MANIFESTO: THINK BIG, ACT SMALL,” 2013. ONLINE AT versionone.com/assets/img/files/ChaosManifesto2013.pdf‎ (accessed January 2014).