Skip to main content

Author: Norman Thuswaldner

BA’s Survival Guide – Negotiating Agreements

Introduction to the BA Survival Guide Series

The Business Analyst Survival Guide series explores the soft skills of the BA.

While you will read many articles that talk about the latest trends and techniques in business analysis, the survival guide series focuses on those skills, without which, no matter how technically skilled the BA is, he or she will struggle to deliver tangible results.

Why should the BA care about negotiation?

Being an effective BA requires working with and interacting with many people. These people include: clients, business leaders, project team members, project stakeholders, vendors, government department representatives, private sector representatives, industry leaders, and so forth.
The reasons why a BA may have to interact with various individuals vary considerably; however, some of the more common reasons include: understanding business requirements, understanding the capabilities and limitations of technologies, selecting and designing technical solutions, and reaching contract agreements.

Rather than providing a “Top 10” list of generic techniques, this paper presents three scenarios involving BAs that are faced with situations that require negotiation. These scenarios are not intended to represent all of the available negotiation strategies , but rather describe practical examples of how negotiation techniques can be employed in the real world.

Each of the BAs in these scenarios has some knowledge of negotiation strategies (having read several books on the subject) but has not yet put these techniques into practise. Let’s see how they do:

Scenario #1 – The Peacemaker

ThusaSuzanne is a BA that has been hired by the IT department of a large federal government department. As part of an asset-renewal project, she has been tasked with developing the business requirements for one of the business areas and she has completed a draft version of the document. The IT branch has a number of projects that are underway using Microsoft Dynamics – an enterprise resource planning and customer relationship management (CRM) software application. In addition, the IT branch is undergoing a change in their development methodology from waterfall to a more iterative, or “agile-like” approach.
Ms. LaChapelle is the IT director responsible for the delivery of the CRM projects, and she has asked Suzanne to drop by her office to provide an overview of the newest project in her portfolio. Suzanne shows up at the required time and describes the business area, the main objectives, and the business requirements. Ms. LaChapelle asks Suzanne if she thinks the business requirements of the new project lend themselves to a CRM solution.


Advertisement

Suzanne knows that there is not quite enough information at hand to determine the most appropriate technology, but senses that there may be some pressure to use the CRM solution. Suzanne suggests that a meeting occur between IT and the Business and Ms. LaChapelle agrees. Suzanne schedules the meeting and includes an agenda that clearly states the goals, which are to review the business requirements and define the scope of the technical solution; however, Suzanne secretly knows that the most important goal of the meeting is to get IT and the Business at the table for a productive conversation, but has not included this in the agenda for obvious reasons.

The next day, the meeting begins and in attendance are Ms. LaChapelle, Mr. Fontaine the Director from the Business side, George a subject-matter expert, and Suzanne. Suzanne begins by presenting the high-level activities of the Business area represented as a process map. Ms. LaChapelle doesn’t wait for Suzanne to finish and declares that the project is definitely a candidate for Microsoft Dynamics, and that any further discussion in the meeting is probably a waste of everybody’s time. Mr. Fontaine is visibly annoyed and suggests that IT is more concerned with developing an MS Dynamics empire rather than delivering quality solutions to the Business. Ms. LaChapelle indicates that she is double-booked and starts to get up from her chair to leave the room.

Suzanne knows that if IT and the Business start off on the wrong foot, all kinds of problems could develop. Suzanne asks Ms. LaChapelle to give her 10 minutes before she leaves and goes to the whiteboard to try and salvage the meeting. She asks each party to identify their top three priorities, and produces a side-by-side list on the whiteboard. The whiteboard looks like this:

 

IT Priorities Business Priorities
1) Production infrastructure 1) Ease of Use
2) Security 2) Data Quality
3) Maintenance & Support 3) Ease of Maintenance

 

