Tag: Best Practices

How To Squash The Template Zombie Problem

Sept6FEATUREWestern culture worships the massacre of zombies by the dozen in movies, books, and music. Wherever we encounter zombies, whether it’s in the garden shed, the attic, the mall, or even the local if your name’s Shaun, we are taught to mow them down with whatever’s at hand.

We have only recently discovered that there are different types of zombies, and one type has invaded your office: the template zombie. There isn’t any need to panic but there’s cause for mild alarm and you should kill them. But in the nicest possible way, by feeding them sweeties.

Template zombies are BAs who just fill in the template blanks. When they’re asked to assist on a project, they immediately reach for the templates they’ve been given, fill in all the blanks and then send them on to the developers. And, let’s face it, that’s a lot of documentation to wade through and we all know developers bin the bulk of it, use a small section to write the programs and everyone’s happy. Or are they?

Companies with a poor requirements discovery competency take 39% longer and spend 49% more to deliver their projects. Nearly 80% of their projects are over budget and over time, and a whopping 50% are runaway projects. Runaway projects are those that go 180% over time, 160% over budget and deliver less than 70% of functionality.

You see, grabbing for templates and filling in blanks is akin to BAs reaching for a bag of liquorice allsorts. There’s no control over what’s in the bag, they simply get the whole package whether they like it or not.

In doing so, there’s little, if any, thought given to what the business is actually looking for. The Dryfus model (used in the IIBA Competency Model Version 3.0) for skills acquisition defines a novice as “someone who rigidly adheres to taught rules or plans and is unable to use discretionary judgement.” The template zombie has never been allowed to develop beyond being a novice, no matter how long they have been doing the job, and it’s no wonder their brain dies after a while. That’s a poor approach since the BA has a role to play in achieving a desired business outcome. If it’s properly done, the business gets a working process, be it manual or automated, but if it’s improperly executed the business gets a lame duck.

In fact, the duck can be so lame that the business has late projects, projects that cost significantly more than they were supposed to, and processes, automated or manual, that don’t meet the requirements. More specifically, developers end up with reams of documentation they don’t need that require effort and expense to create, and they ignore most of it. Poor business analysis also negatively impacts stakeholder input and user acceptance.


Bullet to the brain

So now you know how to spot the zombies: they’re the mindless template devotees. What you must now do is rob the zombies of their sustenance and turn them back into effective BAs. How? Steal their liquorice allsorts and give them pick ’n mix. Pick ’n mix allows people to choose precisely what they want; it’s the ultimate in sweet flexibility because you get a bag and then you browse the seemingly endless options, placing the type and number of confectionery delights in it that you want. It gives a much wider selection than liquorice allsorts because the latter’s a predetermined bag of goodies, while the former is an endless sea of choice that lets wave after wave of sweetie, lolly and candy choice wash over you. Again, it’s effective and that’s our watchword in taking down the zombie menace one toe-scraping carcass at a time.

Template zombies like the liquorice allsorts approach because they get the bag, eat the sweets, repeating ad infinitum. But you have to shake them up, make them think. Of course, in doing so, you need to remember that you’re dealing with zombies here and even the most docile template zombie can be dangerous. Don’t give them free rein with the pick ’n mix bag of sweeties or they’ll likely shuffle along the shelves grabbing all their favourite goodies and leaving everything else. You need to point them to the right shelves and only then release them.

Frame the zombie

While it may be ideal to leave BAs to decide what sweets they want from the entire sweet store, only the most senior BAs are capable of doing that within the greater business context, which is the task of what the Dryfus model defines as an expert. Template zombies aren’t the senior BAs. They’re the other BAs. What template zombies need is a framework to guide them through the process.

The business analysis framework must deliver value to the business, otherwise why are we doing the project? And it implies a problem scope. Not necessarily problem in the standard sense—think of it more in the mathematical sense as a problem for which there is a solution. Once we figure out what the solution is, we need to figure out how we are going to deliver it. Think of it as three layers of a pyramid: at the top we ask a) why are we doing this project, followed by b) what do we need to do, and finally c) how do we deliver the solution?

When we ask why we are investigating the business objectives or goals, when we ask what we are eliciting the business requirements, and when we ask how we’re looking into the functional and non-functional requirements. 

