Tag: Skills

Using Business Objectives to Control Scope

Written by Betsy Stockdale on December 13, 2011. Posted in Articles.

Often when a business analyst is assigned to a project, they are presented with information about the project. Typically, they are given a product concept and perhaps some product features and qualities already defined. A few success metrics may exist, such as the product launch date. From here, the business analyst is expected to carry on and define the rest of the requirements necessary.

And while this approach realistically will not change, why not back up a bit and try to understand what problem the product is trying to solve? Businesses start IT projects because they are trying to solve a problem. Those problems are generally related to revenue, costs or compliance.

Business problems related to revenue generally revolve around the need to make more money.
Those business problems around costs relate to costs being too high, and the desire to lower operating costs of the organization.
Compliance problems arise when the business has a regulatory or compliance issue that they must address or follow.

On the surface, it might seem that the Business Objective for a particular problem is to solve that problem. However, Business Problems rarely articulate the specific metrics that a business is trying to achieve. It’s the metrics that help us measure whether or not the problem has been addressed.

Defining Business Objectives

It can be difficult to get the business users and stakeholders to articulate the business objectives. Many times, they may feel that IT does not need to know why a project needs to be done; they just need to follow orders and do it. Other times, the stakeholders do not want to be measured. And sometimes, the various stakeholders do not agree on the business objectives. This is an opportunity for a BA to use their leadership skills and powers of persuasion to get the business stakeholders and users to understand the importance of business objectives.

So how do you get the business objective? Start by ensuring you understand what the business problem is by asking, “What is the business problem that you are trying to solve?” Keep asking, “Why is that a problem?” until you get to the money, cost or the regulatory answer. Once you get an answer that involves money, costs or compliance, you have the business problem.

Now that the business problem has been articulated, ask, “What metrics can we use to determine that we have solved the business problem?” While this sounds like an easy question to ask, it is not an easy question to answer. The metrics need to be as specific as possible. For example, “increase levels of customer service” is not a good metric because it does not define how much the levels are to be increased. Further, if customer service is increased by 1%, does that solve the business problem? Probably not. You need to push the business stakeholders and users to be as specific as possible when it comes to defining the metrics for the business objective.

Here are some examples of business problems and their objectives:

Business Problem	Business Objectives
Customer retention for online customers in the over 30 age group is poor, and we are losing. customers in this demographic to our competitors.	Increase customer retention for our over 30 age group by 25% by the end of the next fiscal year.
Our customer support team is becoming very expensive, and this is seriously impacting our ability to be profitable on a number of our products.	Reduce support calls to our call center by 45% by the end of August of next year.
The federal government has changed the regulations relating to how Medicare claims are processed. If we don’t update our system, we’ll be ineligible to process Medicare claims.	Ensure full compliance with new Medicare claim regulations when those regulations go into effect on Aug 9, 2012.

Moving from Business Objectives to Strategies, Success Metrics and Guidelines

After measurable business objectives have been defined, then determine what strategies could be used to achieve the objective. There may only be one strategy, but often there are multiple ones. Once a strategy has been chosen, develop a clear product concept. The product concept is the proposed solution to accomplish one or more business objectives. The product concept may or may not be the same as the original product concept, but at least you will be confident that the product concept will help achieve the business objectives.

Success metrics should also be defined. Now that you have a product concept (and a project), how will you know that the project is a success? Success metrics are statements about the specific desired outcomes to meet the business objectives.

Guiding Principles are the guidelines that the stakeholders want or need BAs to follow. For example, the training manager may wish to minimize the amount of changes that the training materials will need to undergo, and thus asks that the general workflow for the system be kept the same. This is something that needs to be considered early in the project, especially if it conflicts with one of the business objectives. But isn’t it best to discover such conflicts early in the project, so they can be sorted out then and not after the product has been developed and tested?

Using Business Objectives to Control Scope

After defining measurable business objectives, determining strategies, defining success metrics and establishing guiding principles, the features for the product or solution are addressed. The features start to describe what the product should be able to do. As a general rule, features:

Provide a specific piece of functionality to the user
Can be linked to a measureable business objective
Can to a limited extent be analyzed independently of other features

If a feature cannot be linked to a measureable business objective, then the feature should not be included in the product. Many times a feature will be added at the request of a stakeholder of the project because it is “cool” or “slick.” But if it cannot be linked back to a business objective, it is out of scope. In this way, business objectives give you an objective way to say “no” and to control scope.

