Tag: Training

How to Prevent the Negative Impacts of Poor Requirements

Written by Sergey Korban on April 30, 2013. Posted in Articles. 2 Comments on How to Prevent the Negative Impacts of Poor Requirements

There is an abundance of stories of failed projects. Research has shown the reasons for IT project failure in the USA, indicated that project success rates were only 34%, with the rest of projects being either “challenged” in some way or failing outright.

The losses can be very significant. For example, British food retailer Sainsbury had to write off its $526 million investment in an automated supply-chain management system. The U.S. Federal Aviation Administration spent $2.6 billion unsuccessfully trying to upgrade its air traffic control system in the 1990s. Ford Motor Company abandoned its purchasing system in 2004, after spending $400 million. In the 8 years since, things probably haven’t changed much.

From the project management perspective, technology projects fail when they do not meet the following criteria for success:

Project delivered on time
Project completed on or under budget
The delivered solution works as required by business stakeholders.

A number of factors are involved in any particular project failure. The most often quoted factors are listed below:

Lack of stakeholder involvement
Unrealistic time scales
Poor requirements
Scope creep
Uncontrolled changes
Insufficient testing.

The quality of requirements can have a lot of impact on the outcome of the project. One high profile project which was significantly affected by the requirements management process was the Chrysler Comprehensive Compensation System which was supposed to handle paychecks for Chrysler’s 87,000 employees but was shut down after several years of development.

The impact is magnified as the BA moves from high-level requirements towards functional and non-functional requirements. The cost of rework of functional requirements is the highest because these requirements define the technical specification and design of the solution.

Here is a visual summary of the impacts:

Project impacts

Projects are undertaken by the business to satisfy a strategic goal. Poor requirements have the following effects on projects (and subsequently impact the strategic goals of the business):

Scope creep negatively affecting budget and completion time
Low utilzation of resources and higher overheads
Inadequate business process design (due to insufficient details about activities)
Poor design and ergonomics of the user interface, resulting in lower productivity
Inadequate software specification, resulting in lower developer productivity
Poor specification amplifies the negative effect of poor requirements when it comes to software testing, leading to higher costs and lower quality of the solution
Time-consuming and costly code rework
Difficulties in solution integration.

Business/organization impacts

More generally, the business as a whole is affected in many different ways by poor requirements through the projects that the business undertakes. Here is the short list of negatively affected areas that I have witnessed:

Lost opportunities for the business
Lost advantage relative to competitors
Breaches of regulatory compliance
Poor stakeholder engagement and loss of trust
Reduced business process efficiency due to poor solution design
Negative user experience due to cumbersome UI design
Lack of cohesive IT landscape due to poor integration
Negative impact on the bottom line, generally speaking.

How to prevent poor requirements

In my experience, there are two ingredients in any given project which help me deliver quality requirements. One ingredient is what I know about the business and the project. The other one is the techniques I use to ensure that I deliver great results.

It probably sounds quite vague at this point, so let’s dive into the specifics.

Knowledge needed for quality requirements

The foundation for creating the future solution is a good level of understanding of the current state. Regardless of the methodology you are following, you have to start here. What do you need to know?

Know the context in which the business operates
The business operates in two contexts. One is the external context where market forces define how the business operates and maintains its sustainability. This includes regulatory requirements, competitors and partners.

The second context is internal. It is actually more complex as it includes organizational structure, business processes, governance around the processes (business rules), people involved in the processes, internal politics, organizational culture and overall pace of changes within the business you work for.
Understand the business problem or opportunity
This is the actual driver for the project. Without knowing the real business need you won’t be able to find the solution that solves that problem.
Identify gaps to be bridged
Once the business problem and stakeholder concerns are clear, you can draft the future state. When the future state has been confirmed with stakeholders, perform gap analysis. Your focus here is on what should be done within the project scope to resolve the identified problem. It is also good to think about extra value the business can get as a result of the project.

Extra value can be delivered when you have a clear understanding of changes going on in the organization, and how the project you are engaged in fits into the change landscape.

Techniques for better requirements

The techniques I’ve settled on in my practice enable me to use stakeholders’ time efficiently and get a clear picture of the current state. Let me share them with you.

Do your homework
Before engaging stakeholders in requirements gathering activities, I read all available documentation on business processes, business applications in use, regulatory requirements (if any), internal communication about changes in the organization, as well as other projects that may have dependencies with the project I am in.

