Tag: Business Analysis

Terms, Terms, Terms. Clarifying Some Business Analysis and Project Management Terms

Written by Elizabeth Larson on October 12, 2010. Posted in Articles.

In order to clarify some basic concepts of business analysis and project management, we need to distinguish between terms that seem similar but are not. Below are some foundational terms and distinctions.

1. Project Management focuses on the work and methods to create new products. The Guide to the Project Management Body of Knowledge (PMBOK^® Guide – Fourth Edition) defines project management as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”[1]

2. Process Management concentrates on the workflow and systems that recreate the products that sustain an organization.

3. Products. Throughout this article, we’ll refer to the end result of the project as the product. It can be a product, service, or any key deliverable that is produced as a result of the project. A few examples of products include a new bridge, a new methodology, landscaping, a project management office, a new car, a feasibility study, an HOV lane added to a freeway, a recommendation, a new or changed process, a new banking service, a new website, creation of a new agency, and a new marketing campaign.

4. Product Management uses processes and knowledge to manage product development, support, and marketing of the product. In this article, we cover the part of product management that occurs prior to deploying, selling, and supporting the end product. We focus on the work needed to define the requirements of the end product, to ensure that those requirements are built into the product and tested, and to ensure that the end product meets those requirements. Product managers exist in some organizations as the driving force behind new product development. They often define the high-level product requirements. In such organizations, this product manager often fills the role of project sponsor. See Table 1.1 for a summary.

Characteristic	Projects	Product Requirements	Processes
Ownership	Sponsor	Sponsor	Sponsor
Keeper or custodian	Project manager	Business analyst	Business process analyst
Planning	Project management plan	Requirements management plan	Documented processes
Execution	Performing project execution	Performing BA activities	Performing the process steps
Closeout	Project close and lessons learned	Closeout of phase(s) & lessons learned	Improved processes
Aligns with organizational vision and strategy?	Must	Must	Must

Project, Process, and Product Requirement Characteristics

Projects are initiated in a variety of different ways, such as new government regulations, competitive market forces, and requests to enhance existing products. In other words, someone in the organization requests a new or changed product.

The person who initiates the request is called the sponsor. We’ll explain the full sponsor role later, but for now let’s think of the sponsor as the person who obtains the funds for the project and makes key business decisions.

Once the request has been approved, a project manager can be assigned to manage the project. Projects result in changed processes for an individual or group of individuals large or small. For example, a new bridge results in new traffic patterns and new processes for those taking the bridge. Landscaping requires processes to maintain it; the HOV lane requires new laws and new processes for use by drivers. A new computer system results in new processes for the end-user. Therefore, stakeholders affected by projects, processes, and products all need to be identified and kept informed of the project status. Figure 1 below shows the interrelationship of projects, processes, and products.

Figure 1: Projects, Processes and Product Requirements Interaction

Life Cycles, Phases, and Methodologies

Project Life Cycle. A project life cycle takes the project from its inception to its conclusion. In other words, each project is alive. It is conceived, born, it matures, and finally ends. Products have their own life cycles. Typically, product life cycles last longer than project life cycles, because in general the product outlasts the project. However, in the example of a lengthy feasibility study whose product is a recommendation, the life cycle of the project can last longer than the end product. Project life cycles are composed of one or more project phases.

Project Phase. The project phase,as described above, usually marks a milestone, at which point a deliverable is usually produced, reviewed, and approved. The business analysis phase(s), then, produces a set of requirements (features and functions) that must be reviewed and approved.

The names of the project phases do not have to be the same for each project. One organization may have projects in different divisions or business units or agencies, all of whom can have different phase names. Nor are there a set number of phases required for each project. For example, the number of business analysis phases for a software development project can vary, depending on the approach taken to business analysis and the phase-to-phase relationship used. The business analysis effort can occur during one project phase or over the course of many project phases. For example, iterative development of software projects occurs over several project phases, as could the piloting of new business processes. For a complete discussion of lifecycles and phases, please refer to the PMBOK^® Guide – Fourth Edition, section 2.1.2.