Suzanne suggests that the two parties have more in common than they realize. She points out that both parties want a solution that is easy to maintain. She indicates that if the system promotes the capture of quality data there will be less of a burden on IT to fix data quality problems, and that a good security layer will also contribute to data quality. Suzanne points out that a system that is easy to use may result in fewer trouble tickets for IT. She also suggests that a system that integrates into the department’s IT infrastructure will translate into less headaches for the Business when they decide to expand the system in a few years to integrate with other corporate systems and databases. Ms. LaChapelle and Mr. Fontaine agree to work together to achieve a common goal.

The meeting came close to becoming a disaster. Both parties had committed themselves to opposing positions, and the more they tried to convince the other side of their position, the more difficult it became to identify the shared interests. By pointing out the common goals, Suzanne provided a baseline for the parties to work as a team rather than as two groups with different agendas.

Scenario #2 – Getting Them to Talk

thusbRobert is a BA with eight years of experience who has been hired by an organization as part of a project to replace a legacy training system. A formal project has not yet been established, there is no business case, and there has not been any money secured for the project. However, Robert has conducted several informal one-on-one interviews with the managers of the business areas that depend on the system, as well as with several subject-matter experts, and he has compiled a set of requirements for each person. Robert has been asked to facilitate a workshop in order to develop a single list of high-level business requirements and to reach a consensus among the stakeholders of the business requirements.

The workshop begins with the attendees that include the business-area managers, the subject-matter experts, an IT branch representative, the director of Human Resources, and the VP of Finance who is the sponsor of the project.

Robert presents an overview of the requirements that have been compiled, and it is clear that some of the requirements are contradictory, while other requirements appear to be out of scope. For example, one of the requirements in question describes the ability to make direct monetary payments to third-party training vendors and to reimburse expenses to employees incurred for training courses and other expenses related to training such as travel, lodging, and incidentals.

One of the business-area managers speaks up and suggests that this requirement doesn’t belong and that if a financial module is incorporated into the system it will detract from the main objective of the system. A different manager defends the requirement by indicating that the new system should be “state-of-the-art” and address all of the training management requirements. The manager continues her defence of the requirement indicating that she has already seen a demonstration of an off-the-shelf solution that can easily be customized to address all the organization’s system requirements.

Robert knows that talking about the solution before having identified the problem is risky and suggests that discussing solutions, whether they are custom built or COTS, should be postponed until everyone can agree on the requirements. Robert asks the IT Branch representative whether integrating the training system with the financial system is practical as a future consideration. He then asks the group if it is reasonable to retain the requirement as part of the larger set of business requirements for the new system but prioritize it as one that is less critical for the first phase of the project.

Robert knows that whether or not the new system will make payments to vendors and employees, it doesn’t change the fact that this is part of the business, and that deciding what parts of the business will be addressed by the system is a decision that must be made after the business requirements have been agreed upon; however, he does not press this point. The important thing is that he has diffused the tension that arose from the differences of opinion regarding the requirement, and he has validated the manager’s requirement while not alienating the rest of the group.

Scenario #3 – The Contract

thusCA consulting company is putting a bid together to respond to a federal government request for proposal (RFP). The company has candidates for all the positions except the business analyst. Last week a recruiter from the company had a coffee meeting with Pierre, a seasoned BA, and she was impressed with his qualifications. The company had initially told Pierre that they could pay him a rate of $550 per day, but a final agreement has not been made and both sides know that they need to agree on a number to move forward.
Pierre knows that there are similar jobs requiring his level of experience that pay more if he is willing to wait. But this work is interesting, and he knows the clients having worked with them in the past. In fact, the clients had called him and asked if he was available, and Pierre in turn had contacted the consulting company.

Pierre calls the company to schedule a meeting, and the company suggests that Pierre meet with the recruiter he had originally met, but Pierre politely insists that he meet with someone who has the authority to make financial decisions. At the scheduled time, Pierre arrives at the company’s office and is shown into a meeting room and shortly after, Ms. Labelle, the Vice President of Marketing, joins him.

Pierre has done his homework. He knows that time is running out for the company to find a qualified BA and most of the experienced BAs in town are working and are not available. He has determined that his bottom line is $600 and has decided that he will walk away if the final number is less than that, but he is confident that it will not come to that.

