Skip to main content

Bad-Ass BA Lessons. Part 1.

Written by Cecilie Hoffman on . Posted in Articles.

Co-authored by Rebecca Burgess

Ten Steps to Becoming a Bad-Ass Business Analyst

Do you want to take your professional capabilities to the next level? Do you want to add more than just techniques to your tool kit? Wanna become a Bad-Ass Business Analyst? Here are ten opportunities to apply “intelligent disobedience” and judicious audacity to your environment to earn those bad ass stripes.

The term intelligent disobedience comes from guide dog training. Blind people who live in cities listen for the auditory cues from a traffic light turning green to tell them it is safe to step off the curb into an intersection and walk across the road. Their guide dog is trained to watch for cars that aren’t showing signs of stopping. When the dog sees danger to their human, the dog is intelligently disobedient, and stays in a “sit” position, letting the human know that they shouldn’t step into the path of danger.

Judicious audacity is the intelligent application of aggressive boldness; that is, taking control of the situation in a fearless fashion because it is the effective and efficient thing to do.

Caveat emptor: there is a significant amount of risk inherent in many of these actions, though the payoff is high. Buckle up tight, fellow BAs, here we go.

Step 1. Exploit the Hidden Power in “Menial” Tasks
Step 2. Delegate!
Step 3. Compose in Real Time
Step 4. Define Gonzo Success Criteria
Step 5. Ask the Crazy-as-a-Fox Stupid Questions
Step 6. Get Their Attention
Step 7. Schmooze those Stakeholders
Step 8. Rat Out those Underachievers
Step 9. Speak Truth to Power
Step 10. Put on Your “Facilitator Flak Jacket”

We’ll cover the first four steps in this article. The remaining steps will be revealed in subsequent articles.

Step 1. Exploit the Hidden Power in “Menial” Tasks

We think that as we advance in our role, we shouldn’t have to do menial work. Tasks like taking notes or writing the first draft of a document or process may feel like they should be beneath us. Wrong perspective! Menial tasks aren’t always low brain power tasks; below are two examples of hidden power for the BA who can leave their ego at the door.

#1: Note taking and the power behind it

When you are the person recording the meeting minutes, you are in control of the official record of the decisions, action items, and open issues. Is the speaker making pronouncements in sentence fragments? You can stop the meeting and request that the speaker give you a statement that can be recorded. Does it appear that a decision has been made but you aren’t sure exactly what was decided? You can stop the meeting and request that someone give you a summary so that you can record it properly. Has an action item been agreed to? You have the power to suggest who should own that action item and what the due date should be. Is note taking a menial task? Hardly. You’re actually running the meeting and finalizing the decision making.

And, of course you are taking these notes directly in electronic form. Pen and paper is a luxury reserved for CEOs and poets; the rest of us have to be more efficient.

Before sending out the meeting notes, you should summarize the key points and decisions. Was there some fuzziness around a particular topic? Clarify it based on your business understanding or by contacting the Subject Matter Expert (SME). This is like stealth direction setting. And think of the visibility you have when you send around the meeting notes for comments and correction. Just be sure to have “recorded by ” in the meeting notes.

#2: Seize the moment: Draft the initial process/doc yourself

Do you ever get impatient with the lack of progress, or the inability of some people to get past a blank template? Start the document yourself and send it out to the team as a “suggestion”. The trick is to influence the process by presenting your ideas to kick-start everyone else’s thinking. Your natural BA instinct will be to try to get everything right before you show the document to anyone. In this case, though, you don’t need to get everything right because you are influencing, as opposed to analyzing; you’re pointing people in the general direction that you think is best, and encouraging them to build on top of your suggestions.

Step 2. Delegate!

Delegate? How am I supposed to delegate? I’m a single contributor, I can’t delegate; I get tasks delegated to me!

True. We BAs are single contributors, we don’t have the authority to delegate, but we have earned the right to suggest that a particular person or group should perform a task. In Step 1, above, there are two methods of “stealth delegation”:

You can delegate by recommending a person to own an action item from a meeting. If a person has special knowledge or interest in a particular area, it is appropriate to suggest they bring their expertise to bear on a task in that area. Minimally, you could ask them to draft a few slides or a couple of paragraphs outlining their ideas or concerns, which you can incorporate in the deliverable. They are likely to come up with some points you wouldn’t have thought of as well as being more invested in the success of the effort.

Delegate by putting a comment in a draft implicitly assigning a section by asking a question of a specific stakeholder, e.g., “Stakeholder A, do you have anything to add here?” Then follow up with that stakeholder both privately and publicly.

There’s also delegating by trading tasks – what can you do for the individual that you want to do something for you? This sort of “horse-trading” is a great way to leverage your own skills to obtain something you need, but can’t accomplish on your own.

In all these cases, be very clear about what you need from the person and when you need it. Follow up with them approximately half way through the time you have allowed for the deliverable to make sure it’s still on their radar. Be sure to emphasize that their special knowledge and input is vital to the success of the project and thank them for taking the time to contribute.

Step 3. Compose in Real Time

Whether you are doing a structured walkthrough of your BRD, or real time process development, when you have a live audience for work that is happening in real time under your fingertips, the pressure is on. This is one of the stages on which you earn your Bad-Ass BA performance award, if you are truly a master of your craft.

Let’s say you are using one of the many application sharing tools that allow people to see what is on your computer screen, no matter where in the world they are physically located and that you are revising the phrasing of a requirement that is giving people heartburn. Three people are talking at once. While you retype the offending requirement before everyone’s eyes, you get to say,

“Folks, let’s agree on who is the actor, here. Do we agree on that it’s the system? Good. Now, what was the exception condition that someone identified? Wait, what has to happen to trigger this requirement to come into play. One at a time folks! One at a time! Any conditions? No? Okay. Let me read this out loud to see if makes sense…. I think we want a different word, here, how about “configuration”? Any disagreement? Good. Now give me a moment to tune up the action … okay, please read this to yourselves. (count from one to five silently) Does anyone feel this does not express what we are trying to capture? Great. What’s the next one we need to work on?”

You own the stage, you clearly own the material, you are in the driver’s seat and you are getting the job done. Furthermore, you are putting pressure on the people who disagree to get their issues out in the open and resolve them by asking if anyone disagrees and explicitly making silence equal consent. The key is to determine when you’ve captured the meat of the idea and not let people wordsmith themselves to death.

