Skip to main content

Tag: Business Analysis

O User, Where Art Thou?

Written by Zeena Kabir on . Posted in Articles. 3 Comments on O User, Where Art Thou?

In my previous article (http://www.batimes.com/articles/are-we-there-yet.html), I referenced the Standish Group’s CHAOS Report, which stated that the biggest issue leading to project pain is lack of user input.  Anyone reading this blog should know that user participation is a vital part of the software development lifecycle (SDLC).  Therefore, you should interview customers for requirements early and as often as possible in the SDLC.  Since you can’t get input from every user, you will need to place users into groups of user classes, which are based on the features and functions that are most utilized by each class.  Each of these user classes will have its own prioritized set of user, functional and non-functional requirements.  Once you have identified the different user classes, you will need to name the product champion within each user class.  This is a person who has expert understanding and decision-making power to formulate requirements on behalf of the user class they are representing. Even if you can locate this spokesperson, they will have other tasks in their day-to-day life that will compete with the time you need to spend with them.  For this reason, you should make a request to the champion’s management, letting them know that the champion’s involvement is a priority.

Since most projects have several user classes and each person knows something different from the others, you will need a small number of these product champions.  During requirements elicitation, each of these champions will get involved often and at different times depending on the function/feature/process being detailed.  You should look for one representative per user class, and sometimes you can get lucky by finding someone who can represent several user classes.  This product champion should be able to communicate requirements, suggest ideas, reconcile between contradictory information and help you arrive at a cohesive set of requirements for their user class.  This person also needs to make key decisions, which means they need to be informed, respected and be an effective communicator within their user class.  In a model situation, product champions are located with the analysts, testers and developers, and can devote their entire time to answering questions and providing all the necessary details during requirements elicitation.  In reality, few champions are located with the analysts, testers and developers.  Also, you are fortunate if you can get a couple of hours a day of the champion’s time due to other tasks they need to perform within the organization.  Therefore, when selecting project champions, look for the following traits and factors:

  • They must be knowledgeable and respected within their user class.
  • They need to understand and be committed to their tasks as product champions.
  • They should have the time to commit and their management should encourage their involvement.
  • They should have the power to make key decisions.  If product champions do not have the power or the willingness to make the necessary decisions, then the developers will make them for them.  This is not a good idea because developers usually do not have the right point of view to make the best decisions for the business.

There are situations where the analyst has very little or no access to the real users.  This happens quite a bit when developing commercial software products for a new or emerging market.  In these cases, you need to use surrogate users versus real user champions.  This can be a product manager or a subject matter expert (SME) in the field.  There are a couple of groups to stay away from if you are going to choose surrogate users.  Avoid the manager of the real users as a surrogate champion.  Usually, managers don’t use the product like the real users use the product.  Secondly, managers don’t have the time to fully dedicate themselves during requirements elicitation.  Another group to avoid as a surrogate champion is the software developer.  Unless the developers themselves are using the product, they do not make good surrogates because developers have a different point of view of the product than the actual users.

If your stakeholders do not put a priority on allowing product champions to work with analysts then tell them this: you’re going to need to get user input now if you want to spend less time, money and cause less frustrations during user acceptance testing.  Your projects will be less “challenged” when you get user input early and often during requirements elicitation versus waiting until the system is in testing or in production.  If the stakeholders can’t get users or surrogates during requirements elicitation then this indicates that there is little assurance of the success of your project.

Don’t forget to leave your comments below.

Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.

A Dressing Down for Business Analysts

Written by Robin Grace on . Posted in Articles.

FEATUREJuly11BA: “They didn’t participate in my workshop. Again.”

Mentor: “You must be mortified.”

BA: “Seriously, they come up with these lame excuses: they don’t understand that computer stuff, they’re too busy, or they think it’s a waste of time. One even told me to just get it done and let him have a look when I’m finished. How must I fathom the requirements myself? And they call that idiot a professional.”

Mentor: “You sound like a stuck record. Every other week you stomp in here ranting about the users, the stakeholders, the so-called professionals who waste your time. You always blame everybody else.”

BA: “So now it’s my fault?”

Mentor: “When I was a green analyst I had the same problem. You know what I did?”

BA: “Hired Chuck Norris?”

Mentor: “I went back to basics – I started planning properly.”

BA: “Planning? First it’s my fault and now I did not plan! Well I did plan. I planned for all those morons to attendmy meeting this morning – I even bought muffins, for goodness’ sake – and none of them arrived. By the way – you want a muffin?”

Music to a BA’s ears

If I had 100 dollars for every time I heard a BA complain about the stakeholders not participating in  their meetings I would have – and I am not making this up – exactly 87 bazillion dollars and 50 cents. The big problem with people not participating in your meetings is that by the time you see a room full of empty seats it’s too late. The damage is done. You see, getting stakeholders to your meetings starts long before you even call a meeting.

In fact, it begins with a classic film: “The Sound of Music”. “When you read you begin with A, B, C. When you sing you begin with Do-Re-Mi.” And then you have the lines, “Doe, a deer, a female deer,” and so on. The point is that you begin at the beginning and the beginning of any BA project is planning.

So, as my fictitious friend asked earlier: What does planning have to do with putting people in the seats? For starters most BAs I come across don’t do enough, if any, planning, yet the Business Analyst Body of Knowledge (BABOK) clearly has an entire chapter devoted to it – Chapter 2 to be precise. Some of you may argue that you do plan. You create lists of stakeholders, you assign roles and responsibilities. But, on closer inspection, most BAs think that copying and pasting a list of stakeholders from some other project is a substitute for planning. It isn’t. There is no way around it. If you copied and pasted then you did not plan.

The list is important because it is the very first step the BA, that’s you, takes in understanding who does what, when, how, where and why. And if you don’t know that then you cannot convey any sense of understanding, relevance, or importance to the stakeholders. And without those only the soft-hearted will attend your meetings.

The BA communications plan describes how we will communicate with the stakeholders. Any stakeholders on the list that have an RACI “C” next to their name must become part of the elicitation process. Most often we will “C”onsult with them in a requirements workshop. We have to inform them of when we would like to “C”onsult with them and exactly what we will need from them.

It all makes perfectly good sense because you are ensuring that the right people are involved and that they know what is expected of them. The next thing you do is get their consent, their approval, because that leads to buy-in. You’ll need them to agree to what must be done, when it must be done, and who must perform each activity to gather all the requirements. There is also an implied contract that the BA needs those people to do their work for the sponsor and, if they don’t pitch, they are wasting the sponsor’s money. One way of getting that message across is through the content of the invitation to the workshop. Suggest that the participant’s involvement is crucial to the success of the project and that the sponsor is aware of this. If the sponsor has any organizational clout, it’s the added incentive stakeholders need to be there and be on time. In other words: wag the big stick.

The BA and the Paperwork

What you’ve done by ensuring only the right people attend the meeting is that nobody’s time is wasted. You don’t have people sitting around wondering why they never said a thing, never contributed to the proceedings. That quickly annoys people, particularly the busy ones These same people are the oneswho are important to the project at some point, if not right then. Having only the right people at meetings also makes the meetings move along more swiftly. Shorter meetings leave people more inclined to attend future sessions. More focused meetings with only the necessary people in attendance, also finish more quickly because everyone is driving to the same clear goal. So where do you find the required participants? You go back to your stakeholder list and communications plan, which should identify who should be present for the process under scrutiny and it’ll be correct because you didn’t just copy and paste.

The next item on your busy agenda is language. Imagine the conversation at the beginning of this story being between a BA speaking Russian and the mentor speaking Cantonese. They’re probably going to get things a little muddled and may even end up becoming frustrated with each other. By the same token you need to speak the language your stakeholders understand. If every other word you use is  jargon that only BAs understand, then your stakeholders will quickly get bored and start imagining the fantastic little getaway they’ve arranged for the weekend..

Context is king. Put the meeting in the context of your stakeholders so that they can understand the reasons why they are there in the first place: “I know you have customers and they place orders; tell me more about what you do when you receive a customer order.” It focuses the workshop immediately, the participants feel you understand what they do, and it shows you value their time enough to have done some groundwork.

If you do all of these suggestions,  through careful up-front planning to obtain a focused, contextualised outcome, then stakeholders will quickly feel appreciated and relevant and possibly even enthusiastic about your meetings. OK, maybe not always enthusiastic. But you will be able to imagine a completely different conversation to the one that opened this story.

I always say: If you can show business real value in what you do, then business will start to really value you.

Don’t forget to leave your comments below.

Unleash the Business Analysis Profiler in You

Written by Kupe Kupersmith on . Posted in Articles. 1 Comment on Unleash the Business Analysis Profiler in You

Kupe_May31The moment I sat down at an airport bar the bartender asked me if I’d like to try a Long Island Iced Tea (an adult drink). I declined and ordered my meal.  Later an older gentleman sat down next to me and the bartender asked if he’d like to try a Bloody Mary (another adult drink). I was confused.  I figured she asked me if I wanted a Long Island Iced Tea because that was the drink they were trying to sell that day.  Since I was confused, I had to ask her why she offered us different drinks.  Her answer was superb.

She said I profile my customers.  Older customers tend to like drinks with juices or sodas that help settle the stomach and younger business looking guys like you enjoy Long Island Iced Teas.  Couples with a fresh tan, most likely coming from a beach vacation, enjoy a good beer, younger preppy women like the sweet drinks, classy looking women like a good wine, and large groups go for Margaritas and Jagermeister shots.  I was blown away with the level of detail she had captured over the years.  I told her she would be an unbelievable Business Analyst.  Of course she had no clue what it meant to be a Business Analyst.

You need to approach your stakeholder analysis in this fashion.  Be a BA profiler.  Start to put your stakeholders in categories to determine how best to communicate with them.  As new stakeholders are introduced you can have a starting point of how you may best communicate with them.  Many of you most likely do this already.  For the solution team you know they’ll need a lot of detail while upper management and project sponsors like summaries.  Younger teammates prefer texting and instant messaging, where older teammates prefer phone calls or face to face interactions. Profiling will give you a starting point. You still have to ask to verify how they’d like to communicate. Don’t assume your stakeholders fit neatly into your profile. If I was drinking that afternoon, I would have preferred a Bloody Mary over a Long Island Iced Tea.   

Another thing to highlight from my bartenders profiling is how people may order differently when in a group as opposed to being on their own. It is important to realize your stakeholders may act differently in a group.  Don’t assume every stakeholder will want to interact the same when working one-on-one and in a group setting.  Individuals that may be very opinionated and comfortable opening up one-on-one, may be very quiet in a group.  Don’t assume those individuals just have nothing to say during a group meeting.  Follow-up with them after the meeting to check-in. 

Profiling does help, but don’t solely rely on your profiles.  The best way to ensure you’ll be communicating and interacting with your stakeholders the way they prefer is simple.  Just ask.

All the best,

Kupe

Don’t forget to leave your comments below.

Asking the Right Question – “Chicken or Egg” Answered

Written by Michal Mintowt-Czyz on . Posted in Articles.

One of the fundamental skills of a business analyst is asking the right question to the right person in order to get to the bottom of an issue. The method of getting to this point is a case of breaking down the issue to an elemental level. To prove this concept we shall attempt to answer the age old question: “Which came first the chicken or the egg?”

Chicken? Or Egg?

The three basic factors in this question are the time, a chicken and an egg.

First, let’s validate our assumptions about all three using an expert source, in this case we shall use a universally accepted authority, a dictionary:

  • Time: the indefinite continued progress of existence and events in the past, present, and future regarded as a whole
  • Chicken: a common domestic fowl
  • Egg: an oval or round membrane laid by a female bird, reptile, fish, or invertebrate, usually containing a developing embryo.

While the Time and Chicken are defined to a reasonable level, the egg definition contain, challenges to our assumptions; i.e. to lay an egg, you don’t have to be a chicken.

Since an egg can be laid by another species other than a chicken (e.g. a dinosaur or crocodile) the answer to our original question would clearly be the egg.

In order to avoid any ambiguity we might then ask our stakeholder, does the original question regard a chicken egg? If the answer is “Yes”, then we need to look more closely at the definition of a chicken egg. We could ask the stakeholder: “Does the egg need to be fertilised to count as an egg?”

Once again, we would refer to a medical definition;

“An animal reproductive body consisting of an ovum together with its nutritive and protective envelopes and having the capacity to develop into a new individual capable of independent existence”

The egg is defined as the membrane that has the capacity to support the growth of a chicken embryo and therefore it does not require a fertilised embryo of a chicken to make it a chicken egg. Therefore, because a chicken egg can be made with out a chicken laying it or emerging from it the chicken does not yet exist.

As a chicken egg can exist without a chicken, it must be concluded that the egg must have come first.

To summarise the process above, you need to break down the question to its core components:

  • Identify the contributing stakeholders/factors
  • Agree definition of factors
  • Identify assumptions
  • Challenge assumptions
  • Define key questions
  • Answer key questions in order to validate the assumptions

Once the smaller/simpler questions have been answered, an overall answer or solution may be built. It is important to note that the more critical you are of your own assumptions the more creative scope the solution has. In other words, it results in ‘out the box thinking’ that will get you a reputation as an ideas person; this is someone everyone wants on their project team.

The basic premise of breaking down problems is not new or revolutionary, but applying structure gives the process scalability so any problem can be solved regardless of size and complexity. The above can be used with challenges you are currently facing, but also with challenges, you believe you’ve overcome (did you really overcome them, or was the issue only temporarily dealt with?)

As business analyst, it’s our job to find out what the business needs and sometimes the needs are in contradictory. Plato once said “Necessity is the mother of invention”. Since the business analyst must identify the necessity, the business analyst must have a hand in the invention.

Don’t forget to leave your comments below.

Michal Mintowt-Czyz is a Business Analyst for the Principality Building Society. He has worked in the financial sector as a BA for 6 years and has conducted analysis throughout Europe and South East Asia. 

Email: [email protected]

As if Re-work Wasn’t Enough …

Written by Tony Higgins on . Posted in Articles.

Studies show that somewhere between 25-50% of software project budgets are consumed by re-work. That means work that needs to be done again because, for some reason, the results were not correct. Significantly, 70-85% of this rework is directly related to poor requirements. Of course, we all know that there are many reasons requirements fall short and that there are many things that can be done to remedy this. But if the wasted budget wasn’t enough to think about, there’s more!

After the average project spins its wheels burning through scarce resources and eventually reaches the ‘goal-line’ with a finished product, we run head-first into another sobering industry statistic: for every software product delivered, 45% of the features, on average, are never used! [1] That’s right. NEVER used.

There could be many reasons why we spend lots of time and money building features that aren’t needed by the user community, but my money would be, once again, on poor requirements. Some probable sources:

  • Requirements elicitation and analysis wasn’t thorough enough to truly understand the needs of the business and/or the user community
  • Requirements validation with stakeholders was inadequate allowing unneeded features to remain undetected
  • Requirements ambiguities that allow developers to “fill-in the blanks” with unnecessary functionality
  • Insufficient user and other stakeholder involvement at key points during the development lifecycle prevented these issues from being detected
  • Inadequate scope management allowed additional and unsanctioned features to be introduced at various points throughout the development cycle

It’s difficult to estimate how much of a project budget could be saved by not building those 45% unused features. It depends on how significant and ‘deep-rooted’ the features are. At one end of the scale, they could simply be superficial features and options whose exclusion would have little or no impact on the underlying layers of the application. At the other end, like an ice-berg, they could represent just the exposed parts of much larger underlying capability. I suspect most are of the former kind, but 45% is a big number. It’s likely that some unneeded features involve significant capabilities of the application.

Adding to the additional development costs for these unused features, there are also the testing costs. Tests have to be written and test data created; the tests have to be run and the results reported; and bugs have to be fixed and then retested with regression-all for a feature set that will never be used. Then, the support group needs to learn more than they’ll ever get support calls for. And add to that, the costs to create training materials, guides, tutorials, online help and other resources for unused features.

The maintenance cost of the application will also be larger than it needs to be. Not necessarily because bugs will be reported on these unused features, but because as long as they exist and are in service, any fixes and enhancements will need to be regression tested to ensure that they remain unaffected.

Those are the hard costs that are incurred when you create an application with 45% unused features. But the soft costs are also significant. New users are forced to learn much more than they will ever use in practice. Plus, the usability of any application with so many unused features has to be negatively impacted. At a minimum those who designed the user interface would have had to make compromises in terms of menu and ribbon designs, wizards, dialog boxes, and preference-option screens to accommodate these additional features. It’s likely that any designer would be able to create a better and more efficient user-experience by focusing on the exact 55% of features that were actually needed.

When looking to improve the economics of application development for business, efforts should be focused on those areas with the largest potential for gain. I would suggest that reducing the 25-50% of your budget wasted on rework, and preventing the creation of 45% unused features are good places to start. And that means improving your requirements.

Don’t forget to leave your comments below.

[1] Jim Johnson. The Standish Group International Inc. 2002.

Tony Higgins is Vice-President of Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst. Tony can be reached at [email protected].