Business email requires a different approach to personal email.  How should you write a business email?  What are the common mistakes to avoid?

Email revolutionized the world of business communications, giving you the ability to send messages and documents instantly to different people all over the world. This way of communicating, however, has also become a common way to interact socially, leading to a blurring of the fine line between corporate and personal writing. How should you write business emails and how can you best avoid problems?

Business Emails Need Different Writing Skills

You may not think that you have a problem to solve here. If you regularly use personal mail to communicate with friends and family, then you may feel that you know how to write for this medium already. Business emails are corporate documents, however, and should be written in a language appropriate to this environment. What you say and how you say it matters.

How to Structure Work Emails

Every email you send at work should have a purpose. You may be sending a quick internal message to remind colleagues of a meeting; you may be sending business-critical information to a customer. Your writing should always be concise and laid out in a logical order so that the recipient gets the message. Tell them why you are writing, say what you need to say, give a call to action if appropriate and then sign off.

The Art of Business Conversation in Emails

You do not have to use formal business language in every email you send. This can sometimes be as inappropriate as being too informal. You will be having a business conversation here, often with people with whom you have a relationship. It helps to take your cue from the emails they send you. If a customer begins every message with ‘Dear Mr Soandso’, then your cue is to use Dear as a greeting. If they open with a Hi or a Hey, then you can be a little more informal too.

But, do remember that your words represent your company. You can inject personality, be friendly and chat if your relationship is at that level, but you should always be professional. Jokes, pictures and attachments are best kept to social emailing. Keep in mind that it’s better to work from formal to informal than to be forced back because you got too friendly too soon. In business writing, formality is still viewed by many as a sign of respect.

Email Spelling and Grammar Issues

Just because email can use a more informal writing style, don’t assume that you can slack off on the basics. You and your business may be perceived negatively if you misspell words or use incorrect grammar. Don’t rely on automated checkers as they won’t pick up some simple glaring errors such as their/there, two/too and it’s/its. Learn what you need to know or have someone double-check what you write.

The easiest way to get a message across in an email is to be straightforward, especially if you are dealing with people overseas. Telling a contact who does not have English as a first language that your new product adds innovative benefits is very different to saying that it pushes the envelope, for example. You don’t want your contact to have to look up what you have written to understand what you are trying to say. You don’t want to leave them bemused, amused or confused.

Tone and Meaning in Business Email

Compared to face-to-face meetings and phone conversations, the written word cannot always reproduce tone and meaning. If you can’t see the face or hear the voice of the person at the other end of your business conversation, you can’t read them 100% accurately. This works the other way, so be careful of your language and tone. A simple rebuttal, worded too strongly, can come across as criticism or defensiveness. A throwaway one-liner may not read like a joke on the page. Think about what you are saying, how well you know the reader and how they are likely to react.

Acceptable Use Policies for Company Email Accounts

You should make sure to check if your employer has a policy that dictates how you should be using your company email account. Although these are often weighted towards general usage, some will include clauses that could affect what you write. You may not, for example, be allowed to copy or refer to confidential information when communicating outside of your company, or you may not be supposed to circulate certain types of material.

Finally, it is also worth considering how appropriate an email can be in certain situations. Sometimes, you shouldn’t just be thinking about how you write it but whether it should be sent. It is often wise, for example, to avoid this type of communication for sensitive and confidential issues that might be better handled by a meeting or phone call.

Since then I’ve relayed this story many times, only to discover that it wasn’t just my erstwhile interviewer that was unsure of what a Business Analyst actually does. Very often it’s not until a BA has delivered on a piece of work that the business that they are working for appreciates exactly what it was that the BA did for them, even then I suspect they would find it difficult to define exactly what it was that the BA did.

In a cold economic climate when IT budgets are being cut, it’s important that BAs answer the question of what we actually do, after all, our livelihoods depend on it! While our documentation skills and communication style will prove invaluable during the development phase of a project, when fingers are being pointed and vendors are demanding more cash, this will be no good to us if we haven’t won the business in the first place.

We have a very positive story to tell about what we do, but what exactly is it that we do?

Other IT professions don’t suffer from this sort of ambiguity, a project manager, for instance, has several very clear definitions of what they do, my favourite being:

A project manager has overall responsibility for the planning and successful execution of a project.

That’s it, it’s to the point and everyone knows exactly what to expect from a Project Manager and how they are going to benefit a project. On the other hand, we have the definition as stated by the International Institute of Business Analysis (The IIBA®) in version 2 of it’s Business Analyst Body of Knowledge®:

Business Analysts must analyze and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The Business Analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires. In many cases, the Business Analyst will also work to facilitate communication between organizational units. In particular, Business Analysts often play a central role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a “translator” between those groups.

It does describe what we do, but it’s not quite as easy to digest as the definition of a Project Manager and you can see why there may be confusion about what the role actually entails. I can hear the business now, ‘Where is the value add?’. It’s a fair question, how does analysing and synthesizing all this information actually help an organisation to meet its goals?

To try to understand more about what Business Analyst actually does, I want to look at each phase of a typical project and examine what is required of a Business Analyst during the life cycle of a typical project:

Initiation

The initiation phase is the period during which the business is feeling some kind of pain and is looking to alleviate the stress that this pain is causing, usually by implementing some form of technology or process based solution.

It’s the role of the BA to clearly identify the problem that the business is experiencing and to map out what a possible solution would look like.

This map is then used to create a business case which shows why a problem is being tackled, how much it will cost to resolve the problem and what benefits the organisation can expect to see once the problem has been resolved.

It is the business case which a Business Analyst will constantly refer back to as the need for changes occur during the course of a project, constantly checking to ensure that a change is in-line with the expected business benefits and to ensure that the business case is still relevant and that something still needs to be changed within the organisation.

Analysis

The analysis phase is the period during which the Business Analyst defines the requirements in detail, stating clearly and unambiguously what the business needs in order to resolve its problem.

During this phase the BA will also work with the development team and, in particular, an Architect, to create the design and define exactly what the solution should look like.