How did you develop this skill? You’ve been taking notes in meetings (see Step 1, Point #1, regarding CEOs and poets) for years and doing the same thing; now you’re just doing it before everyone’s eyes and making it look easy.

Step 4. Define Gonzo Success Criteria

Slang: “gonzo” means conspicuously or grossly unconventional or unusual

As an exceptional BA, you should already have gotten all your project team members and stakeholders to focus on the success criteria for the project and the on-going process. Now take a dramatic step and get them to focus on the end customers’ success criteria for the on-going process. When you start doing this, the team members and stakeholders are likely to tell you that you are crazy and what you’re suggesting is impossible to do/measure/implement. Don’t worry, that’s a natural reaction to out-of-the-box thinking, and you are way out of the box.

The point of focusing on the customers’ success criteria is that we usually measure what is important to us, and what we feel is reasonable to measure. Too often, what we think is important is not what the customers consider important. Here are two examples to illustrate different aspects of this.

Scenario 1.

Airlines have determined that customers’ satisfaction is impacted by how long it takes to check in for a flight, so it makes sense to have a requirement that the flight check-in process be as efficient as possible, and to measure the time it takes to check in. It would be sensible and relatively easy to measure the time it takes for the counter personnel to key in the customer’s information and provide the customer with a boarding pass. If you are the customer, however, when do you start measuring the time to check in? Probably when you get in line at the counter.

So if there’s a 20 minute wait in line because the airline hasn’t staffed the counter properly, it may not matter to you that the time it takes the counter personnel to key in your information has been cut from 10 minutes to five minutes. Nor would you be impressed if they were able to cut it further to two minutes – you are still irritated by the long wait in line. The gonzo success criterion comes from looking at something that the airline doesn’t nominally control and may find difficult to measure: the amount of time spent waiting in line. Once you change your point of view to the customer’s, however, further improvement in the pieces of the process that you control may be wasted investment, compared to extending your control to other, more difficult to manage and measure portions of the process.

Scenario 2.

Software companies don’t want to give away support for their products so they generally require customer companies to pay for a maintenance license. When someone from the customer company calls in for support, the first thing the software company does is determine if that contact and company is entitled to support by checking that company’s “entitlement data”. It makes sense to the software company to make it as easy as possible for the customer companies to keep their entitlement data up to date, so the software company could have developed success criteria about how much time it takes the customer to update entitlement data. From the customer company’s point of view, however, there may be no reason to value entitlement data; the customer company just wants support, now. The customer’s success criterion is for the software company to “automagically” know that they are calling about a legal copy of the software for which maintenance has been paid.

Manual maintenance of entitlement data is just one possible way to meet that need. If the software company came up with another solution that led to the software itself automatically maintaining the entitlement data when it is deployed or updated, the customer would probably be delighted. But as long as the success criteria assumes that entitlement data must be maintained manually, the customers’ real needs are being overlooked. In this case, the gonzo success criteria requires ignoring the solution already in place and getting back to the customers’ underlying need.

As a business analyst, you are used to putting yourself in other people’s shoes to figure out what they want. Use that skill to add the end customer point of view to your requirements and metrics and you will increase your value enormously.

This is the first installment in a three-part series. The next installment will cover

Steps 5 to 8.

Installment 1

Business Analyst Times June 16/09

Step 1. Exploit the Hidden Power in “Menial” Tasks

Step 2. Delegate!

Step 3. Compose in Real Time

Step 4. Define gonzo success criteria

Installment 2

Business Analyst

Times July 14/09

Step 5. Ask the crazy-as-a-fox stupid questions

Step 6. Get their attention

Step 7. Schmooze those stakeholders

Step 8. Rat out those underachievers

Installment 3

Business Analyst

Times Aug 11/09

Step 9. Speak truth to power

Step 10. Put on Your “Facilitator Flak Jacket

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected].

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].

Is the Business Analyst’s Work Ever Done?

Written by Jill Liles on . Posted in Articles. 1 Comment on Is the Business Analyst’s Work Ever Done?

Solution Assessment and Validation

The business analyst’s work is not finished when the requirements document is signed off. Although other experts are responsible for the project activities, the BA remains involved to ensure that decisions made have no adverse impact on the business stakeholders. As the project moves forward, the BA should collaborate with the solution team (for example, development, procurement) to ensure that the final solution will satisfy the requirements.

After the solution has been built, the BA collaborates with many people on activities such as testing, conversion, cutover, and training. Depending on the roles defined in an organization and the project, the BA may collaborate with the people who are responsible for these activities, or the BA may be the responsible person. In either case, the BA ensures that all of the right things happen.

Monitor Solution Design and Planning

As the technical team derives the solution design, the BA must learn enough about the implications of that design to ensure that it supports the requirements well. For example, the BA might:

  • Review user classes to ensure that all of the solution functions, uses, and end users have been accounted for.
  • Review the developers’ functions and feature list for completeness.
  • Map the documented requirements (both functional and Quality of Service) onto the elements of the system design to ensure complete coverage.

When the technical team defines its phasing plan (which identifies the order in which requirements will be addressed and functionalities designed and built) for incremental development, the BA must ensure that the plan supports the stakeholders’ needs. If the plan calls for features to be delivered in a certain order, the BA should ensure that the planned order and delivery dates would be useful to the business stakeholders. The BA should also ensure that the phasing plan provides opportunities for any needed prototyping or validation during the project.