While features describe what a piece of software is supposed to do, Product Qualities provide information about attributes that we want to see in the software that are independent of the specific functionality of the system. Most of these Qualities map to particular types of non-functional requirements. For example, requirements that discuss the scalability of the software or the speed of the software are non-functional requirements that describe Product Qualities.

From the features, the functional requirements are defined; from product qualities come the non-functional requirements. As all requirements are being defined, they must be tied back to a business objective via the features and product qualities. If the requirement does not tie back, then it is out of scope for the project, and the BA team can kill those that do not tie back.

Don’t forget to leave your comments below.

Betsy Stockdale is a requirements architect for Seilevel, a professional services firm that specializes in helping Fortune 1000 clients redefine the way they create software requirements, in order to enhance their business outcomes.

How To Squash The Template Zombie Problem

Written by Robin Grace on September 6, 2011. Posted in Articles.

Western culture worships the massacre of zombies by the dozen in movies, books, and music. Wherever we encounter zombies, whether it’s in the garden shed, the attic, the mall, or even the local if your name’s Shaun, we are taught to mow them down with whatever’s at hand.

We have only recently discovered that there are different types of zombies, and one type has invaded your office: the template zombie. There isn’t any need to panic but there’s cause for mild alarm and you should kill them. But in the nicest possible way, by feeding them sweeties.

Template zombies are BAs who just fill in the template blanks. When they’re asked to assist on a project, they immediately reach for the templates they’ve been given, fill in all the blanks and then send them on to the developers. And, let’s face it, that’s a lot of documentation to wade through and we all know developers bin the bulk of it, use a small section to write the programs and everyone’s happy. Or are they?

Companies with a poor requirements discovery competency take 39% longer and spend 49% more to deliver their projects. Nearly 80% of their projects are over budget and over time, and a whopping 50% are runaway projects. Runaway projects are those that go 180% over time, 160% over budget and deliver less than 70% of functionality.

You see, grabbing for templates and filling in blanks is akin to BAs reaching for a bag of liquorice allsorts. There’s no control over what’s in the bag, they simply get the whole package whether they like it or not.

In doing so, there’s little, if any, thought given to what the business is actually looking for. The Dryfus model (used in the IIBA Competency Model Version 3.0) for skills acquisition defines a novice as “someone who rigidly adheres to taught rules or plans and is unable to use discretionary judgement.” The template zombie has never been allowed to develop beyond being a novice, no matter how long they have been doing the job, and it’s no wonder their brain dies after a while. That’s a poor approach since the BA has a role to play in achieving a desired business outcome. If it’s properly done, the business gets a working process, be it manual or automated, but if it’s improperly executed the business gets a lame duck.

In fact, the duck can be so lame that the business has late projects, projects that cost significantly more than they were supposed to, and processes, automated or manual, that don’t meet the requirements. More specifically, developers end up with reams of documentation they don’t need that require effort and expense to create, and they ignore most of it. Poor business analysis also negatively impacts stakeholder input and user acceptance.

Bullet to the brain

So now you know how to spot the zombies: they’re the mindless template devotees. What you must now do is rob the zombies of their sustenance and turn them back into effective BAs. How? Steal their liquorice allsorts and give them pick ’n mix. Pick ’n mix allows people to choose precisely what they want; it’s the ultimate in sweet flexibility because you get a bag and then you browse the seemingly endless options, placing the type and number of confectionery delights in it that you want. It gives a much wider selection than liquorice allsorts because the latter’s a predetermined bag of goodies, while the former is an endless sea of choice that lets wave after wave of sweetie, lolly and candy choice wash over you. Again, it’s effective and that’s our watchword in taking down the zombie menace one toe-scraping carcass at a time.

Template zombies like the liquorice allsorts approach because they get the bag, eat the sweets, repeating ad infinitum. But you have to shake them up, make them think. Of course, in doing so, you need to remember that you’re dealing with zombies here and even the most docile template zombie can be dangerous. Don’t give them free rein with the pick ’n mix bag of sweeties or they’ll likely shuffle along the shelves grabbing all their favourite goodies and leaving everything else. You need to point them to the right shelves and only then release them.

Frame the zombie

While it may be ideal to leave BAs to decide what sweets they want from the entire sweet store, only the most senior BAs are capable of doing that within the greater business context, which is the task of what the Dryfus model defines as an expert. Template zombies aren’t the senior BAs. They’re the other BAs. What template zombies need is a framework to guide them through the process.

The business analysis framework must deliver value to the business, otherwise why are we doing the project? And it implies a problem scope. Not necessarily problem in the standard sense—think of it more in the mathematical sense as a problem for which there is a solution. Once we figure out what the solution is, we need to figure out how we are going to deliver it. Think of it as three layers of a pyramid: at the top we ask a) why are we doing this project, followed by b) what do we need to do, and finally c) how do we deliver the solution?