Taken together the design and the requirements will guide the rest of the project, with the testers looking to ensure that the requirements have been met and the developers trying to deliver against the design. It’s the responsibility of the BA to ensure that the design meets the requirements and that the testers are testing the requirements.

During this early phase of the project the BA will expend a lot of energy ensuring that any possible changes that can be identified are identified, while they are easily, and often more importantly, inexpensively corrected. Once the initial requirements are documented they need to be tested to destruction by the BA to ensure that they will actually deliver a solution to the problems that the business are facing.

Development

The development phase is possibly the most challenging phase for a BA. It’s quite normal after the pressure of the analysis phase to sit back a little, safe in the knowledge that both quality requirements and design have been delivered. However, it’s during this phase that a BA needs to step up their meetings with the development team, attending daily meetings and generally being the eyes and ears of the business, constantly looking for deviations in course that would otherwise go undetected.

Testing

The testing phase sees the Business Analyst back on firmer footing. There is a process to follow as the testing team go through the process of testing and identifying bugs and the BA can work with the business to set defect fix priorities.

Disputes between the business and development concerning what is and what is not an off spec defect will often be resolved by the BA using documentation created in earlier phases. The mere existence of this documentation is often enough for one side of the other to admit a mistake and for the issue to be resolved amicably.

Implementation

The implementation phase is not the end for the Business Analyst. It’s the last chance for things to go awry and for goals to be missed.

It’s during this phase that a BA should be conscious of how users are using the system. Are they actually seeing the benefits envisaged in the business case? Do the training materials support the business case?

Looking at each of these phases in this way, a common theme of discovery, validation and verification appears throughout a project life cycle. Given the opportunity to answer the question again, I would define the role of a Business Analyst using the following statement which clearly shows what a Business Analyst adds to a project, a business or an organisation:

A Business Analyst is responsible for knowing what the goal of a project is, how to achieve it, managing any changes to the goal and ensuring that all deliverables are aligned with the goal.

In essence, a Business Analyst is a navigator, responsible for reaching the end destination, in our case that destination is the successful resolution of a business problem. The BA always knows what the end destination is, how to get there and is capable of handling course adjustments as they arise.

In the future, when pitching for work, I’ll be better prepared to answer the question and will have a great story to tell.

I hope you found this article useful. If you have a definition of what a BA does, then please feel free to let me know by leaving a comment below.

The development team should trust a BA; this was the first lesson that I got from a senior BA. When I asked him how to do it, he told me that you have to figure that out for yourself there is no proven formula. Some of the things that I tried and how they helped me in building a good rapport with the development team.

• Interact with the developers regularly and keep asking them if they have any doubts. The idea is not to overdo it as they may get a feeling that you are trying to judge their work. Keep it simple and just make sure that they know you are there if they need any clarifications in the requirements.
• Make sure you run the development team through the requirements before they start with the implementation. Do it on module-to-module basis, plan with the Project Managers and Team Leads. Make sure you keep these sessions as informal as possible and try to make them understand the business pain points rather than teaching them (as they may switch off).
• Encourage the team to approach you for any clarification in the requirements. When they approach you make sure you clarify their issues or get the issues raised to correct person, if you are not the right one.
• It is a good idea to explain the business side to the developers and also let them know about the domain, as you have that knowledge. Have these talks at non-work timings like lunch, coffee or while traveling. Make sure you don’t come out as a person who is bragging about his knowledge but as a person who is genuinely helping. Keep it honest; if you are not comfortable don’t try it.

I tried these things and they helped me immensely in building a good relation with the development team. Do let me know what works with you and how you achieved it?

We’re not strictly tech and we’re not strictly business. The definition of what we do is usually written in semi-tech language (we write requirements). But how do we write those requirements, what makes us different? How do we see things and why do we see them in the way that we do? What is the potential of the Business Analyst profession? What do senior managers want that causes them to listen to us? How do we move from Business Analyst to Business Architect? How do we advance ourselves in our positions and advance the profession as a whole?

Let me define the difference between an analyst and an architect. The differences are subtle but I will try to define the three most critical as I see them.

- A Business Analyst reports to developers or an IT project manager. A Business Architect reports to managers or senior managers who may be business or IT but are independent of the project.

- A Business Analyst documents requirements as defined by users. A Business Architect documents and may define a business strategy using requirements provided by the users.

- A Business Analyst operates within the confines of a predetermined technical architecture. A Business Architect is a part of the decision making process to define the technical architecture.

A few more things:

- An Architect is considered a neutral voice and because of that will make more critical decisions than an Analyst.

- An Architect must have the ability to think in both a strategic and tactical manner whereas an Analyst is normally tactical.

- An Architect must be cognizant of enterprise strategies whereas an Analyst is normally concerned with specific projects independent of enterprise strategy.

So we see that each type of “BA” is necessary. How do you become the best BA you can be? Or how do you move from Analyst to Architect? Hopefully I can provide some tips. If this interests you the next few posts will concern listening to the needs of the business in order to become the one who assists in driving out the business strategy – if that’s what you want to do.

Until then – Dum Spiro Spero! (Look it up on Wikipedia)

Who Is the Customer?

Anyone who derives direct or indirect benefit from a product is a customer. This includes people who request, pay for, select, specify, or use a software product, as well as those who receive the product’s outputs. Customers who initiate or fund a software project supply the high-level product concept and the project’s business rationale. These business requirements describe the value that the users, developing organization, or other stakeholders want to receive from the system. Business requirements establish a guiding framework for the rest of the project; everything else that’s specified as a requirement should help satisfy the business requirements.

The next level of requirements detail comes from the customers who will actually use the product. Users can describe both the tasks they need to perform—the use cases—with the product and the product’s desired quality attributes. Analysts (individuals who interact with customers to gather and document requirements) derive specific software functional requirements from the user requirements.

