Tag: Best Practices

UAT Tips and Templates

Written by Abubakar Munawar on August 2, 2011. Posted in Articles. 74 Comments on UAT Tips and Templates

What is UAT?

User Acceptance Test, or UAT or Acceptance Testing, all defines the single meaning.

According to The International Institute of Business Analysis – Body of Knowledge V2.0, User Acceptance Test or UAT is defined as “Test cases that users employ to judge whether the delivered system is acceptable. Each acceptance test describes a set of system inputs and expected results.“

User acceptance test refers to the satisfactory test of solution by users before moving the solution to LIVE Environment. In UAT, users of the software validate the maximum possible scenarios that may come in LIVE environment, which are tested in the solution and found to be accurate.

If UAT is about testing the solution, then a question comes to mind: “What do Quality Assurance departments do at their end when they say they are testing the application?” For that I would simply say, there is a 360-degree difference in both types of testing, and the biggest difference is the goal/objective of both.

The goal of software testing is “to make sure the software meets the specification” or “to make sure that the developed software is bug free.“

Whereas the goal of User Acceptance Testing is “to make sure that system completely supports the day-to-day business scenarios along with other known possible scenarios that may create a hurdle in business operations, and to make sure that software will not hurt the LIVE operation when it will be running in a LIVE environment.“

UAT is considered a final stage of any software development initiative. Without successfully completing the UAT, the project cannot be considered as completed nor does any client accept.

{loadmodule mod_custom,ad 300×100 Large mobile}

The Myth:

While discussing the project issues with different colleagues, friends, community members and others, I have found that many Business Analysts try to implement the system directly in a LIVE environment, i.e., user starts entering LIVE entries and when all entries are entered and reports are matched, the system is considered as implemented and signed off.

Exceptional/abnormal scenarios are part of routine business, and they are also very hard to recall/identify. In the earlier-mentioned situation, when the user was focused on testing the system based on LIVE entries only, he definitely loses the focus on those abnormalities that arise usually in his business transactions. Further, there might be some special cases that were handled in some other way by the users; those cases will also be missed in testing based on LIVE data. All of these abnormalities, special cases and others issues will come someday in the LIVE environment when the user will be using the software, which will be the time the user will say, “I used to solve this case by pressing that button in legacy system” or “I did this case by doing this, this and this,” and the vendor will ask for Change Request and two things will be charged (money and time), and due to time the business may suffer.

Consider the other scenario in which the user took his time with the business analyst and identified the maximum possible scenarios including normal/routine business transactions along with any abnormality or exceptional scenarios. And when the system is ready, users test all those scenarios in the system and after successful completion of testing, the system goes LIVE. This will minimize the chances of abnormality or exceptional cases in the LIVE environment.

Conducting UAT is equally important for both Vendor (Software Developer) and the Client (Software User). Thousands of reasons can be written on the importance and impact of not doing UAT; following, are some very important reasons for which UAT should be done in every project.

Reduce chances of error in LIVE Environment: Maximum possible scenarios are identified and tested before software moved to LIVE environment

Increase User Satisfaction: UAT provides full-fledge access of software to user, which gives him a lot of confidence as well as satisfaction to allow him to test the software that soon he will be using in a LIVE environment

Reduce risk of regulatory & other compliance: As in UAT, the system is tested on maximum business scenarios; the risk of regulatory and other compliances that may bring penalties in term of financial impact, opportunity loss or customer dissatisfaction can be minimized.

Reduce Time: In new/automated system, there is a chance that the system has automated some business processes along with some changes in existing processes, which might have increased some process steps found to be unnecessary or wasting time in the LIVE environment, UAT allows users to identify those unnecessary steps before going into the LIVE environment, it allows organizations to save time by reducing process steps that may take time in the LIVE environment and incur extra costs.

Business reputation: If due to software solution, organization is unable to provide the services to its customer or provide the services with delay or somehow impact customer by giving wrong figures or showing wrong transaction in customer’s account, this may blow the business reputation and definitely results in customer dissatisfaction, and with this, the company may lose a good amount of business that was successfully in hand having the legacy system in place.

Role of Business Analyst in UAT

Business Analyst as a neutral, non-technical, business side representative makes a good UAT conductor. Due to his focus of solving business problems, independent from developer and not having a technical mind, he can easily think in the shoes of the customer to identify the normal as well as complex, uncertain and abnormal scenarios along with real like data and help users in testing the same before going into the LIVE environment. And finally, the Business Analyst has a vested interest of high-quality software along with the solution of the business problem with value addition and so is motivated to perform rigorous testing of the system.

Skills Requirement of Business Analyst for UAT

As mentioned earlier, UAT is the last and final stage after which the system will go LIVE, and therefore, the crust of this activity is to make sure that maximum scenarios are tested in the system and if issues are found they are reported accordingly. Due to the criticality and importance of the UAT phase, the role of the UAT conductor requires multi-faceted skills. These qualities allow the person playing that role to perform this important activity; the business analyst must think in the shoes of the user to understand his problem. Absence of these skills may fail the overall UAT phase.

Further, following skills and competencies are required to be possessed by the Business Analyst to conduct effective/successful UAT:

People Handling: Business Analyst that holds good skills of people handling and can develop a good relationship with users in order to explain his point of view, and that skill also helps business analysts to understand the point of view of users. In UAT, users sometimes try to resist change or try to imply his point, but having a good relationship with the business analyst, the issue of ego doesn’t come between and things get concluded in a positive direction.

Domain Knowledge: As quoted in every business analysis-related article, “Domain Knowledge is mandatory for Business Analyst.” Off-course[G1] , if a business analyst lacks the domain knowledge, he will not be able to conduct the successful UAT. Due to his limitation in business knowledge, he will not be able to identify the business scenarios, nor can he help the user in identification of the same, and also will not be able to question the wrong scenarios or wrong practices that the user requires to be added as scenario in the software.

Software Functional Knowledge: You must have heard a business analyst saying, “I need to talk to my technical team to get the idea how this screen will work?” Consider the confidence level of the user on the business analyst and software when a person who is facing him is telling him how to do UAT? Don’t know about his own solution.[G2] Business analysts must understand the inside out of the whole solution; I would say, “He should be the person who has maximum knowledge of software working.” With this skill set, he can conduct efficient UAT, as the issue of stuck due to software functionality.

Executor, Initiator: Business analysts should have the skills of execution; he should have the ability to drive the users according to the UAT Plan and in case of any issues related to user availability, system errors, other resource availability, any other showstoppers or issues of progress, he should escalate it to the right person immediately without wasting time. Business analysts should observe the situation and inform the relevant stakeholder in case he senses some risk or issue that is arising.

Positive Attitude: Business analysts should always maintain a positive attitude and consider the comments of users as areas of improvement and act accordingly rather than start being defensive or sometimes offensive about it. He should understand the user’s point of view and in case the user is of a different mindset, try to convince him positively with rationals[G3] and arguments to support his opinion.

Common UAT Problems Faced by Business Analysts in UAT

1. User Availability: Issue # 1 of any UAT, even if users are marked as fulltime user to the project, still they will not be able to give you required time, due to their involvement in day-to-day operations. As most of the time organizations find it difficult to execute the full-time strategy, because the user assigned to automation project are usually more skillful than others in their department, and assigning them to the project for fulltime impacts the day-to-day operations of the organization, and if the organization is ready to do so, it will require their users’ interactions, which again impacts the user availability for UAT. Therefore, business analysts should maintain the record of user availability and escalate if user is not available as required for UAT.

2. Detail-Oriented Personality: There are some users who have a very detail-oriented personality or, in order words, they are perfectionists. These users are very hard to handle due to their expectations and requirements; they always want everything completed precisely and in detail. And their focus on detail drives them to the complex scenarios that a business has never faced before and might not face in the future as well, but they insist on testing those scenarios or handling of those scenarios in the software. That type of personality eats your UAT time like a grasshopper eats the grass. And as they are perfectionists, it is usually hard to explain your point of view to them and they also sometimes face problems in understanding the point-of-view of others, which moves the UAT phase into a never-ending cycle. But the important point that should be highlighted here is that this type of personality is problematic in UAT but can be good utilized in the requirement phase due to their detailed understanding of the business process.

3. Overlooking Personality: In UAT, you may face a personality that is easygoing and will not put required efforts on details of the system and its testing. This is the personality that will tell business analysts that “Everything is fine, all is good.” That type of personality focuses on getting things done with simplicity; they sometimes do it because they don’t know about the pain they will be facing if UAT is not done effectively. That type of personality is very high risk for UAT as the chances of overlooking functionalities are too high, and Business Analysts should identify that personality and handle it by going into every detail and letting that user think that BAs want him to go in detail along with escalating the issue to the right level if required.

4. Issue Log Management & Prioritization: In UAT, many issues are identified, and if they are not logged and prioritized at right time, the whole UAT exercise will go wasted. While doing UAT sessions, the user identifies many issues related to application, and there could be a lot of issue types, some of which could be “GUI Related, Logical Observation, Application Bug, Business Not Mapped” etc. The bigger software has a greater type of issues along with their number as well. As a BA, you should follow a good mechanism of logging and managing the process of issues. Every issue reported should be logged-in in enough detail to be understandable by the user and technical TEAM both, as those issues will finally be reported to the technical TEAM for resolution. BAs should also consider scoping at this level, because there might be some issues that were not in initial scope due to “requirement not discussed” or some other reason. Those issues should be reported in log but BAs should identify them as “Out of Scope” and set the expectation of the user that this will not be handled in the current release of the software.

5. Understanding of Requirements: It has been observed that Business Analysts who are conducting UAT with user and were part of the initial requirement phase (Software Requirement Specifications Phase) were able to conduct the UAT more effectively than the business analysts who are assigned directly to UAT without their involvement in SRS Phase. This is due to the understanding of requirements, as if the BA is involved in the initial requirement phase he would have better and a detailed idea of what the specific requirement is all about, and if he is not, he might have his own point of view in place for specific requirements that create hassle for the user who is doing the UAT. Therefore, the recommendation is the BA who is doing UAT should be part of the initial requirement phase, and if he was not, he should go through each requirement in enough detail to understand the different aspects of requirement and its implications.