Tracing the requirements to the design is a good way to ensure complete coverage, and it lays the foundation for maintaining traceability throughout the project. The traceability information must be captured and recorded as the designs are being done, as trying to derive the traceability after the fact is difficult, if not impossible.

Finally, as the solution is being designed and built, the BA may identify business process improvements that are unrelated to the solution but that would be beneficial. This is especially likely where those processes will be affected when the solution is implemented.

Validate the Final Solution

As each deliverable of the project becomes available, the BA must ensure that appropriate validations take place to ensure that those deliverables satisfy the requirements and can be used by the intended end users.

  • System testing looks at the final system to determine if the requirements have been satisfied. System integration testing refers to testing the final solution to ensure that it can coexist and integrate with existing systems and databases. Many organizations have an independent testing group whose main responsibility is to prepare for and perform these tests. When that is the case, the BA will usually review the test plans and the test results, and at times, the BA may help with the testing. However, in organizations that don’t have testing groups the entire responsibility falls to the BA.
  • Operations testing involves testing the final solution to ensure that it can be installed and run without an adverse effect on the other existing systems. If the computer operations group takes responsibility for this testing, then the BA will usually review the test plans and the test results. But if this testing is necessary and no one takes responsibility for it, then the entire responsibility for this testing falls to the BA.
  • Acceptance testing ensures that the business need and user’s needs have been fully satisfied. If the customer takes responsibility for this testing, then the BA will usually review the test plans and the test results. Otherwise, the entire responsibility for this testing falls to the BA.

Assess Other Solution Options

The BA should collaborate with a variety of people on the project as the solution is being put together. In all cases, expect the experts in each area to be making good choices. The BA’s role in the collaboration is merely to serve as the business stakeholders’ advocate and assure that their needs will ultimately be met.

Although the technical team takes the lead in evaluating and deciding on the technologies that could be employed to build the solution, the BA should remain involved. This is because every technical choice has the potential to cause limitations in the final solution that will be noticeable to the users. So, the BA must learn enough about the effects of the team’s technical choices to ensure that they actually do support satisfying the requirements, and ultimately, the business needs.

When the plan involves purchasing or leasing (as opposed to internally developing) a solution, the BA may take the lead in choosing the solution. But even if someone else has primary responsibility for this, the BA will still remain closely involved. The BA ensures that any RFP (request for proposal) or RFQ (request for quote) accurately translates the requirements. The BA should also verify that the proposals received will fully meet the business need. And, when the solution is finally received, the BA ensures that it is adequately tested to be sure that is actually satisfies the requirements.

Support Implementation of the Solution

In some organizations, an operations team takes the lead in implementation, but often the BA is responsible. In either case, the BA must remain involved to ensure that implementation and any necessary conversion meets the needs of the users.

The BA ensures that any necessary installation planning is done, and that the appropriate technical experts review that plan for correctness. This could be as simple as ensuring there is enough disk space for the new software, or as complex as replacing entire computer systems with new ones.

Conversion is almost always an issue. Since the solution is most likely changing some attribute of the business process, there will probably be data conversion; there may also be other kinds of conversions to be done. Planning for these includes identifying the rules for handling the inevitable problems that will be found.

Finally, the plan to the final cutover to the solution must be well thought out. When should it happen? Will there be downtime involved? If so, how much is acceptable? An important, but often overlooked item is the “backout” plan. If the cutover fails, what must be done so the business can resume working with the old system? If there is significant data conversion or other changes, this can be a difficult problem.

Communicate the Solution Impacts

The responsibility of communicating the impact of the final solutions is assigned to different people in different organizations. In any case, the BA must still remain involved. Before the new solution is implemented, the BA should work with the business stakeholders to ensure that they are ready for it by:

  • Ensuring that everyone who needs to know about the implementation has the information they need, when they need it, before implementation
  • Setting the expectations of users and other stakeholders about how the change will affect them and the business process
  • Making sure that any needed training and help is available to the users in a timely manner