Pierre takes the initiative and begins the discussion by reminding Ms. Labelle that he knows the client well and that the client specifically asked for him. Pierre points out that the going “in-pocket” rate for BAs in the city is about $650 and that government clients in the city routinely pay $850 for this calibre of resource, which leaves a healthy profit of $200 a day for the company. Pierre concludes by requesting a rate of $650 for this job.

Ms. Labelle clears her throat and informs Pierre that this is a long-term contract for 12 months with up to two one-year extensions. (Pierre doesn’t want to work for any single client this long but keeps this to himself). Ms. Labelle continues and indicates that there will be a lot of other companies submitting bids for this work and that Ms. Labelle’s company must submit competitive rates to be awarded the contract. Ms. Labelle concludes by urging Pierre to accept $600.

Pierre thinks that he can live with this, but before he agrees, he suggests a couple of amendments. If after the initial 12-month period, the client decides to exercise the first extension, Pierre’s rate will be raised to $650. After all, suggests Pierre, the only reason for an extension would be due to the quality of his deliverables. In addition, Pierre requests complete transparency from the company with full disclosure of the company’s bill rate for his services to the government client.

Ms. Labelle agrees. The paperwork is drawn up and both parties sign a contract.

Wrap Up

thusDHaving read the scenarios, you’re now an expert in negotiation strategies, right? Well, of course not. But you might see the interactions that occur between people in a different light, and you might think about how you can negotiate effectively where you work to resolve a variety of issues. If you want to become a better negotiator you can begin by reading one of the many books that are available on the topic or take a course. However, the key is to practise these techniques with the people you encounter in the workplace.

As a final thought, the cornerstone of effective negotiation is respect and professionalism, regardless of the other side’s behaviour. Some important considerations are:

  1. a) Listen rather than talk. You’re not going to learn anything if you keep talking.
  2. b) Understand rather than educate. Only educate when you are asked to, don’t make speeches, and convey your knowledge respectfully and without talking down.
  3. c) Your reputation is gold. You will be remembered for not just what you did but how you did it.

References
Getting to Yes, 1981, William Ury & Roger Fisher
How to Win Friends and Influence People, 1936, Dale Carnegie
Beyond The Chicken Dance, 2009, Charles H Newman

Survival Guide for the BA Consultant – Top 10 Techniques

This article describes survival techniques that can be used by anyone who has an office job, but focuses on consultants, and in particular, business analysts.

Business analysts are generally in contact with more members of an organization than other consultants, since they interact with both IT and business personnel and are often called upon to explain to senior management the business requirements, solution options, and the alignment of the solution with the business. The manner in which business analysts interact with these different types of people is critical if solid working relationships are to be established.

1) Be Courteous

Thuswaldner 112817 1It’s good to know your stuff, but no matter how good you are or how many books you’ve written, if you are perceived as being difficult to work with, people will find ways to avoid you. If you’re a contractor this will result in, at best, the non-renewal of your contract, or at worst you may find yourself being escorted off the premises by security. If you’re an employee, you may find yourself tasked with a make-work project that requires minimal interaction with staff. Either way, the outcome will not be pleasant, so make an effort to be courteous and pleasant with your colleagues and you will find your day to be more enjoyable and the people that you need to interact with will want to talk with you. Remember, you’re never too important to be nice to people (John Batiste).

2) Listen

Thuswaldner 112817 2If you are an experienced business analyst, you probably have lots of great advice to offer and lots of stories to share. The challenge is to limit the sharing of your personal experiences and to spend more time listening than talking. The saying that you have two ears and one mouth so you should do twice as much listening as talking speaks volumes.

Are people looking at their watches when you drone on and on about yourself? Look for signs of interest or disinterest in the people that you’re speaking with, and adjust your delivery accordingly. Listening to someone explain something that they know about is a great way to get that person onboard.
It’s a tough pill to swallow, but you may not be as interesting as you think you are and not everyone is going to want to listen to your war stories. You’re not going to learn anything if you’re talking, so put your ego aside and start listening.

3) Remember Names

