Tag: BABOK

Getting the Project Client to Focus on Requirements

Written by Brad Egeland on September 21, 2015. Posted in Articles. 1 Comment on Getting the Project Client to Focus on Requirements

Having trouble extracting project requirements from your customer? Does your project client think they have already handed you all of their requirements and is asking why you aren’t starting to design the solution yet? Are they worried about eating up the project budget with useless planning when you could be starting the “real” work on the project?

I know starting the real work on the project is tempting. It may even be possible – if it’s a two day or two-week project. But if your project is of any length and dollar amount to speak of, then you must – repeat MUST – have genuine project requirements. These requirements must be detailed enough to design and build a solution, and complete and complex enough for you to avoid making wrong assumptions that result in expensive and time-consuming rework later on in the engagement.

You can’t please everyone all of the time

For me, it’s about asking the right questions. For the business analyst who is likely leading much of the requirements definition effort and functional design document work, it has to be about asking the right questions as well. What the customer thinks are the requirements usually aren’t the real requirements. Often, as many have found, and the rest will soon discover, what the customer thinks is the problem is probably only a symptom of the real issue. The actual project may be a few layers down – and that’s the problem, need or issue you need to address. Otherwise, you’ll end up delivering something that doesn’t solve the end users’ real needs.

You may have followed the customer’s perceived requirements perfectly and gotten paid handsomely at the end of the engagement (and during). But 30 days later you find out that your customer is not very happy because what you delivered – while spot on with requirements – is not what they needed. And you now have a dissatisfied client and one who will likely point the finger at you while going somewhere else to get it fixed, and their overlooking you for their next project. Ouch. No, let’s get it right the first time. Here’s how you get there.

The key questions for the client

Related Article: Process Approach to Requirements Gathering

What are you current business processes as they pertain to this project?

The key here is to understand how the business operates now. It will help you understand their need or the perceived need. It will help you see the layers you may need to dig through to get to the “real” need if it isn’t the one the customer is currently presenting. It will help you see who else you may need to include in the discussion. What other key areas of the business are tied into this process? You should find that out here.

What do you want the new solution to be?

This one goes hand in hand with the question above and will give you even more insight into what the customer is thinking and if the real need is the one they have identified. Knowing the “as is” and the “to be” environment is critical to connecting the dots to get the client there. The “as is” situation tells you where they are coming from, and the “to be” will tell you a lot about what they are hoping to accomplish. It may help you better define the questioning process from this point forward.

What specific problems are your end users experiencing?

This is where you find out how tied into the process the end users are or have been up to this point. Maybe they originated the project request. Or maybe they know nothing about it. You need to know the answer to this question, and you need to draw them into the process. They are key.

Do you have specific technology needs or wants in mind?

There may be some underlying desire for a specific technology. I’ve gotten to this point a couple of times only to find out that a new technology – no real urgent need – is the only reason for the project. That’s not a bad thing – just a good thing to know up front. It may (or may not) change how you manage the project or the urgency of it. Just ask, you won’t be sorry.

Is this project supported by the executives?

Finally, make sure there is support for the project by the higher ups. It may not be appropriate to ask of an outside client. But if this is an internal project, it is definitely a question to ask. Why? Because lots of project “phishing” happens before any real funding or project approval has happened when you’re dealing with projects that are internal to your own company. They tend to skirt the formal process and may end up wasting a lot of your time and PMO time when there is no project out there. And how do you approach this on an external project? Well, carefully. But a skilled PM or BA can figure out a way to ask if the customer’s leadership is behind the effort. If you see this as a “weak” project or one that may not really be necessary, it’s a good question to ask no matter how you may go about it.

Summary

There really aren’t any magic questions that will that will draw out everything you need to know to deliver the right solution. No magic question that will make everyone happy and make all those potentially costly change orders completely unnecessary. Stuff happens, change orders happen, requirements change and sometimes they are foggy no matter how hard you try. They key is to try hard up front – put the effort into it. Good PM and good BA oversight and investigative questioning of the project client will get you 90% of the way there. The other 10% will be experience, skill, interpretation and a little luck.