Unfortunately, customers often feel they don’t have time to participate in requirements elicitation. Sometimes customers expect developers to figure out what the users need without a lot of discussion and documentation. Development groups sometimes exclude customers from requirements activities, believing that they already know best, will save time, or might lose control of the project by involving others. It’s not enough to use customers just to answer questions or to provide selected feedback after something is developed. Your organization must accept that the days of shoving vague requirements and pizzas under the door to the programming department are over. Proactive customers will insist on being partners in the venture.

For commercial software development, the customer and user are often the same person. Customer surrogates, such as the marketing department, attempt to determine what the actual customers will find appealing. Even for commercial software, though, you should get actual users involved in the requirements-gathering process, perhaps through focus groups or by building on your existing beta testing relationships.

The Customer-Development Partnership

Quality software is the product of a well-executed design based on accurate requirements, which are in turn the result of effective communication and collaboration—a partnership—between developers and customers. Collaborative efforts only work when all parties involved know what they need to be successful, and when they understand and respect what their collaborators need to succeed. As project pressures rise, it’s easy to forget that everyone shares a common objective: to build a successful product that provides business value, user satisfaction, and developer fulfillment.

Figure 1 presents a Requirements Bill of Rights for Software Customers, ten expectations that customers can place on their interactions with analysts and developers during requirements engineering. Each of these rights implies a corresponding software developer’s responsibility. Figure 2 proposes ten responsibilities the customer has to the developer during the requirements process. These rights and responsibilities apply to actual user representatives for internal corporate software development. For mass-market product development, they apply more to customer surrogates, such as the marketing department.

Early in the project, customer and development representatives should review these two lists and reach a meeting of the minds. If you encounter some sticking points, negotiate to reach a clear understanding regarding your responsibilities to each other. This understanding can reduce friction later, when one party expects something the other isn’t willing or able to provide. These lists aren’t all-inclusive, so feel free to change them to meet your specific needs.

Figure 1. Requirements Bill of Rights for Software Customers

As a software customer, you have the right to:

1. Expect analysts to speak your language.
2. Expect analysts to learn about your business and your objectives for the system.
3. Expect analysts to structure the requirements information you present into a software requirements specification.
4. Have developers explain requirements work products.
5. Expect developers to treat you with respect and to maintain a collaborative and professional attitude.
6. Have analysts present ideas and alternatives both for your requirements and for implementation.
7. Describe characteristics that will make the product easy and enjoyable to use.
8. Be presented with opportunities to adjust your requirements to permit reuse of existing software components.
9. Be given good-faith estimates of the costs, impacts, and trade-offs when you request a requirement change.
10. Receive a system that meets your functional and quality needs, to the extent that those needs have been communicated to the developers and agreed upon.

Requirements Bill of Rights for Software Customers

Right #1: To expect analysts to speak your language. Requirements discussions should center on your business needs and tasks, using your business vocabulary (which you might have to convey to the analysts). You shouldn’t have to wade through computer jargon.

Right #2: To expect analysts to learn about your business. By interacting with users while eliciting requirements, the analysts can better understand your business tasks and how the product fits into your world. This will help developers design software that truly meets your needs. Consider inviting developers or analysts to observe what you do on the job. If the new system is replacing an existing application, the developers should use the system as you do to see how it works, how it fits into your workflow, and where it can be improved.

Right #3: To expect analysts to write a software requirements specification (SRS). The analyst will sort through the customer-provided information, separating actual user needs from other items such as business requirements and rules, functional requirements, quality goals, and solution ideas. The analyst will then write a structured SRS, which constitutes an agreement between developers and customers about the proposed product. Review these specifications to make sure they accurately and completely represent your requirements.

Right #4: To have developers explain requirements work products. The analyst might represent the requirements using various diagrams that complement the written SRS. These graphical views of the requirements express certain aspects of system behavior more clearly than words can. Although unfamiliar, the diagrams aren’t difficult to understand. Analysts should explain the purpose of each diagram, describe the notations used, and demonstrate how to examine it for errors.

Right #5: To expect developers to treat you with respect. Requirements discussions can be frustrating if users and developers don’t understand each other. Working together can open each group’s eyes to the problems the other faces. Customers who participate in requirements development have the right to have developers treat them with respect and to appreciate the time they are investing in project success. Similarly, demonstrate respect for the developers as they work with you toward your common objective of a successful project.

Right #6: To have analysts present ideas and alternatives for requirements and implementation. Analysts should explore ways your existing systems don’t fit well with your current business processes, to make sure the new product doesn’t automate ineffective or inefficient processes. Analysts who thoroughly understand the application domain can sometimes suggest improvements in your business processes. An experienced and creative analyst also adds value by proposing valuable capabilities the new software could provide that the users haven’t even envisioned.

Right #7: To describe characteristics that will make the product easy and enjoyable to use. The analyst should ask you about characteristics of the software that go beyond your functional needs. These “quality attributes” make the software easier or more pleasant to use, letting you accomplish your tasks accurately and efficiently. For example, customers sometimes state that the product must be “user-friendly” or “robust” or “efficient,” but these terms are both subjective and vague. The analyst should explore and document the specific characteristics that signify “user-friendly,” “robust,” or “efficient” to the users.

Right #8: To be presented with opportunities to adjust your requirements to permit reuse. The analyst might know of existing software components that come close to addressing some need you described. In such a case, the analyst should give you a chance to modify your requirements to allow the developers to reuse existing software. Adjusting your requirements when sensible reuse opportunities are available can save time that would otherwise be needed to build precisely what the original requirements specified.

Right #9: To be given good-faith estimates of the costs of changes. People sometimes make different choices when they know one alternative is more expensive than another. Estimates of the impact and cost of a proposed requirement change are necessary to make good business decisions about which requested changes to approve. Developers should present their best estimates of impact, cost, and trade-offs, which won’t always be what you want to hear. Developers must not inflate the estimated cost of a proposed change just because they don’t want to implement it.

Right #10: To receive a system that meets your functional and quality needs. This desired project outcome is achievable only if you clearly communicate all the information that will let developers build the product that satisfies your needs, and if developers communicate options and constraints. State any assumptions or implicit expectations you might hold; otherwise, the developers probably can’t address them to your satisfaction.