After the implementation is complete, the BA collaborates with the appropriate people to report on the implementation. This reporting provides pertinent information to all the parties who need to know that the implementation took place, and if there were problems. A key item is the business impact that the change had. Since the project was undertaken to improve a business process, the actual impact on the business process is of major concern.

Perform Post-Implementation Review and Assessment

The final validation occurs after rollout of the solution is complete. This activity, also known as “Lessons Learned,” is designed to help the organization learn from each project, supporting continuous process improvement.

You need to capture these successes, identify why they happened on this project, and determine what can be done on future projects to make them routine. The parts of this project that worked particularly well represent opportunities for future projects.

By the same token, if there were things on this project that were problematic, they also represent opportunities for improvement. You need to capture these issues, identify why they happened on this project, and determine what can be done on future projects to avoid them.

The Lessons Learned review is one of the most potent mechanisms for organizational learning and continuous improvement, as long as you actually use what you learned in future projects.

In Summary

Solution assessment includes all the activities that the BA collaborates in to ensure that the technical and other decisions being made by the development team result in meeting the needs of the business and users. These activities include design decisions, phasing for incremental development, maintaining the traceability matrix, choosing technologies, procuring solutions, and ensuring usability.

Jill Liles is the Senior Product Marketing Manager at Global Knowledge http://www.globalknowledge, where she primarily focuses on marketing activities for Cisco training courses. She also coordinates all marketing for Canada. In her spare time she volunteers with her local Susan G. Komen Foundation affiliate and crafts jewelry. This article draws from Global Knowledge’s Requirements Development and Management course.

Copyright © Global Knowledge Training LLC. All rights reserved

Avoiding Conflict between the PM and BA. Part 2.

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on Avoiding Conflict between the PM and BA. Part 2.

Planning Business Analysis Work

When I first read the BABOK® Guide, my initial reaction was, “What are they thinking?!” With my PM hat perched squarely on my head, my reaction was “but… but this is PM work!” In my mind I imagined all kinds of conflict occurring as the BA took on more and more of the PM role. After all, as a PM I had done such traditional project management tasks as creating work breakdown structures, activity lists, estimating,  scheduling, and now a body of knowledge was saying that the BA was supposed to do this work? I could see heads butting already.

When I joined the BABOK committee about a year later and raised these concerns, I was asked an insightful question: “Elizabeth,” one of the committee members asked, “as a PM did you come up with all the deliverables, tasks, and estimates for everyone on the project?” Ah, BAs sure do ask good questions! I remembered that as a PM I had gone to many team members, in particular technical SMEs, the developers, our full-time business SME on the project, and others to get their deliverables, tasks, estimates, and availability. But it had never occurred to me to involve the BA. With that one question the light bulb came on. The image of locked horns disappeared. In its place I saw a PM (me) with the weight of too much project planning on her shoulders suddenly stand up straight and unencumbered. How much easier my life as a PM would have been if for the business analysis work, I had taken the information from the BA and rolled it into the overall project. What a relief it would have been to get the business analysis input from the person who knew the most about business analysis!

With the light bulb came a few related insights:

  1. Planning doesn’t mean doing all the work yourself, so PMs don’t have to complete all the planning processes listed in the PMBOK® Guide themselves. PMs need to ensure that all the work appropriate to the project is done, but that does not mean that the work in Section 5.1, Collect Requirements, for example, must be completed by the PM.
  2. BAs are closer to the business analysis effort, so input from BAs is apt to be more complete and correct. When competent BAs are on the project, PMs do not need to micromanage business analysis. There’s enough for PMs to do, so getting out of the way during business analysis will likely reduce the PM’s stress. PMs, so focused on delivering on time and within budget, need to realize that PMs and BAs working collaboratively get more done, so the project has a better chance of completing sooner.
  3. On large projects, both the PM and BA have full-time work doing project management and business analysis respectively. If either is saddled with doing the work of the other, both will be overburdened, increasing everyone’s pressure and stress levels. Under such circumstances, resolving the inevitable territorial conflict will be that much more difficult and take that much more time, delaying the project even further.

