Asking questions and getting answers

In the old days ya could just wack a guy and be done with it. Now everyone's feelings are involved.

That quote is from the movie Knockaround Guys. Not a great movie (it's quite bad actually) but an interesting quote from John Malkovich's character. When you look from the perspective of a business analyst, one of the most important things a business analyst can know is the answer to the question, "Why?"

• Why is this important?
• Why do you want this?
• Why? Why? Why? Why? Why?

Some individuals take offense to this sort of questioning. They misinterpret the question to be a challenge to their statements rather than the educational exercise it really is. Understanding "why" will basically allow you to determine whether you are going in the right direction. How does this requirement align with what the project is trying to accomplish?

To avoid receiving a chilly response to your "why" questions, you can do two things:

• Prep your client as to the purpose of the "why" questions. Explain that understanding the rationale will allow you grasp the essence of their desires.
• Word your questions to be non-threatening (e.g., cater for people's feelings.). As suggested in this post from Tyner Blain, use "what" and "how" questions to answer the "why" questions.

Ultimately, you are trying to foster a strong working relationship with your client. Understanding how to question them and get the answers you need in an open environment is paramount.

Defining requirements by priority

Or how do you know where to start?

For a large number of my posts I have written guidelines to help you write better requirements. One thing that I have not covered is how you can tell which requirements you should concentrate on.

If you refer back to my post How do you know you are done? you will find a subtle hint. Recall that I suggested that you get a handle on the basic overview of what a project is trying to accomplish.

When using iterative or Agile development methodologies you group together smaller pieces of functionality into work packages or releases. The order in which items get into work packages is usually based on a combination of anticipated benefits (ROI with NPV) and dependencies.

Why not use this same methodology to prioritize the order in which different areas of the overall requirements' set will be examined? This is why I say you need to understand the 'big moving parts' (as mentioned in a previous post.) Each of these 'big moving parts' (e.g., capabilities) has a defined benefit to it. Each capability can then be decomposed into more discrete sections.

The picture below outlines the basic principles of this exercise.


Once again, each of these sections can be assigned a priority (based on natural dependencies and the section's contribution to the benefit of the capability) After this activity has been done, a business analyst (e.g., you) can then start exploring the sections based on their priority. This yields a few advantages:

1. You focus on the most important pieces (e.g., highest priority.)
2. You reduce the amount of time spent on unimportant pieces. I know this sounds like the first item but I want to emphasize something. You can use this reasoning to control your requirement gathering sessions. When your clients, because of their attention to detail and natural excitement, venture into areas outside of your area of focus you will have the ammunition to refocus them. You can politely state that you want to park their current ideas and refocus back on the pertinent requirements' section.
3. You will have an idea about how much is left to do.

You may think, you could implement this methodology to help prioritize everything as you delve deeper and deeper into the most atomic requirements. Would I suggest doing it?

My answer is a polite, "No." Understanding how much benefit an atomic low-level requirement contributes to the overall project may be useful information, but I feel the amount of effort needed to maintain this data far outweighs any benefits that can be gained. You need to find a happy medium otherwise eventually your productivity will hit the law of diminishing returns. Furthermore, for low-level requirements, it may be difficult to say how much benefit a specific feature is providing.

Other related thoughts

Think about how the previous picture would change if a waterfall-type of approach was used rather than an iterative one.

Basic negotiation tips

During many points of your life you may be faced with a need to negotiate for something. Whether it be a promotion, a sales contract or to set expectations, there are some basic things that may make you more successful. This post does not seek to go into all of the advanced negotiation tactics, merely to provide practical guidelines.

Tips

1. Preparation is of the utmost importance. Do not enter a negotiation unprepared.
2. Perform due diligence on your position as well as the other party's. This will help you understand what you need, what the other party is looking for and perhaps what the other party thinks you are looking for. Understanding their rationale will offer you insights into their negotiation tactics.
3. Know the minimum you will settle for. This is your measuring stick for proposals.
4. Be open, flexible and willing to talk.
5. Be calm. Always try to be more patient than the other party.
6. If you are losing control, take a break. People make poor decisions when they are angry.
7. Clarify your terms.
8. If you think someone is bluffing, ask for proof to support their position.
9. Stress the common goals.
10. Use active-listening to ensure understanding.
11. Concentrate on one issue at a time.
12. Do not think a negotiation is a win-lose proposition and that you will only succeed if you screw the other party. Ponder this, if you feel you got screwed the last time you negotiated with someone; do you think the next time you negotiate with them you will try to get even? You may be establishing a long-term relationship, you do not need carry-over animosity.
13. Once you have gotten an acceptable offer, try to close the deal immediately. Do not allow the other party to rethink things.

Other resources

Here are some other resources you can read for negotiation tips.

• Barbara Braham, Business Co. - Negotiation Tips
• Work911 - Basic Negotiation Tips
• Creativepro.com - The Art of Business: Learn to Love Negotiating

Well-done or done well?

I remember flipping through the channels on TV and finding an interview with George Lucas (yes, that George Lucas.) The interview occurred shortly after the release of the Special Edition version of the first Star Wars trilogy. The interviewer asked George Lucas how complete the original trilogy was now. Mr. Lucas' answer was that he felt the movies were about 85% complete. The obvious follow-up question then became, "Are you going to revisit them and complete them?" The response was:

"A movie is never finished, only abandoned."

I wondered if this quote had any bearing on requirements and projects in general. My experience is that when you ask end-users what they want, a lot of them have a tendency to ask for everything under the sun. Features and requirements that probably would never be used by the vast majority of end-users will surface. Feature creep and change requests galore!

As a business analyst or business systems analyst you have a few cards to play to counter this.

1. Sometimes it is too early in the requirements gathering stage to get that specific. If you do not understand the general concepts and objectives, then getting into the nitty-gritty will not help. If this is happening to you, just ask your client to help you understand the big picture while stating that you made note of where you parked their thoughts so they can continue later.
   
2. When you prioritize things using cost-benefit analysis and dependencies, many specific features will become less and less important. Remember, not everything that is asked for necessarily is provided (refer to How do you know you are done?)
   
3. At some point in time, the team will need something they can work with. Lock-down the requirements for the iteration. Any changes require either a formal change request or must wait until a later iteration.

Number 2 in the list, implies that not everything will be developed. I think people have a mind-set that everything they have asked for is important and should be provided. But, as you know, some things are more important than others while other items are not important at all.

I would rather spend my time getting the most beneficial and important features done correctly than waste time chasing after one-offs. After all, use of your time is an investment. Would you rather invest in more profitable activities or not?

First things first: learn the skill

I was reading a post on Tyner Blain entitled, "Requirements management software will not solve the problem." Scott's point is the use of requirements management software does not mean you will have decent requirements for your project. I agree whole-heartedly.

I have found writing requirements is very different from writing prose or telling a story. Just because you have MS Word or another word processor it does not mean you are a writer. A person could be a writer using a word processor, an old-fashioned typewriter, or even pen and paper. The skills and talent to be a writer do not come from the tools used.
Writing requirements is a skill. And as with any skill, it needs to be cultivated and practised. To help you learn this I have put together a lot of posts on items that will help you improve. After you have increased your proficiency, you will be ready to use requirements management tools to improve your productivity. Note that it will take time to learn how to use the tools properly to gain all of the benefits they provide.

Cultivating the skill
Below are some of my older posts that will help you hone your requirements writing skills.

Tips on how to gather requirements: Understanding the Situation, Requirement Gathering Techniques, Expectation Setting, Time Estimation, Preparation and Words to Look Out For.

Tips for writing requirements: Correctness, Completeness, Clarity, Consistency, Testability, Traceability, Feasibility and Design Independence.

Things to avoid when writing requirements: Ambiguity, Multiple Requirements, Escapes Clauses, Rambling & Mixing, Speculation & Jargon, and Wishful Thinking.

How do you know you are done?

A while back I wrote a series of posts on requirement do's and don'ts. I would like to revisit two of the themes from that series (Bad Practices - Part III - Escapes, Rambling & Mixing and Good Requirements - Part VI - Traceability & Modularity) to provide more of an end-to-end perspective on how you know when have enough to move to the next step.

If you look back at those two posts you will notice that I mentioned that traceability is very important as you move from a higher level requirement to a lower, more specific one. Furthermore, I cautioned against mixing high-level requirements with low-level requirements. To show you my reasoning, I would like to step back and examine the rationale behind the different parts of a project.

A project's steps

Please note that this is an abstraction and it makes a few assumptions such as the use of an iterative (e.g., Agile) methodology and the existence of a project with a good return.

1. Identify the business problem or opportunity.
2. Make sure it aligns with your business' goals and objectives.
3. Quantify the key performance metrics.
4. Measure how you are doing and have done historically (if you are enhancing a pre-existing behavior.)
5. Determine the major business capabilities that would address the problem (or capitalize on the opportunity.) This provides a basic overview of the big moving parts.
6. Determine the success criteria. What will happen if you do it right? This should tie back to the key performance metrics.
7. Estimate the value of each business capability (e.g., how much benefit would you get from it.) Most people equate this to ROI, however you should make sure that you account for the risk of the venture and the timing at which benefits would be realized. A project with a higher amount of risk should use a larger factor to discount the expected benefits. A project whose benefits will be realized far into the future should have those benefits discounted more than a project whose benefits will be realized earlier. After all, a million dollars today is worth more than a million dollars five years from today. This concept is called net present value or NPV. Tyner Blain has a great post on calculating ROI using NPV.
8. Prioritize the major business capabilities using a combination of their business value, dependencies and other prioritization criteria (e.g., legislative deadlines.)
9. Examine the highest value business capability and break it apart into reasonable pieces that can be investigated.
10. For each piece, define the key requirements keeping in mind design independence.
11. Determine which aspects require process changes, software solutions etc... Basically, do some solution architecture / design work. What can you reuse? What can you buy? What do you need to build?
12. Estimate a cost for realizing the design of the piece.
13. Assign a proportion of the high-level capability's benefit valuation to each piece.
14. Prioritize the pieces based on cost-benefit and dependencies.
15. Work with end-users to define the layouts, workflows and characteristics associated with the piece with the highest priority.
16. Start an iterative development cycle for this piece. You can also concurrently examine the next high priority capability.
17. Interact with your end-users to show progress, development and to keep them engaged with the project.

Observations

• Cost-benefit valuations are used to assist the prioritization of components to analyze and develop.
• Break things up into digestible chunks but know how the chunks fit into the grand scheme of things.
• More detailed requirements were prepared, but the order in which they were gathered matched the priority associated with the component. Do not waste time on things that have low value.
• Pieces that have low or negative cost-benefit may not be developed at all! The interactions with business users were deliberately setup to focus on the level of abstraction that was desired. Initially, only the big picture things were desired. Then the next level for the most important component. And finally the detailed requirements for the highest priority piece of that component.
• Engagement between business and IT users promotes joint accountability for success and failure.
• I have purposely avoided using names such as functional specifications, business requirements, user requirements, functional requirements and the like because I do not feel the name is what is important. A name may imply something different to another person. The important thing is the activity which transpires.

Other resources

If you are interested in this topic here are some other blog postings that you may want to check out.

• Requirements vs design - which is which and why? from Tyner Blain
• MRDs, PRDs, FRSes, and SRSes from Roger Cauvin
• Requirements document proliferation from Tyner Blain

It's the little things... Words that should make your ears perk up

I was commenting on a post on Tyner Blain called Top five ways to be a better listener, when I saw a comment by Scott that stated, "reliable and fast can be completely ambiguous terms, because they mean different things to different people." I could not agree more.

I am not sure if you recall my earliest posts, but ambiguity is one of the biggest requirement pitfalls. You can refer to the following: Requirements & ambiguity, Bad Practices - Part I - Ambiguity and Bad Practices - Part IV - Speculative & Vague Terms to understand the consequences of a miscommunication.Then I got the not so brilliant idea to start up a list of simple words that can be viewed as ambiguous within the context of business requirements. This list is by no means exhaustive:

• Reliable (from Scott)
• Fast (also from Scott)
• User-friendly
• Flexible
• Easy-to-use
• Never
• Intuitive
• Future-proof

What do these terms actually mean? Anytime you hear one of these words be prepared to call for a time-out and clarify exactly what your client means.

Basically, if you hear qualitative statements from your clients, these are areas where you may need to clarify things using simple techniques such as active listening. This may sound like paranoia but remember it is much cheaper to clean up a miscommunication early in a project versus later in the system development life cycle.
There is a great post on Tyner Blain called How to interview when gathering requirements that I suggest you read as it will give you tips on how to extract the information you need.

Requirements & ambiguity

There is a great post on requirements defined called, "The art and science of disambiguation," that illustrates how easily it is for ambiguity to find its way into requirements. Even the most simple of statements can be misconstrued due to differences in perceptions of people.

That post fits well with my own post called Bad Practices - Part I - Ambiguity. Ways that you can counter ambiguity include:

1. Use active listening techniques to rephrase (in your own words) what you have heard back to the individual providing the information. If your client agrees, there is no ambiguity. If your client does not agree, you have the opportunity to eliminate any miscommunication and misconceptions by additional probing or questioning.
2. Use a common lexicon or establish a common context that can be used so that both you and your clients start on the same page. This may include avoiding the use of internal acronyms. Also, no jargon please.
3. Improve your listening skills. This post on Tyner Blain provides some tips.

Putting it all together

During the last month I have blogged on marketing and presentation topics. I wrote about the marketing mix, segmentation and positioning. I provided some presentation guidelines as well as some thoughts on how to craft your presentations and arguments to be more appealing to different types of people.
What I want you to realize is that you do not need to view these posts as isolated topics. You can use what you know about marketing to help you when you are trying to approach people and introduce different ideas. Likewise, you can use what you know about tailoring communications and creating effective presentations to assist you to market ideas more effectively.

All of this is geared towards improving your communication skills which will make you a more productive and effective person. Think about the different ideas I have written about and see which ones work for you and which ones do not. Does it change your perspective or approach?

The art of war

Basic Marketing Classes

I remember many of the lectures I received back in university on different marketing concepts and principles. Introductory marketing courses generally dealt with situations in existing markets for products.

In stable established markets, companies ceaselessly fought for marketshare. Think about how Coca Cola and Pepsi have fought over the soft drink market for the last century. The game was to take share from your competitors.

In growth markets, the objective shifted to growing faster than the marketplace was growing. If you can accomplish that it was likely that your company was growing faster than your competitors. Eventually, growth will taper off and you will be left fighting it out for marketshare.

Parallels between marketing and warfare

In the past, a lot of parallels were drawn between marketing and war. If you step back and listen to the terminology used you will hear words like: mission, strategy, tactics & campaigns. All of these terms are associated with military activities. Books like Sun Tzu's "Art of War" or Carl von Clausewitz's "On War" provided insights into the prevailing marketing thoughts of the time. For a more complete read on marketing warfare follow this link to Wikipedia.

Marketing in innovative times

Marketing approaches have changed towards market creation and generating consumer loyalty. Why fight over a market when you can build your own or make your marketshare more profitable? An excellent source for insights into marketing is Seth' Godin. He has a lot of interesting thoughts and observations on his blog (a must read for people interested in marketing or innovation.) Another good blog on this subject is Guy Kawasaki's.

Marketing and you

Many people view marketing with disdain. They think of all the direct mail and junk email that floods their inbox. They see the plethora of TV advertisements and messages that are shoved down their throats. As such, they dislike or distrust marketing in general.

But there is a practical side of this. One that applies to you. What are you doing when you are giving a presentation? Or looking for a job? Or trying to convince someone of something? You are essentially, marketing to them!

Take the example of designing a presentation. Your idea or message is the product you are trying to sell. Your presentation and conversational skills are your promotional tools. Face to face discussion is your distribution means ("place.") Product, promotion and place... these are all elements of the marketing mix! Your audience is, in truth, the target consumer.

I know that I have not gone very deep into marketing and all its nuances. However, what I am hoping is that you can take something from what I have said and apply it to your day-to-day activities. Perhaps, you can get a different perspective on things and use this to your advantage.

The last P

In a previous post, Marketing Basics - the 4 P's, I wrote about the marketing mix. The 4 P's were: product, price, place and promotion. By varying these elements a marketer can create a more appealing offering to a specific group of individuals (alternatively called a segment.)

The last P of marketing is concerned with how a product is perceived in a marketplace vis. a vis. other products. This concept is known as positioning. Positioning occurs when people identify a specific perception to a product. For example, Rolls Royce automobiles are viewed as some of the most luxurious and prestigious vehicles around. Once ingrained, these perceptions are extremely difficult to overcome. If you have a bad experience with a company you may tell all your friends about it and allow it to influence any future dealings you have with that company.

That is why company's spend a great deal of time and effort cultivating favorable impressions and counteracting activities that have undermined their market position. Do you remember what happened when there was a Tylenol scare at Johnson's & Johnson's in 1982? In brief, extra strength Tylenol capsules had been laced with fatal levels of cyanide. Many unfortunate individuals had taken Tylenol to relieve headache and fever symptoms only to receive a fatal dosage of cyanide. If you read Tamara Kaplan's write-up, you will see how Johnson & Johnson's was able to salvage their brand and maintain their leadership position.

One thing to note, product positioning will occur whether a company wants it or not. You can either allow the market to determine where a product will shake out or you can try to help influence the outcome. Using a marketing mix can help influence a product's position, however, nothing will compensate for a bad product. A lemon is a lemon after all.

Bits & bites

Quick notes...

Changes to this blog

• Added Feedblitz so readers can receive email updates.
• Added my Del.icio.us tags so anyone can view them by keyword.
• Changed how my Del.icio.us links look so that the tags associated with them are also shown. This change was also made to clear up a rendering problem I noticed when I used Opera to view the blog.

From an aesthetics perspective, it is starting to get a little crowded; at least that is my opinion. However, I do not feel like mucking around with the templates or doing any HTML coding so I will let it go.

Blogger.com service disruptions

I have seen a few reports of Blogger.com having service disruptions. Hopefully, this will be resolved soon. Annoying but since I do not feel like moving to a new provider...

Next posts

Sorry, I have been a little tied up with work to post much this passed week. I hope no one minds my slightly off-theme posts on marketing topics. My next post will be on the last P in marketing (e.g., not a member of the marketing mix.) Afterwards, I will try to tie together marketing concepts to practical, day-to-day aspects of your life and how it may change your approach to things.