I also explore information relevant to the industry as a whole to identify possible good practices that I can re-use.

I call this exercise my “homework”. The benefits of the homework exercise are that I know the “language” I will use when talking with stakeholders. I also know what to articulate to confirm information that is unclear. I feel confident about my part in the project and I know that I can help the business.
Power up communication with visuals
There is nothing better than diagrams to explore the current state and get an idea about the desired future state. The time savings due to using visuals can be enormous. How much time do you spend to define the future state? If you don’t use diagrams at present, you could probably save a significant portion of that time.

Outline organizational boundaries, processes and data they use, add used applications, process and technology interfaces where required, and finally add roles involved in the processes. Now you have a snapshot of the current state.
Use templates to support your work
Any business analysis task has to be organized to save your valuable time. Templates are of great help here as they let you re-use the common parts of documentation, and customize as necessary. They also serve as a kind of checklist of required documentation, and ensure that you don’t miss anything.

My favourite template is the Current State Analysis. It includes analysis findings, identified business need, visualized current state (including the external context) and recommendations on what the solution may look like in terms of capabilities.
Avoid common pitfalls
Requirements become poor and vague when they mix project related tasks, statements about the future state, applied rules and solution design.

A good way to avoid these common project pitfalls is to plan business analysis, and to document the planned activities and deliverables in the Business Analysis Plan. It’s an integral part of the project plan. However, the Business Analysis Plan does not deal with project tasks.

A hierarchical approach has to be taken to the future solution. Firstly, list the required solution capabilities. They can include both changes to business processes and technology services supporting these processes.

Secondly, translate these capabilities into a business process design and business requirements for supporting technology services. You always need to tweak a business process if you change software used to support the process.

Thirdly, add relevant business rules to justify future business logic.

Next, validate the business process design and specified business requirements with the stakeholders.

Finally, transform the validated requirements into functional requirements. These will guide the development and implementation of the solution. Don’t forget to describe business data (along with data types) to be used within the solution.

Adding prototypes of the user interface will make the functional requirements more precise and also help establish new terminology to be used in the solution.

These steps are executed in an iterative fashion so they align well with modern “fast” methodologies such as Agile and Scrum.

Summary

Poor requirements may lead to project failure. Functionality that is poorly specified, implementing something that isn’t needed, poor processes, lost development time, missed project deadlines, poor quality of documentation – the list of impacts can go on and on.

I believe that we as business analysts can do our job well and contribute to business success. Sometimes we don’t have enough time to stop and consider why our requirements are poor.
In the article above I listed the key ways to improve requirements. I’ve tested these approaches in many projects and they always produce positive results.

I hope they will help you, too!

Don’t forget to leave your comments below.

The Bad Ass BA: How Do You Know When Business Analysis is Being Done Well?

Written by Cecilie Hoffman on October 16, 2012. Posted in Articles. 1 Comment on The Bad Ass BA: How Do You Know When Business Analysis is Being Done Well?

A senior manager posed this question at the end of an all-hands meeting: “How do we know when business analysis is being done well?”

If you are a business analyst, it is easy to answer the question, “How do you know when business analysis is being done poorly?” While it is likely that what this senior manager wants is success criteria, there’s a useful intermediate step, which is to identify the symptoms of success. Let’s assume this manager is getting ready to make changes in his organization so that defining business needs and recommending solutions that deliver value to stakeholders enable the desired organizational change. Moreover, the activities leading to and following from the change will happen in a predictable, efficient and, dare we say it, a manner that makes people proud to be part of the organization? Yes, we dare.

Try the following exercise for yourself. Fill in the blank: “You know that business analysis is being done well when _______________________.” Here’s what we came up with. We have included the perspectives of many different organizational levels.

