Building a presentation - Part 4

My basic presentation has been assembled as per the plan found in my last post. I'm still preparing my demo scripts and getting ready to do a short mock presentation for one of the individuals helping setup this meeting. Any feedback or suggestions I get from the mock-up will be incorporated into the presentation. Additionally, I still need to take into account presentation best practices to help the delivery.

You can find a copy of my version 1 presentation on my enips.com account. The name of the presentation is: RM & Tools v1.0 - small.ppt. If you have any comments or suggestions feel free to tell me about them.

Building a presentation - Part 3

Let's continue on my building a presentation series with the next stage which is to map out and plan my presentation using the information gathered previously in the 1st and 2nd articles. To recap, the objective of my presentation is to introduce requirements management techniques and Telelogic DOORS to a team that is skeptical of the software tool.

Assemble the material
I've looked through my existing material and saw a decent PowerPoint presentation titled Clarity in my esnips.com account. There were also, earlier incarnations of requirements management presentations I had laying around. I'm sure I can reuse some of this material.

I am definitely going to have to come up with some demonstration scripts and new slides to show benefits etc...

Major components to present
Here is a summary of the major components I want to include in my presentation:

• A demo of loading an MS Word requirements document into Telelogic DOORS. All of their requirements exist in this format. This will show how requirements can be migrated into the software package.
• A demo showing traceability and its application to a project. Traceability is what will allow this team to assess the impact of a change.
• A demo illustrating how to export requirements from Telelogic DOORS to a more readable MS Word format. Before I go through this demonstration, I will show them requirements from a project that does this without telling them. This demo will bookend the presentation with the first demo.
• Tips on how to get the most out of requirements management. To ensure clarity, modularity and make requirements testable.

Map the material to an appropriate presentation style
In a previous post, "Use the right presentation style to convey your message," I wrote about some templates for presentations. One of them, "selling an idea," seems to fit in with my objective. Based on that format, I will lay out my presentation as follows:

• A simple statement of purpose. To show how good requirement management practices and requirements management software can benefit the execution of projects.
• An articulation of the audience's needs. Currently there is little / no documentation. The team has a difficult time assessing the impact of a change in requirements.
• An illustration of the features of good requirements management practices. What are traceability, modularity, verifiability and clarity?
• The benefits that can be realized by the team. What benefits do these features yield? Let's load in a requirements document to the product.
• What's wrong with the status quo? We need to change because we have difficulty understanding the impact of a change in requirements. What does this change affect? Who knows!?
• Reconfirmation of the benefits. Now let's manipulate some of the requirements within the product and show how we can understand the impact.
• What we need to do to benefit. What steps do we need to take to improve?
• Complete the 'sale.'

Next steps

1. Assemble the material as per my plan.
2. Follow presentation best practices.
   
3. Give a quick rendition of my presentation to one of the individuals helping set up the meeting. This will ensure that my presentation speaks to them.

Do you see what I see?

I've been goofing around with a Nintendo DS Lite trying to reduce my Brain Age (I'm hovering around 23-24 for anyone interested.) One of the more interesting exercises in the game is something called the Stroop Test.

The Stroop Task is a psychological test of our mental vitality and flexibility. The task takes advantage of our ability to read words more quickly and automatically than we can name colors. (University of Michigan)

The object of the test is to say the color not the word. For example, if you saw BLUE, your answer would be, "Red!" The Brain Age test is basically to answer 50 of these items as fast as you can.

This got me thinking about how this relates to business requirements and clarity. One party sees, "Red," while the other sees, "Blue," even though they are both looking at the same thing. Furthermore, both parties think they understand completely. Hence, techniques like active-listening need to be used.

Of course, the Stroop Test probably won't work if you have a condition called synesthesia, but that's another story. A common form of synesthesia results in an affected individual seeing letters and numbers in color.

Building a presentation - Part 2

Continuing from my last post,...

I decided to do a little more research into my audience, their backgrounds and perceptions.

What I uncovered
A few members of the audience have worked previously as business analysts. They are familiar with basic requirements gathering. None of them used requirements management tools and all attested to using MS Word.

As we have some Telelogic DOORS users at my company, some of the audience members had already seen the product and developed impressions about it such as,

I can't export my work (to MS Word.)

Why it's important
This information provided insight into how I can alter the content and structure of my presentation to be more effective to this group of individuals.

1. I was originally thinking of doing 2 demos. One to show the loading / creation of requirements and the other to show how to link requirements together. However, it seems apparent that a 3rd demo on how to export a requirements document from Telelogic DOORS to MS Word-friendly formats is required. This demonstration would overcome the, "I can't export my work (to MS Word)," angst.
   
2. The audience does have experience as business analysts; though I would say that collectively they do not have a lot of experience. Also, since they use MS Word, they are probably more used to writing full paragraphs and sentences versus atomic and easier to test requirements. Thus, I may want to include some examples on how to make requirement statements more clear.
3. Because these individuals have done some requirements work in the past, I probably do not need to express why it is important to have good requirements.
4. If they've only used MS Word documents, they have probably never really had decent requirement traceability and modularity. I'll want to show them the benefits of having these qualities.
5. My audience will be composed mainly of people who I would say are logical thinkers. They like hearing facts and being shown proof!