Another way of looking at it is when we ask why we are seeking the value of the project, when we ask what we are investigating the entities, processes and business rules, and when we ask how we are looking at the required solution functionality. The framework gives us a matrix of objectives on one axis, and tasks or techniques on another, all culminating in outcomes and deliverables. It’s that matrix that arms BAs to choose which techniques are best suited to their projects. All BAs are armed with a bag of sweeties they can dip into, containing practices and disciplines such as planning, business case, business requirements, functional requirements, non-functional requirements, transitional requirements, solution validation, elicitation, and requirements communication. Within each of those portions of the matrix are tools that BAs can use to help them achieve their goal and that’s their pick ’n mix. They’re given the matrix, the framework, but they get to choose within the framework because that’s where they’re the domain experts. For example, they may choose more common tools such as process analysis, ERD, use case and others. But there are several methods of analysis, such as PESTLE, heptalysis (which is not a gum disease), MOST, SWOT, CATWOE (which is not a sad cat), De Bono’s Six Thinking Hats, Five Whys, MoSCoW, and others in their bag of sweets.

Powwow

But what are they looking for in selecting these techniques or sweeties? Some time ago I attended a presentation by Scott Ambler, who is an Agile guru. Often at a conference or industry powwow, there’s a pearl of wisdom that leaps out and sticks in your brain. For me it was, “We need repeatable results, not repeatable processes.” Pick the right tool for the job.

It requires some thought from BAs in the context of the business while considering the numerous techniques available before ensuring a suitable match. Handing BAs a bag of liquorice allsorts in which they’ll find a predetermined collection of techniques that they must follow because “that’s the way we’ve always done it” doesn’t cut it—that is just a repeatable process. You need to appropriately select the techniques that will most effectively deliver against the requirements in the context of the business objectives for repeatable results.

Don’t forget to leave your comments below.


Robin Grace is a Business Analyst Principal Consultant at IndigoCube.


Implementing Change

Evolution is key to the survival of any species. This isn’t a revolutionary concept; it has been around since man moved from eating raw meat to finding his first source of heat and energy. In business, the same is true. Those still using caveman techniques in a world evolving around them are likely to become extinct like the dodo.

There is clearly a need to constantly adapt, to realize that if one approach doesn’t work that it isn’t the end but rather the beginning. There is a need to recognize that you do not know all the answers, but collectively, those around you may.  This ability to adapt, to change tack at will and collaborate with others is what distinguishes the business analyst profession.

I have sat in many meetings listening to stakeholders who are convinced beyond a shadow of a doubt that their approach is right, that what they have been doing for the last 10, 20 or 50 years is right. That no outsider could, or should, tell them otherwise or even propose that another way is feasible or better. I have also sat in meetings where the stakeholders love the new approach, some even raving about it, while their ash-faced colleagues look on, knowing full well the work required of them and the difficulty involved in implementing such a change.  The change-experienced business analyst is willing to assist them through this process, and help both the stakeholders and the users adjust to (and even celebrate) the change.

Yes, business analysts are great at changing, at adapting. We can go into an industry, ranging from publishing to banking, airline industries to petroleum, adapting our approach to the content as necessary.

 What we business analysts often forget is that our clients and stakeholders are not always ready for such change, especially in the timelines expected of them. 

“Change management” is becoming more and more of a buzzword. The adoption of a word by industries somehow seems to devalue its meaning, perhaps as a result of its frequency of use, or use in the wrong contexts. Whatever the reason, phrases like “synergy,” “business model” and “thinking outside of the box” all end their days unappreciated, undervalued and disused in the cemetery of boardroom blabber. And if they haven’t yet, they should.

 A project is only as successful as the change embedded by it. A solution that meets 80% of requirements but is 100% embedded is by far a better outcome than a solution that meets 100% of requirements but is only 20% embedded. Implementing change in small to medium organizations or multinational conglomerates should be pursued with the same amount of vigour, conviction and creativity.

Asking people to change the way they function is no easy task, nor should it be viewed as such. The scale may change, but ultimately people are reluctant to change, particularly when they do not see anything wrong with their approach. Often, they will simply ask why? Unfortunately, this is a question that remains unanswered in most failed change management attempts.

Based on my interactions with change management, there are 6 key concepts that should be kept in mind:

  1. Answer the unspoken question first: “Why is this change being made?”
  2. Ensure that everyone is reassured, e.g., “This change is not being made as a result of you, but rather to improve our overall approach.”
  3. Remember that not everyone enjoys change. Make sure the approach taken is creative, innovative and engages all stakeholders. As a business analyst on the ground and interacting with a variety of different stakeholders from different sections of the business, your role may be more important than you realize.  
  4. Involve as many formal and informal influencers as possible. Observe team/group interactions:  there will be indicators of who to engage with.
  5. People will often only do what they are measured on, so to ensure a sustainable change is created, it is important to introduce reasonable measures reflecting target behaviours.
  6. Be patient and communicate. The change cannot be implemented or accepted overnight. Implement regular reminders of why the change is being made, and why each individual involvement is crucial.

