Improving clarity in communications

One of the most important skills you can master is to be able to communicate effectively and efficiently. In the past I wrote a few pieces on improving clarity for requirements and presentations:

• So it's still not clear?!
• 3 simple rules for business writing
• Be clear

I've decided to summarize the main points from these three posts into a presentation deck. As usual I've uploaded the deck to esnips.com so please feel free to access it (I've used high quality images so the file is on the large size.) The file is called, Clarity, and you can access it here. As always, any feedback is greatly appreciated.

The ignored step-child - the non-functional requirement

There have been some very interesting posts on non-functional requirements taking place recently.

About a week ago I posted, an item called Non-functional requirements & QA test strategies that was based on a comment received my leathej1 for my non-functional index as well a link to his post, The Fallacy of Non-Functional Requirements. The thrust of leathej1's idea was that non-functional requirements need to be collected in the same manner as functional requirements. This concept comes from his experience in quality assurance; where response times and performance targets are important to a system's acceptance. He made an excellent point that these sorts of items are usually given little consideration.
As a follow-up to leathej1's post, Scott Sehlhorst put up an article called, Non-Functional Requirements Equal Rights Amendments. Scott proposed a different way of looking at functional and non-functional requirements.

Read these articles, they're excellent.

Why you need good requirements

Why are requirements important to a project? The answer may seem trivial but let's look at some empirical evidence.

• According to the Standish Group's chaos report (1995), only 16.2% of software projects are completed on-time and on-budget.
• The KPMG Canada Survey (1997) stated that over 61% of projects were deemed to have failed.
• According to Forrester Research, "No single factor is responsible for more wasted effort, rework, or failed projects than inadequate requirements (Carl Zetie.)"
• Borland recently posted a new press release for Caliber DefineIT in which they state, "Analysts ... cite inaccurate, incomplete and mismanaged requirements as the number one reason for software project failure. The Standish Group's annual CHAOS report indicates three of the top five reasons for project failure are related to requirements. In addition, requirements errors are a primary factor behind most rework efforts, which ... can add up to 40 percent of the total development effort within a given project."

Let's also consider trends in business.

• We are dealing with more complex systems.
• We need to move faster because the business environment is changing faster. We need to react more quickly.
• Project teams are moving towards more people-oriented development paradigms (e.g., Agile.)

What does this all mean? Successfully delivering projects (e.g., on-time and on-budget) is a difficult task. Furthermore, the environment is evolving and becoming more complex than ever, making a difficult task more even difficult.

I remember talking to a small group of business folk about requirements management practices and its importance (I've uploaded a variant of the presentation I used, titled The Need For Requirements.) It was very encouraging to watch the expressions of the different individuals as we went through the conversation and they started to appreciate the complexity of a project and their role. Understanding is step one.

Online folder for file sharing

One idea I've been toying with is the proliferation of materials I've used to foster more understanding and learning for others as well as myself. To this end, I've added a new icon on my menu bar.

If you press it you'll be directed to the esnips.com folder for this blog where you can get access to some of the slides and presentation material I have created. Feel free to use the material, I only ask that you credit where appropriate. One thing to note, as you look at the presentations, they are done in a very visual style. There is a bit of information on the notes pages to provide context to the presentations; so I suggest you look at them.

I've been writing a lot about presentation skills and requirements, so this is your chance to see how well I, "walk the talk." If you have any comments or feedback I'd love to hear it.

Slides available: Testing & validation

The slide I used on my post, Testing & validation, is available for download at esnips.com. You can find it using this link.

Slides available: The project and the business analyst

I've been running around giving a lot of presentations recently. I'm going to start making some parts of them available for interested people. Please feel free to provide any feedback you may have on either the content or my slide design. I don't mind if you distribute them, but I ask that you credit appropriately. Thanks!

The first set of slides I'm making available were used on my post, The project and the business analyst. You can find them on esnips.com using this link.

Non-functional requirements & QA test strategies

I received an interesting comment on my index post for non-functional requirements, from leathej1. Below is a short clip.

I just posted something on my site that has been gnawing at me for a few years - the fact that in my mind there is no such thing as a non-functional requirement. As defined in the traditional RUP sense.

A link was provided to leathej1's blog that contained his rationale. I'm still mulling it over in my mind but his post called, The Fallacy of Non-Functional Requirements, contains an excellent QA test strategy covering off the testing of "non-functional" requirements. I encourage you to visit his blog and check it out.

The 4 P's plus 1 reloaded

Back in January, I outlined the basic 4 P's of marketing in my post, Marketing basics - the 4 P's. As a recap, the 4 P's (plus 1) of traditional marketing are:

• Product - The offering be it a physical product, service or combination of the two.
• Place - The method of distribution (e.g., physical storefront, online.)
• Promotion - The strategy and messages comprising the communication aspects of marketing the product.
• Price - The pricing strategy utilized. This includes discounts and product bundling.
• Positioning (the last P) - How a product or company is perceived in the marketplace.

I came across a post called Marketing Remix, by John Sviokla, that provided a new 4 P's (err... plus 1!) It's an excellent read and demonstrates how marketing is shifting from the traditional view to a newer paradigm. To paraphrase (as well as add some of my own thoughts):

• Product becomes Personalization - Standardized products are giving way to more customizable offerings composed of physical products and the services associated with them.
• Place becomes Presence - The main argument on this piece is that there is much more than just a physical storefront. People can augment everything with simple web searches for more information. The main business concern translates to having a presence where people gather their information and make their decisions.
• Promotion becomes Persuasion - Sending out traditional advertising is a big item in promotion. However, notice the trend towards the proliferation of user reviews (and other social mediums that are not controlled by marketers) for products.
• Price (static) becomes Price (dynamic) - With the availability of information there is a greater ability to do direct price comparisons between products and retailers. Bundling, in-the-moment discounts and specials mean pricing strategies are more dynamic.
• Positioning becomes Preference - Preferences can be interpreted based on things a consumer says, through analysis of their past purchases, through analysis of their search (information gathering) behavior and finally from configuration tools that they use (e.g., a design your own car tool from Volkswagen.)

Please go read John Sviokla's post. It's an excellent read for new age marketing.

INDEX for business analysis

Starting out:

• First things first; learn the skill: Understand how to structure and write requirements before you start using requirements management tools.
• Asking questions and getting answers: Learn how to ask questions to get answers to the important issues.
• Why you need good requirements: Some quick facts on project success and requirements. Presentation available.

Requirements:

• What are requirements?: A quick definition.
• Correctness: There are some things you just can not do.
• Completeness: Make sure that all of the, "what," questions are answered.
• Clarity: Requirements should be succinctly stated; using as few words as possible. Otherwise, ambiguity may occur. Excessive rambling, jargon & wishful thinking confuse readers -- avoid it. So it's still not clear?! Here's a short presentation deck recapping all of these items (the presentation is simply called Clarity.)
• Consistency: I hate it when people say, "Turn right. Your other right!"
• Testability: Prove to your client that the solution meets their needs. When a statement contains multiple requirements it's testability can be compromised.
• Traceability: What requirement led us to do this? How much work do we have left?
• Modularity: Update in one place and only in one place. Makes change management a lot less painful.
• Feasibility: Do you really think with enough time and money you can solve any problem?
• Design Independence: It starts with what and why. How comes later.
• Requirements vs. requirements management: Gathering requirements and managing them.
• Assessing requirement quality: How do you know if you have decent requirements?

The why of business analysis:

• The business analyst & the business systems analyst: What's the difference?
• The why of business analysis: What purpose and role do business analysts serve?

Running a business analysis engagement:

• Prepare thyself - make sure it's not you: Make sure you're mentally and psychologically ready and able to work. Eliminate any preconceived judgments and notions.
• Know the situation: Before you start an engagement take some time to grasp the nature of the project, it's urgency and the resources you'll need.
• Choose your tools: Decide what approach you will use. Will you prototype, interview, brainstorm or observe behavior?
• Set expectations: Ensure your role on the project is clearly defined and that you understand the roles of others as well.
• Time estimation: Estimate how long it will take you to complete your tasks. As you run through more projects your estimation skills will increase.
• It's the little things... Words that should make your ears perk up: Little words that your clients say that create headaches for you unless you clear them up now!
• New! How are your business analysts doing? Understand how to assess them.
• New! Understanding the goal: Knowing the objectives of your requirements gathering sessions helps you determine whether the requirements you are getting will actual help to solve the problem.
  

Project Bits & Bites

• How do you know you're done?: Use requirements management practices and traceability to see how much work you've done and how much you have left to do.
• Well-done or done well?: Use cost-benefit to determining where to invest your energy.
• System development life cycles & requirements: A very high-level overview of different system development life cycles and how this impacts requirements gathering.
• The project and the business analyst: Understand your role in a project and the activities you'll perform to support the initiative. Slides available!
• The sweet smell of success: Measuring success on a project ultimately boils down to meeting or exceeding targets established earlier in the project.
• Choose a methodology that suits your project: No one methodology will fit all projects.
• Testing & Validation: What are the different types of testing that occur as a project moves forth? Slides available!
• New! Requirements in an agile world: Understand that impact a different project methodology will have on requirements.
• New! Setting expectations: It's important that people know what you are delivering and why.
• New! How a "bad" requirement can stifle innovation: A lack of design independence in requirements can lead to a sub-optimal solution.
  

Non-function requirements: Upgradeability

It's been a while since I last posted on non-functional requirements so I'm going to ease my way in with a simple one, upgradeability. This characteristic defines the ease at which components of a system (e.g., software) can be replaced with newer pieces with minimal changes to the rest of the solution.

Let's use some examples to demonstrate this non-functional requirement. Suppose your system uses a service-oriented architecture approach (you can find lots of information on SOA at ebizq.) Your system handles purchase orders from a web site, calculates taxes and then sends out orders to your fulfillment group. If the tax rules change, you can build or purchase a replacement component to handle the tax calculations. Components are loosely-coupled in a service-oriented architecture, thus changes to one component are transparent to other components (as long as the service itself functions the same way.) In this case, the upgradeability of the system is high.
On the otherhand, suppose you purchased an accounting system and built a lot of direct interfaces (e.g., tightly-coupled) to different applications to provide information to it. Now, a newer version of the accounting program is released that uses XML to transfer data around. The custom interfaces and other custom work will have to be examined to see whether they will still be able to function. There is a high probability that you will need to rework or rebuild a significant amount of them. As such, you would say the upgradeability of the system is low.

In general, tightly-coupled systems and systems with high levels of customization are more difficult to upgrade.

A breakaway innovation

Time magazine has an interesting article called, A Game For All Ages (by Lev Grossman), which provides a hands-on preview of the new Nintendo Wii video game system. The control system used for this game platform would qualify as revolutionary (see an earlier post Types of innovation) as it incorporates motion sensing technologies into a controller that resembles a remote control (something a lot of us are too familiar with.) It has potential to change the way people play games since a different level of interaction can be used (see the article for details.) Of course, it remains to be seen how well this translates into profit.

In the article, there were two very interesting comments that stuck out to me:

If you are simply listening to requests from the customer, you can satisfy their needs, but you can never surprise them.

It is definitely more difficult to come up with revolutionary ideas. When listening to your customers, you'll hear more along the lines of the tried-and-true with some new bells and whistles. On the otherhand, you can't ignore your customers either.

Cutting-edge design has become more important than cutting-edge technology.

The overall experience of using a product or service is the new paradigm. Simplicity of design and usability are key factors for success and product adoption. Think of why the Apple Ipod has been so much more successful than any of its competitors.

INDEX for presentation skills

This is an INDEX for my presentation skills postings. As new items are added I will include them in the list below. I'll make sure that this post stays near the top of my popular list. Remember, presentations are about communication. Communication is about getting people to understand and buy-in to your ideas.

The picture above is from Apple's 1984 Superbowl commercial.

Communication from the pros - This post is based on two articles: How to Wow 'Em Like Steve Jobs (by Carmine Gallo) and Speech Writing Secrets of President Bill Clinton (by Tomas Murrell.) It covers the styles of two of the foremost communicators.

*NEW* Use the right presentation style to convey your message - Depending on the objective of your presentation, it is important to select a template that aligns with your goal. The use of an inappropriate template can render your presentation ineffective.

*NEW* Improving clarity in communications - A short presentation deck providing some tips and common sources of ambiguity. You can find the deck (called Clarity) in my esnips.com folder.

Give each of them something - Some people want to see a plan. Others will listen to you after you've established a relationship with them. Still others will want to know your goals; they'll figure out their own way to get there. This post speaks on how to communicate with these different types of individuals.

Some more presentation tips - General tips for improving your presentations such as stopping side-conversations, using active listening techniques to respond to questions and using physical presentation aids.

Some tips on presentations - This post is one of the more popular ones on my blog. The basic parts are the pre-planning, slide design principles, and other prep activities that will help you make & deliver great presentations.

The soft-side of presentations - This post provides tips on the delivery aspect of a presentation rather than slide design. These tips include how to use gestures, to speak more slowly than conversation speed, and to change the pace of your presentation every 15 minutes or so (the average attention span.) A good PowerPoint deck won't mean anything if you can't sell your ideas.

Other resources & tips for presentations - Online resources for improving your presentation skills.

A walkthrough of the process I followed to make a presentation

• *NEW* Building a presentation - Part 1 - Who is the presentation for? Initial planning...
  
• *NEW* Building a presentation - Part 2 - Do a little digging to find clues that will help you make a more effective presentation.
• *NEW* Building a presentation - Part 3 - Assemble your material and choose an appropriate template to communicate.
• *NEW* Building a presentation - Part 4 - Version 1.0 is ready for a mock-run.
• *NEW* Building a presentation - Part 5 - A short run-through to make sure I'm on track.
• *NEW* Building a presentation - Part 6 - The morning after... Assessing how your presentation went.
  

How to listen and hear nothing at all

Courage is what it takes to stand up and speak; courage is also what it takes to sit down and listen. (Winston Churchill)

This post extends upon a previous post (Make sure it's not you) covering the topic of listening skills. More specifically, how to identify when you are listening but not actually hearing what people are saying. I strongly believe that listening (recognizing the words) and hearing (thinking & understanding) what people say are two entirely different things.

For example, you can introduce prejudices that influence how you interpret the actions and words of another person in either a good or negative fashion. However, you are introducing distortion and potentially negatively affecting your relationship by doing this. Suppose, I listen to you with rose-colored glasses (e.g., I take everything in a positive light), I may not realize I need to deliver a strong message to you such as, "I don't think that idea will work because it does not address your core need." On the other hand, I don't think you'd like it if I merely gave you lip service and didn't even consider your arguments seriously. So how can you tell if you aren't hearing what people are saying? Here are some indications:

1. Are you constantly interrupting people? Do you finish their sentences?
2. Are you unwilling to even listen to anything that doesn't fit with your thinking?
3. Do you think the issues facing others are trivial before you even speak to them?
4. Do you feel you know what people need before they even discuss it with you?
5. Do you roll your eyes when others are talking to you?
6. Do you enter a conversation with a preset position? Does this position distort what you hear?
7. Do you start side-conversations with other people rather than always being attentive to the speaker?

These types of behaviors can be indicative of a listening (I mean hearing) problem. The hardest part is realizing that you are listening but not hearing. However, you can resolve this problem with a few simple steps:

1. Before you enter a discussion, divest yourself of any preconceived judgments and notions.
2. Let people talk to you in their own words. Don't put words in their mouths or lead them.
3. Use active listening to play back what you understood. Clarify any miscommunications.
4. Ask probing questions to fill in the gaps.

After taking these simple steps you'll have a more unbiased and objective perspective. Furthermore, your clients will know you're listening and interacting with them.

INDEX for non-functional requirements

I talked to Scott at Tyner Blain about my non-functional requirements series and he suggested that I create an index for them. As I add new posts, I'll add them to this list and make sure the index appears in the Popular posts section.

Complete list of non-functional requirements
This is a very early post containing the names of the different types of non-functional requirements. No details provided but a good starting point.

Availability
There are two key concepts for availability: Hours of operation and reliability. The first refers to what times a system will be available for production. The second refers to it's availability during the stated hours of operation. I supplemented this post with the following one, Extreme availability & reliability.

Capacity
Capacity deals with the projected load that a system will handle. This includes its growth and the timing around when heavy load conditions will occur. As companies move towards a more service oriented architecture approach it becomes very important to be able to understand capacity.

Data currency
How up-to-date does your information need to be? Do you need real-time or are delays acceptable? Data warehouses generally operate a few days or weeks behind. For general reporting needs, this situation is acceptable.

Data retention
Address your needs to store and dispose of information. There are industries which have legislation surrounding the acquisition and disposal of information. Recognize that some types of data become useless as time passes.

Disaster recovery
This non-functional requirement relates to a business' needs for a system to recover from an outage. How important is the system and how quickly does it need to be returned to production?

Error-handling
Describes a system's ability to handle unexpected situations such as purchase orders for unrecognized products. How should you account for these transactions?

Internationalization
This is an important characteristic for applications that will operate in multiple geographic regions, currencies, tax regimes and languages.

Logging
A system's ability to keep track of its activity. This provides an audit trail that can be used for problem-solving.

Security
Describes how a system handles customer privacy as well as user privileges.

*NEW* Upgradeability
This characteristic describes the ease of replacing a component in a system with another one.

*NEW* The ignored step-child - the non-functional requirement
Links to an important conversation on the importance of non-functional requirements and their neglect.

The strangest things

Sometimes as a business analyst you'll hear some of the strangest requests. Things that will make you do a double take. "Excuse me, did you just say...?"

Some of the most odd requests I've heard are:

• "I want you to put a little lightning bolt in the top right corner of the screen that indicates the application is still processing." At the time we were working on a web-based application, so we asked, "You mean like the little symbol that twirls in the browser?"
• "In the older application, when I hit the ENTER button it tabbed to the next field. I want the new web-based version to do that as well." Of course my web developer looked at me incredulously and proclaimed, "I didn't build the damn thing (the browser!) So if ENTER is pressed to tab, what is the TAB button for?"
• "I want you to run a pharmaceutical patient compliance program. We get the pharmacists to contact the patients and talk to them about the importance of refilling their medications. Oh yes, because of privacy concerns we cannot identify the individuals. You'll get an unique index for each person, but it is only unique within the same store." Needless to say at the end of the day, our data was very useless.

The important thing is how would you handle these requests?

1. Suppress the urge to laugh out loud no matter how funny you think it is.
2. Make sure it's not you! Make sure you're listening properly.
3. Use active-listening techniques to see if that's actually what your client meant. Remember your objective is to foster understanding.
4. Your client has told you what they want. Make sure you ask, "Why do you want it?" What is the business justification?

The greatest ignorance is to reject something you know nothing about.

A practical guide to communication

When you are explaining something to someone, you may use a different approach based on your understanding of the other party's background, knowledge and areas of concern. Messages that work well for one person will be poorly received by others. The reason for this is simple, you need to be able to communicate to someone in a manner that resonates with them (see my earlier post, The why of business analysis.)

How does this play out in the real-world? Suppose you applied a patch to a database but something went horribly wrong (for the sake of simplicity let's assume there aren't any redundant systems) and the database is not longer available. Also, let's assume this database provided product information that was consumed by your website, IVR and agents. How would you express the problem?

When talking to the technical support staff, you may mention that the patch has brought the system down. Next steps may be to inform your clients of the outage, roll-back the patch, get the database operational and then contact the database vendor for support.
Now suppose you are talking to the business side, how would you express this outage? Would you use the exact same language? Probably not. The questions that interest the business are:

• What is the impact of the outage? Explain which systems are impacted and the extent to which they are impacted (e.g., It's taking the servers 3 times as long to respond.)
• How long will the outage last? How much money is this costing me? The system will be fully operational at ... In terms of lost sales opportunities, during that amount of time we would normally have 800 sales transactions.
• What can I do in the meantime? How can I help? Direct your consumers to use alternative channels or to contact you a little later.

Note the drastic difference in the responses between the technical and business people. Business users are very interested in the, "So what?" types of questions, not the details. When explaining something to people, put yourself in their shoes. What would they want to know?