How about our readers? What do you “ask” or “demand” to get you through the muck to the real customer need and true customer requirements? Please share your thoughts and expertise (and failures if you don’t mind).

8 Tips for the Newbie Business Analyst

Written by Racquel Ellis on September 14, 2015. Posted in Articles.

For many of us, a new experience comes with varying degrees of anxiety and nervousness. This is particularly true if we have lingering doubts as to our ability to do what is being asked of us – even if such doubts have no basis. Moving from a job where you knew what to do like the “back of your hand” to one where the learning curve is steep is one of those nerve-wracking moments that test the mettle of any business analyst. Of course, the extent of your anxiety is minimized given your years of experience and success stories as a business analyst. That said, it is critical that as a business analyst entering a new role or job position you showcase confidence. Let your stakeholders know that you know that you can deliver the results they need even if you do not know their business like the “back of your hand”. Your work will speak for itself! It’s only a matter of time before you too become a domain expert.

I want to give a few suggestions to any business analyt who might find themselves in the “newbie business analyst” position.

1. Come to the job armed with a set of tools and techniques that you can readily transform into something of value to immediately show your stakeholders that they made the right decision when they chose you for the job.

The very first assignment should be done so well that it not only pleases your team leader but demonstrates to stakeholders that you possess the ability to clearly detail the business needs and value-added approaches to deriving a solution.

When I changed my job of over 18 years to take up a job in an institution that I knew little about, one of my first assignments was to assist the insurance arm of the business in implementing an electronic document management system. I started by understanding the process from existing team members, then went on to observe the process to prepare a presentation with best practice information to show team members time and cost savings they would achieve by implementing such a system. I also provided high-level process flows and steps showing the integration of the document management system in the business’s workflow.

I will not tell you that it was smooth sailing, but the quality of my work was apparent, and the stakeholders were able to use the information to present their case to the Board of Directors, who approved of the electronic document management system.

2. Be prepared to go above and beyond the call of duty.

While completing the task of assisting with the online document management system, the business was thinking of having clients complete and submit a form online, which they would use to give the client an estimated insurance quote. So I took the opportunity and did the additional work to show the business how an online insurance quote system would provide clients with even greater value instantaneously while obtaining contact information that the business could use to follow up and sell their services.

3. Be of no reputation.

Do not surrender your dignity but adopt an attitude where you care more about serving your stakeholder than explaining to people why you are a business analyst. Your work will speak for itself. People sometimes do not see the importance of a business analyst until they have a task to accomplish and realize how the work of the business analyst brings structure, organization, as well as diagrams that give a better understanding of the issue. When you hear negative feedback, analyze the truth of it, strip away what you can learn from it, apply the learning and disregard the rest. Every experience will make you a better business analyst and sometimes the feedback, though negative, is true and is an opportunity for you to change something about your attitude or approach. Believe me, I know. During the document management project, I learned that the importance of clear communication and the power of an organization’s culture is not something to be taken lightly.

4. Complete company sponsored courses that will help you to understand more about the business.

You will have a lot of work to do but in the midst of it find the time to complete any company sponsored course or read up on the business to understand how it works.

My new job was with an investment company with a banking and insurance arm. My previous company was quasi-government and dealt with mortgage financing. To say I knew little about the operations of my new job was being generous. However, I jumped at the opportunity to complete a securities course that opened my eyes to the nature of the business. This knowledge served me well in my next assignment that mostly had to do with the core business.

5. Become genuinely interested in team members and their roles at all levels.

Get to know people – from the security officer to the CEO (to the extent that you have the opportunity to) – and understand how their role contributes to the bigger picture of value and profits. People will willingly share their knowledge if they understand that you genuinely care about making their work simpler and easier, and are there to improve the business. The best ideas or feedback come from the people who are engaged in the work on a day-to-day basis. Getting the feedback is so much easier if you form a good relationship with fellow team members and never adopt an “us against them approach”. A business analyst should assist in making it easier to implement change, not turn people off by dictating change.

6. Know when to keep silent and start by asking questions.