6. Complex/Demotivating/Offensive Personality: In projects, you face different types of personalities, and all of them impact the project in different ways at different stages. You might have seen some personality in your projects who used to say, “This project is not going to work,” “This project is Pandora’s box,” or my favorite, “We are playing GIGO (Garbage In Garbage Out).” Complex, demotivating or offensive personalities exist in projects and BAs cannot afford to avoid them. Good BAs should understand how to work with those personalities And how to get maximum out of them without going into never-ending arguments. These types of personalities are not very hard to handle and Business Analysts can handle them by maintaining his positive attitude, good relationships with individuals and good arguments to support his decision every time. And if things get uncontrollable, then BAs should know when and to whom the matters should be escalated.

Tasks performed by Business Analysts in UAT Phase

While doing UAT, business analysts perform different tasks based on the type of projects, duration and organization standards. The following tasks are generic to be followed in every UAT:

Solution Validation: Validate that solution meets the Business Requirements
Verify the Organization Readiness: BA should make sure that the end user is ready to use the software, by checking that the required resources along with relevant tools and trainings are delivered
Identification & Validation of Scenarios: BA should identify scenarios that will be tested in UAT Phase and get those scenarios validated from end user
Create Training Plan: BA should publish the training plan to engage the required resources
Create UAT Plan: BA should publish the UAT plan so that required resources can be arranged
Conduct the training of software: BA should allow user to do hands-on UAT by providing training of software, so that user satisfaction can be achieved
Conduct UAT: UAT should be conducted keeping in mind the objective of UAT, which is to “make sure that system fulfills the day-to-day transaction of business along with any other known exceptions”
Record the Results: UAT can only be effective if issues are logged religiously
UAT Feedback: BA should from time to time confirm from user that solution fulfills the business needs as anticipated by user and update the feedback to related stakeholders
Conduct UAT Signoff (Approval to GO LIVE)

Documentation created by Business Analyst in UAT

There could be different sets of documentation a Business Analyst does in UAT. The type and level of documentation is totally based on the methodology of the overall project, type of project and organization standards. E.g., By following the Water Fall, methodology in overall projects the level of formality in BA documentation becomes high and the number of documents increased, whereas in Agile there are low numbers of documents due to the low level of formality.

Following documents has been found to be useful for Business Analysts in the UAT phase; for better understanding, the list of documents is divided into sub-phases of UAT:

UAT Planning

for UAT (Must Have Document) & Business Scenarios Download Template 1 Template 2
Business Process Flows to make sure that user is doing the right things (Must Have Document) Download Template
Application Process Flows to map the business process on application to support user in identifying the relevant screen for each business process step (Must Have Document) Download Template
Deployment Things To do to make sure setup/primary data is ready with user before initiating the UAT along with any other resources (users, trainings, machines, etc.) that are required for UAT Download Template
Deployment Slip on successful deployment of application on client premises Download Template
Training Plan to schedule the resources required to provide software training to users (Must Have Document) Download Template
Training Script: This document is to prepare BA for the training and UAT session, in which BA identifies what screens he will be training and by entering what data and how?
UAT Plan to schedule the resources required to conduct UAT (Must Have Document) Download Template

UAT Execution

Training Signoff: User has accepted that training is done (high formality) Download Template
UAT Issue Log: Should be maintained at any cost and shared with all stakeholders (Must Have Document) Download Template
Daily UAT Summary to inform all stakeholders about the daily progress of UAT (Must Have Document) Download Template

UAT Closure

UAT Signoff is authorization from user to GO LIVE Download Template
Customer Testimonial

Don’t forget to leave your comments below.

Abubakar Munawar, is a Trainer, Mentor and Consultant for Business Analysis, Process Improvement & Reengineering. He is a Business Graduate with over ten years of experience in Business Analysis, Software Designing, Development, Quality Assurance, Implementation Project and Product Management. He is working in Lucky Cement Limited as a Deputy Manager Information Technology and earlier he was a Project Manager & Lead Business Analyst with Plexus Private Limited for Investments Applications Division. He has conducted many corporate training programs for in-service personnel of large organizations in Pakistan.

History Repeats Itself, But It Doesn’t Have To!

Written by Paula Bell on July 25, 2011. Posted in Articles. 1 Comment on History Repeats Itself, But It Doesn’t Have To!

Why does it take an ‘Act of Congress’ for some organizations to realize that what they are doing is not working? I have been in many industries (media, manufacturing, financial and the judicial system) and no matter what industry I’ve been in, I’ve seen some of the same themes. I’ve come to realize that common sense is not that common and some organizations would prefer, for whatever reason, to continue to do things the same way even though it has been proven that the current way DOES NOT work. So you may ask, “What are some of the common themes that I’ve seen?” Well, I’m here to tell you and I’m sure some of you are experiencing, or have experienced, the same thing. I am not pinpointing any industry over another.