When we ask why we are investigating the business objectives or goals, when we ask what we are eliciting the business requirements, and when we ask how we’re looking into the functional and non-functional requirements.

Another way of looking at it is when we ask why we are seeking the value of the project, when we ask what we are investigating the entities, processes and business rules, and when we ask how we are looking at the required solution functionality. The framework gives us a matrix of objectives on one axis, and tasks or techniques on another, all culminating in outcomes and deliverables. It’s that matrix that arms BAs to choose which techniques are best suited to their projects. All BAs are armed with a bag of sweeties they can dip into, containing practices and disciplines such as planning, business case, business requirements, functional requirements, non-functional requirements, transitional requirements, solution validation, elicitation, and requirements communication. Within each of those portions of the matrix are tools that BAs can use to help them achieve their goal and that’s their pick ’n mix. They’re given the matrix, the framework, but they get to choose within the framework because that’s where they’re the domain experts. For example, they may choose more common tools such as process analysis, ERD, use case and others. But there are several methods of analysis, such as PESTLE, heptalysis (which is not a gum disease), MOST, SWOT, CATWOE (which is not a sad cat), De Bono’s Six Thinking Hats, Five Whys, MoSCoW, and others in their bag of sweets.

Powwow

But what are they looking for in selecting these techniques or sweeties? Some time ago I attended a presentation by Scott Ambler, who is an Agile guru. Often at a conference or industry powwow, there’s a pearl of wisdom that leaps out and sticks in your brain. For me it was, “We need repeatable results, not repeatable processes.” Pick the right tool for the job.

It requires some thought from BAs in the context of the business while considering the numerous techniques available before ensuring a suitable match. Handing BAs a bag of liquorice allsorts in which they’ll find a predetermined collection of techniques that they must follow because “that’s the way we’ve always done it” doesn’t cut it—that is just a repeatable process. You need to appropriately select the techniques that will most effectively deliver against the requirements in the context of the business objectives for repeatable results.

Don’t forget to leave your comments below.

Robin Grace is a Business Analyst Principal Consultant at IndigoCube.

So How’s That Working for You?

Written by Mark A. Monteleone on May 24, 2011. Posted in Articles.

Often while teaching business analysis, students ask me, “Why should our business adapt any of these business analysis techniques? We don’t use these techniques because they take too much time.” My initial response is always, “So how is that working for you?” This open question requires not only an elaboration, but some thought and not just a quick response. It is also an effective question that allows me to start a dialogue with the student rather than a discussion defending the use of business analysis techniques.

The word dialogue in Greek means to “talk through” as opposed to the word discussion which is derived from the Latin root meaning “dash to pieces” (1)

As the students ponder, I follow-up with some more focused questions to “pull” information from the student rather than immediately “push” my opinion onto the student. “How are your projects performing today? Are your expectations being met?” These questions, of course, assume that they are tracking projects via measurements. And by measurements I am not just talking about being on schedule, within budget, and delivering the stated scope. I’m including the delivery of the benefits and/or compliance issues as stated in the project business case (discretionary and nondiscretionary projects).

Often, project benefits are not realized until after project closure; therefore, they need to be tracked at the enterprise level.

Continuing with the follow-up questions, “Does your business actually audit the business results? Or does your firm declare victory upon the completion of a project and then move its attention to the next endeavor without any reconciliation of the business needs actually being met?” Unfortunately, many firms only measure the project level “triple constraint” (time, cost, scope) while the tracking of the business results at the enterprise level goes unrecognized and unrecorded.

Success is not gained from the project execution, but in the business result it provides.

Using active listening, I gain a better understanding of the students’ experiences. Typically responses to my initial question are the following:

“Our project performance is good; our projects generally come in on time, within budget and deliver the committed scope” or
“Not so good. We have experienced some challenges in maintaining project scope along with unclear business results.”

With the former response, I advise the students if they feel project results cannot be improved then don’t change. Of course, in reality there is always room for improvement; it’s just a matter of cost vs. benefits. Along with this, I recommend that students consider benchmarking their results with other firms in their industry to ensure they are not missing an opportunity. Competitors may have found ways of achieving better results, not only lowering cost, but gaining new revenue and deteriorating your firm’s market share.

Those who do not monitor their competitors soon find themselves working for them.

