The Lay of the Land: Enterprise Analysis

With spring right around the corner, you are no doubt anxious to begin getting at your garden that has been dormant during the winter months. While I personally wrestle with the idea of perennials and annuals, and those plants that require shade and those that don’t, I can assure you my planning has already begun. My love of food has got me thinking about how to make certain that my crops yield a healthy harvest of both vegetables and herbs—this year I’m hoping to grow garlic!

Not unlike gardening, Enterprise Analysis takes very careful stock and consideration of the current state of your environment. By IIBA® definition, Enterprise Analysis is:

1. The identification of business opportunities
2. Development and maintenance of a business architecture
3. The determination of optimum project investment

The resulting output is a clear understanding of what solution best meets the business needs and is articulated as business requirements.

This can be best illustrated in my Requirements Management & Development Assurance Model:

® ESI International 2009

Starting in the center of the diagram all great things evolve out of business goals and objectives. While I’m not certain that most Business Analysts are privileged to participate in development of these goals and objectives, they should be able to conduct business goals and objectives development sessions with a high degree of facilitation expertise. This would no doubt prove to be beneficial, especially as we consider the planning, management and interaction activities at the beginning of our quest to realize the right solution match.

With the goals and objectives set, the three core areas of focus are Elicitation, Analysis and Assessment. Assessment can include a variety of considerations and activities, such as peer reviews, structured walkthroughs, and user acceptance testing, to name a few.  All of these activities play an instrumental role not only in defining the potential solution at the Enterprise level, but in nurturing its growth through to solution development.

Not unlike any solution we choose to develop— including gardening—a great plan and approach is critical to its success. Imagine the challenges Farmer Brown would encounter if he simply sowed different types of seeds aimlessly throughout his fields. Great care and consideration must be given to all kinds of variables in order for his crops to yield an optimal investment. Business Analysts, too, must consider the following very carefully before engaging in Enterprise Analysis activities:

1. Their approach
2. Stakeholder involvement
3. Deliverables and the activities required to realize them
4. Level of interaction – a/k/a communication
5. How requirements will be managed
6. Quantification of performance

Two other activities that I am always adamant about in Enterprise Analysis is the development or repurposing of a glossary of terms and the definition of a vision statement. A glossary of terms plays a critical role in that it sets a level playing field for the terms and vocabulary that are expected to be used during the Enterprise Analysis activities. If you don’t believe me, ask your stakeholders what the difference between a user and a customer is! A vision statement does just that—provides vision—a short 30-second elevator speech that defines the purpose of what it is we are about to undertake. Don’t be afraid to repeat this at the beginning of every meeting you participate in. This is akin to watering the plants, and preventing scope creep, or the wilting of scope as it were!

Essentially there are six core areas of activities that must be considered when engaging in Enterprise Analysis activities:

1. Articulation of the business need to support goals and objectives
2. Analysis of existing environment and desired future state
3. Conducting feasibility study and analysis of proposed future state
4. Development of solution scope
5. Development of the business case
6. Presentation of the decision package

It should be noted that for all activities cited above, careful consideration must be given to the potential size and complexity of the endeavor to be undertaken; all activities should be scaled accordingly. If this is a case in which what is being realized is uncertain, an incremental approach may work best. It’s similar to a farmer expanding his crops from a simple garden to a field to multiple plots of land.

1. The articulation of business needs proposes that business goals and objectives remain in alignment with the desired solution. Opportunity and problem analysis should be major considerations in your endeavor to define the business needs. You want to consider involving executive management, middle management, “operators” of the solution and operational teams that may be responsible for implementing the solution, and any “regulators” of compliance.

2. Analysis of existing environment and desired future state will allow for a Business Analyst to clearly understand the impact the proposed solution will have on the organization as a whole. It’s a very rare occasion that you can pull a solution out of a box and slide it right into an organization with little to no impact. Careful consideration of all the impacted areas must be given and could include, but certainly are not limited to, any of the following:

1. Overall organizational structure
2. Lines of business
3. Function
4. Business processes
5. Level of competency for targeted audience
6. Training and development plans
7. Interdependent projects (those that may be affected either by the input or output of your solution)
8. Technological infrastructure