No time for planning – What I have witnessed is that someone comes up with a great project idea; however, no one wants to spend the time needed to effectively plan the initiative and truly understand what the initiative is about. There is an expectation that the idea will go from an idea to a reality in an unrealistic timeline. Someone of influence in the organization has committed to an objective without consulting those that will have to bring this idea to fruition. Then when the project team advises that the timeline is unrealistic as they start to look more into what is being asked for, they are told to make it happen because the promise has already been made. In a lot of these cases, the amount of resources needed to complete the project effectively is under estimated, if even committed, and this means burnout for those few who will have to work on the project.
Choosing solutions before understanding the business needs – Let’s take this one step further. Most organizations have vendors that they have built relationships with over the years. What I have found is that “someone of influence” in the organization has a vested interest in maintaining a certain vendor relationship. This maintenance could be because they are the more cost-effective vendor (this doesn’t mean they have delivered projects successfully by any means), personal relationships that have been established over the years (you rub my back and I’ll rub yours sort of thing) or other reasons. This particular individual has been sold on an idea regarding some additional functionality that the organization can possibly use, conversations occur and the vendor makes commitments without truly understanding what is needed. This “someone of influence” sells how this particular vendor can solve all of the needs of the organization, and since this someone of influence has credibility, they are told to go forward with their suggestion. This project is then funneled down to the project team, who finds out the exact depth of what is being asked of the solution, people start having heart attacks, aneurisms and heart burn because it is determined the system won’t meet the business need. So instead of the requirements driving the solution, the solution is driving the requirements.
Politics – Politics to me equals personal agendas and ulterior motives. I have not come across an industry in which I worked yet that didn’t have some level of politics. We have projects that evolve and people have their stake in the projects, which is to be expected, and that is why we have stakeholders. However, that doesn’t mean bring in your own personal agendas or ulterior motives to bring unnecessary negative energy to the project. Half the time politics is a waste of time. Projects are hard enough so why complicate it with politics? It’s a waste of energy and that energy could be utilized positively to build better solutions opposed to fighting among ourselves and everyone getting so frustrated or focused on the politics that work can’t get done. There are realistic reasons to have hard conversations to build better solutions, but I’ve actually been in elicitation sessions where I have individuals intentionally throwing wrenches into the project process because they may feel they are not getting their way. I’ve seen people trying to save their job so they make things more complicated on the project than it really needs to be. I’ve also seen the business; project team and technology teams point fingers to ensure neither look bad in front of the sponsors. All of this is a waste of energy because no one knows the future, and believe it or not, maybe the way you present yourself in these meetings may save your job if you have a fear of losing it.
Lack of honesty and integrity – People are not stupid. If the project that is being executed is going to eliminate jobs, people tend to figure that out during the requirements elicitation phase. I have had SMEs admit to me that based on the requirements being gathered, they can tell that the system will replace their job. I’m by no means saying you shouldn’t be sensitive to the situation and handle the business partners with care, but I have been[G1] parts of organizations that just flat out lie to people to ensure they get what is needed for project success (because they have to look good of course) and then these same individuals are kicked to the curb as if they weren’t even valued when the project ends. This also puts those who are part of the project team in a bad and uncomfortable position.
Lack of learning – Every organization that I have been a part of has conducted a ‘lessons learned’ session after the entire project is complete or during project phases along the way. I am convinced that some of these organizations only conduct these to mark a task complete on the project schedule because nothing has changed from the way projects are run going forward.

Despite all of this, I do believe there is still hope and that business analysts are important to this hope. There are some steps we can take to mitigate what is listed above:

Plan upfront – Planning upfront is CRUCIAL to project success. This doesn’t matter if you are using a plan-driven approach (i.e., waterfall) or change-driven approach (i.e., agile); regardless, there needs to be some level of planning. Spend the time upfront to really understand what is needed opposed to doing little work and then realizing two months in that instead of a bread box of a project you have a submarine of a project. Utilize the business analysts in the organization to help with planning upfront. Good business analysts are equipped to do Enterprise Analysis (higher-level statements of the goals, objectives or needs of the enterprise) in addition to Requirements Analysis (statements of the needs of a particular stakeholder or class of stakeholders). Engage the business analyst upfront to have some of those critical conversations opposed to just filling out a template with a high-level scope that is so broad that almost anything can go into it producing your submarine opposed to your bread box.
Don’t jump the gun –- Opposed to choosing solutions due to past relationships or other reasons, again, leverage the business analyst to understand the true business need so the needs drive the solution opposed to the solution driving the requirements, which in turn limits the true needs of the business. I would strongly recommend that leaders of the organization go out onto the floor and meet with those that actually do the work to find out the true pain points they encounter day in and day out. Just because you are a leader, don’t get too disengaged from what is going on within your organization. I know this can be as challenging as schedules, but there is value in staying connected with those who are actually doing the work. If anyone understands the pain of the system or process, it’s the one using the actual system or process, so don’t take that for granted. This is also a great opportunity to leverage the business analyst as well. Maybe have the business analyst do some job shadowing as part of their planning to understand truly what the needs are. This will help leaders make more informed decisions.
Channel positive energy – Let’s take energy away from politics and channel that energy to producing better solutions. There are crucial conversations that may need to take place and hard conversations to be had, but those conversations should occur for the benefit of the project not because of someone’s ulterior motives and personal agendas. When a project is created, the end goal of everyone on the project team should be project success.
Don’t compromise – Character is the very fabric of who we are, and if we lose our character because of dishonesty or lack of integrity then how are we going to gain that credibility needed to become a person of influence, if you are not one yet, or a credible leader to those you lead? Be sensitive to projects that are eliminating jobs as you are impacting someone’s life, but don’t lose your credibility in the process. Fellow business analysts don’t fall into the trap of having to lie to do your job. In all things, be honest and kind. Don’t compromise your character to get your job done because sometimes we are put in that position. Once you compromise that you are compromising the business analysis profession based on perception.[G2]
Learn from your past – If you are going to do lessons learned then truly learn from them. If anything, to my fellow business analysts, learn what went well and what didn’t go well in requirements gathering and use that as your thermometer for other projects. Everyone on the project team should learn from the past, but if no one else does, business analysts I really encourage you to learn from your mistakes because this makes you a stronger business analyst.