Thuswaldner 112817 3Have you ever been introduced to someone and then immediately forgotten their name? You’re not alone. As a business analyst, you will meet many people that you will interact with on a regular basis, so you may as well get to know them. That begins by not just remembering their faces but by remembering their names. There are lots of techniques that you can learn in order to remember names, and we won’t go into all of those methods save for one: When you are introduced to a person for the first time, repeat the name by saying “Hello Jennifer”, or “Hello Peter”. This will emphasize the name in your memory.

Remembering a person’s name is not just good form, it gives you a leg up on those who don’t remember, either because they’re not able to or can’t be bothered. It also serves as a message to the other person that you are interested in them and what they have to say, and you are more likely to get quality information from this person that will help you do your job.

Forgetting someone’s name, or making a guess, is something to avoid, but if you forget it’s best not to guess – just apologize, admit that you’ve forgotten, and move on.

4) Research the Organization

Thuswaldner 112817 4Equipping yourself with knowledge about the organization will demonstrate to your clients an interest in the organization and will also enable you to adjust your approach in order to be compatible with the organization’s culture and work environment. Some factors to consider when researching an organization are:

  • Organization size and the number of employees
  • Organizational structure, culture, and mission statement
  • Organization history
  • Competitors
  • Working conditions and work environment
  • Main products, services, and programs
  • Annual sales, funding sources, annual budget
  • Location of headquarters and other office locations
  • Internal job descriptions
  • Dress code
  • Morale of employees

5) Make Your Ideas Your Client’s Ideas

Thuswaldner 112817 5As a business analyst, especially as a consultant, you are hired to use the experience that you have acquired over the years to deliver innovative and creative solutions. Your goal is to contribute to the successful delivery of the project or the organizational initiative. You are not looking for a promotion, but your client might be, and if the project or the initiative that you are working on is successful, the chances of your client being promoted, or at least recognized, are elevated. This may be warranted because if your client was smart enough to hire you, and you delivered, then that deserves some recognition. Therefore, try to be humble and make it your mandate to make the people who hired you look good by letting them take the credit for your work. If you put those around you first, this will be noticed, your client will love you, and you will be rewarded with respect.

6) Deliver Beyond the Expected

Thuswaldner 112817 6

Your client has more than likely indicated to you what is expected from you and you will, of course, make those deliverables your priority, but that doesn’t mean that those should be your only deliverables. As an experienced business analyst, you know that there may be other areas that will need to be addressed, and as long as you are not treading into someone else’s area of responsibility, you might consider identifying these areas to the client. Consider for example a business analyst who was asked to develop a series of process models describing a particular business area. This particular person was hired because she has experience in process modeling, but she also has experience modeling business information, and knew that if each of the process models identified the information that is used or created, there would be added value for the client. The business analyst spoke to the client, made the pitch to develop a logical data model, and delivered more than was expected of her.

Exceeding your client’s expectations doesn’t always have to have the “wow” factor. There are many less grand ways that value can be added to the service that you provide. By thinking outside the box and avoiding the status quo, asking yourself if there is a better way to accomplish the tasks that are at hand, and keeping in mind the best interests of your client, you will exceed your client’s expectations.


Advertisement

7) Make Friends with Admin Assistants

Thuswaldner 112817 7Although the administrative assistant holds one of the lowest paying jobs in an organization, they play a key role in its success. They are usually the first person in an organization to answer the phone. They are responsible for booking meetings, arranging documents to be signed, and locating specific documents.

They are the gateway to the executives of the organization, and they have the power to help or hinder you as they choose. If you treat them with respect they are more likely to make things happen for you. Like any person, when they are treated well they will respond in a positive manner. It’s just all the more important to treat the administrative assistant respectfully, because they can make or break you.

8) Make the Difficult Client Your Friend