Never assume or use preconceived notions as a basis for interacting with your stakeholders. Silence does not mean “dumbness”. When you’re new, you learn a lot more through listening and asking questions than by just talking. Don’t just talk with the intent of letting people know that you know. You’ve already shown your expertise because you’ve been hired. Even if you got the heads up about stakeholders, use that to guide how you present information to them, not to develop a negative attitude towards them.

7. Accept when you’re wrong.

You are a business analyst, not a perfect human being. You won’t get it all at first, and you will make some mistakes along the way. Don’t be too hard on yourself. Don’t explain your error away – even if you have an explanation, accept where you’ve erred, apologize if you need to and move on. In apologizing, state what went wrong and what you have done to not repeat the error. Misunderstandings will occur – we can’t help ourselves. However, a placated stakeholder now can be of great support for future tasks. Leave your stakeholder believing that you are still the right person for the job.

8. Be appropriate, functional and relevant.

Every working environment is different. Yes, you have a plethora of templates, tools, and techniques but they should operate as the universe from which you choose based on your environment. Don’t overwhelm your stakeholders with everything. Tweak your templates so that they address the needs of your current environment.

My previous job was very structured and formal. My current job is less structured with some aspects of informality. Here, stakeholders want to immediately see what you’re talking about, not get lost in concepts, theories, and templates. It was my duty to look at the templates I had and modify them in such a way that made it easier for stakeholders to make decisions. Don’t get boxed into template thinking. Sometimes, all that is required is a simple email! You don’t want to use a sledgehammer to kill an ant!

When I wrote my first requirements document, the IT department was so appreciative of it and the IT business analyst decided to use aspects of its layout in the preparation of her requirements. At another time, in order to get a decision from a stakeholder at a senior level, all I did was sent an email succinctly detailing the issues, pros, and cons. The executive confirmed that the email correctly captured our discussions and used it to communicate a decision.

As I said at the beginning of this article, being a newbie business analyst is temporary. Soon you will become an expert. Just keep doing well what you know and keep reminding your stakeholders why you are the best person for the job. All the best! Looking forward to your comments.

Leadership Lessons – Problems! Glorious Problems!

Written by Peter de Jager on August 17, 2015. Posted in Articles.

C. K. Chesterton penned a quote that I’m especially fond of, “It isn’t that they can’t see the solution. It’s that they can’t see the problem.” It’s one that constantly reminds me that there is always, without fail, an opportunity lying around somewhere. I just need to find a way to find it.

That wasn’t a typo, I meant to type ‘opportunity’, I didn’t forget that this discussion was about ‘problems’. A problem is an opportunity disguised as a thorn in your assumptions. Fix the problem and you’ve moved yourself forward in some manner, large or small.

Because of how I earn my living, I get lots of feedback – more than a person normally gets in other lines of work – file folders filled to overflowing with feedback. The good feedback is great, I love it (great reading when I’m down in the dumps), it’s what keeps me motivated to keep going. But it’s the negative feedback when people point out a problem, that’s the true treasure. Becoming aware of new problems, if we have the motivation to respond to them, is what motivates us not only to keep going but to start going in a new and improved direction. Problems are always doors to something better.

Organizations don’t like problems. We shy away from them; we shoot messengers who bring them to us, we surround ourselves with 800lb gorilla problems no-one dares talk about. We have terms describing cultural approaches to problems – ‘wilful ignorance’ comes to mind- and we have to legislate whistleblower laws to protect those who make problems public. Organizations let problems fester until there is no other option but to lance them like boils.

When I originally wrote this article, Wikileaks announced that in January 2011 it would release documents disclosing a pile of ‘problems’ in a major US bank. Of course, every ‘major’ bank worried that their ‘problems’ would see the light of day and scrambled to either hide these problems more deeply or hopefully fix the problems as soon as possible.

The irony is that whatever organization got their knuckles soundly rapped by Wikileaks… all of the organizations knew of these issues before Wikileaks, before someone else decided to take action. Organizations ignore problems that obviously need fixing until they are forced to act.