With the themes above, someone of influence is driving the actual theme whether positive or negative. As business analysts, it is imperative we become someone of influence in our organization. This is not going to happen without credibility and proven success on projects, and I will be honest, even with this, sometimes it’s hard to influence due to company structure. However, if you take time to learn your organization’s culture, learn the key players in your organization, establish relationships where you can to start gaining credibility, you will become that someone of influence in the organization. We need more business analysts to be leaders and people of influence in the organization because we have the skill set to promote organizational cultural shifts that will make the organization stronger and better. Changing an organization’s culture can be extremely difficult; look at organizations that had to change from a waterfall methodology to an iterative methodology and the pain that came with that.

And for those business analysts that are consultants/contractors, you have a very important role as well because you can help organizations reach their optimal potential. Though you may be there for a temporary amount of time, you can still have massive impact on the organization as a whole.

Don’t let history repeat itself in your organization because it doesn’t have to. As business analysts, we have come too far to go backwards now. Keep pushing forward and help organizations realize the benefits business analysts bring to the organization.

Don’t forget to leave your comments below.

Paula Bell is a Business Analyst, mentor and coach known for consistently producing exceptional work, providing guidance to aspiring business analysts (including those that just want to sharpen their skills), as well as providing creative and strategic ways to build relationships for successful projects. With 14 years in project roles to include business analyst, requirements manager, technical writer, project manager, developer, test lead and implementation lead, Paula has experience in a variety of industries including media, courts, carpet manufacturing, banking and mortgage. Paula has had the opportunity to speak on a variety of topics to include business analysis, project management, relationship building, diversity and software methodology.

Business Analyst Says: Let’s Pretend We’re Secret Agents

Written by Teri McIntyre on July 18, 2011. Posted in Articles. 1 Comment on Business Analyst Says: Let’s Pretend We’re Secret Agents

“Please don’t call me by my real name, it destroys the reality I’m trying to create.”

–Wallace Ritchie, “The Man Who Knew Too Little”

Back in 2009, I presented at an education conference that had as its theme “CIA — The Not So Secret Service.” All presenters were to incorporate a spy story or approach within their presentations to support the theme. My topic — an introduction to business process mapping — was by request so I welcomed a little extra inspiration to heighten my own interest.

While most people went the route of James Bond or Jason Bourne or the like, I was drawn to a favorite, little-known 1997 movie “The Man Who Knew Too Little.” In this movie, the lead character, Wallace Ritchie (played by Bill Murray), flies to England to spend his birthday with his brother James. James, however, has a business engagement is not too keen to have his brother involved with it. Instead, he signs Wallace up to participate in the “Theatre of Life,” a role-playing exercise that promises to treat the participant as a character in a crime drama.

Things go off the rails early when Wallace answers a phone call intended for a hit man, and he is mistaken for a real spy. Wallace becomes tangled up in a plot to kill Russian and British dignitaries on the eve of the signing of an important peace agreement between the nations. For Wallace it’s all an elaborate act; to the men who want a second World Cold War, Wallace is public enemy number one.

While I found the film entertaining, I also found it informative in respect to how I conceive of my business analyst dealings. I often feel like a secret agent when embarking on a new project or rather a new stage within the “Theatre of Life.” Walking onto a new stage means coming into contact with a new configuration of players, some of whom have been patrons of that particular theatre for many, many, many years. It means entering an evolving story, one that has characters entering and exiting stage left and right, up, down and center. It is our challenge as business analysts to infiltrate this story, flush out the secrets and motivations of the characters, survey the stage for dangers and allies, and ultimately fulfill our mission.

In a nutshell, we are secret agents.

Literature and cinema have schooled us well that all secret agents are governed by two sets of rules of engagement: those laid out by the boss and those learned on the job. I recently re-watched this movie and found myself yet again inspired by its entertaining and informative applications to my business analyst career. So I decided to start sketching out some of the various rules of engagement I have learned thus far on my secret agent missions. Presented here is a sampling of these rules, as identified in collaboration with this particular movie.

Play the role that fits the situation

There is no law that a business analyst must play the same role in every situation. Thank goodness! One key characteristic that separates good business analysts from great ones is the ability to assess a situation and take on the role required. You are always ‘you,’ but sometimes a little play-acting is necessary to get done what needs to get done.

Wallace: You’ve got a great accent, are you from here?

Wear the appropriate uniform

Pretty simple rule — match your attire to the role and to the situation. If you are working in an environment that is t-shirts and jeans, don’t show up in a suit and tie. And vice versa. You are revealing your status as a secret agent otherwise! Respect the situation and it will respect you.

Lori: Do you think I look silly in this outfit? I could take it off if you like.