So my advice, PMs, is to let the BAs do business analysis work, which includes business analysis planning. My advice, BAs, if confronted with a PM who wants to plan for the entire project, is to keep asking those insightful questions!

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]

BA & QA

Written by Marcos Ferrer on . Posted in Articles.

During a business analysis transformation project at a large organization, I had a quality assurance management executive ask me what the BOK says about QA.  Surprisingly little, and in my opinion, rightly so.  The quality movement succeeded in Japan, and mostly failed in the U.S., because in the U.S. QA was given out as if it was a separate job.

BA IS QUALITY, and I quote Edward Deming and his followers to make the point.
http://en.thinkexist.com/quotation/if_you_can-t_describe_what_you_are_doing_as_a/12330.html 

“You can’t inspect quality into a product – the quality is already there.”  In other words, you must examine how you do things, not what you have done.

“If you can’t describe what you are doing as a process, you don’t know what you’re doing.”  Indeed, they don’t.

“It is not enough to do your best; you must know what to do, and then do your best.”  If only – so many projects work so hard so everyone can feel good about their contribution, as if every contribution was the “best”.

“We should work on our process, not the outcome of our processes.”  Can you spell BPR?

“Quality is everyone’s responsibility.”  Goodbye, ineffective QA Managers?

“If you do not know how to ask the right question, you discover nothing.”  This is why elicitation of requirements is such a key “art” for BAs – how do you explain what else to ask?  Experience!

“Does experience help? NO! Not if we are doing the wrong things.”  BA is committed to doing the right thing – no wonder it struggles for status in the U.S.

“It is not necessary to change. Survival is not mandatory.”  As demonstrated by the last two large IRS IT projects (look ’em up!).

And my contribution:  “If there is no significant change in the business, there is no significant requirement to analyze.”

More shall be revealed. Keep the feedback coming to [email protected].

Have fun!

© 2009 Marcos Ferrer

The Realities of Surveys in Requirements Gathering

Written by Cynthia Low on . Posted in Articles. 1 Comment on The Realities of Surveys in Requirements Gathering

Requirements gathering techniques include the easy to send, but sometimes hard to develop, survey method to obtain data from a wide variety of people located anywhere. Surveys, however, are notorious for many faults such as ambiguity and a lack of response.

But surveys can produce a large volume of information for the gathering parties to peruse and collate, so developing good surveys is important for both the respondents who have to understand the questions and for the collators to get useful data.

Statistics Prove “IT”

It has been said you can prove anything with statistics if you ask the right question. Obviously, you need to ask the right questions to get the right data. Right?

Reality can be different. The interpretation of an ambiguous question, an open-ended question, a leading question, or a question made up of words most people do not understand, can be very detrimental to getting the answers you need.

For instance, if the requirements were related to virtualization of your datacenter equipment, you should avoid being too general or assume too much knowledge on the part of the respondent.

Ambiguous Question examples:

How does it help?
Who can use this?

Open Ended Question examples:

Why do you need this feature?
What services would help you?

Leading Question examples:

If this service were to fail, who would be affected?
Without web based access to this device, what can be done?
Who amongst your group has the necessary required certifications?

The “Right” Questions

So what is the right question to ask? You do not want to insult your respondent nor do you want to assume they understand the situation or concepts entirely.

How can you ask the right question? Ask an eight year old. Or rather, pretend the audience is eight years old. Assume they do NOT have a vast knowledge of the topic, a slanted knowledge of the world, or possibly a jaded view of the system. Use simple language that is less likely to be interpreted differently.

Provide respondents with some background information or assumptions at the beginning of the survey, or point them to relevant documents or websites they can use to clarify the concepts and issues.