Not all problems fall into the category that Wikileaks exposes. Most of the organizational problems that readers of this article might encounter are more mundane, with less serious consequences. More in the line of “our projects are always delivered late; it takes an inordinate amount of time to get things approved; our meetings are a waste of time; our customer service needs improvement etc.”

Even these can become so much a part of the work environment that we become blind to them, hence my fondness of Chesterton’s quote. We are typically blind to most of the problems around us. We need some way to heighten our awareness of the invisible problems so that we can then, if we choose, correct them. If only we could place a bounty on problems, and in so doing, get everyone looking high and low for them!

Many organizations have some type of suggestion program where they always encourage, and then sometimes reward, employees for bringing new ideas, usually in the form of ‘solutions’, to management’s attention. It’s a step in the right direction of constant improvement, but this strategy contains a hidden flaw. It usually, not always, requires that an individual identifies a problem and then comes up with a viable solution – often on their own. That’s a lot of work for someone who’s already overworked in these tough economic times.

Here’s another idea – instead of requiring a solution – how about just identifying a prominent problem? The individual tagging the problem doesn’t have to solve it, just recognize that it’s worthy of solution. The problem is then passed along to a group of people who love solving problems, people like myself who see all problems as a personal challenge, even as an affront to our sense of order in the universe.

The challenge is still the fact that many problems just hide deep inside the “we’ve always done it that way!” bushes. It takes either a new set of eyes to see these opportunities, or a quickly annoying habit of constantly, incessantly, persistently asking “Why?” about every business process until inefficiencies (if they exist) are exposed.

Borrowing a new set of eyes isn’t too difficult to arrange. Just make it part of the organizational culture to have people from one department work in other departments for short periods of time and report back what they see. The hurdle is for everyone to grasp that the observations, while they will sound like criticisms, are intended – from the very outset – as a way to get better at whatever it is we do for a living.

As to the Why? Why? Why? Why? Why strategy? That requires someone with a peculiar personality. They must have both an analytical mind and a very very good sense of humour. The Why? Why? Why? Why? Why approach – especially about things that everyone takes for granted, takes some getting used to – a sense of humour can take the edge off just a little bit.

Leadership Lessons – Change in Seven Questions

Written by Peter de Jager on August 4, 2015. Posted in Articles. 1 Comment on Leadership Lessons – Change in Seven Questions

What must we do to bring about a Change initiative as smoothly as possible? Communicate! Communicate! Communicate!

How much, and for how long do we do this? Until we get sick and tired of the sound of our own voice – then we take a deep breath and a drink of water, and we start all over again.

Communication isn’t something that stops and starts; it’s a constant activity before, during and after any Change initiative.

This isn’t exactly news. We sort of get this. Ask any audience to tell you the secret to good Change and they will repeat back “Communicate, Communicate, and Communicate some more!” as if it was forcefully injected into their cerebellum. The problem arises when the questioning becomes a bit more detailed, “What exactly should we communicate?”

The response to that question is usually either a blank stare or the reasonable recitation of the reporter’s standby; Who, What, Where, When, How and Why. Not a bad start. If you’re writing a news article, then these are good solid questions. The Change Management problem requires all of those, and a few others besides. It’s not that the reporter’s questions are a poor tool; it’s just that they don’t address the peculiar psychology of the Change challenge.

For what it’s worth, here’s a carefully selected list of questions specific to Change Management. If we take the time to answer these, then we’ve covered the bulk of the key concerns of those facing the Change we’re contemplating.

1) Why?

This is the winner, the key question; it’s almost the only question worth discussing. If someone asks me to move from one side of the room to the other, or to stop using system ‘X’ instead of system ‘Y’, my response is always the same. “Why?” Understanding why a Change is necessary is the most important question we have about any Change. Without a good answer, we’re reluctant to do anything different.

There are lots of good answers to the “Why?” question. One good one is “Trust”. If I trust you and you ask me to do something, my trust in you might be sufficient to prompt me to Change. If that trust doesn’t exist? Then the reason for Change had better convince me, or I’m not moving from where I am.