With the latter response, I advise the students that business analysis techniques lower the risk of maintaining project scope and ensuring business results. These techniques are best practices and as best practices, they are proven to be effective and efficient in analyzing business requirements and process improvements. Some of these are:

Using the diagnostic approach
Modeling the current (AS-IS) and desired (TO-BE)
Determining root cause of problems
Measuring performance via metrics
Involving users
Building a business case
Defining and validating requirements iteratively
Tracing requirements back to the business need

I suggest to the students that they have before them the opportunity to help explain to their firm how business analysis techniques at both the project and enterprise level can improve their business results. Their first step is to list the threats and opportunities for their business. They can then gain support by developing stories that predict both positive and negative results for their firm.

Business analysis techniques lower the risk of maintaining project scope and ensure business results.

This means, of course, that their firm must change their current posture and adopt business analysis techniques at both the project and enterprise level. Unfortunately, history shows that human beings typically are not motivated to change until they reach a cusp of a crisis. Hollywood portrayed this behavior recently in a dialogue between an outer-space alien and an earth scientist on changing the nature of human beings to save the environment of their planet (2). In this context, the key is for the firm to change prior to the demise of the business.

For change to happen, a sense of urgency needs to be established.

So in conclusion, “How is that working for you?” If your answer is “not so good,” then you have an opportunity to take the Kotter’s first step in changing the organization – state a sense of urgency (3). Start a dialogue on addressing the business threats and loss opportunities of not achieving business results (i.e., a business case). After you have established the urgency (As-Is model), establish a team, define a vision (To-Be model), and conduct a gap analysis on how to make the transition using those business analysis techniques. Yes, business analysis techniques do take time, but in reality they are time savers and saviors of the business.

Pay me now during the project or pay me much more later during the business.

Don’t forget to leave your comments below.

Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

References

(1) Cracking Creativity: The Secrets of Creative Genius by Michael Michalko, 2001
(2) The Day the Earth Stood Still, 20^th Century Studio, 2009
(3) Leading Change by John P. Kotter, 1996

Be an IT Star: Practice Business Analysis Skills

Written by Kupe Kupersmith on April 26, 2011. Posted in Articles.

I came across an article written in 2008 on CIO.com and thought you would love to know the Four Secrets to Becoming an IT Star. According to this article, being an excellent BA will help you on the path to stardom. The author does not say that outright in the article, but it sure was my interpretation. The fours secrets are:

Be good to your end user

The author of the article says if you want to get ahead don’t make people feel stupid. You need to remember whether it is technical speak or discussing your business analysis process don’t try to sound smarter than your customers. All that does it make them feel uncomfortable and not want to collaborate with you. Don’t try to impress them with buzz words. Impress them with compassion and empathy. It’s not about you; it’s about solving their problems. Always use language that is comfortable for your customer.

Go beyond the walls of IT and learn the business

This is so a business analysis activity. The article talks about understanding business processes and observing the business community to know and see their pains. As a business analyst, if you are not away from your desk talking with your business stakeholders and observing how they operate, you may want to consider another profession.

Understand the organization’s structure and goals

As a BA you need to be focusing your efforts on the top priorities of the company. When assigned to a project make sure you know where your project fits in with the overall goals of the organization. During planning you should make sure you choose activities allowing you to spend the appropriate time based on the company’s priority of your project. In the article there was talk about creating value and knowing what the business views as high priority. As a business analyst this needs to be your primary mindset. If an activity adds value to the goals of the company do it. If it does not add value, don’t.

Build trust with your boss

In the article it is discussed that you have to be open and honest with your boss. Share the good and bad news and don’t sugar coat issues. The last thing a boss wants is to be blindsided with an issue which could he/she could have known about. This is something I believe should go beyond just your boss. In my last blog, It’s Time to Take the “Naked” Approach to Business Analysis, I touched on this concept. You have to be open and tell the truth whether the news is good or bad. This applies to your boss, your team, and definitely your business stakeholders.

If you’ve read my earlier blogs you know I believe these are some of the qualities you need to separate yourself from the pack and be a desired business analyst. I have also been saying for awhile now that the next generation of CIOs will be coming from the BA ranks. This article supports that conclusion especially since the article was written based on interviews with CIOs. So keep it up and be a star in your organization.

To soaring to the C-level,

Kupe

Don’t forget to leave your comments below.

How to Impress Executives with Your Presentations

Written by Sergey Korban on April 19, 2011. Posted in Articles.

Business analysts and project managers need to be able to present their work, such as findings of completed analysis, proposed changes to business processes and/or underlying systems, or project status. If you Google “executive presentations”, you’ll get a lot of links but quite often these resources are focused on how to prepare or behave during the presentation. There is another aspect I’d like to propose – what should be in the presentation and how the content should be organized. This article lists the important considerations in preparing an executive presentation from my experience.