Figure 2. Requirements Bill of Responsibilities for Software Customers

As a software customer, you have the responsibility to:

1. Educate analysts about your business and define jargon.
2. Spend the time to provide requirements, clarify them, and iteratively flesh them out.
3. Be specific and precise about the system’s requirements.
4. Make timely decisions about requirements when requested to do so.
5. Respect developers’ assessments of cost and feasibility.
6. Set priorities for individual requirements, system features, or use cases.
7. Review requirements documents and prototypes.
8. Promptly communicate changes to the product’s requirements.
9. Follow the development organization’s defined requirements change process.
10. Respect the requirements engineering processes the developers use.

Requirements Bill of Responsibilities for Software Customers

Responsibility #1: To educate analysts about your business. Analysts depend on you to educate them about your business concepts and terminology. The intent is not to transform analysts into domain experts, but to help them understand your problems and objectives. Don’t expect analysts to have knowledge you and your peers take for granted.

Responsibility #2: To spend the time to provide and clarify requirements. You have a responsibility to invest time in workshops, interviews, and other requirements elicitation activities. Sometimes the analyst might think she understands a point you made, only to realize later that she needs further clarification. Please be patient with this iterative approach to developing and refining the requirements, as it is the nature of complex human communication and essential to software success.

Responsibility #3: To be specific and precise about requirements. Writing clear, precise requirements is hard. It’s tempting to leave the requirements vague because pinning down details is tedious and time-consuming. At some point during development, though, someone must resolve the ambiguities and imprecisions. You are most likely the best person to make those decisions; otherwise, you’re relying on the developers to guess correctly. Do your best to clarify the intent of each requirement, so the analyst can express it accurately in the SRS. If you can’t be precise, agree to a process to generate the necessary precision, perhaps through some type of prototyping.

Responsibility #4: To make timely decisions. The analyst will ask you to make many choices and decisions. These decisions include resolving inconsistent requests received from multiple users and making trade-offs between conflicting quality attributes. Customers who are authorized to make such decisions must do so promptly when asked. The developers often can’t proceed until you render your decision, so time spent waiting for an answer can delay progress. If customer decisions aren’t forthcoming, the developers might make the decisions for you and charge ahead, which often won’t lead to the outcome you prefer.

Responsibility #5: To respect a developer’s assessment of cost and feasibility. All software functions have a price and developers are in the best position to estimate those costs. Some features you would like might not be technically feasible or might be surprisingly expensive to implement. The developer can be the bearer of bad news about feasibility or cost, and you should respect that judgment. Sometimes you can rewrite requirements in a way that makes them feasible or cheaper. For example, asking for an action to take place “instantaneously” isn’t feasible, but a more specific timing requirement (“within 50 milliseconds”) might be achievable.

Responsibility #6: To set requirement priorities. Most projects don’t have the time or resources to implement every desirable bit of functionality, so you must determine which features are essential, which are important to incorporate eventually, and which would just be nice extras. Developers usually can’t determine priorities from your perspective, but they should estimate the cost and technical risk of each feature, use case, or requirement to help you make the decision.

When you prioritize, you help the developers deliver the greatest value at the lowest cost. No one likes to hear that something he or she wants can’t be completed within the project bounds, but that’s just a reality. A business decision must then be made to reduce project scope based on priorities or to extend the schedule, provide additional resources, or compromise on quality.

Responsibility #7: To review requirements documents and prototypes. Having customers participate in formal and informal reviews is a valuable quality control activity—indeed, it’s the only way to evaluate whether the requirements are complete, correct, and necessary.

It’s difficult to envision how the software will actually work by reading a specification. To better understand your needs and explore the best ways to satisfy them, developers often build prototypes. Your feedback on these preliminary, partial, or possible implementations helps ensure that everyone understands the requirements. Recognize, however, that a prototype is not a final product; allow developers to build fully functioning systems based on the prototype.

Responsibility #8: To promptly communicate changes to the product’s requirements. Continually changing requirements pose a serious risk to the development team’s ability to deliver a high-quality product within the planned schedule. Change is inevitable, but the later in the development cycle a change is introduced, the greater its impact. Extensive requirements changes often indicate that the original requirements elicitation process wasn’t adequate.

Changes can cause expensive rework and schedules can slip if new functionality is demanded after construction is well underway. Notify the analyst with whom you’re working as soon as you become aware of any change needed in the requirements. Key customers should also participate in the process of deciding whether to approve or reject change requests.

Responsibility #9: To follow the development organization’s requirements change process. To minimize the negative impact of change, all participants must follow the project’s change control process. This ensures that requested changes are not lost, the impact of each requested change is evaluated, and all proposed changes are considered in a consistent way. As a result, you can make good business decisions to incorporate certain changes into the product.

Responsibility #10: To respect the requirements engineering processes the developers use. Gathering requirements and verifying their accuracy are among the greatest challenges in software development. Although you might become frustrated with the process, it’s an excellent investment that will be less painful if you understand and respect the techniques analysts use for gathering, documenting, and assuring the quality of the software requirements. Customers should be educated about the requirements process, ideally attending classes together with developers. I’ve often presented seminars to audiences that included developers, users, managers, and requirements specialists. People can collaborate more effectively when they learn together.

What About Sign-Off?

Agreeing on a new product’s requirements is a critical part of the customer-developer partnership. Many organizations use the act of signing off on the requirements document to indicate customer approval. All participants in the requirements approval process need to know exactly what sign-off means.

One potential problem is the customer representative who regards signing off on the requirements as a meaningless ritual: “I was given a piece of paper that had my name printed beneath a line, so I signed on the line because otherwise the developers wouldn’t start coding.” This attitude can lead to future conflicts when that customer wants to change the requirements or when he’s surprised by what is delivered: “Sure, I signed off on the requirements, but I didn’t have time to read them all. I trusted you guys—you let me down!”

Equally problematic is the development manager who views sign-off as a way to freeze the requirements. Whenever a change request is presented, he can point to the SRS and protest, “You signed off on these requirements, so that’s what we’re building. If you wanted something else, you should have said so.”