2) WIIFM (What’s in it for me?)

The fly in the ointment for many organizations, “It’s not about you!” they cry as they bend over backward to avoid answering this question. Here’s the newsflash, as long as they are concerned about the WIIFM question, they don’t pay attention to any other information. More precisely, until that WIIFM question is answered, they can’t pay attention to anything else.

The best way to think of the WIIFM question is as a nasty, vicious guard dog, blocking the gate to our attention. Until that dog is thrown a bone, no information about the Change, sometimes not even the answers to the “Why?” question, is getting through to our reasoning process.
Even if we honestly have no information about the WIIFM question we must still acknowledge that the question exists and that as soon as we do have more information, we’ll get back to the audience.

3) Monday?

Assume, for the moment, we have returned from our strategic planning weekend with a wondrous, phenomenal vision of the future of our organization. Also assume, for the moment, that our ability to convince everyone that this is indeed the direction in which our organization should move, is up to the task. Assume that we’re silver tongued devils and get everyone on board, on the bus, bought in and generally all fired up. With me so far?

Now they have a question. What do we do differently, specifically and precisely on Monday (or next Friday…or next month… ) to start moving us towards the promised land of milk and ever flowing honey?

It’s a fair question. If we want people to Change, we must describe what they’re going to do differently in terms that everyone can understand. If we can’t, then we go back to the drawing board, our vision is flawed and unattainable.

4) Won’t?

What won’t Change? What will remain the same during this Change?

The problem here is that when we face a Change, all we see are the unknowns, we lose sight of the fact that only one ‘small’ part of our status quo is going to flux. That the rest of our surroundings will likely remain the same.

For example? When the accounting system is going to Change, we’re still going to report to the same boss, earn the same paycheque, receive the same benefits etc. In fact, most of our status quo will remain the same. This works for nearly all Change, the only time everything Changes is when we die, and then? It’s not our problem anymore. In nearly all other cases regardless of the size of the Change, nearly everything else remains the same.

5) Might?

What might go wrong during this Change? And what contingency plans have we put in place to mitigate those risks?

The worst thing we can do when heading into the uncertainty of Change is to insist that nothing can go wrong. That’s not only asking for the Gods to pay attention to us, but it also communicates to those around us that we haven’t really thought this through. Although if we’re looking for a sure-fire way to lose the trust of those who follow us, insisting, “Nothing will go wrong” is a wonderfully effective strategy.

6) Will?

What’s going to hurt?

Change hurts. That’s almost the ‘First Law of Change’. If we’re doing something significantly different, then we’re going to be at the bottom of the learning curve. Even if we pay close attention to training and support and fall back positions, we’re going to make mistakes, production will decline, and we’ll get things wrong. If we pretend that the Change will be painless, that it will be “transparent to the user”, then people will know we’re lying, or at least overly optimistic.

7) Signposts?

Change doesn’t always happen quickly, sometimes it’s slow, almost glacial in nature – we need some way of measuring our progress towards a goal. Without feedback we lose both the motivation and the will to make sacrifices to move forward. The question on the table is, “How do we know we’re succeeding in our efforts?”

These aren’t the only questions we need to answer during a Change, but they’re crucial ones and if the answers aren’t forthcoming, neither will the Change. Stick them on the wall in front of you when crafting a Change message and ask, “Am I answering these? If not? Why Not?”

Intelligent Analysis from Intelligence Analysis: Using Psychology Tips in our BA Tool Kit

Written by Bronia Shaw on August 4, 2015. Posted in Articles.

Have you ever wanted to be a spy?

We may not be qualified to be the gun-wielding, smooth-talking James Bond, but maybe a savvy CIA analyst might be more up our street. There are, of course, parallels in many types of analysis work and while our projects may be a little less glamorous than counter-terrorism, there are things we can learn from the world of Intelligence Analysts.

Richard J Heuer Jr in his book “Psychology of Intelligence Analysis” discusses the topic of when to make decisions. He explores methods used by doctors making diagnoses and applies this to the world of the CIA. How to know when you have enough information about a government, regime or situation to spot risks and make informed decisions.