Thuswaldner 112817 8If you work long enough in an office environment you will eventually find yourself having to work with someone who is difficult. This is a person who will irritate you by either being uncooperative, disagreeable, unfriendly, or outright caustic. If it hasn’t happened to you yet, it is just a matter of time, and if it has happened to you, it will probably happen again, so it is a good idea to equip yourself with a few ways to manage this type of person. The first step is to realize that there is always an underlying reason that makes the difficult person difficult. It may be due to an insecurity, a perceived sense of a lack of respect among their colleagues, or problems that they may be having in their personal lives. Whatever the reason, you do not want to add to their stress by becoming a threat to them. A natural tendency is to avoid such people altogether, but before you revert to this, there may be a better way. Instead, draw them into a conversation where they do not feel threatened. The manner in which you engage them needs to be gentle, and the topic needs to be carefully chosen, but the main point here is to make them feel valued. If you don’t know the person, then you have no reason to doubt that they can make a valuable contribution to the task at hand. If on the other hand you are acquainted with the person and know that they may not be that helpful, you will need to find a way to gracefully minimize this person’s impact on the project and the team members.

9) Proofread all client-ready documents

Thuswaldner 112817 9We are all writers and readers with the need to be understood and to understand, and therefore, writing in an effective and efficient manner is important. Written materials such as formal documents, slide decks, handouts, and emails that you produce are a direct representation of you and the quality of your work.

With spell-check, there is no excuse for spelling errors, and poor grammar can contribute to confusion and create additional work in order to clear up misunderstandings. Learn to “write right” either by taking a course on business writing or at the very least picking up a book on the subject. A book that I refer to often is The Elements of Style (William Strunk and E.B. White). When your client reads a document that you wrote they will have one of two thoughts, and it will be either good or bad – a document is rarely thought of as middle-of-the-road, and why take that chance anyway? This is your time to shine, so you might as well put everything into it and wow them.

10) Sometimes “Good Enough” is “Perfect”

Thuswaldner 112817 10Up until now, we have talked about being better at what we do as business analysts. We have talked about talking less and listening more, remembering people’s names, being humble and not seeking validation all the time, greeting people in the morning (when all we really want is to be left alone with our emails and our coffee), working with grumpy people, writing awesome documents, and so on. But sometimes, it’s ok to take a break from this drive to be the perfect business analyst and be satisfied with who we are. The suggestion is not to revert to sloppiness, but rather to strike a balance between what is desirable and what is achievable. The perfect document, for example, that is never shared is far less helpful than one that is 80% quality, since the extra 20% may not be worth the time required to achieve it.

Conclusion

We all want to survive in the office environment. But most of us want more than to just survive – we want to thrive. We want to feel good about the work that we do and we want to have good working relationships with our colleagues, and in order to do that we need to recognize that human relationships are just as important as technical know-how. By implementing any or all of these survival techniques, you will see positive changes in the quality of your deliverables and how you work with the people around you.

Data Requirements – Should the Business Analyst Care?

I was once told by the director of an IT branch of a federal government department not to concern myself with the data requirements of an in-house information system project and to focus only on the business requirements. The system should have taken about six to eight months to deliver, but it took more than two years and few people were happy with the end result.

Should business analysts care about the data requirements? You bet! Unfortunately, business analysts spend much more time analyzing business processes than they do analyzing business information. This often leads to requirements that only tell half the story. When it comes to building information systems, understanding the data is no less important than understanding the processes. In this new world of fiscal restraint, few organizations can afford to build a system more than once. There is a way to ensure that the requirements that are captured represent a more complete picture of what is needed (and only what is needed), to deliver maximum value, and to get it right the first time.

What about the Data?

As business analysts, we are experts at getting to the root of the problem or the opportunity at hand, and we have many techniques to do so. The techniques that we use are dependent on a variety of factors, including the business environment, the preferences of the stakeholders, the availability of the subject-matter experts, accessibility of systems and related documentation, and so on. When we develop business process models, we often model the current “as-is” and the target “to-be” business processes. Use cases, data flow diagrams, functional decompositions, sequence diagrams, and state diagrams are just a few of the techniques available. When it comes to modeling business processes, we have a full arsenal of techniques in our toolkit, yet the notion of documenting information is often put aside.