Both of these attitudes fail to acknowledge the reality that it’s impossible to know all the requirements early in the project and that requirements will undoubtedly change over time. Requirements sign-off is an appropriate action that brings closure to the requirements development process. However, the participants have to agree on precisely what they’re saying with their signatures.

More important than the sign-off ritual is the concept of establishing a “baseline” of the requirements agreement—a snapshot at some point in time. The subtext of a signature on an SRS sign-off page should therefore read something like: “I agree that this document represents our best understanding of the requirements for the project today. Future changes to this baseline can be made through the project’s defined change process. I realize that approved changes might require us to renegotiate the project’s costs, resources, and schedule commitments.”

A shared understanding of the requirements approval process should alleviate the friction that can arise as the project progresses and requirements oversights are revealed, or as marketplace and business demands evolve. Sealing the initial requirements development activities with such an explicit agreement helps you forge a continuing customer-developer partnership on the way to project success.

Whether you are building a brand new product or working on evolving an existing product, understanding customer business needs is the foundation of a marketable product. But few of us are experts in interviewing techniques, and few customers talk about their tasks, needs, and context in neat, concise statements about product requirements.

Building the right product starts with asking the right questions. The right questions are those that help us get beneath the surface and understand the customer’s world, work, and concerns.

First Things First

Before you plunk yourself down in front of the customer and start asking questions, articulate your objective. What do you hope to accomplish by interviewing the customer? Do you want to explore broad options, understand a specific business processes, or learn all you can about how a customer uses a particular feature? Articulating a research objective sets the stage for a successful interview. A wandering, unfocused interaction will yield paltry results and frustrate the customer.

Once you’ve defined your objective, brainstorm a list of all the questions you might ask related to the topic. Then organize the questions into themes and arrange them to flow from general to specific and familiar to unfamiliar. The process of preparing questions helps to identify key topic areas to cover. Following a set list of questions isn’t the point: successful interviewers invest time in designing and testing questions—but then use them as a guide, not a script.

As you prepare for an interview, consider different types of questions. Each type will serve a purpose and elicit a different response.

Context-free Questions

Context-free questions are useful in the early stages of a project, when you are beginning to explore. Context-free questions help you decide which avenues to investigate and provide global information about the problem and potential solutions. Because these questions don’t imply any particular context, they are useful for any design project.

Here are some product-related, context-free questions:

· What problem does this product solve?

· What problems might this product create?

· What environment is the product likely to encounter?[1]

Context-free questions generate a deeper understanding of the product and project.

Meta questions—questions about the questions—are a special sort of context-free question. Meta questions, such as “Do my questions seem relevant?” or “Is there anything else I should be asking?” are likely to surface areas where the customer assumes that you already know.

Open-ended Questions

Open-ended questions invite the customer to expand on the topic.

Use What questions to learn about events and considerations.

· What happens next?

· What factors are involved?

How questions ask about the way things happen.

· How do you use the product to__________?

· How do people decide which option to select?

Could questions ask the customer to imagine or express a wish.

· Could you conceive of an example when you’d use the product this way?

· Could you see a way to use the product to solve this problem?

Closed Questions

A closed question is one that naturally leads to a one-word answer, usually Yes or No. Questions that start with Can, Do, Are, or Is are usually closed questions.

Q: Do you have any problems with the wonder widget?

A: No.

Closed questions are useful for confirming specific information, but are deadly as an interview staple. You want to delve beneath the surface, and closed questions won’t help you with that.

If you do happen to slip into a closed question, follow with a probing question to uncover more information:

Q: Can you recreate the problem?

A: No.

Q: What steps have you taken to try to recreate the problem?

Multiple-choice questions offer a limited set of options and help to establish relative priority:

· Which would you prefer, A, B, or C?

· If you had to choose one, which would you choose, X, Y, or Z?

Like closed questions, multiple-choice questions have their place, but shouldn’t make up the bulk of an interview.

Past, Present, Future

Ask questions about past use to understand problems and weaknesses in the product or feature. Use present-time questions to learn about how the customer currently uses the product or how he currently performs his job. And ask questions about the future to learn about trends and anticipate future needs.

Past: When has the product failed to perform as you expected?

Present: How are you using the product now?

Future: How do you see your workflow changing in the next several years?

Tell Me More

Don’t stop at the first answer. Follow an opened-ended question with a probe to gain further insight. A good interviewer will elicit a second, third, and even a fourth response. When you want to learn more, use questions like these:

· What else?

· Can you show me?

· Can you give me an example?

· How did that happen?

· What happens next?

· What’s behind that?

· Are there any other reasons?

Be sure to probe for more information when you hear emotion or judgment:

“I hate the way the floo feature operates!”

“The product does a poor job.”

Dig deeper to identify unmet needs or weaknesses in the product.

Vague statements like “The product must be easy to use” call for probing to learn what “easy to use” really means to the customer.

Questions That Aren’t Really Questions

Some questions don’t elicit the customer’s opinion, but confirm the interviewer’s opinion instead. Biased questions suggest a “right” answer: “My investigation shows that automating the floo process will provide the biggest savings. What advantages do you see in that?” Leading questions make one response more likely than another. Biased and leading questions tend to feel manipulative, and a customer will tune out if he feels the interviewer is leading or putting words in his mouth. Compound questions make it difficult for the customer to respond at all, as in this example:

“Do you think it’s okay to have a question with two topics—unless there are more than that, or if the topic is complex—and is it better to stick to short questions, except in the case where a longer question is better, or is it a judgment call, except in a special case?”

Ask one question at a time, and give the customer time to answer. Rushing in with another question can give the impression that you don’t really care to hear what the customer has to say.

Ask Why Without Asking “Why?”

Curious children ask “Why?” endlessly. They want to know the answers to everything, even things that are unknowable.

We want to know why customers do the things they do so we can understand the tasks they perform and the business needs behind the tasks. But an endless stream of “Why?” questions can wear on anyone’s patience. Worse, “Why?” can sound blaming, or feel like the interviewer is demanding a cogent explanation for something that’s unknowable.