Change and the management thereof is a key part of evolution, and without it we will stagnate. Without sufficient change management, people will covertly continue to do as they have always done, or will accept the change with barely contained contempt. Remember, unless shown otherwise, people will prefer to do things as they’ve always done.  After all, “why fix it if it’s not broken?”

Don’t forget to leave your comments below.


Catherine Perks is a London-based business analyst working for BSG (UK). She looks at what make a solution work, including the technical and interpersonal effects of implementing the solution. 

10 Tips to Working Without the Essential Inputs

FeatureAug9It can be trying to read about what as a business analyst you should have as inputs to begin BA activities when you don’t have those materials but are still actively working.  Business analysts who are responsible for product installation and software implementations at client sites do not always receive the necessary information they need as inputs to their processes.  In addition, not every organization is supportive about providing input materials to begin business analyst activities.  Still, projects kick-off and resources are assigned and business analysts and project teams get to work.  What should a BA do when placed in this situation?   

Below, I will share 10 tips to help guide BAs mitigate requirement risks when faced with some of the most common business scenarios where they do not have the essential input information.

Business situation

What you can do
  1. The contract is not finalized so the scope is still not defined.

After the formal project kick-off, start off the requirements project by reviewing the assumed boundaries of scope.  Secondly, clarify those original assumptions once the contracts are finalized and reset expectations if there were changes.

  1. The project charter is not shared with the consulting BA team.

Project SMART goals can still be established through means of elicitation either before the kick-off or during the first week of elicitation.  This is as important as the scope to understand how the project success will be measured and it should not be skipped.   Even if the goals are not SMART and measurable, obtain as much information as you can and include it in your discovery notes and documentation, and perhaps at a later date the client may be more open to re-addressing with you.

  1. Requirements planning cannot be conducted prior to a formal project kick-off.

When the pressure is on to begin a project immediately after a contract signature and the time is not given for proper requirements planning, you can roll requirements planning into the project itself.Requirements planning still needs to occur and must happen in a joint fashion with the clients.  You can conduct a joint planning meeting on the first day of the project and continue into the second (if necessary) with the clients while on-site prior to any elicitation activities.This is a very important activity that can save time and iterations of unnecessary elicitation sessions by having the joint teams ready for each session and taking a tactical approach.  The time spent planning will save time overall and will allow you to flex your influence and ensure that this critical step occurs.If your company does not have a standard tactical approach for the planning of your projects, save your plans, take out the client references and begin to build your standard plan for re-use on other projects.

  1. Your company does not have a requirements management plan.
Many of the things that are typically handled in a requirements management plan also exist in the project methodologies.  It is not uncommon for a service organization to default to utilizing project management planning or methodology to cover areas such as:

  • Project communication plans
  • Conflict and issue management
  • Identifying project deliverables
  • Sign-off procedures for project deliverables
  • Change control processes

What you will need to work out with the PM and the team is a smaller requirements management  plan for:

  • Traceability of the requirements
  • The streamlining of every BA’s notes to requirements in a single format

Again, if your company does not have a standard tactical approach for the management of the requirements activity during the project, save your plan, take out the client references and begin to build your small requirements management plan for re-use on other projects.

  1. The current state documentation or the business workflows are not always made available.

You can be working with a client who refuses to give you the information or you can be working with a client who doesn’t have it documented.  The outcome is the same regardless—you don’t have an idea of what they do today as a business model.When implementing a new system, it becomes very important to draft future state business workflows and/or business use cases during your elicitation period.  Remember to validate those business workflows by conducting brief system mock-ups and creating high-level scenarios for which the client will validate whether the workflow is accurate.  These workflows can then be used as a baseline going forward.  Obtain the client signature by including these in the requirements package for sign-off.Project estimations often do not account for time spent focusing on current state processes so you really need to discuss with the project manager.  Ultimately, you can request a change order to the current project or call this out as a potential project risk.

  1. Your client signs off on business requirements and continues to change requirements during implementation.

You will need to work with your project manager to enforce the change control process for the project.  Assess the root cause for the new business requirements and address them at executive review meetings to identify the potential impact to the project go-live dates or success of the project.Not every change needs to be accommodated so you really need to focus on those prioritized the highest.  Use the simplest model for assessing the risk.  What is the risk of not accommodating a requirement and is it an obscure area of the company or one that’s widely utilized in all business areas? [Risk = Impact * Rate of occurrence]

  1. Your client is not prepared for the elicitation session(s).