Methodology. This prescribes how to get through the project life cycle, including the business analysis phase(s). It usually includes processes, procedures, forms, and templates for completing the project or project phase. Each project phase could, but does not have to, follow the same methodology. There are methodologies for completing business analysis, project management, product development, and testing to name a few.

Iterations, Increments, and Releases

These terms have created a great deal of confusion over the last several years. In the blog Don’t Know What I Want But I Know How to Get It, Jeff Patton uses art, movies, and pop music to explain the difference between “iterating and incrementing.”[2]

In a PowerPoint presentation, Managing Increments and Iterations with “V-W” Staging, Alistair Cockburn distinguishes iterations and increments by referring to increments as “build, deliver, learn, build, deliver, learn,” and iterations as “build, examine, learn, rebuild, ship.”[3] For another short differentiation, see Kevlin Henney’s article from December, 2007.[4]

Incremental development implies that new features and functions are added with each increment. For example, software can be developed using a plan-driven approach, with increments or new functionality added incrementally. Incremental business analysis implies that requirements are defined for an increment, and new requirements are added for each increment. Again, releasing in increments is appropriate for both plan-driven and change-driven approaches.

Iterative development implies planned rework. We expect the product requirements to evolve and change, so that change is viewed as part of the development process, not as a defect. Each iteration evaluates what has been built, and the product is rebuilt as needed. Iteration implies planned rework, because not only do we expect requirements to evolve, but there is a process to handle changes iteratively. Change-driven business analysis combines incremental and iterative requirements definition.

Product and Solution

Although the industry sometimes treats these two terms synonymously, we will use the term “product” for the end result of the project, and the term “solution” to mean the implementation of the requirements. The solution is a term used to describe a set of key deliverables that when taken together solve the business problem for which the project is undertaken.

Here are some examples.

The productof a project is a new marketing campaign. One solutionmight be to hire a consulting firm to produce the campaign. Another solutionmight be to have the advertising department develop it.
The productof a project is a new piece of software. One solutionmight be to build the software. Another solutionmight be to buy it from a vendor. Yet another solutionincludes new software, new hardware, and new processes.
The product of a project is a new order replenishment system. One solution might be the software, hardware, new and changed processes, and a recommendation on whether or not the organization is ready for the change. The requirements describe the features, functions, and capability of the new system. The deliverables (work products) from business analysis include a business requirements document, a recommendation on new hardware, a model of the future processes, and a recommendation on a new organizational structure for the affected business units. The order replenishment system alone will not solve the business problem, so the solution has to include more than just the system. This solution may involve many projects, each of which will have products.

Summary