Avoid putting the customer on the defensive by using How or What questions to dig beneath the surface.

· How did this come to be?

· What was the thinking behind that decision?

Or simply ask “Can you help me understand this?”

Putting It All Together

Before you rush off to try out your interviewing skills, practice. Start with a colleague, and then try your interview with an internal customer proxy or subject-matter expert.

Most people find that maintaining rapport and tracking the interview takes all their attention. To help with this, consider working with a partner who can take verbatim notes during the interview. At the end of every interview, perform a short interview retrospective to identify what worked well and what you might want to do differently in future interviews.

Most customers appreciate the opportunity to talk about their work and participate in shaping the products they use. Prepare for your customer interview carefully and hone your interview skills through practice. Invest in learning your customers’ wants and needs so you can deliver the right products.

In some ways, I feel I have grown along side the profession. Very early in my career the IIBA did not exist, then mid-way in my career it came to fruition, and now as they continue to drive new, and different conversations about the role of business analysis in the modern corporation; I find myself in the same position – attempting to provide leadership in an ever evolving and still much needed field.

I give you this background to give you context to my ah-ha moment as I sat in yellow belt training. To me, it is a rigorous and well tested process for conducting business analysis whether the solution is technology or not.

As we walked through the methodology it sounded curiously familiar to the Enterprise Analysis chapter in the Business Analysis Body of Knowledge (BA BOK). The interesting part is that regardless of what you call the activities, every organization should be doing them and have people proficient in doing them.

The six sigma continuous improvement methodology follows the DMAIC approach which involves:

• Define
• Measure
• Analyze
• Improve
• Control

Define simply has to do with defining the problem. As business analysts” we can use problem statements to define this, we also typically scope a project from a business perspective where you may create a context level dataflow diagram. The purpose of this activity is to simply understand the problem and put some boundaries around what you are trying to solve.

The Measure activity is what really intrigued me and seems to be the area we have been missing in the business analysis world. Many times we present information based on hunches or previous experience whereas with measure, you focus on the facts. This is an extremely powerful aspect of the six sigma methodology. It says, ‘you think there is a problem, but let”s find out if there really is”. In other words, what may at first seem like a problem may not be the problem at all but you can only determine that through gathering metrics. The six sigma methodology recommends things like the time series plot and pareto charts. If you are not familiar with these types of artifacts, I recommend taking a class or at a minimum, googling to get more information.

Analyze again provides power and I think this is an area we are still struggling with as business analysts. In this field, there continues to be this behavior where a solution is decided before true analysis is even done. As an example, on a project I was on, the leadership team insisted the problem was the technology supporting a specific business area. Essentially, they said the technology was no good. After doing a root cause analysis, it was determined the real issues had to do with amount of time it took to make a request and receive a response from the IT team. The technology itself was not the problem, the process around it was.

Improve has to do with offering up solutions. Again, it is important to look at all possible solutions to a particular problem. From the example above, one the solutions was to improve the process and response time for the business from the IT team. Although it may not be widely supported in your organization, I still challenge you to look at a problem from all the angles and provide objective solutions (even if the solution has already been dictated to you). At the very least, you may uncover some additional requirements through your detailed analysis. There are several benefits you will reap from this approach. As you begin to provide valuable information to your leadership, you will become the go-to person. Leadership typically wants a well rounded picture before they make decisions. You can help provide a view of all the possible solutions. In addition, you will be adding to your repertoire of skills and improve your own marketability (which is important in this world of ever increasing lay offs).

Control has to do with monitoring a project all the way through its lifecycle and evaluating the results at the end. This is yet another opportunity for business analysts to take it to the next level. In the last 10 years of my career, we continually fall down in this space. We don”t do a good job of measuring whether we were successful or not. When we don”t do a good job of measuring success, every project begins to look like a failure. If you look at the statistics, there are still a high number of IT projects seen as failures. What are we doing wrong? There are several pieces to the problem (which I will save for another article) but one piece most definitely is not establishing critical success factors up front (another six sigma trick) and then measuring against those at the end of the project.

In conclusion, whether you are a business analyst, business architect, customer engagement manager, client engagement manager, enterprise business analyst, system analyst, project manager, or any other title we can come up with and whether you are a six sigma shop, a BA BOK shop, PMI BOK shop, a Lean shop, or an Agile shop – I hope you are doing these activities. We should all be doing these activities to make our projects more successful.

Even if you are perfectly content in a current technical writing role, most of us can benefit from at least considering other organizational roles and making ourselves marketable for more than one position. Additionally, in many companies, a business analyst position is in a higher salary range than that of a technical writer, making the transition financially appealing.

If you are a technical writer wondering what you might have in common with a business analyst, consider these commonly shared skills and character traits:

• Both roles require diligence in tracking down subject matter experts and locating existing research. Like you, a business analyst must likely develop a roster of experts that he routinely turns to in order to accurately document his work.
• Both roles require strong interviewing and listening skills. A business analyst also has to ferret out details, continually ask “Why?”, and read between the lines to discover what they can’t afford to miss.
• Both roles strongly benefit from close familiarity with the inner-workings of an organization’s products or services.Like you, a business analyst has to know every possible occurrence of a product or service (and know how to document those occurrences in clear and understandable ways).
• Both roles require the ability to write clearly and precisely, including the ability to describe products or functions graphically (such as diagrams, tables, charts, etc.). Indeed, your step-by-step help manual probably requires much of the same creative thinking as a business analyst’s use case diagram.
• Both roles must actively solicit reviews and feedback for their work. Both also require the ability to evaluate and integrate that feedback as appropriate, and to keep detailed records of what changes were made and why.
• Like you, business analysts are sticklers for details. Methodical thinking through every aspect of a company’s business is also part and parcel of a business analyst’s work. Whether a writer is creating a how-to manual, help copy, or requirements, she has to pay close attention to all of the steps and features of the service or product and their potential interactions with other services or products, including the lesser-known ones.