You should stop the elicitation session while it’s in progress and change the plan.  No one wants their time wasted in sessions that do not serve a purpose.  Bring this issue up at project risk meetings as a requirements risk and something you need mitigation planning around. It’s better to spend time planning the sessions, prepping the attendees and marking out the information that is required to be brought to the meeting versus continuing on and getting only some of the information. Lastly, remember that most projects do not have the budget to continue iterative rounds of elicitation sessions.  This can be the main reason for overages in requirements projects.  You must avoid this situation and assist with mitigating it if it occurs.

  1. Your client continues to identify product enhancements and rank them all as “HIGH”.

If you are on a project installing or implementing software, your focus is on what the client need now for their business to go live with the software they are implementing.  Sometimes, the perceived needs by the clients are more of ‘wants’ versus ‘needs’ .   If this is the case, you might be able to negotiate with a client by holding a prioritization meeting and using certain criteria to help them categorize items as Critical, High, Medium and Low.Also, at times the perceived critical or high needs of the end users are not enough to stop the overarching project goals.  If your client insists that you submit enhancements as Critical or High for go-live, as a BA you should take those needs and prioritize and rank them.  If the ranking still seems incorrect to you, you may need to work with the project manager to bring those project needs forward to the executive steering committee overseeing the project for final project determination.

  1. Clients are not interested in participating in formal stakeholder analysis.

If the client has been a long-standing customer, they expect that their partnered IT solution company understand who they are and what they do.  They may become agitated if you start over and ask about their vendors or their stakeholders. I do not recommend that stakeholder analysis occur on every project with clients like this. During IT projects, especially upgrades for which stakeholder analysis happens internally within the organization, some clients are not open to this concept and so it’s best to assess the client’s openness and expectation of how well you know them already.  When you need to be a little covert about identifying the stakeholders of the project, do so by validating the stakeholders that you know of in each elicitation session or when addressing a new business segment area.You can continue to capture the stakeholders along the way and include them as a reference in the final requirements package for client review.

  1. You had a team of people assisting with elicitation and they have not provided you with the requirements.
During projects that hold parallel paths of elicitation, it is not always feasible for the lead business analyst to be in all of the sessions. It is typical that there are responsible and accountable resources for each area of elicitation, and the lead analyst needs to share with them the management plan on how to communicate requirements.  Request the documentation and give the deadline for the information.If resources continue to not provide their information, the business analyst needs to communicate the expectation of the documented requirements by a stated date and copy their resource managers along with the project manager.  Not obtaining the necessary team requirements internally can jeopardize the requirements documentation and should be escalated as a project risk if it continues to be an issue during the project.

When it comes to working without the necessary inputs, it requires business analysts to get creative and find alternate ways to get the information.  Take a lesson from the 1840 short poem “If at first you don’t success, try and try again.”  Input materials do not always come to you in a nice package, nor do they come exactly when you need them.  

Business analysts really need to have constant communication with project managers during a requirements project on what they need and what they recommend for the success of the project.  When a project manager and a business analyst work together on project and requirement risk, project and business scope, and project time, budget, hours versus project needs, projects roll out with a higher likelihood of success both in terms of budget and met business objectives.

Don’t forget to leave your comments below.


Maryanne Miller, CBAP, Business Services for MEDecision, Inc., has over 15+ years of business and technical experience in the corporate world of health care IT services. As a professional consultant providing business and technology leadership, her areas of experience include business process improvement, business analysis and health care IT.

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:

  1. Solution Validation: Validate that solution meets the Business Requirements
  2. 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
  3. Identification & Validation of Scenarios: BA should identify scenarios that will be tested in UAT Phase and get those scenarios validated from end user
  4. Create Training Plan: BA should publish the training plan to engage the required resources
  5. Create UAT Plan: BA should publish the UAT plan so that required resources can be arranged
  6. 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
  7. 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”
  8. Record the Results: UAT can only be effective if issues are logged religiously
  9. 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
  10. 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

  1. for UAT (Must Have Document) & Business Scenarios Download Template 1 Template 2

  2. Business Process Flows to make sure that user is doing the right things (Must Have Document) Download Template
  3. 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
  4. 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
  5. Deployment Slip on successful deployment of application on client premises Download Template
  6. Training Plan to schedule the resources required to provide software training to users (Must Have Document) Download Template
  7. 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?
  8. UAT Plan to schedule the resources required to conduct UAT (Must Have Document) Download Template

UAT Execution

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

UAT Closure

  1. UAT Signoff is authorization from user to GO LIVE Download Template
  2. 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!

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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] 
  5. 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.