Avoiding Acronyms and Industry Jargon

Often times, in the technical world, we have developed our own jargon or acronyms for the myriad technologies, services, applications, and such that we developed and/or have to deal with every day. For instance, SMB is one acronym that has vastly different meanings depending on your perspective. A recent book had this acronym within the title, and it was very confusing for the network specialist who later found out the book was meant for a general business type audience. What does it mean to you? In the book context, it was Small- to-Medium Business, to the technician, Server Message Block. To my kids on their instant messaging service, it meant So Much Better.

The standard axiom of KISS (or, Keep It Simple, Stupid), applies for questions – keep them short and simple but clearly to the point. In some cases, a preliminary paragraph stating the base assumptions will help to clarify the premise for the questions.

In Requirements Gathering

A common method of gathering requirements from many stakeholders, when interviewing or workshops are not prudent, is to send a general topic survey of questions in the early phase of discovery. These general questions should lead toward more specific questions as the discovery phase progresses. This is when specific questions become more critical. The questions must be very topical or delivery-oriented, maybe even very technical in nature, and yet they must ensure the respondent clearly understands both the premise and concepts.

For instance, a general trend today is toward using virtualization. Most people have no idea what this really means or even implies. To make your survey results more coherent, you may need to include references to websites, local or external, that explain the concepts. Have multiple people within your organization peruse these materials to assess their usefulness, and employ a wide cross-section of people to gauge if the content is technical in nature. You should not rely exclusively on technicians for feedback.

Survey Says …

The right questions on a survey may not always be enough. In some cases, the options to respond and/or the choice of responses can affect your survey results.

Fixed answers, such as in multiple choice, should give the reader plenty of leeway for their decision. Be as wordy as necessary for each choice, without too many overlapping or confusing variations of the same request.

Assumptions

Surveys have to assume some level of knowledge for the respondent, but that is not always achievable when dealing within different technical or managerial staffing levels.

For instance, the following question assumes a great deal of knowledge on the part of the respondent:

Q. How would your department benefit from using virtualization?

This is a rather open-ended question requiring the respondent to be very familiar with the topic and critical about the lack of virtualization use for a long time. To improve this question, provide some options that will make sense rather than have the respondent come up with all the answers:

Q. In an effort to reduce our data-center footprint, the company has been looking into the possibility of moving toward the use of specialized hardware that maintains the separate host services on a centralized, redundant virtual computing platform. Each current host that meets all the criteria (see website //xxx/criteria for details) for being virtualized will be transitioned to the virtual environment. How would your department benefit from using virtualization?

Redundancy [ ] Backups [ ] Ease of recovery [ ] Availability [ ]
Reduce licensing requirements [ ] Reduce number of physical boxes [ ]
Reduce management overhead [ ] Reduce resources [ ]
Expand service levels [ ] Ease of testing [ ] Ease of deployment [ ]

This may be too limiting, instead provide a range of responses

Q. [same intro] How would your department benefit from using virtualization?
(Scaled response with 1 being the least important and 5 being the most important)

This might be followed-up later with questions that specifically define some of the key attributes for switching to a virtualized platform or not.

Q. Select all that apply to your server:

Server provides: [ ] file [ ] print [ ] dns [ ] AD [ ] other _____
Comments: _________

Service must be: [ ] kept separate [ ] own IP [ ] behind firewall
Comments: _________

Setup requires: [ ] Win2K [ ] Win2K3 [ ] Win2K8 [ ] XP [ ] Linux
Comments: _________

Survey Choice Option Default Settings

Surveys often provide a scale for their responses. Some include as few as three options, while others may have 10 or more within the range. There is no best answer, although five to eight choices are probably more than adequate for most ranges.

Imagine a now defunct restaurant asked you to fill out their web-based survey as you left the restaurant. They failed, however, to put an easy-to-find link to the survey on their website. After searching the entire main page, and a few subsequent pages, a small, bottom menu link was eventually found. Within the survey web page, there was a simple explanation of their scale being from 1 to 5, for the 10 questions presented. Each question ended with the same simple drop down list. The default drop down value was preset to 1 for all 10 questions. This may have been planned or not, but it might produce a lot of low results.

Common survey choice ranges include:

“Excellent, Good, Fair, Poor, N/A”

“Strongly Agree, Agree, neutral, Disagree, Strongly Disagree”

“1=Very Bad to 5=Excellent”

“1 is worst, and 10 is best”

Clearly, each of these ranges requires questions that would elicit such a response from the expected target audience. However, do not expect that you will get the top-level choice. How often are you told you are doing an “excellent” job as apposed to a “good” job? Probably not very often. So why would you expect the general public to give a 5 or 10, an Excellent or Best response? Why would you then assume anything else is unfavorable if you have not clearly defined to the respondent what each choice represents?

Do Ranges Reflect Expectations?

The option “Good” could mean many things to many people such as: good, good enough, acceptable, expected norm, at least as good as you expect, etc. This is especially true when the “Excellent” response is the only one good enough. If anything other than “Excellent” is not good enough, ensure the respondent knows that they have to explain why they did not select “Excellent.”

In many hotels, you are given a document requesting that you call the local manager if there is anything that is not to your liking at any time. They want to provide you with a “10 out of 10” experience every visit. They conveniently provide a survey form for when you leave. What do you think happens if you do not fill out the survey for your stay? Perhaps an automatic “10” for that visit?

In some local grocery and department stores, they now have “Outstanding Service” forms you can fill out to honor anyone who has gone out of their way to provide exemplary service for you. No mention of where to enter complaints.

Can you remember your last few visits to a restaurant and a large department store? What was your experience? What was your expectation? What would you expect to be asked? Which range would you expect for the answers?

Surveys Everywhere

Surveys are now ubiquitous throughout the world and we have developed a love-hate relationship. We love to send them but hate to respond to them. We, and this is a collective “we,” tend to ignore most surveys unless there is something in it for us. There are companies on the Internet that offer rewards for filling out surveys from their clients.

Many years ago, a former boss had a great philosophy about surveys done by large groups of customers. He would sort them according to rank, from best to worst, and then ignore the first and last to get the average. He assumed that there was always one in the crowd who had a weird idea of what “good” meant, and he balanced this against those who just quickly gave a general “good” or “excellent.”

There are lots of ways to interpret survey results – many of them bad!

The professional sports teams have all sorts of methods, or “improvements,” to make their stats look good. There are rules for how stats are accepted and interpreted. They usually keep a running total, not just the single events. Keep this in mind when you are working on your results. Taken in small groupings, there can be wide swings in averages. Taken in gross, these averages of averages are more consistent.

In Summary

The usefulness of a survey is in the responses that are received. Be as helpful as possible to the respondents by ensuring they have sufficient information and knowledge to complete the survey. Strive to provide a reasonable and clearly stated range if used. Restrict the space for open-ended questions and keep the questions as simple and succinct as possible, so that anyone can understand each question. Adding an incentive for respondents to complete the survey quickly may also speed up the process. Surveys can take a long time to prepare, collect, and collate but with careful planning, a well-executed survey can simplify the process of gathering requirements.

David Egan is a Course Director and developer of content for more than 20 Global Knowledge courses. David has more than 20 years of teaching experience including more than five years of teaching ‘on-line’ virtual classes over the Internet using Centra, Interwise and iLinc virtual classroom services. David has also written technical books and delivered adult learning seminars on UNIX, Linux, Microsoft Operating Systems and Services, as well as Business Process Analysis and Project Management since 2005. David and his family live in a suburb of Vancouver, B.C. This article was originally published in Global Knowledge’s Management in Motion e-newsletter, Business Brief. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training.

Copyright © Global Knowledge Training LLC. All rights reserved.