Moving forward
Armed with this knowledge, I have a better idea of what type of material I need to cover and what things I don't. I also have some ideas on suitable approaches for them (e.g., logical arguments and demonstrations.) On to the next step of assembling material and defining my structure!

Building a presentation - Part 1

I've been asked to give a presentation on requirements management (more specifically Telelogic DOORS.) The purpose is to show how these things could be used within my company to help a particular business team. What I'd like to do in my next set of posts is walk you through my thought process developing this presentation. Let's start!

Know the audience
Looking back to an old post on presentation tips, one of the first things I need to do is understand my audience.

• Who are they? A group that provides front-line support to data analysts who use a variety of data analytics and reporting products.
• What is their background? Their backgrounds vary (I'm going to need to look into this more) but the team members (on average) have been with the company for less than a year.
  
• What problems or opportunities are they facing? Little or no documentation on existing reports and processes. Hard to assess the impact of changes across the body of reports they maintain. They gather requirements for new data products and are expected to help bring them to fruition with the IT team. Currently, requirements are captured in MS Word and MS Excel (report mock-ups.)

Plan the presentation

• Do I need a formal presentation at all? Verbal only? Will it be projected or given in a more 1-to-1 fashion? I'm going to be presenting to a group of 6-8 people so a visual presentation is probably more appropriate. I won't really be able to tailor it specifically to one individual.
• What is the objective? The purpose of the presentation is to introduce Telelogic DOORS and requirements management. The message I'm trying to get across is basically to , "sell them," requirements management techniques and tools. This fits in well with the presentation template, "selling an idea," from my post Use the right presentation style to convey your message.
• Do I need hand-outs? Handouts with additional detail and information would be very useful to drive home my point.
  

Poll: What do you use for requirements management?

What requirements management tool do you use and why do you use it? I've placed a poll on the right menu bar.

What do you like about it and what don't you like?

Use the right presentation style to convey your message

Presentations are about selling. Whether it be a product or even an idea, you are trying to communicate your point and get people to buy-in. But sometimes your message isn't presented in a manner that connects with your audience. There are a few reasons for this:

• The contents of the presentation were not suitable. As a presenter you'll notice bewildered looks, the checking of watches and the occasional sleeper. Expectations need to be set! They should be set before you even start.
• Your presentation did not use an approach that related to the audience. Some people are convinced by facts, others want to know the end goal while other people want to see a plan. Know your audience!
• The presentation was not structured appropriately to convey your message. Even if you follow all the tips I've previously provided, a well thought out structure will be very beneficial.

This post will deal with providing the best template for your message depending on your objective. Its inspiration was a course I attended from Bina Feldman. Some of the material is derived from her work. As such, I will only go in-depth on a few of the templates.

First what are you trying to do?

• Present a solution to a problem?
• Share information?
• Sell a product?
• Recommend an alternative?
• Give bad news?

The key is to understand what you are trying to accomplish and then use a presentation template that aligns with your goal.

A template for "recommending an alternative"

For arguments sake, let's suppose you are trying to recommend one alternative versus others. A suitable presentation template would be as follows:

1. State the key decision.
2. Define the key selection criteria (e.g., "must haves" and "nice to haves.")
3. Rank the, "must haves." To quote George Orwell's Animal Farm, 'All animals are equal, but some animals are more equal than others.'
4. List the choices.
5. Eliminate choices that do not satisfy the, "must have," criteria.
6. Analyze the remaining choices against the, "nice to have," criteria.
7. Outline the pros and cons of each choice.
8. State your recommendation.

Notice the whole presentation style focuses on the recommendation and how it was reached. Everything works towards building up a strong case.

A template for "selling an idea (or product)"

1. State the purpose.
2. Outline the audience's needs.
3. What are the features of your idea (product)?
4. What are the benefits that your audience can reap?
5. What's the problem with the status quo? Why don't we want to do nothing?
6. Reconfirm the benefits.
7. Show how to achieve the benefits. What needs to be done to get there?
8. Ask for acceptance (e.g., complete the sale.)

Unlike the previous template this one focuses on illustrating the need for your idea and the benefits it provides. Create demand for your idea by stating the problems that are being faced.

Summary

I am only outlining 2 of the templates; in truth, there are many different ones (If you need some ideas feel free to contact me. Also, if you want formal training I suggest contacting Bina Feldman.)

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.

Webinar: Incorporate Real Innovation into Your Company's Business Processes

Below are the details for a 1-hour webinar, sponsored by Ziff-Davis, on innovating a company's business processes. The webinar will occur on July 11, 2006 @ 2:00 p.m. Eastern/11:00 a.m. Pacific. You can sign-up for it here.

Here is the description.

Real innovation, whether it's in technology or business processes, is not just about inventing something new, but rather it requires a conscious investment strategy, and the will to carry it out. As organizations feel the effects of globalization setting in and competition heating up, companies large and small are turning to the diligent application of any number of innovation practices to try and stay ahead. Customer innovation, innovating from the edge, and innovation road maps are all well-meaning efforts to help companies with the innovation process, but without the proper focus and follow through, these efforts could be fruitless and waste employee time and company money. Innovation means little if new products and services never see the light of day. Therefore, innovation by itself is not enough, it requires an investment strategy that puts your company's resources where they count, and a people strategy that aligns those resources with the best skills of all your employees.

Join this live, eSeminar, sponsored by IBM, and hear directly from technology and business process experts on:

• How to encourage an atmosphere of innovated thinking in your organization
• How technology advancements can assist an organization in staying on an innovative path
• Innovative ways to approach customer service to differentiate yourself from your competitors
• How to put in place the business practices and processes to see innovative ideas through to fruition

Some web apps to get you going

Here are some web applications that you can use to improve your productivity as a business analyst. All of these are free! But you should realize that there are some things you need to consider when using these types of products:

• Confidentiality - Should business critical information be placed online?
• Acceptability - Is the use of these tools acceptable to your client(s)?
• Availability & recoverability - Can you get to your valued work products?

List of web apps

• Gliffy - A diagramming tool that supports online collaboration. Easy to make simple process flow diagrams.
• Google Notebook - A tool that allows you to make collections of information that you can arrange by subject.
• Google Spreadsheets - Online spreadsheets! Not as powerful as Microsoft Excel but still useful.
• Imagination Cubed - An online whiteboard where multiple people can collaboratively diagram and brainstorm ideas. Drawings can be saved and emailed.
• Remember the milk - A to-do list application. You can email tasks to add to your list.
• Thumbstacks.com! - A web-based presentation application.
• Voo2do - A to-do list application that is suitable for project task lists.
• Zohowriter - A word processing application.

Unfortunately, I have not found any free online tools that support things central to business requirements such as traceability and change request management. Perhaps that's an idea for a Web 2.0 start-up. Hmmm...

An RFI defined

What is an RFI?

A request for information (RFI) is a formal request made to a vendor (or service provider) who's aim is to ascertain whether a vendor's product would be suitable for addressing a company's need.

In a previous post, I mentioned that there were a few ways to get a solution:

1. Leverage existing systems.
2. Extend existing systems.
3. Buy a vendor product.
4. Build a solution.

An RFI is used as one of the earlier phases of determining which (if any) vendor products fit; thus if you should buy it. Prior to performing an RFI, a high-level understanding of a company's needs are required as well as a short analysis of vendors who may possess suitable product offerings.

Why do we use RFIs or RFPs (Request for proposal)?

We don't need to build everything do we? Just because we can do something doesn't necessarily mean we should do something. Basic economic theory has something known as comparative advantage. This theory is usually used to describe international trade but I feel that it can be applied to many other situations.

Suppose a company has limited people resources but these resources have the expertise to develop either spreadsheet or IVR applications. Also, suppose that the company needs both of these applications but can only do one or the other. Because we know that there are suitable products that support spreadsheets, is the company better off purchasing a spreadsheet application and building their IVR applications versus attempting to build everything themselves?

Unless something is a strategic differentiator, if suitable offerings exist, you should use them. This allows you to concentrate on the activities that are key to your company.

Parts of an RFI - The introduction

• Confidentiality agreement - You will be sharing information about your company that you do not want distributed to anyone else. Thus, before an RFI can be sent out, you must have a signed confidentiality agreement from prospective candidate vendors. Your company's legal team must approve both the RFI as well as provide the confidentiality agreement.
• Corporate overview - This information is provided to give vendors insights and context into what your company does.
• Project background - State what the project is trying to achieve as well as where you are in the process (what steps you have done or are in the process of doing.)
• IT overview - Give the vendor a basic idea of the types of systems their solution will have to interact with (e.g., we have mainframes, IVR systems, we use J2EE and Oracle.)

Parts of an RFI - Description of the process

• Timelines - Provide timeframes for RFI completion and evaluation.
• Post RFI participation needs - State what the process will be after receiving the RFI. Will there be a need for face-to-face conversation to go into more depth? What follow-up will you want to do (e.g., reference checks & demos)?

Parts of an RFI - The questionnaire

• RFI questionnaire - An elicitation of the basic requirements that need to be met. Obviously, a high-level understanding of your requirements is needed, but not a detailed one. Prematurely getting into too many details may bias your RFI and lead you towards a build mentality! Major non-functional requirements should also be stated (e.g., projected capacity, availability.)

Summary

This post is not meant to be a guide on writing an RFI but rather to give you a basic introduction to the purpose and components of one. RFI's are extremely important as they can lead to the purchase of expensive products and services. An inappropriate product choice can cause a company more harm than good.