Always carry the right tools

You need a solid set of tools for whenever you enter a new stage. Be selective with what you choose to put in your toolbox; you can always pick up other items along the way. I always have a white board pen, a little squeezeable toy and a rotation of three favorite necklaces. These items become my indispensible project assets. The pen lets me draw/write things down almost everywhere (all you need is a glass surface), the toy helps me alleviate frustration and the necklaces, well, just make me feel good.

Wallace: Conveniently found a mallet outside but I’m gonna swap it for this one, ok?

Never give up on you

Being a business analyst is hard, dirty, exhausting work. Don’t try to tell me anything different; I know of what I speak. Expect some bruises, some scarring on your missions. But don’t just give up when things get tough. Giving up on yourself is to allow external forces to become more powerful than your own will. Draw on your strengths even more readily to push through the negative, and remain confident that you can achieve success no matter the obstacles being faced.

Wallace: Hang on Bill, clench your buttocks.

Stand by your principles

Adapt to the situation but do not adopt it. Be authentic. Do what is right and not what you are told is right. Comprising your principles is akin to sacrificing your arm. You risk the quality level of your produced work and of not being seen as standing for anything.

Wallace: And I want a stairmaster, I want a juice master, I want a thigh master, and I want a butt master. And if you can’t give it to me, then I’m going back to Des Moines.

Don’t get boxed in

Believe it or not, you are paid to be creative, to think outside the box, to even blow up the box if need be! Being analytical does not mean following every prescribed rule or template out there. It means learning from these entities and assessing how best to apply them to the box so that you can do your absolute best. There may not be an ideal solution for any given situation; you need to be innovative and individualistic and creative enough to when/where/how to deploy your skills to the greatest effect.

Wallace: It’s for allergies — actually, it’s a powerful agent that sharpens my senses, yet deadens my emotions.

Know what works

Textbooks, training courses, templates, etc., are great starting points when embarking on a new mission, but that is all they are: starting points. Don’t be brainwashed into believing that there is a single right way of doing anything or that the same approach is applicable to every situation. Wrong! Learn the methodology and methods but always assess each unique situation to determine what will work and won’t work.

Wallace: They pay all your expenses, you’re licensed to kill, but there’s a downside. Torture.

Take the shot

You will encounter people who throw roadblocks your way occasionally; accept this. But if the roadblocks are not constructive or serve to satisfy individual agendas or hamper your work in any way, be direct as to the potential damage the blocks may be inflicting on the project. Be as polite as possible, but don’t be afraid to exercise some strategic confrontation in order to set up the tactical shots.

Wallace: Yo matey, you just stabbed me with your pen.

Question those in charge

In theory, a business analyst needs to question everyone and everything. What often happens though is that access to the higher end of reporting channels is blocked from your reach. Don’t accept this if you know or even suspect that the answers you seek are behind that block. You need to get at agendas and biases earlier rather than later. Continuously seek more answers for your questions rather than settle for the ones received.

Wallace: Time out. Uh, I hate to break out of character, but, you cannot shout into a person’s ear. It does damage. The spitting I don’t mind…

Team does so have an “I”

Yes, yes it does. Being on a team does not negate your individuality, nor does expressing your individuality within a team equate to being an egoist. You still need to look after you; it is just that now you need to figure out a way to translate that need constructively into the team narrative. You have uniqueness, a distinctiveness that should not be stripped or hidden away in the name of achieving a false ideal of what it means to be part of a “team.” It should be privileged, maybe even exploited a little.

Wallace: Well what about our story? Are we just a doomed couple, do we have to be Bonnie and Clyde? Can it be like The Getaway, couldn’t it be like that?

Have a signature drink

Or dessert. I much prefer the idea of a signature dessert.

Now your turn: what secret agent rules have you discovered through your missions?

Don’t forget to leave your comments below.

Teri A McIntyre, MA, CBAP, is a principal at Charann Consulting, providing business analysis and project management services to public and private industry. She is a Libra/Tiger, which scares and pleases her and her clients simultaneously. She adores analytical work and getting in front of the clients but rebels against putting a pre-conceived box around how such activities should be completed. Personal philosophy: “Why should a painter paint if he is not transformed by his own painting? – Michel Foucault

A Dressing Down for Business Analysts

Written by Robin Grace on July 11, 2011. Posted in Articles.

BA: “They didn’t participate in my workshop. Again.”

Mentor: “You must be mortified.”

BA: “Seriously, they come up with these lame excuses: they don’t understand that computer stuff, they’re too busy, or they think it’s a waste of time. One even told me to just get it done and let him have a look when I’m finished. How must I fathom the requirements myself? And they call that idiot a professional.”

Mentor: “You sound like a stuck record. Every other week you stomp in here ranting about the users, the stakeholders, the so-called professionals who waste your time. You always blame everybody else.”

BA: “So now it’s my fault?”

Mentor: “When I was a green analyst I had the same problem. You know what I did?”

BA: “Hired Chuck Norris?”

Mentor: “I went back to basics – I started planning properly.”

BA: “Planning? First it’s my fault and now I did not plan! Well I did plan. I planned for all those morons to attendmy meeting this morning – I even bought muffins, for goodness’ sake – and none of them arrived. By the way – you want a muffin?”