Despite these similarities, becoming a business analyst may not be the right choice for every technical writer. The role of a business analyst requires effective oral presentation skills and no small amount of diplomacy. If the following are a natural part of your work persona, you will want to do some careful consideration before applying for a business analyst’s position:

1. You enjoy working alone most of the time, spending most of your day reading, writing, and editing. Throughout a project, business analysts continually interact with stakeholders, project managers, developers, and even training and customer care.

2. You do not enjoy oral presentations, or explaining concepts to larger groups. Requirements are normally presented to all stakeholders in meetings, and the analyst must be prepared to explain and defend them.

3. You do not want to host multiple meetings to facilitate a project from scope to conclusion. Depending on the company, meetings to define scope, business reviews, usability reviews, and technical reviews are all part and parcel of an analyst’s work.

4. The thought of working to resolve conflicts between stakeholders sounds disagreeable you. Almost no business analyst enjoys resolving conflicts when stakeholders offer contradictory wish lists for inclusion in a requirements document, but such conflicts are often a regular part of the requirements cycle, so one must at least be amenable to addressing them.

If you’re still wondering whether a business analysis position may be a good fit for you, the answers to these three questions may reveal the answer:

(1) Would I enjoy business analysis work?

If you enjoy technical writing, the chances are pretty good that you have the temperament to enjoy business analysis. But one easy way to find out is to volunteer for a small business analysis project within your project management division. (Most analysis groups are overloaded and would be glad for the help.) Go through the entire process of discovery, writing your requirements documentation, soliciting feedback, and getting final approval. Not only will this reveal whether you have an affinity for business analysis, but if you decide to pursue it as a career, it will give you some experience for your resume. Of course, before you can “try on” the role of the business analyst, you may need a bit of training.

(2) Where will I find the proper training and resources to make such a career transition?

You don’t need a degree in business analysis. (I know business analysts with degrees ranging from accounting to English literature.) And although it will help, you don’t need a college course to get started. You will, however, need to familiarize yourself with industry terminology, the process of requirements discovery, and the standard templates for requirements documentation. One industry-acknowledged resource is BABOK 2.0, available here. Although your organization may use slightly different terminology or processes than those described in BABOK 2.0, the basics will serve you well.

(3) Can I become a business analyst in my current industry?

Industry familiarity helps when you enter any job, but particularly so in the role of business analysis, where details are king. If you can make the move to analyst in the industry you’re already trained in, you’re ahead of the game.

If the answers to these questions whet your appetite for business analysis, naturally your next question is going to be, “As a technical writer, how do I market myself as a candidate for business analysis when experienced business analysts may be competing for the same position?” Three ways: (1) If you’re not already doing so, attend your organization’s requirements reviews. Pay close attention to the style of your organization’s requirements as well as the requirements process. Note what you could bring to the table that might enhance what is in place, and be prepared to highlight that in an interview. For example, “I’ve noticed that the discovery stage is sometimes rushed because of our current production schedule. I bring five years of experience of painstakingly documenting our services, and I don’t need a long discovery process.” An outside business analyst candidate is not likely to offer that. (2) Volunteer for smaller analyst projects to gain experience with discovery and writing requirements. (3) Highlight your transferable skills to the analyst position (listed at the beginning of this article) on your resume and in your interview.

Most of my business analysts colleagues and I began our careers as technical writers. We each benefited from our technical writing stints because they afforded us deep, necessary knowledge of our organization’s services. Also, in our technical writing research, we each read numerous requirements documents to help us understand the services we were documenting. Most writers learn to write by reading, so by the time we became analysts, writing requirements was almost second nature. If you decide the move to business analyst is one that is right for you, take advantage of every opportunity in your current role to prepare yourself for what may lie ahead. As far as job transitions go, you’re likely to find this one a natural.

Over the last 20 years, we lost sight of that, as the technology focus began to shift away from IT and toward the business users. The PC dethroned the mainframe and minicomputer. Local-area networks enabled whole companies to run on PCs and servers. The chips powering PCs got more and more powerful, allowing the software to get more full-featured.

Then the Internet hit the big time, and for the past 10 years, we’ve been exploring the many things you can do when you combine people and computers in real-time networks via the Web. But by now, the newness has worn off, and we are back to thinking about that old concern of how to use this stuff to make money. That’s where the business analyst comes in once more.

A lot of IT functions have been outsourced, including data center operations, programming and the help desk. The one function that doesn’t seem to lend itself to outsourcing is business analysis. To effectively look out for their best interests, companies have to analyze their specific challenges and find unique responses to them. If they play the “me too” game of simply doing what everyone else is doing, they will reap no real competitive advantage. Sure, a company can bring in consultants to help and to train its analysts, but it cannot get consistently good results if it outsources the whole analysis function. Why? Because an analyst needs to really understand the company he is working with, and the best way to do that is to live there and be part of it.

I often hear that companies have not developed their business analysis capabilities because they believe that analysts use soft skills that anyone can exercise without much training. I beg to differ.

I was once asked to start up and run a group of business analysts for a company that already had a 100-person IT department. As part of that job, I had to define the specific skills my analysts should have and then put in place a training and career advancement program that would develop those skills. This gave me cause to think carefully about the skills that analysts need and how to develop them.

Here’s what I found:

• Business analysts must be able to facilitate joint application-design sessions that involve groups composed of both business and technical people. They need to actively include everyone in the sessions and encourage people to contribute their ideas.
• They need to do process mapping. This is often a very good way to focus the conversations of a group in a design session and provide a big-picture context in which to place people’s ideas.
• They need to apply data modeling to organize the data flowing through the business processes they are designing. By this I mean logical data modeling (not the creation of physical data models in fourth normal form).

Once analysts have facilitated group design sessions, created process flow diagrams and organized the relevant data into a logical data model, they must pull this all together and create the user interface for the system that will drive the activities in the process flow and handle the data in the data model. This is where analysis turns into synthesis, and where the design of any new system emerges. And as ifall that weren’t enough, good analysts must also be skilled at system testing, user training and even project management.