The business’s “vision” is expressed in terms of a vision statement and a roadmap for how it is going to get there. The roadmap is updated frequently to reflect the progress of development programs and projects, and changes to the business vision as the market changes.
Product management teams understand the difference between a vision, a roadmap, a portfolio and a project pipeline.
After the agony of elicitation, modeling and analysis, the answer/solution/approach is obvious to all stakeholders (and they agree on which one it is).
Successful approaches are repeatable and results are reproducible.
An organization’s ability to identify the success criteria for a proposed new program or project includes meaningful metrics.
The enterprise has the habit of building in baseline measurement and trend analysis.
There is no resistance to measuring/monitoring the effect of change.
Time to create quality documentation is protected; historical documentation is valued for potential re-use and for use as a reference.
Junior and mid-level business analysts can connect their tactical work to their organization’s strategic goals and the enterprise’s strategic goals.
Senior business analysts know what their business customer’s 5-year business roadmap is and how that roadmap is supported by IT’s 5-10 year technology roadmap.
New-hire business analysts are given ready-for-them-on-day-1 materials, organizational charts, process map repositories, and BA best practices/templates repositories.
HR, product managers, project managers and line (organizational) managers understand the difference between the following roles: business analyst, application analyst, quality assurance analyst, UI designer, database analyst, developer.
Entry-level new hires are not given the business analyst title until they have demonstrated some if not all of the fundamental skills of a business analyst. This common practice devalues the role of the business analyst.

“But wait,” you say, “there’s more!” You are right, there’s much more, but let’s press forward past the symptoms. Let’s take an organizational perspective. First, we need some context.

Here’s the conundrum that line managers of business analysts face: business partners/clients/customers want a business analysis service that provides both a strategic partner and a faster-than-light order-taker. Many BAs begin their professional lives in order-taker roles. Over time, they develop their skills and chance upon a situation where their insight, experience and knowledge enable them to contribute at the level of strategic partner. After the head rush and deep sense of professional fulfillment from receiving the first “Your contribution as our strategic partner delivered results far beyond our expectations” comment, few business analysts will be content returning to the role of an order-taker. A good manager understands that the BA as strategic partner vs. order-taker isn’t an either/or question, but is a question of organizational maturity.

Regarding organizational maturity, we need to remember the late 1980s when Watts Humphrey first published his Capability Maturity Model (CMM) as a paper, then as a book, Managing the Software Process. The 1989 model defined five levels that were points on a continuum:

Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new or undocumented repeat process.
Repeatable – the process is at least documented sufficiently such that repeating the same steps may be attempted.
Defined – the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being work Instructions).
Managed – the process is quantitatively managed in accordance with agreed-upon metrics.
Optimizing – process management includes a deliberate process of optimization/improvement.

According to the Software Engineering Institute, which sponsored the development of the Capability Maturity Model, “Predictability, effectiveness, and control of an organization’s software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief.” That was the perception back in the late 1980s. Fast forward to 2012. We now have a variety of rapid iteration software development methodologies that have the intent of optimizing the software development process but, well, let’s be honest, are often misused to avoid doing the hard work up front of defining goals and success criteria.

As a result, we have this notion of “quick hits.” A quick hit is often a solution to a problem that everyone wants solved yesterday. Getting any form of relief to the problem is so urgently demanded that people adopt a just-get-it-done attitude and throw money at it. Quite often the quick hit is a short-term success, not because the effort in the spotlight and a few individuals’ careers are riding on a good outcome, but because the business analyst defined the problem so well that the solution’s objectives were highly constrained so that the requirements could be met with a minimum of design, which would mean that development was low risk so functionality could go into production like an arrow to the target.

While the quick hit model for projects delivers immediate gratification, anyone taking the long view realizes that the success of a quick hit is often counter-intuitive. Sure, the quick hit solution was speedy, and it met the letter of technical requirements but it isn’t extensible and it has few “-ilities,” namely, scalability, reliability, compatibility, manageability (four of the many “non-functional,” requirements for readers who aren’t business analysts).

Moreover, the more emphasis placed on quick hits, the less focus there is on strategic planning and understanding the big picture, that is, the business model and business architecture view of the business’s needs. People who are rewarded for putting out fires with quick hits are not receiving incentive for thinking about the long-term ramifications, nor do they feel at liberty to think strategically.

In 2010, Alexander and Osterwalder and Yves Pigneur published their handbook for visionaries, game changers, challengers and empowered business analysts called Business Model Generation. When there is no business model, an organization is low on the capability maturity model; development is chaotic, quick hits are the norm rather than the exception, and innovation is haphazard at best.

In 2011, Robert Strohmayer identified the business architect at the top of the list of the six hottest jobs in IT (“The 6 Hottest New Jobs in IT”, Infoworld, June 2011). Strohmayer quotes Alex Cullen, a VP at Forrester Research and the Research Director for Enterprise, Business, Application and Development and Technical Architectures, “Business architecture is about making sure the whole business holds together . . . it’s a role built around business planning, pointing out opportunities to utilize IT more effectively.” Simply put, business architecture model is a blueprint of the enterprise that provides a common understanding of the enterprise and is used to align strategic objectives and tactical demands.