Music to a BA’s ears

If I had 100 dollars for every time I heard a BA complain about the stakeholders not participating in their meetings I would have – and I am not making this up – exactly 87 bazillion dollars and 50 cents. The big problem with people not participating in your meetings is that by the time you see a room full of empty seats it’s too late. The damage is done. You see, getting stakeholders to your meetings starts long before you even call a meeting.

In fact, it begins with a classic film: “The Sound of Music”. “When you read you begin with A, B, C. When you sing you begin with Do-Re-Mi.” And then you have the lines, “Doe, a deer, a female deer,” and so on. The point is that you begin at the beginning and the beginning of any BA project is planning.

So, as my fictitious friend asked earlier: What does planning have to do with putting people in the seats? For starters most BAs I come across don’t do enough, if any, planning, yet the Business Analyst Body of Knowledge (BABOK) clearly has an entire chapter devoted to it – Chapter 2 to be precise. Some of you may argue that you do plan. You create lists of stakeholders, you assign roles and responsibilities. But, on closer inspection, most BAs think that copying and pasting a list of stakeholders from some other project is a substitute for planning. It isn’t. There is no way around it. If you copied and pasted then you did not plan.

The list is important because it is the very first step the BA, that’s you, takes in understanding who does what, when, how, where and why. And if you don’t know that then you cannot convey any sense of understanding, relevance, or importance to the stakeholders. And without those only the soft-hearted will attend your meetings.

The BA communications plan describes how we will communicate with the stakeholders. Any stakeholders on the list that have an RACI “C” next to their name must become part of the elicitation process. Most often we will “C”onsult with them in a requirements workshop. We have to inform them of when we would like to “C”onsult with them and exactly what we will need from them.

It all makes perfectly good sense because you are ensuring that the right people are involved and that they know what is expected of them. The next thing you do is get their consent, their approval, because that leads to buy-in. You’ll need them to agree to what must be done, when it must be done, and who must perform each activity to gather all the requirements. There is also an implied contract that the BA needs those people to do their work for the sponsor and, if they don’t pitch, they are wasting the sponsor’s money. One way of getting that message across is through the content of the invitation to the workshop. Suggest that the participant’s involvement is crucial to the success of the project and that the sponsor is aware of this. If the sponsor has any organizational clout, it’s the added incentive stakeholders need to be there and be on time. In other words: wag the big stick.

The BA and the Paperwork

What you’ve done by ensuring only the right people attend the meeting is that nobody’s time is wasted. You don’t have people sitting around wondering why they never said a thing, never contributed to the proceedings. That quickly annoys people, particularly the busy ones These same people are the oneswho are important to the project at some point, if not right then. Having only the right people at meetings also makes the meetings move along more swiftly. Shorter meetings leave people more inclined to attend future sessions. More focused meetings with only the necessary people in attendance, also finish more quickly because everyone is driving to the same clear goal. So where do you find the required participants? You go back to your stakeholder list and communications plan, which should identify who should be present for the process under scrutiny and it’ll be correct because you didn’t just copy and paste.

The next item on your busy agenda is language. Imagine the conversation at the beginning of this story being between a BA speaking Russian and the mentor speaking Cantonese. They’re probably going to get things a little muddled and may even end up becoming frustrated with each other. By the same token you need to speak the language your stakeholders understand. If every other word you use is jargon that only BAs understand, then your stakeholders will quickly get bored and start imagining the fantastic little getaway they’ve arranged for the weekend..

Context is king. Put the meeting in the context of your stakeholders so that they can understand the reasons why they are there in the first place: “I know you have customers and they place orders; tell me more about what you do when you receive a customer order.” It focuses the workshop immediately, the participants feel you understand what they do, and it shows you value their time enough to have done some groundwork.

If you do all of these suggestions, through careful up-front planning to obtain a focused, contextualised outcome, then stakeholders will quickly feel appreciated and relevant and possibly even enthusiastic about your meetings. OK, maybe not always enthusiastic. But you will be able to imagine a completely different conversation to the one that opened this story.

I always say: If you can show business real value in what you do, then business will start to really value you.

Don’t forget to leave your comments below.

The Role of the Implementation Consultant – 3 Things You Must Know!

Written by Remzil Kulkarni on July 5, 2011. Posted in Articles. 1 Comment on The Role of the Implementation Consultant – 3 Things You Must Know!

Congratulations! You’ve just won your first large client and you are being chosen to play the role of the Lead Implementation Consultant for the engagement. You are being chosen because you are, at your core, an excellent BA and have a very high level of expertise about the product or solution that has just been sold. You will now be the one chiefly responsible for understanding the client’s requirements and , as far as possible, addressing gaps so that the solution or product that has been sold will meet your particular client’s needs.

While the role of an Implementation Consultant sounds (and in fact is) very exciting, there are few things you must know before you dive head long into the shoes of an Implementation Consultant. It is obvious that knowledge of business analysis is critical to succeed at this role. However, this article is not about the art or techniques of how effective business analysis is performed. There are far too many guides, models, and other bodies of knowledge that cover these essential tools.

What then are the other things any Implementation Consultant should be aware of? The things you should pay heed to and have a strategy for comes from a finer understanding of the role of the Implementation Consultant itself.