Business analysts sometimes forget or ignore the data requirements. This may be because they think it isn’t their job, or that someone else will take care of it. Or it may be that they are intimidated by some of those diagrams they see with all those boxes and lines going every which way. But regardless of why data requirements are not documented or understood, if you’re part of a team that is building an information system, and you’re documenting business processes without any notion of the data, then you’re only doing half of your job.

Why I should care?

There are all sorts of benefits in understanding data requirements. When the business analyst has an understanding of the business processes and the data, there is a great opportunity to cross-check both areas. For example, if there is a business process that uses (or produces) no data, the chances are it isn’t a business process. Similarly, if there is a data element in a data model that is not used by any business process, there may be a missing business process, or the data element is not in the scope of the system. Either way, this knowledge can be used to ensure that the business processes are complete and that all of the data requirements have been captured.

Many of the questions that business analysts ask subject-matter experts and stakeholders that pertain to business functions and activities invariably involve business information. This is the best time for the business analyst to get a sense about what information is important to the stakeholders. There are four key techniques that I use to document data requirements. The technique you choose will depend on the business environment, the amount of time and money and the preferences of the stakeholders and subject-matter experts.

Data Requirements Techniques

Data Modeling

A data model is one of the more powerful tools used to capture information requirements. It is powerful because every data element can be thoroughly documented, including its data type, field length, and its relationship with the other data elements. As previously mentioned, the data model is an excellent means to validate the completeness of the business process model. Another aspect of data modeling that makes it powerful is that once it has been established and validated by the subject-matter experts, it is possible for the business analyst to work with a database administrator to forward-engineer the model into a physical database, especially if the model has been designed using a data modeling tool.

Data modeling takes practise, and unless you have experience with this technique it may be necessary to take a training course and work with an experienced colleague or a mentor who can help you learn.

Data Dictionary

The data dictionary is a necessary part of the data model, but it is possible to develop a data dictionary independently. A data dictionary is a written description of the data elements of a system that describes the entities, the attributes of each entity, and the relationships of the entities with each other. No significant training is required to develop a data dictionary, but it is not a trivial exercise and it will require persistence to complete.

Validating the data dictionary can be challenging since the business analyst will often be faced with disagreements amongst the stakeholders about the definitions. Reconciling these differences early in the project lifecycle is imperative, and ignoring them can be catastrophic.

Report Analysis and Prototyping

Another way the business analyst can describe data requirements is to develop a series of report mock-ups. The assumption is that all of the data that goes into the system comes out, in one form or another, in a report. After all, if the data is not going to appear in a report, why put it in a database at all? In theory, once the business analyst has a set of report mock-ups that have been validated by the subject-matter experts, every data element should be accounted for.

Usually the business analyst will not have to produce the report mock-ups from scratch because there will already be reports that the organization uses. There may be new or different reports that will lead to additional data requirements, and there may be changes to some of the existing reports. This is one of the more straightforward techniques to develop data requirements, and one that does not require significant training.

Reverse-Engineering

Many information system delivery projects focus on commercial off-the-shelf solutions (COTS) because the majority of organizations recognise the risk and expense of developing custom solutions. When deploying a COTS solution, organizations that do not do their homework in terms of defining their business process and data requirements, quite simply, risk complete failure. It is not enough to trust the vendor, because at the end of the day you will either know exactly what you bought, or you will soon find out.

The reverse-engineering technique involves acquiring a trial version of the COTS solution in question and copying the software’s database into a data modeling tool to create a physical database schema. The schema is then compared with the data model representing the organization’s data requirements. An analysis of the differences between the two will identify the areas where decisions will have to be made. For example, if the solution doesn’t support certain data requirements, then the organization will have to decide if it can live without it, or implement a manual work-around, or determine if the solution can be customized. There are a host of reasons why it not always feasible to reverse-engineer a vendor’s database, and even if it is possible there is some technical know-how required.

Yes You Can!

You do not have to be a data modeling expert to capture data requirements. You only need to be curious, have a willingness to try something new, and be willing to work with other IT professionals who may know something that you don’t. This is an opportunity to step outside of your comfort zone and venture into in an area which is business analysis but unknown to more than a few business analysts.

Don’t forget to leave your comments below.