When business analysis is being done well, the practice of creating and maintaining the business model and the business architecture is as deeply ingrained in the organizational practices as the tradition of the quarterly all-hands meeting. Not having the business model and the business architecture model as references would be unthinkable. After all, how will an organization know what it is doing and how things will affect it in the long term?

When business analysis is being done well, the organization values having the solution to a problem defined along the dimensions of the users, the interface, the capabilities that the users and the business will have, the data, the controls, the environment that the solution will deployed into, and the quality (those “-ilities”). If you want to know more about these seven dimensions, take a look at Discover to Deliver, just published by Ellen Gottesdiener and Mary Gorman. Discover to Deliver articulates a methodology based on rapid iteration for ensuring that what gets built has long-term value and can be linked directly to an organization’s strategic goals.

When business analysis is being done well, business customers see their business analyst as a strategic partner, and they see an empowered business analyst who knows the business’s 5-year roadmap, not just their program portfolio, not just a project pipeline and not just the project in front of their nose. In our experience, business analysts who work in organizations that are not mature in the CMM sense are only as good as the managers who protect them. No business analyst who consistently takes initiative, challenges the conventional perspective, raises uncomfortable issues and brings transformational (disruptive) ideas to the table will survive without at least one manager watching their back and providing them with information about the political climate and budget sensitivities.

When business analysis is being done well, executives see the product managers as entrepreneurs, the enterprise architects as intrapreneurs, and everyone sees senior business analysts as brilliant strategic partners.

Don’t forget to leave your comments below.

Cecilie Hoffman‘s professional passion is to educate technical and business teams about the role of the business analyst, and to empower business analysts themselves with tools, methods, strategies and confidence. She works for a Fortune 100 company that is asking the right questions. [email protected].

Rebecca Burgess is a certified Six Sigma Black Belt and a business process analyst at Academy of Art University in San Francisco, California. After many years of uncovering problems and determining root causes, she is now applying her BA skills to strategic process design and improvement. [email protected]

The Best Virtual Meeting…EVER! Five Fun Games to Engage Your Virtual Project Group!

Written by Claire Sookman on March 26, 2012. Posted in Articles.

Do you ever have those days when go you off on philosophical tangents? You know, those cold, gloomy mornings when you stare out the window, coffee mug in hand, wondering, “Does a fish know what water is?”, “Is the colour red really universal?” or “Is Robert from marketing a real person?”

We’ve all been there. The truth is it’s hard for virtual project groups to bond on a personal level with other group members…partly (well, mostly) because we may not even know what the other person looks like! Without bonding, the results could be dangerous. The University of California, San Francisco, lists some of the common symptoms of a disengaged team:

Decreased productivity
Conflicts or hostility among staff members
Confusion about assignments, missed signals and unclear relationships
Decisions misunderstood or not carried through properly
Apathy and lack of involvement

And there’s more:

Lack of initiation, imagination, innovation; routine actions taken for solving complex problems
Complaints of discrimination or favouritism
Ineffective staff meetings, low participation, minimally effective decisions
Negative reactions to the manager
Complaints about quality of service

And there’s still more! A 2009 article from the Occupational and Environmental Medicine showed that a lack of team spirit can even cause employee depression…But don’t panic!

Before you scurry off to Google, furiously searching “how to engage virtual project groups” — take a breath. We’ve done the work for you. Here are some innovative games that are sure to have your team amused and engaged in no time.

1) Virtual Charades – Charades is a great game that builds group spirit, whether in a traditional workplace or a virtual one. If your company usually sets up video conferences for meetings, this is definitely a game that will have everyone working together, solving problems and having fun along the way. If you’re unfamiliar with the game, Charades requires the player to mime or imitate a certain action or subject that the rest of the team has to figure out. For more information on how to play, click here .

For those who use voice chat instead of video chat, there’s a fun alternative for you too — Voice Charades. For Voice Charades, create a secret list of objects, animals or famous people. To decide who will go first, enter all team member names onto a site such as Random.org and choose the first name that shows up. Email or send an individual/private instant message to this team member letting them know what they will be acting out. Remember to keep the clues work-appropriate and respectful of others. Have fun guessing what/who the person is imitating. Some entertaining suggestions are:

Printer sound
Al Pacino impersonation
Star Wars Light saber
Monday traffic
Radio anchorman

2) Spin a Tale – This fun game fosters creativity and helps team members think on their feet. During a meeting, make up the first line of a story. Then ask team members to take turns and add each subsequent line until a whole plot develops! Let the story go along on its own path and deviations. This is the fun part of the game; you never know what perils or fortunes can occur next! The best thing is, even though your team may develop favourite start tags, the story will never end up the same! In other words, you learn how to think innovatively. Here are some ways you can start your tale:

I woke up at 9am — that was when we were supposed to Skype in for the meeting…
Jared looked over the ledge of his balcony, wondering why the crowd had gathered…
The email had no subject line…I hate it when he does that…
Fifteen years, 15 days, 15 hours and finally the letter had come…
As Sophia hid behind the red SUV in the parking lot, she tried to remember how exactly she had gotten there…and why there was that giant scar on her arm…

3) Situation Puzzles – Situation puzzles are an exciting way to exercise creative problem-solving skills while also building team unity. In a situation puzzle, the team leader states one mysterious sentence such as, “a bell rings, a man dies, a bell rings”.* The rest of the team must now solve the situation by asking “Yes” or “No” questions. As each question unearths new information, the team can creatively build on each other’s thought patterns and ideas until all the loose ends are tied. A great reservoir of situation puzzles can be found here! *(Click here for the answer)

4) PowerPoint Game – You will never look at PowerPoint presentations in the same light after this game! This is a great way to get group members thinking on their feet while having loads of fun. To play the PowerPoint game, go online and find a series of complicated or extremely nonsensical PowerPoint presentations (try SlideShare). Then ask team members to improvise a presentation with the slides they’re using. Hilarity is bound to ensue! Go here for more information about the PowerPoint game.

5) 2-Minute LOL – This is another improvisation game that will get everyone thinking fast, learning about team members and literally laughing out loud. First, divide the team into smaller groups or partners. Then give each group a topic or let them choose one. Allow each team about five to ten minutes to create a set of jokes based on their topic. Make sure they have this discussion in a separate virtual conversation so that the rest of the team does not hear the punch lines beforehand. When everyone regroups, randomly choose a group to go first while timing their comedy improvisation for two minutes. Once again, remember to keep all jokes respectful and workplace-appropriate. Award the funniest team with a gift card or some other form of prize!

And there you have it — five amazing ways to engage your virtual project group! Try them out and let us know which game your team liked the best! And if five tips aren’t enough, here’s a whole book full of tips! Across the Hall, Around the World is the ultimate archive of virtual team-building tips that’s sure to get your team engaged!

Don’t forget to leave your comments below.

Claire Sookman is the driving force behind Virtual Team Builders, Claire brings to the table over a decade’s worth of corporate and public sector training experience, working with over 4,500 managers in the past three years. Specializing in virtual team building and communication strategies, Virtual Team Builders provides training that enables global teams to work more efficiently.

Meet Your Business Analysis Influencer

Written by Kupe Kupersmith on March 6, 2012. Posted in Articles. 1 Comment on Meet Your Business Analysis Influencer

My goal in life is to meet everyone in the world. I know that goal is not SMART (specific, realistic, etc.). It is not reaching the goal that is important; it is the effort I go through to try and meet the goal that counts. The goal goes deeper than just “meeting” people. I try to meet everyone I can and establish a relationship. Building strong relationships is a constant, consistent goal of mine. Some grow deeper than others, but I don’t discriminate. I meet and engage with people sometimes without knowing how I will add value to that person or how they will add value to me. For some this is a hard concept to grasp. Some feel so busy and can’t fathom spending time getting to know someone new without knowing why you should get to know them.
We work in a highly collaborative work environment. You don’t have to do everything on your own. If you build strong relationship people are more willing to help you. So if you are too busy to build relationships it is because you are not building relationships.

