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.

Simple process flow diagramming - Part 2

Let's expand a little on why initial process flow diagrams should be kept simple. Answer this question, "For a process, is it more important to know what or how?" The how question can lead you down a treacherous path.

Common Problems

• Effort becomes focused on specific details too early in the requirement gathering process. Eventually, the prototypical, "I can't see the forest for the trees," scenario occurs.
• Mysteriously, the to-be process looks eerily similar to the as-is process in terms of the different steps that are undertaken. Problems inherent in the as-is solution may still exist in the newer one. I can't tell you how many times I've encountered this problem. People are generally resistant to change. There is comfort in the familiar. Sometimes, people just don't know a better way to do something.
• We end up spending excessive time defining a to-be process that restricts our thinking and may not be used. In short, we are designing a solution.

To be or not to be?

Think of it from the perspective of a company trying to come up with a solution to a problem they are facing. Ultimately, there are a few different avenues: buy, leverage (what you already have), extend (enhance what you have) or build (from scratch). If I use a complicated process to evaluate vendor products, it is very unlikely that I will find one that meets my requirements to a tee. Instead, I may conclude that, "We are unique and as such no vendor product suits our needs. Thus, we must build a solution."

Think about how many companies you've encountered in your life that were truly doing unique things and compare this to the number of companies that thought they were doing unique things. A rose is a rose is a rose.

To me, this is the worst outcome. You have already, determined your path without realizing it (you have, in effect, not been solution agnostic.)

In Conclusion

• You may choose a less optimal solution path (e.g., build something that can be purchased.)
• You have not used your time effectively.

These things represent inefficient use of time, resources and money. And the ultimate solution may not be as efficient as it could have been.

Simple process flow diagramming - part 1

A picture says a 1,000 words... or so the saying goes, but do you really need 1,000 words to communicate a process? In truth, it depends.

Many times, on business analyst engagements, I've asked people to describe, in picture form, the basic processes that are important to their business. What I usually received was something that required a plotter to print... a huge, complicated process flow that took into account every single odd-ball anomally (even if it would only occur every 5th blue moon.) Why did this happen?

• Subject-matter-experts (SME) can talk ad nauseum about what they do.
• SME are detail-focused people; every detail is important to them.
• SME do not like to see their business processes trivialized into one or two little boxes on a process flow diagram.

My own learning point was to find another way of getting what I needed to know rather than ask this of the SME directly. When diagramming a high-level process flow I usually follow some basic guidelines:

1. Identify the initiator and actors of the process.
2. Be technology and system agnostic.
3. Understand what is required to move from one part of the process flow to the next.
4. Show the main process flow not the alternates.
5. Understand the goal of the process.

The time will come when more detail is needed and the process will be flushed out. But I do not feel you have to start like that. Simple and elegant always win out.

Online webinar for requirements management

There is a webinar coming up on June 21, 2006 entitled, Requirements Management: Best practices for enhancing project success. Follow this link to register for it.
Here's a brief description directly from BZmedia, Get to the bottom of the prime reason for project failure--poor or incomplete requirements capture and management. Geared to project managers, business analysts, architects, developers and QA/testers, this session will highlight the benefits of structured requirements with SteelTrace to all stakeholders.

How are your business analysts doing?

How do you determine how well your business analysts are performing?

There are a few different aspects that can be used to measure your business analysts. When I say measure I mean from the perspective of areas for improvement and to understand the strengths and weaknesses of individual analysts.

Deliverable quality
I already wrote about how to assess requirement quality. Use requirement clarity, completeness, consistency, testability, traceability, modularity, feasibility, design independence and correctness to assess the quality of the deliverables.
Meeting expectations
As part of any engagement, a business analyst needs to set expectations regarding the deliverables.

• What are the work products to be delivered?
• What tools and applications will be used?
• What is the estimated time required to complete the deliverables?
• Who needs to be included in the process?
  

Basically this amounts to a business analyst following through on what they said. However, some leeway is needed to allow for the use of different approaches when the situation warrants it. Flexibility is important afterall.

Soft skills

• Professionalism and conduct
  
• Development of relationships
• Facilitating understanding across the business and IT teams.

Conclusion
Ultimately, the outcome of a project determines its success. When looking at the business analysts involved you can measure them based on three basic areas:

• Quality: Quality of deliverables
• Time: Meeting of expectations
• Resources: Facilitating understanding, development of relationships and professional conduct.
  

Assessing requirement quality

How do you assess the quality of your requirements? We know that requirements change over time. We know that sometimes we are working on projects in areas where we are not subject matter experts. We know that there can be many unknown unknowns. So how do we know we have a solid set of requirements?

A while ago I posted a series on characteristics of good requirements. These characteristics can be used as measurement criteria for quality.

Items to consider:

Clarity - You should be able to provide your requirements to an uninvolved third party and they should be able to understand what you're trying to say.

• Is there a lot of jargon being used?
• Is the language used simple and concise?
• Can alternative meanings be derived (e.g., ambiguity)?

Completeness - Understanding whether a body of work is complete may be a little tricky. If there are common industry models that relate to your project compare and contrast them with what you have. Gaps may emerge that indicate missing requirements.

• Do the requirements provide a sufficient level of detail and understanding to the business need?
• Do you understand the context and how groups of requirements fit in with the entire body of work?

Consistency - Inconsistent messages are like bad driving directions, you may never get to where you wanted to be.

• Are there contradictions in the requirements?
• Is the terminology used consistent in it's meaning?

Testability - Requirements must be determined to be fulfilled or not.

• Is there a way to test the requirement? Are there proxy tests?
• Are there many requirements joined together (e.g., the word "and" is used often)?

Traceability - You can trace forwards and backwards and prove that your needs are being accounted for.

• Can you determine which high-level requirement a low-level one belongs to?
• Can you determine what are the higher-level requirements that lead to a low-level one?

Modularity - Making changes as simple as possible.

• If you have to make a change, do you only need to make it in one place or must you correct many different places in the document?

Feasibility - Add a touch of realism. If you are a marketing company, it is probably not feasible for your team to design a rocket ship.

• How realistic are the requirements based on your understanding of the client's goals, objectives and capabilities?
• Is it even possible to do what is being asked?

Design Independence - Requirements should be agnostic of technology and speak only of business need.

• Do the requirements answer the "what" questions or the "how" questions?
• Are the requirements trying to fix a problem with an existing system rather than defining a business need?

Correctness - Everything must be in accordance with legislation and client guidelines.

• Is everything legal? What guidelines or legislation must be followed?
• Is everything ethical?

Epilogue

When examining requirements documentation these questions can help you get a grasp on the quality of the requirements. High quality requirements contribute significantly to better products. A previous post, Why you need good requirements, explained the rationale for wanting solid documentation and the potential consequences of poor requirements.