Making distinctions in terminology is important for both planning and execution of projects, and common language can help reduce misunderstanding and miscommunication. When everyone understands the underlying concepts of business analysis and project management and uses the same terminology, they can complete the work more productively and with less conflict.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (http://www.watermarklearning.com/), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (C BAP ) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).

Management Institute. A Guide to the Project Management Body of Knowledge, Fourth Edition (PMB[1] Project OK^® Guide). Newton Square, Pennsylvania: Project Management Institute, 2008. p. 435.

Patton, Jeff. “Don’t know what I want, but I know how to get it.” Agile Product Design. 21 Jan. 2008. <http://www.agileproductdesign.com/blog/dont_know_what_i_want.html>.

Cockburn, Alistair, “Managing Increments and Iterations with ‘V-W’ Staging.” <http://alistair.cockburn.us/>.

Henney, Kevin. “Iterative and Incremental Development Explained.” Search Software Quality. 3 Dec. 2007. 29 Jan. 2009 <http://searchsoftwarequality.techtarget./news/article/0,289142,sid92_%20gci1284193,00.html>.

Business Analysis May Be the Problem

Written by Kupe Kupersmith on September 14, 2010. Posted in Articles.

I recently ran across this quote from Marilyn Kennedy a leadership coach, “It’s better to be boldly decisive and risk being wrong than to agonize at length and be right too late.”

Taking a look at her site it appears she is not speaking directly to business analysts, but I can tell you this quote should speak to you as a business analyst. When I read the quote the first thing that popped in my head was “analysis paralysis”.

Often BAs struggle with determining when enough is enough. Even with the great work many of us are doing to help improve project success and business improvements, the need for the right level of business analysis can be a tough sell. In our field, I believe the “Great Perception” is still alive…we don’t need analysis, we need development. The quote got me thinking of a reason why this perception exists.

The problem partly stems from our name. We are business analysts and we perform business analysis. Is that the best name to describe what we do? My BA colleagues everywhere and friends at the IIBA^® are probably rolling their eyes…please hear me out. In my opinion the word analysis is kind of fluffy. A Merriam-Webster definition of analysis is, “an examination of a complex, its elements, and their relations”. I see why discussions continue about not needing business analysis. Uninformed about the value of business analysis, managers and executives don’t want an examination of their problem or opportunity. They want solutions. The definition of develop according to Merriam-Webster is “to create or produce especially by deliberate effort over time”. That’s what I want. That’s why development is a must. It sounds more concrete. Analysis alone is not concrete.

I suggest we describe ourselves as Business Advisors. An advisor is someone that recommends, gives advice, and informs. My comparison is a financial advisor vs. a financial analyst. For my retirement fund I don’t want a financial analyst…someone that analyzes the market and trends. I want a financial advisor. I want someone who will analyze my current portfolio (AS IS), work with me to define how much I need to retire (TO BE), and then recommend options to fill the gap. Doesn’t that sound like what we do?

Barring a major change like the IIBA^® renaming itself to the international institute of business advisors, what can you do to change the perception? When working with team members and business partners that may not know the value of business analysis, you need make it clear that you are in the advisor or solution business. The best way to recommend solutions is to do the right level of analysis first. This way they know why you are asking the probing questions.

In addition, this is a big reason I advocate for business analysts developing a business analysis work plan. If you lay out what, why, when and how you will be taking on the analysis effort for a project, you now have a negotiation tool with real data to negotiate the necessary time and stakeholder involvement. Your work plan should include a:

stakeholder communication plan
list of deliverables
detailed task list
time and cost estimates for you and other stakeholders

By discussing your plan with your manager, project manager and business partners you can discuss how these activities will help develop recommended solutions that address the problem or opportunity the business is facing.

What do you think? Are you an advisor?

Happy Advising,
Kupe

Don’t forget to leave your comments below

The Business Case for Business Analysis

Written by Marcos Ferrer on July 13, 2010. Posted in Articles.

Apologies to any economists – the real value of BA is probably way higher than I could determine in 1000 words. There is probably a multiplier just from workers watching crazy process insanity disappear from their daily lives.

To see the big picture sometimes we drill down. I give a specific example (completely fictional of course – this is not you, so don’t call please). In this project BA 007 was asked to help introduce BA practices into a water utility’s IT project practices.

The usual “fire hose” of information was sprayed on 007 for the first weeks. As 007’s intelligence base grew, one of his early questions was “How much money is currently spent on IT projects and infrastructure per year?” The response was: “Oh, we have that, it’s around $3,000,000.00”. No documentation available, but, what the heck, eh?

So 007 continued to analyze the information he was getting, patient and secure that his question had been, or would be, answered. As an initial business case for implementing BA for IT projects began to emerge, it became apparent that the out of pocket costs looked something like the following:

12 SMEs on staff acting as BAs
8 person team doing requirements for ERP enterprise project
100 stakeholders engaged part time at any given time (about 10 full time equivalents)
70 Contract IT personnel
Average IT Infrastructure investment of $3,000,000/year

Total 100 personnel out of 2700 employees @ $75K/year on average = $7,500,000/year

At this point, 007 starts to suspect that the $3,000,000 only covered total annual infrastructure costs (hardware, software, support and maintenance), and that the client was not counting payroll or overhead costs for projects (not unusual in a government environment). Given the 35% failure rate across all water utility IT projects (we ignore those that were merely “compromised”), the “lost money” to failed projects seemed more like $2,625,000 per year, or $26,250,000 over 10 years.

The costs of BA (requirements) failure above are incomplete and incorrect – they do not include overhead like office space, supplies, PCs, office equipment and other resources wasted on failed projects (promotion of the guilty, punishment of the expert, rock bottom morale, employee turnover and more).

The cost of retraining personnel for improving the BA function at the water utility was calculated to be 20 BAs plus 20 IT personnel, Each receiving 8 weeks of training in year one, 4 weeks in year two, and two weeks per year in subsequent years. Classes were estimated at $3500/week including travel, and salaries/benefits at $75K per year on average.

It was also estimated that increased/improved BA activity would require twice as much involvement from stakeholders – 20 full time equivalents instead of 10.

These costs to invest in BA came to about (40*(8+4+2+2+2+2+2+2+2+2) person weeks * ((75,000/52) +3,500) per person week)
= $5,536,385

PLUS 10 more full time equivalents @ $75K * 10 years
= $ 7,500,000

TOTALING:
$ 13,036,385

OK, those of you who do real business cases know just how flawed this is, but, as 007 likes to say, $26M – $13M gives a LOT of room for refinement. Go ahead, add inflation to personnel costs, add in lost benefits to the “merely wasted” money, add any complexity you want – 007 defies you to show that BA investment can ever lead to a negative ROI.

Have fun, and I’d love to get your feedback!

Don’t forget to leave your comments below

Five Steps to a Winning Business Case

Written by Cynthia Low on June 29, 2010. Posted in Articles.

Making a successful business case for your new project is the winning way to ensure a good beginning for your team. How often have you been asked to “work the numbers” and provide a basis for a compelling project? Often, if you are a project manager with responsibility to help your sponsor and your company make decisions about which projects are the right ones to do. The PMBOK provides the body of knowledge for “doing it the right way.” In this article, you will learn about the five steps of a methodology that you can take away and use everyday for identifying, selecting, and justifying a new project or a significant change in scope to an ongoing project.

Projects with a solid business case return value to the business, to their sponsors, and to the stakeholders and customers. Meeting scope, staying within budget, and getting done on time are the tactical elements that deliver the value. This being so, it is self-evident that successful project managers are those that effectively make the connection between project accomplishment and business value. (Goodpasture 2001)

Business Case Basics

A winning business case is really no mystery. First, it provides the background and context for the project. Historical performance is often necessary to illustrate opportunity. As is operating results from functional and process metrics are part of context. Perhaps there are lessons learned and relevant history of other projects that got you to where you are.

Second, the business case identifies the functional, technical, or market opportunity that the project is to address. From opportunity, specific solutions can be developed.

Third, the project proposal is given, laying out a description of scope, required investment, expected results and project benefits, and key performance indicators (KPIs).

Next, understanding is conveyed about how the results of the project fit into the business operationally. For this, a “concept of operations” is needed.

Last, and perhaps most important, you ask for a decision on the project proposal. In this section, it is customary to ask for approval of the assignment of managers for performance responsibility.

Step 1. Establishing Context: Put History Together

Assembling history and setting the context for a new project may not be where project managers expect to first come into the picture. However, often times it is necessary to bring forward completed, cancelled, or deferred projects for analysis, or to analyse the operating metrics of ongoing functions and processes. Activities in this step are identifying the similarities, highlighting the differences, and making certain irrelevant aspects of past endeavors do not color the current situation.

Here’s a helpful hint: start with the WBS of all prior engagements. The WBS contains all the scope and should link directly to the financial records and chart of accounts. Make adjustments for change orders or other scope differences. Examine the project charter; make adjustments for tools, facilities, constraints, assumptions, and policies that influence the project, but may no longer be operative. Look also at the OBS (organizational breakdown structure) and the RAM (resource assignment matrix) that maps organization to scope.

Step 2. Responding to Opportunity

We begin with this idea: Opportunity is “unmet need.” Investing in projects to satisfy identified need leads to reward. Reward enriches all who participate.

Goal Setting and Strategy Development

To effectively and wisely choose among opportunities requires goal setting and strategy development. We make these definitions: Goals are ends to be achieved, a state of the business in a future time. Objectives do not differ materially from goals, though some prefer to think of objectives in more of a tactical time-frame and goals in more of a strategic framework.

Opportunity is most often found within the goal sets of the “balanced scorecard” [Kaplan and Norton, Chapter 1]. Typically, there are four such sets: Customer and Market, Operational Efficiencies and Improvement, Organizational Development and Learning, and Employees.

The value of opportunity is transferred into goal achievement. Not all of the opportunity may be available to the business. Thus, more practically, we speak of the “addressable” opportunity as being that part that can find its way into the business. To make good on the addressable opportunity, strategy is required.

Strategy is actionable, often requiring projects for execution. Projects are identified by flow-down from opportunity analysis; projects are an instrument of strategy.

Business Case Preparation

Action plans, the essence of strategy, are a natural for project managers. The strategy is a high level WBS for the overall business case, identifying those actions that are in scope, and perhaps identifying strategy elements considered but deferred or not accepted.

Step 3. Proposing the Project and Laying out the Investment and Benefits

Opportunity is in the future. There are no facts in the future, only estimates. As such, your project proposal must identify four elements:

Scope of accomplishment in terms with which sponsors and approving authorities will identify;
Major milestones that are meaningful to the business;
An assessment of risk factors that affect both investment and benefits estimates; and finally,
A specific proposal of risk-adjusted investment dollars, benefit dollars (benefits recover investment), and KPs.

Many projects have only intangible KPIs and indefinite benefits. Sometimes it is possible to “dollarise” these benefits using the “before and after” methodology: what does it cost to run the business before hand, and what will it cost to run it after? Even though any specific cost element may not be directly linked to the project, the business as a whole will be different.

Identifying and Assessing Risk

The traditional investment equation is: “total return is provided by principal at risk plus gain.” Project methodology transforms this equation into the project equation: “project value is delivered from resources committed and risks taken.” The project equation is the project’s manager’s math and the balance sheet for the project. [Goodpasture, 2001, Chapter 3]

One means of risk assessment is through statistical analysis of the major schedule elements. For purposes of the business case, only major project outcomes need be scheduled. The best estimator of the schedule outcome is the expected value of the overall duration, defined simply as the sum of possible outcomes, each weighted by their probability.

Financial estimates should also be adjusted for risk. After all, financial performance is one key performance indicator (KPI) for all new projects. Two financial measures that account for risk are Net Present Value (NPV) and Economic Value Add (EVA).

Financial Measures with Risk Assessments

NPV measures cash on a risk-adjusted basis. Cash is consumed by projects, but subsequently is generated by project deliverables. EVA measures profitability. Although it has been said “profit is an opinion, but cash is a fact” [Pike, 1999], reflecting the influence of accounting practices on calculating profit, project managers should know that NPV and EVA are equivalent when profit is restated in its cash components.

Net Present Value

How can projects managers affect the NPV or its equivalent, the EVA? Simply put, the main effects under project management control are timelines for cash flows, that is, the schedule for the development of project deliverables and subsequent operations, and assessments of the risks associated with cash flows. After project completion, the responsibility for cash flows is transferred to a benefits manager through the KPI’s. Project management participation in risk-adjusted financials has many parallels with risk-adjusted scheduling of critical path using such techniques as Monte Carlo, PERT, or critical chain scheduling.

Economic Value Add

EVA is a financial measure of how project performance, especially after the deliverables become operational, affects earnings. [Higgins, 1998 Chapter 8]. Projects with positive EVA earn back more than their cost of capital funding; that is, they return to the business sufficient earnings from reduced costs or increased revenues and margins to more than cover the cost of the capital required to fund the projects.

The bottom line on financial analysis: NPV (Cash flow) = present value EVA (After-tax cash-equivalent earnings).

Estimating Cash Flow

Estimating the cash flow for the business case is a project manager’s task. Estimating cash flows is tantamount to estimating the resource requirements for the project, and then estimating the benefits that will accrue from a successful project. The PMBOK identifies several estimating techniques that can be applied. The key is not only to estimate the resources for the project, but also the benefit stream from operations.

Step 4. Outlining the Concept of Operations

A concept of operations need not be rocket science. The idea is this: Once the project ends, and by definition, as given in the PMBOK, all projects end, we must address the question, “how will the project deliverables be made operational in the business?”

Deliverables in the Concept of Operations

If project deliverables are to be inserted into, or change, or bring into being new processes, then there are process actors, inputs, methods, and outputs to consider. If there are new products, the fit to marketing and sales must be considered, as well as support after sale. And if there are new plant, systems, and equipment deliverables then the concept of operations will address the on-going operations that would be touched by these new assets, new or changed workforce, their training and relocation, and retirement of legacy assets.

To convey the concept of operations (ConOPs) in the business case, identify effected organizations, jobs, roles within jobs, tasks within roles, skills, tools and facilities necessary to do the tasks, operating budgets, and other relevant components. By narrative or diagram, explain the operating concept.

For purposes of the business case, it is most useful to reduce even complex processes to a handful of boxes, and back-up this abstraction with whatever detail is needed to satisfy participating managers that their needs are covered.

Step 5. Asking for a Decision and Assigning Responsibility

Hopefully, business cases in your organization are subject to a rational decision policy. Rational means: “outcome is a predictable consequence of information applied to methodology.” With a rational decision policy, the business case should make a direct appeal for a decision to approve the project.

On the presumption of a favorable decision, the managers responsible for executing the decision should be identified. It’s easy for the project sponsor to identify and assign responsibility for the investment: it’s the project manager. The project manager controls the consumption of resources invested, scope accomplished, and the timeliness of it all.

Assigning responsibility for benefits and KPIs is more problematic. We use these definitions: Benefits are the mechanisms for recovering project investment. KPI’s are different yet: they are the “balanced scorecard” of the project. KPIs measure business success as a consequence of project success, and are many times intangible.

The manager(s) for benefits and KPIs becomes loosely defined as the “benefit managers.” They must make commitments in the business case to make good on the ConOPs and the changes envisioned. Benefit managers must accept this responsibility in a transfer from the project manager at the conclusion of the project. A slip-up here will materially affect the investment recovery.

Summary

A good business case lays out the response to opportunity. Such a response is made contextually relevant with history setting the background. From opportunity, all else flows. Risk adjusted financial measures, the project ConOPs, and the strategy response to goals rounds out the completed business case. In short, good business cases define good projects. Good projects return value, provide benefits, and have measurable KPIs.

Don’t forget to leave your comments below

John C. Goodpasture, PMP and Managing Principal at Square Peg Consulting, is a program manager, coach, author, and project consultant specializing in technology projects, strategic planning, project office operations. He is the author of several books, articles, and web blogs in the field of project management. He blogs at johngoodpasture.com, and his work products are found in the library at www. sqpegconsulting.com, and at www.slideshare.net/jgoodpas. His full profile is at www.linkedin.com/in/johngoodpasture. Mr. Goodpasture’s most recent book is “Project Management the Agile Way: making it work in the enterprise”, published in January, 2010.

References
Goodpasture, John C., “Managing Projects for Value,” Management Concepts, Vienna, Virginia, 2001, cover piece Ibid, pg 40.
Pike, Tom, “Rethink, Retool, Results,” Simon and Schuster Custom Publishing, Needham Heights, MA, 1999, pg 177.
Higgins, Robert C., “Analysis for Financial Management,” Irwin/McGraw Hill, Boston, MA, 1998.
Kaplan, Robert S. and Norton, David P., “The Balanced Scorecard,” HBS Press, Boston, MA, 1996.

John Goodpasture shares his views on contemporary topics in project management, methodologies, and the value propositions of programmes and projects on his blog A Project Management Opinion.

Business Analysis Scenarios; Understanding the Business Interactions

Written by Suzanne Jane Maxted on June 1, 2010. Posted in Articles. 94 Comments on Business Analysis Scenarios; Understanding the Business Interactions

In previous articles we examined the use of a business context model, and which concepts exist and what is true, using a business domain model. And we looked at how business behaves in the business analysis process article.

This article discusses the role of Business Scenarios to express connections between people and business elements and suggests a way to model them. Even to this day, the clarity and beauty of the jewels of truth of a business are frequently obfuscated in an avalanche of inexplicit verbiage (ha ha!) – and the poor old techies have to pick out the gems from the piles of verbal diarrhea disguised as ‘documentation’.

A business scenario can be used to:

Understand the business interactions.
Prototype or storyboard a piece of software from a business point of view without presenting screens and buttons which distract from the point of the exercise, thereby keeping the design activity separate.
Test the completeness of requirements, thereby finding gaps in the logic understood so far. For instance:
- Test for completeness a single path through a business process or use case
- Find characters in the story (domain classes) that have been missed and their responsibilities
- Understand changes to characters in the scenario (state changes)
- Understand a ‘user story’
- Use as a test case for a new system component
Take notes as an observer or to further our own understanding; a tool for asking questions.

The aim of a scenario is to understand and communicate a single interaction between the people, systems or anticipated logical components of a business or system. In other words, a business scenario is simply a conversation between people or things/objects in the business.

Scenarios are also a good tool for testing theoretical business processes and domain models by using real-life examples or instances of a situation and the people in it. Although we are specifying behaviour in a business scenario; specifying one single real-life instance renders business scenario modelling a separate tool from modelling business process or use cases.

So how do we start building a business scenario? Using the idea of holding a conversation, imagine that all the things that exist in the business are people or invent people that can talk to other people. For example, I need a way to handle billing once I’ve placed an order. I don’t know what the concepts are yet for billing but I do know that there exists something called Order. Imagining that Order is a person, it will need to have a conversation with some other thing or person. I’m going to call it the Billing Manager (a logical component because I don’t know enough to break that down yet). Now these two ‘actors’ in the business process can have a specific dialogue (say, a single path through a business process or use case if these have been specified already).

Business scenarios can be written as a set of scenario clauses of requests and orders moving around the business using the following grammatical construct: – subject verb noun object

Example Scenario:

Joe asks “will you fix my bike?” to Fred
Fred replies “yeah, if you pay me” to Joe
Joe asks “how much?” to Fred
Fred replies “$100 mate” to Joe
Joe says “OK” to Fred
Joe gives bike to Fred
Fred fixes bike
Fred says “I’ve fixed your bike. Please give the $100 to Mum” to Joe
Joe says “thanks, I will” to Fred
Joe pays $100 to Mum
Mum asks “what’s the $100 for?” to Fred
Fred replies “savings for a new bike” to Mum

This is a perfectly valid way of expressing a business scenario. However, the old problems crop up. We have written “Joe” nine times instead of once, “Fred” 11 times instead of once and written “Mum” four times instead of once, thereby increasing our workload. We cannot reuse what we have created in this scenario To use or reuse “Joe” say, in other artefacts; we have to type “Joe” or copy “Joe” each time. In addition, the knowledge gained here will be lost in a document and difficult to find later on, as opposed to maintaining business architecture in a good modelling tool allowing us to simply drag Joe into the picture next time he crops up in conversation. The model element “Joe” would not be a modified clone. It would be the one and the only Joe.

One way of introducing stakeholders to modelling business scenarios is to begin writing it as above on a whiteboard, and then convert it into a diagram by erasing the object names on the left and right sides, and by adding the direction (arrows) of ‘conversation’ and the people (object lifelines) involved as follows:

Joe		Fred
~~Joe asks~~	“will you fix my bike?”→	~~to Fred~~
~~Fred replies~~	←“yeah, if you pay me”	~~to Joe~~
~~Joe asks~~	“how much?”→	~~to Fred~~
~~Fred replies~~	←“$100 mate”	~~to Joe~~

Messages are represented by an assortment of arrows (as with all modelling techniques, I recommend that the reader researches the notation available) but basically, the messages sent are either calls (an order or request) for a service of another object or returns (answers) to the calls. (Note that services offered by an object are operations on a class.)

Here is the scenario expressed as a UML sequence diagram:

I prefer to use the Unified Modelling Language (UML) because:

It is broadly accepted as a worldwide standard formal notation,
It allows me to cover all the types of modelling I need to do with only one notation
I can use an existing standard notation with my business audience rather than impose one or more non-universally understood notations that colleagues and I have invented.
I can maximise the reuse of model elements, reduce my workload and eliminate inconsistencies and errors in terminology, and in notation, across all diagrams.

In my experience, business and technical audiences love the precision and speed of describing the business given by a business analyst who can think in an abstract and logical way, and who uses meaningful labels for model elements. The only exception I have come across was a business owner who claimed to be a verbal thinker and who found it difficult to review a diagram later. However, her complaints to the business analysts were about endless repetition and inconsistencies in text and one feedback comment said ” …should not ignore the business scenarios analysis!” and another “I expected to see those stick diagrams …”.

My recommendation is to use UML sparingly and pragmatically, referencing help manuals to avoid breaking the rules as far as possible. I use only four to five symbols in a workshop session – easily digested by a high calibre business audience. My intention in a workshop is not to teach UML to my business. I may not even mention UML, but simply reassure the audience that I am using the current standard notation to the best of my knowledge for describing business. As I record (much more quickly than I could in prose) what is understood and agreed, I ‘speak’ the symbols as I draw them. Later, when I have formalised the model, I talk it through with those who would like another viewing. My other rule is never to send or hand over a model without having gone through the above process with the business audience.

Back to scenarios: a respected solution architect colleague told me that allowing a business analyst to do sequence diagrams is like handing a carving knife to a toddler. I protested but found myself wondering if he was right. Given the general propensity in organisations to jump into solution mode and talk about systems, he may have seen a number of business analysts stepping on the toes of the solution team instead of focussing on business concepts and objects when modelling, albeit not ignoring constraints imposed by existing solution components. I’ll come back to this point.

As with any modelling technique, it is important to judge when it would be appropriate to use, as there would not be time to develop every possible business scenario. To scope this work, think about the core business services that respond to the goals and expected outcomes of important external stakeholders. On the other hand, I know a business analyst who uses this tool by preference as a starting point for his understanding. If you do use them, then I would recommend modelling the successful happy day scenario i.e. what should happen 80% of the time, and a few major and typical exception scenarios for each major domain of the business. Certainly, in the book I’d like to write, they should be created by the business and testers with the help of the business analyst. For the advanced modeller, I recommend researching the principles of distributed control and encapsulation to reduce the impact of future changes by keeping related behaviour and data together.

Back to my point. Let’s not forget, a business analyst’s role is to analyse the business, describe it and its intentions. In this and the articles referred to at the start, we have focused on understanding, specifying and communicating the problem, the scope and the requirements of business change. If we stick to business concepts and business speak, we won’t run the risk of scaring our audiences with models of a technology bent. We need to record the business talk in a sophisticated and useful way, and keep it looking like a real human conversation.

Don’t forget to leave your comments below

Suzanne Jane Maxted BSc.(Hons), MBCS CITP, is a business architect and analyst with 17 years experience from around the world. She is an accomplished business modeller, workshop facilitator and presenter. Suzanne coaches business analysts and project managers, and is a regular contributor to the Business Analyst Times magazine, with extensive hits and positive feedback from readers. In 2008 and 2009, she was a speaker and panel member at the BA World Symposium in Wellington, NZ. Suzanne fills her spare time teaching and performing dance (performed NZ Dance Festival 2007, Wellington Cuba Street Carnival 2009) and having fun with her two little children. She can be reached at [email protected]