It also applies to our world.

We all conduct interviews and workshops, dig into documents and ask questions but we determine for ourselves when enough-is-enough. Or rather time usually dictates when enough is enough. Heuer proposes that instead you could rather consider a smarter approach.

Make Decisions Earlier

Heuer warns that more knowledge leads to more confidence in a decision but not necessarily more accuracy. Using the example of horse racing pundits he shows that pretty good estimates are made with reasonably scant information and that experts recognize the limitations of their guesswork at this stage. As they are given further information about form and conditions their confidence levels grow, but interestingly their accuracy does not grow proportionately or even by much in real terms.

In business this may mean that when we gather a small amount of information we may get a reasonably accurate picture. As long as we can deal with the uncertain feeling, we save a lot of time and resources gathering more when the only outcome is greater comfort. Understanding the confidence level of stakeholders when they provide information gives us a good indication of when enough is enough.

Analyze Root Causes

How else can gathering more information be counter-productive?

Heuer tells of how analysts propose a theory while gathering or reviewing intelligence but that sometimes this would lead an analyst to use new information to strengthen an incorrect theory. Each piece of additional intelligence was being wrongly valued according to whether it reinforced the existing understanding.

How can this affect us? When considering the possible options of a new business proposition we need to check if fresh information reinforces more than one choice, not just if it supports the current favorite. If we have determined a product to offer, simply getting a positive response from a focus group on that particular product doesn’t make it the best proposition. They may be reacting to a particular product feature that is a feature of more than one product.

Knowing what probing questions to ask to uncover the underlying facts is for careful consideration by analysts. It surely grows with experience but can be honed when explicitly considered.

This book is just one example of the many that discuss psychology or the techniques learned from psychology studies. We have a mine of information we can extract and apply as a modern Business Analyst.

Consider another couple of examples:

How not to raise a risk

“Does fear persuade or does it paralyze?” is the title of a chapter from one of my favorite business books “Yes! 50 secrets from the science of persuasion” by Goldstein, Martin and Cialdini. They refer to the study of a public health leaflet highlighting the dangers of tetanus infection. The study gave leaflets to students were either frightening or not and that either had a plan of action or not. Which would motivate the students to get a tetanus injection? The leaflets with a high-fear message only generated action if a plan was included. The authors then note: “it’s important to accompany high-fear messages with specific recommendations for actions that will reduce the danger.” Readers of the leaflet were less likely to resort to denial if they had a clear action plan.

We, as Business Analysts are key experts in reporting potential risks to project management but if we often find that our warnings fall on deaf ears then perhaps consider how we present the risk. If we don’t already recommend or suggest mitigating activities then doing so could improve our chances of the risk being reduced.

Warping views with information

Daniel Kahneman in his book “Thinking, Fast and Slow” shows us the effect of “availability” of information, that is how often we come into contact with information and how readily we recall it. Availability affects our perception of our world and, therefore, our judgment. He discusses a study where participants were asked to judge the likeliness of different causes of death. They were then compared against statistics of the time. He notes that “Strokes cause almost twice as many deaths as all accidents combined, but 80% of respondents judged accidental death to be more likely.” This is revealing. He argues that “estimates of causes of death are warped by media coverage.” If we see multiple reports of tornadoes or earthquakes, then we are more likely to deem them as a higher risk, even where true probability states otherwise.

So how can we apply this to our Business Analysis work?

If we discuss one type of business problem using multiple examples then we can only expect that the participants will, for at least a short time after, view that type of problem as larger than it really may be.
After experiencing the realization of a project risk we would expect stakeholders to view avoiding similar risk as disproportionately more important because the information is easily called to mind.
We must be careful then that we don’t set up a situation where we create an increase in the availability of information prior to discussing subjects that may need to be downplayed to meet our objectives.

Getting the most out of the people we encounter during our project life-cycle and the time that we spend with them is so important. There are many more exciting tips and techniques discussed in psychology best-sellers. In the future I hope we see some of these techniques becoming part of the formal toolkit of the successful Business Analyst and not just the CIA.