Initiating the Project

Try to limit the summary or overview to ONE slide
Executives rarely have time to go into a lot of detail for a project, so my approach is to summarize the project on exactly one slide. This slide should provide an overview of the key points at a glance. As this may be the only slide that you are given time to present so it needs to succinct and direct. By concentrating on this single slide you are forced to focus on presenting only the essential information. Short sentences, rather than bullet points, are more appropriate, especially if the handout will be referred to later, or passed on to others who were not in attendance. You can still go into detail during the rest of the presentation as needed, or as time permits.

Use metaphors

The human mind loves metaphors, especially curious ones. I use the metaphor of a highway with distances between towns to prepare the executives for a phased approach to moving from the current state with its pain points to the painless target state. You should use whatever is appropriate for your executives or project.

Give direction

To get the executives’ attention, I use the strategy of transition from one state to another as a foundation of my one slide presentation. I outline the key pain points, align the transition strategy with the enterprise’s business objectives and draw the future state. Executives should be able to relate to this approach.

Announce stop points

Depending on the nature of the message; I divide the whole route into several segments with stop-points and call them phases. The stop-points are gates which will be used to assess the results of the completed phase before making the decision to move further forward (also known as go/no-go decision points). I describe what will be done during a particular phase and how long it is expected to take, at what cost, what risks are known, what changes are envisioned, and then highlight the expected achievements to keep everyone’s spirits up.

Deal with risks

The picture can’t be completely idyllic however! There are no actions without risk, so it’s best to identify the initial risks upfront. The executives will usually add a few more through their discussions and questions, and I make sure to write them down. I also let them know that the identification and mitigation of risks is a major process and will continue throughout the project.

Show costs vs. savings

Any trip costs money. I use this idea to keep executives in the comfort zone. When giving cost estimates I think it’s important to mention savings and/or benefits even if they are only potential. The key point here is that you have given thought to that business aspect of the project. Just remember that any initial cost estimate, even though the emphasis is on “estimate”, will be recorded and unfortunately never forgotten.

Close with a summary

At the end of the presentation I quickly summarize the key phases and key achievements, the projected costs, expected potential savings, changes to the existing state and what the target state looks like.

Here is an example layout that could be used for an executive presentation:

Reporting project progress

After the project has started, you will be required to report its progress, as needed or as identified as part of the project plan. These progress reports are usually presented to various formats and to different audiences, but often include presentations for the executive team. In addition to the normal progress report elements of budget and schedule I have noticed that there is a missing piece of information that should be provided by BAs for these presentations. Very seldom are the executives told how the business goals of the project are being met by business requirements in the course of the project effort.

The executives can derive some information from the Project Status report: the results which have been achieved (or not achieved, as the case may be) during the current phase, the costs incurred to date, the activities planned for the next phase, as well as resourcing issues, identified risks, outstanding issues and so on. However, this is detailed information which may be commonly presented but may not be optimal for executive decisions that are needed.

A good approach can be borrowed from the ERP world. There, all system capabilities are translated into the terminology of business needs and goals, thus greatly simplifying executive decision making. The factsheets from well-known vendors are full of descriptions of what their system does but not how exactly it operates. How can this approach be applied to the BA realm?

When doing business analysis work, a BA produces different artifacts, such as the Project Vision. This document outlines the high-level business requirements and expected outcomes. These requirements reflect the executive view of the solution and can be used to validate the high-level business requirements and summary capabilities of the solution being delivered.

Each phase of the project from now on can be reported on in terms of coverage of the solution capabilities by the determined business, functional and non-functional requirements, as long as these remain at a high level. Too much detail tends to make executives lose interest (unless they are very detailed oriented and not functioning as an executive).

What are the benefits of this approach for the executives?

Firstly, the executives deal with a much less complex context of the project. Secondly, the decision making is supported by assessing the top level of capabilities expressed in the business language. Finally, progress on the project is easily tracked through a proxy of the capabilities.

Both business analysts and project managers will benefit from this approach. The project team as a whole will be better able to communicate the results of their efforts on the project clearly and effectively. They will also find it easier to address questions in a more business focused manner, without getting bogged down by the details of functional requirements, changes to software, and especially non-functional requirements.

Conclusion

The key to executive presentations is to include only the information, and in the most appropriate method, which is crucial for executive decision making while avoiding diving into details unless it’s specifically requested.

Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of visual learning and reference materials for business analysts.