Essentially the output of this activity would realize a clear understanding of the existing Enterprise Architecture, through internal, external and gap analysis techniques. If necessary, and depending on the size and nature of the effort, document analysis may also prove to be fruitful. Consider that the Enterprise Architecture is not complete without consideration of the business, information, application, security, and technological infrastructure. This should give you a clear three dimensional view of how the organization functions and any gaps that may exist to allow you to function in a desired future state.

3. Conducting a feasibility study and analysis of the proposed future state is perhaps an area that is most often neglected. The reason is simple:  clients tell us that they know exactly what they want and, given their time constraints and our desire to immediately satisfy clients’ needs, we drive out the solution the client thinks they need. Without properly exploring all possible solution angles, we sell ourselves and our clients short of the opportunity to view the solution from all angles. For example, did you know there are 190 varieties of potatoes registered with the Canadian Food Inspection agency? While I certainly wouldn’t recommend 190 solution options for your clients, I definitely would steer you to consider conducting a feasibility study that looks at the following elements of at least three solution options:

1. Economical
2. Operational
3. Legal
4. Technical
5. Time to develop
6. Ability to market
7. Benefits
8. Risks
9. Issues
10. Assumptions and constraints
11. Potential costs

4. Development of solution scope essentially puts your proposed solution in “a patch of land” from which it will grow and flourish.  It defines the boundaries for which your business need will be realized and lays the foundation from which your business case can be built. Major deliverables, project objectives, assumptions constraints and dependencies will serve as the seeds from which the scope will be realized. Product decomposition or scope models describing the who, what, where, when, why and how are all tools you should consider pulling from the tool shed when defining your solution scope.

5. For development of the business case, quantify, quantify, quantify. Essentially putting your money where your mouth is is at the heart of this major activity. If a farmer wanted to produce 220 bushels of corn from an acre of land he would have to plant 40,000 seeds. And, not unlike most organizations that we work in, we would have to carefully consider these numbers to consider our return on investment. Quantification of benefits, the initial organizational risk assessment, and a proposed means by which you are going to monitor the progress are all essential ingredients of your business case. Other critical elements for consideration of the business case might include any or some of the following:

1. Project costs
2. Solution Implementation Plan
3. Financial metrics
4. Selection criteria to realize the best option
5. Business benefits
6. Alternative costs for alternative solutions
7. Impact analysis
8. Risk assessment
9. Risk management plan

6. Presenting the decision package is a key area where we most often miss the mark. Far too often we are coerced into delivering what the client wants to hear, and forget that our primary role as a BA is to remain as objective as possible. If that means that we recommend against a solution, then so be it. At the end of the day, if we are unable to demonstrate and quantify that a solution meets overall business goals and objectives, we should stand strong in not recommending it, in the best interest of the whole organization. With stakeholder profiles in hand, carefully consider what information you are going to share with whom.  More importantly, consider how you are going to present the information. For example, consider the following:

1. C-level executives are generally big-picture thinkers, concerned with costs, profitability, governance and overall impact on the organization. Their time is limited and often filled with distractions, namely the “crackberry.” I recommend scheduling your meetings in short iterative bursts, avoiding a PowerPoint presentation if possible and walking them through documentation that is relevant to them— such as the business case. This way, hopefully, you will have their full attention. Giving them pencils to take notes or highlight key areas always proves to be effective as well.
2. On the opposite end of the spectrum, implementers—developers and administrators— generally tend to be very systematic in nature. A presentation with plenty of checklists, models and diagrams will give them an opportunity to understand what the expected solution may end up looking like and quite likely have them visualizing the final solution. 

Your decision to present your artifacts to a homogenous group (all the same) or heterogeneous group (a variety of people and groups are represented) will play a critical role in how your output is perceived.

Whether you are planting crops or a small garden, or developing a solution for your organization, it is critical to carefully consider the lay of the land. For your bounty to be truly rich, goals and objectives, your existing architecture, the feasibility and scope of the solution, the quantification of your findings and the presentation of those findings should all be carefully considered before you begin sowing the seeds.

Author: Glenn R. Brûlé has more than 18 years’ experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI International, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. These engagements focus on understanding, diagnosing and providing workable business solutions to complex problems across various industries. Glenn is a member of the board of directors and Vice President of Chapters of the International Institute of Business Analysis® (IIBA®). http://www.esi-intl.com