Soft skills? These are some of the hardest skills to master in the whole IT profession. And companies need good business analysts now more than ever if they are going to thrive in our fast-changing global economy.

In retrospect, I am thankful for the difficulty I experienced in finding a job. As a result of this experience, I have learned how to make myself stand-out, no matter the economic situation. This article will share my top 5 tips for maintaining an edge in a difficult market and landing a job.

1. Know your trade, inside and out. Get back to the basics.
During the time I was unemployed, I found I landed interviews fairly easily. It was sealing the deal that I found difficult. Part of the reason I had difficulty was due to my inability to naturally speak the language of my chosen profession – business analysis (BA). I had been a practicing BA for a good 5 years at this point, but I was shaky about my skills when interviewing. Once I realized this was part of my problem when interviewing, I started to study my own trade. I purchased a few basic books on the subject and read them all. I knew most everything in the books, but it reinforced what I hadn’t practiced during my 8 months of unemployment. This gave me a common language to speak with the manager with whom I was interviewing. It also gave me confidence that I really did know what I was doing – which can be easy to forget when you go through long periods of unemployment.

In the same sense, keep yourself marketable. What sets you apart that makes a potential employer want to call you in for an interview? Future employers search for people that will be an asset to their organization. Demonstrate this by participating in activities that set you apart. For me, I try to publish articles in my field, attend and present at trade shows like Business Analyst World. I also look for opportunities to lead within my organization – like starting a Business Analyst Center of Excellence for my latest employer. These activities demonstrate my ability to lead a team, conduct public speaking, and write. Look for opportunities within your community or current organization to similarly demonstrate how you are an asset to an organization.

2. Interview, Interview, Interview. Practice makes perfect.
Interviewing is a skill you must keep current – no matter how long you have been an employee of an organization. One recommendation I make to people is that they try to interview with another company every year. Interview even if you are perfectly content in your current position. Why? You need to practice interviewing and the best way to do that is to explore different opportunities. You may find that you discover opportunities you would not have otherwise pursued. If you do find that you are in the position to look for a new job, you will be better prepared to face the challenges of navigating through an interview then someone who has not practiced the skills in years.

3. Know your strengths and weaknesses.
Prospective employers will inevitably ask you what your strengths and weaknesses are. These questions usually make me squirm because it is difficult for me to talk about why I am so great (I tend to downplay my own strengths.) To help myself get over this fear, I purchased a book called Strengthfinders 2.0 by Tom Rath. I took a short test and was surprised at the accuracy of the results. The test will produce a top 5 list of your strengths and a strengths profile. While this may seem hokey, it is a great tool to use to make this conversation easier. I would never list my top 5 strengths verbatim from the book. However, I would tell my prospective employer that I am known best for being a great team builder. I would then list examples of how I have used this skill in my day to day work.

Strengthfinders or any similar tool, can give you insight into areas of weakness. Any strength taken to an extreme can be a weakness. Most Websites which offer interviewing advice will tell you that when answering the question “What is your greatest weakness?” you should use this as an opportunity to highlight one of your strengths. For example I could say something like: “I like to build consensus among my team members and can become frustrated when certain team members are antagonistic. To combat this, I would sit down one-on-one with the individual and try to probe the root cause so that the team can address the individual’s concerns.”

4. Keep your resume up-to-date.
This seems like a no-brainer right? I am always surprised by the number of people who tell me they do not have a resume or have not looked at their resume in years. A friend of mine recently found herself looking for employment after 11 years with her company. She started at the organization fresh out of college and had spent her entire career there. She fully expected to spend her entire work life working for this organization. She was shocked when she found herself a part of a reduction in force. She also had never written a resume. She didn’t know where to start. Don’t let this happen to you! Have a current resume ready and available at all times. I also suggest that you have different people periodically review your resume for areas of improvement. This outside perspective will enhance your resume and ensure you are putting your best foot forward at all times.

5. Find a path to success.
During my 8 month period of unemployment, I had many rejections from many companies. Prior to this experience, I had found it fairly easy to land a job. This was a different business climate and I needed to adjust my expectations. After about 6 months of not finding a job as a Business Analyst, I started to expand my definition of acceptable employment. I applied, tested, interviewed and accepted a position as a Metro bus driver for the Seattle metro area. While I had no intention of making this a permanent career move, it did me a world of good. It gave me a success under my belt. I was able to land a job. I was a desirable employee to someone. While I never did end up driving a bus, the experience gave me tremendous self confidence that I had lacked dearly at that point. I used that newly found self confidence to land the perfect job a few weeks later at a large Insurance company as a Senior Business Analyst.

Another approach may be to keep your skills current by contributing to an Open Source project. Grant Ingersoll1, a distinguished contributor to the Open Source project Lucene, recommends you find a well known Open Source project and start contributing. These types of projects often need people to de-bug, test, write small patches (if you know how to code), and contribute ideas. They are grateful for the help. There are similar projects available to Analysts. Eclipse.org produces the Open Requirements Management Framework. Check out their website (http://www.eclipse.org/ormf/project_home/get_involved.php) to see if there is potential for you to contribute. Using this technique allows you to publicly demonstrate your skills and keeps you active in the software community while you continue your search for a job. Who knows, you may even find that this type of work is a good networking vehicle to launch your next career!

In Summary – Stretch Yourself
I have a quote framed on my desk which I take with me to every job. It states: “Twenty years from now you will be more disappointed by the things you didn’t do than by the ones you did do. So throw off the blowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover.” (Katsumi Sugita) Apply this principal to your career. Take a risk. Sail away from the safe harbor and stretch yourself, you won’t regret it.

In the end, each of us is responsible for our own career. We decide whether or not we are an asset to a company. We decide how well we perform. We decide how long to work for an employer. We decide our future. Own it. Live it. Be your best, every day. We owe that much to ourselves.

While I can’t guarantee that following these tips will land you a job every time. I have found they have worked well for me and have helped me stay competitive no matter where my career takes me.