The Role of the Implementation Consultant

Typically, the Implementation Consultant is hired by the product or solution provider; and while they may consult with the client or customer for the duration of the Implementation, they most probably will return to their employer to be staffed on some other engagement once the current implementation consultancy is done. In terms of long term association and who is responsible for job security, the employer has the upper hand.

As a consultant to the client however, the Implementation Consultant needs to build strong and lasting relationships with the client. The Implementation Consultant will be one of the major representatives to the relationship the client will have with the provider. The key to any strong relationship is trust. Essentially, the Implementation Consultant has to perform his/her role by staying true to the client’s interests, and thereby build a relationship built on proven good faith and trust.

While this may sound relatively easy, it can be very tricky, meeting both your employer’s and customer’s goals and meanwhile doing what’s right for the role itself. However, by bearing in mind these important keys to the trade, you will find yourself far better equipped to perform effectively, rather than if these situations catch you off-guard.

Handling Conflict – The Implementation Solution Roadmap

While managing conflict sounds easy, most conflicts arise when what the customer truly wants would involve extensive changes which they believe cost relatively nothing. In return, the provider would like to propose alternatives that might meet certain parts of the requirement but probably wouldn’t agree to do exactly what the client wants or has requested.

In liaising between the two, the conflict often lies in whether the Implementation consultant should be true to his/her employer, recommending what they would prefer, or honoring the trust based relationship they have established with their customer.

However, the best way to handle conflict is to study the requirement and determine what’s best for that particular implementation, irrespective of what the customer says they want, or what the provider says they can (or are willing to) offer. This involves understanding true business value and clarifying these concepts into measurable processes or results.

For example, while the client may want a user interface for entering batch data (multiple rows), the customer might provide an interface to accept data one record at a time. The true solution to the requirement might not in the end be either what is requested or offered! The Implementation consultant should investigate the source of the data, the volumetric data involved, the business process and goal, and offer a solution based on these aspects of the requirement. For example, it is very likely that the implementation consultant might suggest an EDI file upload, which would bring immense value in terms of reducing data entry effort, face to face time with the system and increase the ability to perform a key function more quickly and easily.

Configuration Vs Customization

In terms of their responsibilities, the Implementation Consultant is in charge of understanding the client’s requirements and suggesting how best these requirements can be met by the proposed product or solution. While every proposed product and solution will have gaps, over-architecting the means to address gaps can be the biggest pit an Implementation Consultant can fall into.

In such situations, the goal of the Implementation consultant should be to address all gaps via “configuration” rather than “customization”. Configuration level changes are made to settings that do not require the code to be rewritten and the executables to be rebuilt. Customization, on the other hand involves changes to the code which are custom built or specific to this implementation.

Confining most changes to the Configuration realm will allow quick and effective changes to the product or solution rather than long drawn out changes which will require time, effort and money! This strategy also allows the client to get the best out of a ready to ship product or solution where their time to market is minimized.

Industry is recognizing the importance of this principle and it has resulted in the popularity of the widely hailed “SaaS” or Software as a Service model. Most organizations follow the 80-20 rule where gaps which can be addressed by customization up to 20% of scope is acceptable, beyond which it’s not advisable and would tend to reduce the benefits you get from a proposed product or solution.

Changing the Business Processes

Every product and solution will have a logical process that runs through the lifeline of the product. When a customer purchases a product or solution, most want to have the product or solution changed to match their business processes. In fact, most customers will realize value by changing the way they do things to match the inherent process present in the proposed product or solution.

While I’m by no mean suggesting a major change to a business model or making an existing business process ineffective, quite a few business processes in use in an organization have evolved as a result of the demands of the current infrastructure. A typical example of such a process would be how a particular department processes dividend payouts which would involve steps such as recording the dividend announcement, the dates and the rates, isolating the qualifying payees, calculating the amounts, clearing payments, reconciling differences and finally processing payments. The order that an organization performs these steps could very well be a dictate of how their current solution processes this task.

Rather than carry these types of processes forward to the new implementation, however, it is absolutely essential for the Implementation Consultant to explain what business process the proposed solution expects and encourage and drive change within the customer’s organization to suit it. While regulatory processes, for example, will not be subject to change, certain other processes such as the one detailed above should be redesigned based on how the new solution works.

In Summary

All said and done, the role of the Implementation consultant is tricky, complex and very influential. How well this role is played out can make all the difference between a successful implementation that is the canvas for a case study and one that turns out to be a disaster, retold for years to come about how things can go wrong.

Every Implementation Consultant has to play the base role of a Business Analyst over and above which they have to manage the direction of the implementation. Being aware of the 3 key aspects of implementations we’ve talked about will help guide your implementation down the right track, and ensure your customer gains the maximum benefit out of their investment in your solution.

Don’t forget to leave your comments below!

Remzil Kulkarni has over 15 years of experience in technology enabled business transformation focused on Insurance, Telecom and Finance. She has a Masters degree in Engineering Management from Southern Methodist University, Dallas TX and is President of the IIBA Pune Chapter. She is a certified Prince2^TM Practitioner and a Fellow of LOMA ( FLMI ). She currently heads the Business Analysis Centre of Excellence at Mastek Ltd., where she has worked for the last 5 years.