If you still need some convincing regarding building relationships, here is one big reason you should bother. Build relationships to ensure your message is delivered. This thought popped into my head after seeing an interview with Bono, lead singer of U2. He is a huge advocate to reduce or eliminate the AIDS virus. He has helped raise money and awareness that is dramatically helping the cause. But Bono is not a doctor. He does not work for the Center of Disease Control. He is not trained to do the research, administer tests or provide medicine to patients. What he does do is use his influence to help raise money to support the cause. He uses his influence to convince lawmakers they should allocate funds and resources to support the cause. He delivers the message.

I speak with many BA professionals that get frustrated when they can’t convince their management that they need more focus on the BA practice. I speak with many BA professionals that realize projects are not going well, but are not sure how to get their message to the right person. Sometimes you don’t have the influence necessary to get your message across. Does that mean you should stop? Of course not. You need to detach the message from the delivery of the message. The point is not who delivers the message; the point is that the message gets delivered.

Most likely Bono won’t be stopping by your office anytime soon trying to convince your management that they need to fund your effort to start a Business Analysis Community of Practice. Go out and meet some new people in your company at all levels. Who knows, maybe they’ll be delivering a message for you.

Don’t forget to leave your comments below.

Business Analysts; The CEO’s Army

Written by Jarett Hailes on January 26, 2010. Posted in Articles.

As the economy slowly recovers, businesses and governments continue to look at ways to maximize their organizational potential with the human capital they currently have. Over the years several management strategies have been presented to ensure consistent long-term performance (and outperformance). Methodologies such as Six-Sigma quantify results to identify opportunities for improvement and monitor subsequent performance. Others take a more qualitative approach and look to unleash the most important asset any organization has – its employees.

One management strategy that was formalized in the 1980s focuses on organizational improvement through ‘inverted strategic analysis’. Management by Wandering (or Walking) Around (MBWA) was introduced in Tom Peters’s book “In Search of Excellence“. Instead of coming up with ideas in the boardroom and communicating these initiatives to lower-level employees to implement, MBWA flipped this model upside down. Management (particularly the CEO) is encouraged to meet with as many personnel (particularly front-line staff) as possible to understand the current state of the organization, learn what is working and get suggestions for what can be improved and how.

Several companies over the past 30 years have followed this management style, including HP, GE, Pepsi, 3M and Wal-Mart. Recently Costco’s co-founder and CEO Jim Sinegal was designated as one of America’s Best Leaders in 2009 by US News & World Report magazine. For decades Jim has effused the MBWA ethos by “store hopping … about 200 days out of 365”. Former Procter and Gamble CEO A.G. Lafley also made it a priority to listen to employees and customers to ensure that strategy and operations at one of the largest corporations were aligned as much as possible.

These examples demonstrate that it makes sense for leaders to keep a pulse on their company by staying in contact with as many people within the organization as possible. However, the larger the company the harder and more impractical it is to spend a large amount of a leader’s time on such activities. How can a CEO get the knowledge needed to ensure they can devise appropriate and relevant strategy while at the same time receive feedback on whether the strategy can and is being executed effectively? I believe that business analysts can fill this gap by becoming the CEO’s “eyes and ears”

As a profession, business analysts have the qualities required to listen to a group of people and then communicate essential information elicited from this group to others. Whether it’s software requirements, product ideas, operational efficiency suggestions or customer feedback, business analysts have the skill set to gather, prioritize, manage, maintain and collaborate with stakeholders to meet the strategic goals of the organization. Most BAs experience this on a day-to-day level, typically between internal business units and the IT organization. But I believe that business analysts can leverage these skills to help the organization in a far greater capacity.

Some business analysts are already well-suited to play the role of the CEO’s sounding board. Those who are assigned to one or more business units typically become intimate with the people and processes that make up the sub-organization. Often these BAs will be privy to knowledge that otherwise has no outlet; whether it’s hearing about issues as to how a certain process operates, or hearing first or second hand feedback from customers about a product or service offered.

Business analysts need a channel to be able to relay this information throughout the organization and ensure that ideas can be systematically evaluated and executed in the appropriate context. Usually, BAs know how to handle this information and leverage it to improve the organization if it’s IT related, but there typically are not structures in place to handle suggestions that would impact other external units.

As business analysts, we often see or hear about opportunities before the decision makers in the organization know they even exist. In order to successfully capitalize on opportunities, decision makers need to have such information in their hands so they can decide whether to act on it. How can we get this information to them in a timely manner?

While each organization is different, here is a proposed framework for enabling business analysts to relay the pulse of the organization to upper management:

Have at least one business analyst assigned to work with each business unit on a regular basis. This will allow the BA to get a level of expertise in the business area and will provide staff within the unit with a go-to person to discuss requirements or suggestions for improvement. The number of analysts you need per area will vary greatly depending on the size and structure of the organization. You may only need one BA to cover several units or several BAs to cover one unit.
In addition to informal information gathering that will occur as part of a BA’s normal activities, hold formal sessions occasionally to generate new ideas. This does not have to be your typical brainstorming session, and the activity can be targeted to a specific group based on their skill set (although I recommend allowing everyone to do the same activities, as you never know who has a hidden talent in a certain area). For example, have new product contests that pit teams from different areas against each other. As West Paw Design found out, employees from any area can have a creative bent that will improve the company’s offering.
Come up with a process to evaluate the information you receive. First you need to classify the information – is it a business requirement, a process improvement suggestion, a product or service offering suggestion, etc.? Each type of information will need to be dealt with via its own process. For example, business requirements may need to be collected and a business case developed for meeting the identified needs, either through technology or process changes.
Ideas and suggestions may need to be channeled through some sort of review process. Depending on the size of the organization, it may not be feasible to have all suggestions placed in front of upper management. A vetting process is recommended, performed by individuals who will be held accountable for the decisions made (i.e. which suggestions are to be brought forward). I would recommend that business analysts are responsible for overseeing this process and can participate but are not the ones who make the decisions – this should be left to a group that upper management has confidence in with such matters. As part of the review process, I would look to have an absolute grading threshold rather than a ‘Best X ideas’ threshold. This is not meant to be a one-time event – some months you may get several great ideas while others you may get very few.
Have the originator of the whittled-down list of suggestions and ideas present their suggestions to upper management on a regular basis. I would recommend allocating a flexible amount of time based on the number of ideas that have passed the review process. BAs should be in the room to hear the feedback and thoughts of upper management, and to help make suggestions on how to implement the ideas, particularly if it requires effort from many different areas of the organization. BAs can also collect feedback from management to improve the overall process and to communicate decisions and results back to others in the organization.

If such ‘internal engagement’ concepts are foreign to your organization or your organization is not used to tackling opportunities across organizational boundaries, setting up a structure similar to the one above may take a great amount of effort. Here are some suggestions on how to get started on the road to a formal structure.

Learn how upper management sees their own roles and how they divide their time currently. Ask them what they’d like to see improved internally in the organization and what sort of things they would do if they had more time. With this information, look for ways to suggest having BAs do some of the ground work on their behalf.
Talk to front-line employees and ask if a) they feel they understand the higher level goals of the organization and b) if they feel their voices are heard higher up in the organization. Use straw/anonymous polls to have some concrete numbers to discuss underlying needs with upper management.
Leverage the PMO or BA Centre of Excellence within your organization to cultivate ground-level staff buy-in and build awareness for Management by Wandering Around principles. Look for case studies that have demonstrated how such techniques improve financial and operational performance within an organization such as yours.
Get BAs on board through the Centre of Excellence. If you don’t have one, start an informal community of interest and discuss ways for BAs to play a more prominent role in the organization.
Implement the technique without the structure – find a relatively small opportunity that you can execute on and take it all the way. For example, let’s say BAs are hearing about how everyone dislikes the vacation approval process. Talk to HR about the chance of improving the process by getting people from around the organization involved. Hold a lunch session where people can break up into teams to come up with a new process. Have HR managers review the ideas and pick a winner (with a small prize going to the winning team). They don’t necessarily have to implement the idea as-is, but follow up with them to see how feasible it is to implement a variant to improve the process. Once you have some informal successes, present your results to upper management.

CEOs have many people they need to work with in order to achieve the goals of the organization. They simply can’t be everywhere all the time. Business analysts can extend the reach of the CEO by being a two-way conduit for information that will impact the strategic direction and operational excellence of the organization. A strong, formal structure to perform these tasks will help everyone in the company know that they have a chance to play an important role in the direction of the organization, regardless of their job description.

Do you already have a framework like this set up in your company? If so, do BAs play a part in the process? If so, let me know in the comments section below.

Don’t forget to leave your comments below

Jarett Hailes is a Business Consultant with Larimar Consulting Inc. He has worked with large and small organizations as a Business Analyst and Project Manager, and is also a Scrum Certified Product Owner and ScrumMaster.