Skip to main content

“Oh No, You Gave Me What I Asked For!”

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on “Oh No, You Gave Me What I Asked For!”

Part 1: Common Pitfalls to Uncovering Expectations

Project professionals – specifically project managers and business analysts – realize that no matter how well projects are executed, projects still fail when customer requirements are not clearly defined and customer expectations are not met.

“Uncovering expectations takes a commitment to defining requirements in sufficient detail to understand what those expectations truly are.”

Uncovering expectations takes time and requires the art of consultative questioning. It demands patience with clients who have difficulty articulating their requirements. It requires a process for not only eliciting the requirements, but also for analyzing, documenting, and validating them. Finally, uncovering expectations takes a commitment to defining requirements in sufficient detail to understand what those expectations truly are.

This two-part article discusses five common pitfalls and the associated risks of not uncovering expectations in part one and, in part two, how a consulting approach will help mitigate them.

Requirements and Expectations

According to various standards bodies such as PMI, IIBA, and IEEE, a requirement defines a condition or capability needed to solve a problem or achieve an objective that must be met by a system or system component to satisfy a contract, standard, or specification.

Requirements, then, state a business need and describe how the solution, or final product, will meet that need. Detailed requirements describe such things as what the end-user of the product needs to know or do or have, and how they need to use the product.

It is helpful to think of requirements as being stated, whether spoken and/or documented. Expectations on the other hand, while also requirements, are not usually articulated by the sponsor and client stakeholders. We need to meet both expectations and stated requirements in order to satisfy business needs and produce enduring results. When we ignore expectations, even if we have been meticulous in documenting stated requirements, we are apt to develop unusable products.

Common Pitfalls

1) The Time Trap

One of the challenges cited frequently in our informal research is what we call the Time Trap. There are two parts to the time trap. The first is that project professionals usually feel they are not given enough time to define requirements, let alone uncover expectations.

The second is that clients are not always available to define their requirements. We frequently hear from key clients that they don’t have time to attend requirements workshops, for instance. We’re then left with undesirable alternatives. We can postpone the meetings and delay the project, we can hold the workshops without the clients, or we can proceed with incomplete requirements. Each one of these alternatives has the associated risk of incomplete requirements, surprises, rework, and expense. Research shows the total percentage of project budget due to requirements defects is typically from 25 to 40 percent and costs the economy $59.5 billion annually (SEI study, 7/15/2005).

2) Stated Requirements Don’t Meet Expectations

Another pitfall is assuming that the requirements stated by the sponsor and clients will produce a product that actually works, and will be used. In other words, we mistakenly assume that if we get the sponsor and clients to articulate their requirements, the product will meet their expectations. Having sponsors state their requirements is only the beginning of the process. If we collect the requirements as given without a consultative approach, it is highly unlikely that the end product will meet expectations.

3) Ineffective Questioning

“Project professionals need to master the art of asking questions to ensure expectations are discovered.”

One reason that stated requirements may not meet customer expectations is because ineffective techniques are used to ask questions about the requirements. Project professionals need to master the art of asking questions to ensure expectations are discovered. Asking questions like “what are your requirements for this project?” is not apt to yield successful results. Yes, surprisingly, this is a frequent type of question asked!

Asking the wrong questions, even when asked with good intentions, can lead to unwanted results. The categories discussed here include:

  • Open- vs. closed-ended questions 
  • Solution presentation 
  • Feature fallacy. 
  • Questioning Style

Open- vs. closed-ended questions. Some project managers and business analysts erroneously think it best to always ask questions that allow the interviewee to expand their thoughts, avoiding what are called closed-ended questions. Asking these expansion questions exclusively can be time-consuming and can make the elicitation process longer than needed.

Solution presentation occurs when we fall into the trap of presenting solutions that sound like questions. Also known as leading questions, these closed-ended questions often force the interviewee into a position of disagreeing with the interviewer or worse yet, feeling foolish. Therefore, by avoiding leading questions, such as “wouldn’t it be better to…” or “have you ever thought about…” we reduce the risk of creating barriers to communication. Listen to yourself during the course of a day and count how many times you ask leading questions.

Feature fallacy occurs when either the interviewer or the interviewee focuses on the features and functions of the product before determining how the product fits into the context of both the business and the project. It is a pitfall that occurs across disciplines. As an example, software engineers and vendors sometimes concentrate on desirable features, rather than determining whether the software will solve real business problems or the impact of the software on the organization.

In a recent article, James Surowiecki discusses the issues related to what he calls “feature creep” (Surowiecki, May 28, 2007,

“People are attracted to features, but will not be happy without usability.”

p28). Citing statistics for consumer returns on defective but difficult-to-use products, Surowiecki shows how many non-defective items are returned annually. Sixty percent of those participating in a focus group picked products with more features. However, when asked to use the product, they became frustrated as “feature fatigue” took over. People are attracted to features, but will not be happy without usability.

Questioning Style. Another pitfall is asking the right questions the wrong way, which can destroy trust and create barriers between interviewer and interviewee. If we are to elicit good requirements, we need to put the interviewee at ease. We need to build trust with our stakeholders and asking questions in a way that does not facilitate communication, even if they are very good questions, can produce unintentional negative results. Here are three sins that can destroy trust.

  • Asking ‘why’ accusingly. Sometimes the interviewer can give the impression of being a prosecuting attorney. Asking ‘why’ directly can put some people on the defensive and should be avoided. 
  • Showing lack of interest. There are many ways to show that the interviewer is not engaged. Checking cell phones is an obvious one. Less so are neutral non-verbals, such as lack of eye contact, slouching, etc, which while not actively presenting communications barriers, can inhibit the conversation. 
  • Using inappropriate non-verbals, given the culture of the interviewer. How we show that we are engaged in the conversation differs from culture to culture. Making the assumption that everyone responds similarly to engagement signals and affirmation can lead to barriers and distrust.

4) Using The Wrong Techniques

Even experienced project professionals are guilty of using the same techniques repeatedly, even when the techniques are not appropriate for the project at hand. For example, using business process modeling for a reporting function may not uncover the true requirements. Using inappropriate techniques can result in clients answering the wrong questions, thereby providing incomplete or incorrect requirements. This can result in being surprised at the end of a project with sponsors saying, “yes, I know that’s what I said I want. But it’s not what I really need!”

5) Accepting Solutions Presented by the Business and Technical Experts

A final pitfall is accepting a business solution provided by the sponsor and other key stakeholders. Although not a good practice, it’s common for business stakeholders to try to save time by giving specific product details (e.g. fields on a database table) without providing business reasons. Accepting solutions presented by business stakeholders forces project managers into the role of order takers, which usually leads to unusable and unused products.

A related pitfall is feeling constrained by an imposed technical solution, often forcing business needs to be subjugated to technical architectures, rather than having technical architecture support the business need. Forcing business solutions without taking existing business processes or needs into account, invariably leads to customer disappointment.

Overcoming Requirements Pitfalls

Look for the conclusion to this two-part article in the next Business Analyst Times, as we explore overcoming the above pitfalls. The consultative approach described shows how being a consultant to the business helps ensure that expectations are met. Part two explores practical approaches to meeting and exceeding expectations through understanding the business problem, and recommending solutions that meet real business needs, not just stated requirements.

 

Elizabeth Larson, PMP, CBAP, and Richard Larson, PMP, CBAP are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management skill development company.

Over 15 years, they have used their extensive experience to develop Watermark Learning’s training into a unique approach that combines industry best practices, a practical approach, and an engaging format. Attendees immediately learn the retainable real-world skills necessary to produce enduring results.

Each has presented numerous workshops, seminars, and training classes to thousands of participants on tree different continents. Their speaking history includes regular appearances at Project Management Institute (PMI) North American, European, and Asia-Pacific Congresses and PMI chapter meetings.

Both were recognized in 2006-2007 as two of the world’s first registered CBAPs (Certified Business Analysis Professionals) by the International Institute of Business Analysis (IIBA). They also serve on the BABOK development and review team. Both are certified project management professionals (PMP) through PMI, and are contributors to the upcoming 4th edition of the Project Management Body of Knowledge (PMBOK).

References

Project Management Institute (2004). A Guide to the Project Management Body of Knowledge(PMBOK®) (2004 ed.). Newtown Square, PA: Project Management Institute.
International Institute of Business Analysis (2006). A Guide to the Business Analysis Body of Knowledge, version 1.6. http://www.theiiba.org. 
SEI updated May 12, 2005 viewed 7/15/05. System Quality Requirements Engineering (SQUARE) Project, http://www.cert.org/sse/square.html 
Surowiecki, J. (2007, May 28) Financial Page Feature Presentation, New Yorker Magazine, page 28.

 

BA Rising

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on BA Rising

So, last month I covered Business Analysis, and How I Came to Realize What It Was And What It Meant. This month, I want to go more into what it means, and why the increased influence of BA (and the CBAP certification) is so important.

The short version is this: Systems are increasingly important in our quality of life (are you on the no-fly list yet?), and good BA leads to good systems, bad BA leads to Gartner and Standish Group negative statistics (if you don’t know what these groups do, Google them). BAs don’t always have the influence it takes to prevent these bad outcomes, but they should, and they will, now that the IIBA has established some neutral standards.

So, why BA – why can’t we build good systems without it? PMs are trained to deliver on time and under budget, so what’s the problem? (Hint – How hard is it to deliver on time and under budget? How much have you got to spend by when?) If you read the literature, you will see that MOST causes of project failure are related to stakeholders and requirements. These are failures of BA, by definition of the profession, and by default since they are not key to PMI.

I want to make the statement that the techniques of BA work because they are exactly those of due diligence. Sometimes we say that BA is just common sense, then laugh when we realize how uncommon it is. Due diligence IS common sense. Surely no one objects to due diligence? Indeed, why should anyone be concerned about the rise of due diligence? Isn’t that for dullards?

Before anyone spends millions of dollars (or even thousands), or takes any risk of consequence, it pays to do some amount of homework. If the homework seems overwhelming, expensive, or incomprehensible, that just means that the first 10 hours of homework are VERY important. They may be even MORE important than the next 100, or even 1000 hours. There is a LOT of earned value in doing ANY thinking versus none. Once thinking gets to thousands of hours, there is increasing risk of ossification, and the benefits diminish. In spite of this, a common complaint is “We don’t have time for analysis,” as if none were better than too little.

A common project mistake is to assign too much earned value to development, and not enough to analysis. Million dollar mistakes rarely happen at the field definition level, and are typically easy to explain and correct. This is true in spite of the fact that a significant percentage of labor and time may be spent on field level issues, or other technical concerns. Most of the value and risk control in the project may go to the first hours of analysis, with the development being quite low risk, as the “big” problems are actually resolved. It pays to control costs with analysis, and does NOT pay to control it with code change control.

This seems obvious enough, but analysis is overlooked and under-respected on more than a few projects – witness the 35% success rate of projects!t is, in fact, overlooked by the society in general. My father was once a Quality Analyst for a bank. “What do you do?”, I asked? “I make people think.”, he said. “Thinking is painful, and left to themselves, many won’t do it.”

Hmmm. The problem is, that the lax attitude about thinking is due to the illusion that we understand something is so strong. “I’ve been doing this for years, I know what to do!” In effect, EVERYONE thinks they understand, therefore, there is no need for an analyst – no one is (admits to being) confused – that would be awkward, scary even. In my experience, EVERYONE thinks they are THE analyst. It is, apparently, a strong hero role, even if we are only legends in our own minds.

Think about George Washington, fighting a desperate and losing war with England. In the midst of his desperation, he invented enterprise analysis, from a sheer common sense need – “What does the continental army consist of, what is it not, and what can we do about it?” That is bravery, true action, in the face of seemingly insoluble problems.

Imagine making these decisions without a sense of the whole enterprise. Imagine making these decisions under illusions of how coherent the enterprise was, instead of basing them on the best intelligence available.

Imagine pushing resources around “just because you can”.

And if you want to imagine those things, just imagine working on any project for the last 100,000 years, because human nature is such that it prefers illusion to facts, egos to inventories and simplistic principles to problem solving. Our progress comes in spite of ourselves, because nature supports common sense, and punishes lack of care.

The saying that ” common sense is none too common,” applies especially to BA. BA is the refined, professional level, experience based, highly predictive form of common sense. BAs don’t cite common sense; they practice it. They practice it because they are willing to learn, and think, in spite of the petty discomforts.

An example of how rare common sense actually is: Everyone knows you have to think of your customers to have a successful product (at least everyone would select it correctly on a multiple choice test). In spite of this fact, IBM was able to release the PCjr, with no applications that anyone cared about. IBM followed this up by dissing any employees who pointed out the problem. IBM’s slow decline in the late 80s and early 90s was inevitable, and that IBM no longer exists.

Professional BAs really believe in practicing due diligence, because they have seen what happens when you don’t. They are not in denial, and not afraid of the truth. They believe it, and live it, where others don’t, for whatever reasons. YES, they can see the future, because they remember the past.

In a world where “doing it because you can” is the message from the top, it’s easy to abandon due diligence – the paychecks can flow for years sometimes. It is much harder to adopt the Quixotic position – things are worth saving, improving; the world deserves to be a better place.

Given the importance of systems to the state of the future world (identity systems, micro-cash, medical imaging, health management, internet security, etc.), does anyone doubt that they want BA to rise?

This is an important question, for the following critical, political reason: If BA represents stakeholder value, doesn’t that mean that the Project Manager actually reports to the BA, instead of the other way around? Why or why not? Don’t most PMs wish they had a better handle on the requirements before the deadlines and budgets are set? Stay tuned.

Our society has hardly started building systems. We have traffic managements systems to build that will save lives, medical management systems that will empower patients, and identity systems that benefit the users (us) as well as the implementors (them?).

If anyone is against BA, they are against common sense, stakeholder interests, due diligence, and successful outcomes for a democratic society. If you are out there, and don’t want to play, please stand up, so the rest of us can work around you.

BA Rising

Written by Marcos Ferrer on . Posted in Articles.

This is the first entry in Marcos Ferrer’s blog, BA Rising, an an ongoing series where Marcos shares his views, observations and thoughts on business analysis – and would like you to share yours.

When I was young, I asked my dad what he did at work. “I’m an analyst”, he responded.

In the course of my career I have run into (and sometimes been grouped with) systems analysts, financial analysts, organizational analysts, sales analysts, marketing analysts, computer analysts, network analysts, security analysts, user interface analysts, software analysts, investment analysts, business analysts, enterprise analysts, quality assurance, analysts who analyze analysis, psycho-analysts, and probably others.

Needless to say, my father’s answer, back then, didn’t provide much insight as to what he did to keep the family going. In fact, at the time, I didn’t give it any thought at all. Most of the analysts seemed like people who knew some stuff about some specialty, that’s all. Most were pretty smart, but not all.

Nor did it make sense that in my time there, IBM called me a Systems Engineer. Yet, It didn’t bother me; I figured they knew what to call it. Still, it didn’t feel like engineering. To me if just seemed like a bunch of things to know about computers – and the world – that let you help your customers. Some of it was just knowing that large inventories at year-end were financially punishing to businesses that had them. Some of it (e.g., correct balanced systems and network configuration) was stuff that customers could have figured out for themselves, if IBM had provided the means on-line. Instead, IBM’s engineering support systems gave me information power with my customers, and I used it to leverage information out of them concerning their business interests, becoming an analyst without knowing it.

When Mendes Worldwide (high tech bowling company) called me an Industry Rep, again, it didn’t bother me. They must know! When a client of mine installed the world’s first fully automated duckpin bowling center, after a year of negotiations and Excel “what ifs” with Duckpin industry officials, Duckpin Bowling Center proprietors and potential investors, someone said to me that I must really know the business. Again, I was operating as an analyst, without even knowing to call it that.

What I figured out later (when I found IIBA) was that I was practicing business analysis the whole time. I just didn’t know it was business analysis. I know I didn’t know, because every boss I ever had (except one) challenged me by spluttering “What are you doing, why are you doing that?” And with comments like, “don’t let me catch you doing that ever again!” And I never knew what to say except “But, it’s working!” and “I promise you‘ll never catch me doing that again!”

Over time, I met other people who made things work. They made them work well. They were different from the ones who made things look good. The “look-gooders” made things look good just long enough to get promoted, so someone else would actually have to fix the mess. A small number of people seemed to be able to make things look good AND make them work. All these people seemed to be CEOs; high-level executives, but certainly not business analysts.

What the “make things work” people did, always made sense, got results, and allowed energy time and resources to complete tasks and quickly focus on new opportunities,

In a word, these people left things better than they found them.

That was not easy at IBM, nor is it easy in organizations of any size larger than, say, one person. None of this was identified with business analysis, or analysis of any kind – at least not by my bosses at IBM in 1983 – this changed later.

The Eureka moment for me came while I was consulting with DOL as a client/server analyst. Peter Gordon introduced me to the International Institute of Business Analysis (IIBA, www.theiiba.org). I read their material, and then their Book of Knowledge (if that sounds pretentious, remember that it is really the Business Analysis Book of Knowledge – BABOK – the name adds a little humility, in my opinion, and all to the good).

The IIBA BABOK had summarized (it is still a work in progress) all my knowledge and more techniques than I had ever heard of, but it all made sense – anyone trying to “git ‘er to work” instead of just “git ‘er done”, might do exactly the things listed in the BABOK.

Business analysis meant thinking/being thoughtful! That’s what first attracted me to IBM – the motto – “Think” – and what chased me away later – the lack of actual thinking. Business analysis is what one does, if one really cares about achieving the outcome! Risk analysis doesn’t pay if you will get promoted regardless of project outcome. It only pays if you care, AND if you use it wisely, for issues that the project can truly affect. Anyone with major meteor (>50km diameter) strikes in their risk plan is obsessive, not thorough, and not to be admired, as they have no concept of risk vs. cost. Anyone considering small (<.0.1m diameter) micrometeor strikes, is working on space travel, or is also (frankly) screwy.

Now that I realize my “common sense” skills, that I took for granted and have used during my career, really consisted of BA practices and CBAP standards, I’m hooked. Stay tuned. It will hook you too. Imagine a world where stuff worked better – stuff like medical care, flight safety, telecommuting, war plans, credit protection, law enforcement, more.

Remember, there is strength in numbers – the more CBAPs there are, the better our chances of being heard, and making the difference that is so needed. Join us, or give up and be a spectator. I know you will join, because if you could help it, you would have quit this complex and difficult career long ago.

Again, welcome, and please share your thoughts with us.

, is an experienced teacher, public speaker, and instructor with ESI International. He has over 20 years of experience in the practice of business analysis and the application of Information Technology for process improvement. Mr. Ferrer began his BA career in 1982, while still a student at the University of Chicago, when he developed a consulting practice (he didn’t know it was BA then) with local property management and accounting firms. After graduating in 1983, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in a number of different fields. In 1990 Mr. Ferrer became an independent consultant, again working with a variety of customers, most notably in the Family Entertainment industry. He has also worked on multiple government systems projects and “business” projects, including A-76 work.

In November of 2006 Mr. Ferrer became one of the first 16 CBAPs certified by the IIBA. He has served as VP for Certification at theDC-Metro chapter of the IIBA, and is speaking publicly and promoting certification (CBAP) on behalf of that chapter (www.iibadc.org).

Copyright 2007, Marcos Ferrer. All rights reserved.
07/27/07 

Marcos Ferrer, CBAP

Putting the User Back into User Acceptance Testing

Written by Kupe Kupersmith on . Posted in Articles. 2 Comments on Putting the User Back into User Acceptance Testing

Why is getting users involved in User Acceptance Testing (UAT) so challenging? Isn’t it called UAT because the users are the main participants? My experience has shown that involving users in all phases of the project, especially UAT, is the best way to ensure project success.

I recently worked on a project in which a major defect was found after the software application moved to production. This defect caused the users to perform three days of manual processes. Users on the IT project team worked countless overtime hours. The defect also resulted in a frustrated user group and business sponsor. The project team’s morale was low and the business users lost a great deal of confidence in the project team’s ability to deliver quality software solutions. To reduce the risk of making this crucial mistake in the future the project team improved the UAT approach by getting users more involved.

Traditional Approach

Too often, User Acceptance Testing is not taken seriously. For many reasons UAT gets shortened, is not conducted in a way that ensures a successful project or, the worst scenario, is not done at all.

An approach I have used in the past consisted of the project team members—Business Analysts and QA Analysts—writing test scripts and providing demos of the new application to the users. The users would then walk through test scripts step-by-step. In some organizations the BAs write and execute the UAT tests and then present the results to the users for sign-off.

Traditional approaches are often not effective because they are missing a key ingredient—the right amount of user involvement. In the project previously mentioned, there were five major issues relating to UAT that we had to address. These are common problems in many organizations related to lack of user involvement:

• Users may not be fully vested in UAT. In the traditional approach the users are directed by the BA during UAT and are brought in too late in the project to have an impact on the test plans. This results in a lack of ownership by the users and less responsibility on their part for the success or failure of the project.

• Users do not fully understand how the new functions should work when they are asked to test them. Just seeing a demo is typically not enough. This can result in the UAT session becoming a training opportunity and not a true test.

• Tests are often generic and are not all based on real-life scenarios. If the test scripts are written by the IT project team, there is a greater risk for missing real-life scenarios. This is because, unlike the user, the IT project team does not use the application every day.

• Project team members are usually pressed for time. Often a BA has already been assigned to perform requirements activities on another project during UAT. Balancing multiple projects means that BAs have a hard time focusing on UAT, while meeting their other project deadlines.

• High pass rate of UAT test plans. Ironically, this is not a positive thing. Often a BA writes test scripts and tests them himself prior to UAT to ensure the scripts pass. When a BA writes the test scripts the users are not given an opportunity to interject enough real-life scenarios to validate the system.

A Recommended Approach

To address these common issues and increase the chance for project success we need to take a new approach to UAT.

1. Involve key users early

Once Quality Assurance (QA) begins testing, UAT planning should start. Identify users who have a deep understanding of the business requirements and are change agents for the group. Identify all of the tasks that need to be accomplished, the owners of each task, and a high-level timeline. This will help ensure that all the right people are involved.

2. Provide hands-on training of the system for the UAT participants

Providing a demo is not good enough. Once QA feels the application is stable enough, give hands-on training to the UAT participants. It is critical to explain to the users that issues may arise because QA testing is not complete. Ask the users to stay focused on how the application works and not so much on the fact that it is not fully operational.

3. Use facilitation sessions to create test plans

Have the users write their own test plans. This may sound far-fetched, but it is key to getting UAT as close to real life as possible. The BA’s primary role is to facilitate the UAT test plan creation process, but not to write a single test script. Using process workflow diagrams and Use Case documentation from the requirements package, ask the users to determine what processes and system functions need to be tested. Provide the UAT participants with examples of test scripts and explain the need to capture the goal of each test, the necessary steps, and the expected results. The steps become second nature to the users of the system, and they often find it difficult to document each step they take to accomplish a goal. Help them think through their processes in detail to ensure they have documented each task completely.

Review the test plan. Once the test plans are written, the BA reviews the test plans to ensure all the necessary functions and processes impacted will be tested.

Determine necessary inputs and outputs. Once all the test plans are written, ask the users to document the inputs they need to complete each of their test scripts and the outputs that will be generated. Make sure all UAT participants have the necessary inputs to complete their tests based on all of the outputs. If some are missing, enlist other users to create those inputs during testing execution.

Make it as close to real life as possible. To enhance the real life feel, the BAs work with the users to determine a testing schedule. Make sure the schedule follows their daily process. Again, use process workflow and Use Case documentation to ensure the test plans are executed in the order the activities would be done in real life.

4. Ensure users execute the test

The BA’s role is to ensure the test environment is set up and to assist the users as they execute the tests. The user’s role is to execute their tests and document the results.

The Results

Recommended Approach to UAT

1. Involve key users early

2. Provide hands-on system training for the UAT participants

3. Use facilitation sessions to create test plans

4. Ensure users execute the test

Using this approach can help reduce the risk of major defects making it to production and ensures the users are satisfied that the solution meets the objectives of each project. Here are some of the key results from using the improved approach:

• The UAT participants take responsibility for the success of the release. They feel part of the team due to their collaboration with the IT project team and involvement in UAT planning, and test creation and execution. They also help champion the benefits of each release to the larger user base.

• Due to the pre-test training, users are comfortable with new applications. This allows the users to develop real life test scenarios, and the time allotted for testing is not used for training.

• Since the users create and execute test plans, the tests are very close to real life scenarios and the users are more comfortable running the tests.

In addition there are tangible benefits to future projects:

• QA incorporates the scenarios documented by users in the QA test plans for future releases.

• Over time there is decreased use of the BA’s time for UAT. With the BA facilitating the UAT process and not doing most of the work, the BA can focus on other necessary tasks – like launching the next project.

Implementing the Approach

A lack of user involvement in UAT is not uncommon. I urge you to try this approach even if you have not yet experienced a drastic wake-up call, such as major defects in production.

As we are called upon to deliver solutions faster and faster, it is just a matter of time before major defects make it to production. Here are some tips for getting started:

• Start small. To help manage the changes with the new approach, identify a release with a low number of users and/or new functions. This will allow you to test the new process, discover lessons learned, and make the necessary adjustments.

• Plan for additional time. Using this new approach will initially require more time. Work with your Project Manager to plan more time into the UAT phase for your first two or three projects. As you get accustomed to this approach, it will require less time.

• Identify power users and champions of application. They are your best testers and have the most interest in the project’s success.

• Sell the benefits of the new approach to your users. As with any new approach, BAs need to help the users understand what the approach is, and how it will ultimately improve their business.

• Save the user test plans for future releases. Reuse of test plans will help speed up the time dedicated to UAT in future releases and can be used to update your QA test plans. Successful implementation of this approach helps ensure projects meet the user needs. The collaboration of users with the project team leads to a shared responsibility for the success and failure of the project.

What is UAT and Why We Do It?
UAT is the final approval by customers signaling the new system or enhancements can be deployed. UAT is unlike other types of software testing (e.g., unit testing, system testing, integration testing), because during UAT we are looking for conformity. We need to validate that the solution meets the business objectives and works correctly with real-life scenarios. UAT is typically conducted by users with assistance from the BA and other project team members.
UAT is most often conducted before a system is deployed into a production environment. For higher risk projects UAT may continue for a period of time while running the old system and new system in production. This gives the users ample time to become comfortable that the new system meets their needs. For commercial software companies UAT is also know as “Beta” testing. Here the system is launched into a production environment, but only to a subset of customers who will provide feedback on defects and necessary improvements. 

The Business Analyst as Strategist

Written by Kathleen B. Hass, PMP on . Posted in Articles.

A recent survey conducted by Evans Data Corporation, The New Business Analyst: A Strategic Role in the Enterprise, found that business analysts are key players in making strategic decisions. “A clear line in the corporate sand has been drawn as to the importance of the business analyst. The BA plays an increasingly integral and strategic role in organizational success,” said Evans Data Corporation President John Andrews. Business analysts are emerging as the central business competency of the future. Different from systems analysts or project managers, business analysts (BAs) not only manage project requirements, they also contribute vital information to strategic planning, goal setting and strategy execution. It is in this capacity that BAs can have the greatest impact on the long-term success of the enterprise.

Business Analyst as Master Strategist

In their Body of Knowledge, the International Association of Business Analysts (IIBA) defines a BA as someone who “works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.”

To help distinguish the roles played by the BA and the project manager, consider an analogy from the world of sports. On a football team, the coach (the project manager) is given a game (the project) with requirements (to win), as well as team members and resources (players and equipment). But what happens when the requirements change? The team owner feels it’s not enough just to win games, and the goal is now to win the Super Bowl. Enter the general manager (the BA). Responsible for the team’s overall strategy for success, the general manager continually validates that the project team is focused on the strategic imperatives. Similarly, the BA keeps her eye on strategic-level decisions that impact the project, leaving the project manager free to focus solely on optimizing project team performance.

No analogy is perfect, of course. In football, the coach reports to the general manager, but in business, the BA and the project manager share leadership of the project team. Much like a general manager, however, the BA keeps track of the overall direction of the team’s season, freeing the project manager to “get in the huddle” with the team and direct it on a play-by-play basis.

Specific Strategic Planning Tasks

Of course, the BA is not the only one on the project team familiar with the strategic goals of the organization. Employees perform best when they understand their organization’s plans and their role in them. One vital role for BAs is to translate strategies into new proposals for the company, as well as to ensure existing operations mesh with the strategy. In fact, all proposals for organizational change should be aligned with corporate strategies, and the BA is best suited to handle the enterprise analysis needed to ensure alignment.

The BA must have a thorough understanding of the organization’s strategic goals to facilitate the process of matching project objectives to business needs.The BA assures the project deliverables meet the business needs and helps to realign the project when requirements change. BAs makes certain that throughout their life cycle, projects continue to meet business needs and deliver benefits that outweigh their costs. Because of their familiarity with the organization’s strategic goals, the BA is often adept at securing additional support from the business sponsor, if needed. At the end of the project, the BA examines the ROI to determine if the project met its goals.

The BA can also be a valuable provider of information to the strategic planning team or top-level management. BAs may perform analyses of the competition, gather customer feedback and complete benchmark studies to support a business case or project investment decision package. In addition to providing data for decision-makers, senior BAs may also conduct goal setting meetings and even help conduct strategic planning sessions.

A Vital Role

Just how important is the strategic planning role that is filled by the BA? Judging from the poor success record of projects in the business world, very important. Consider these statistics:

  • $80 -145 billion per year is spent on failed and cancelled projects (The Standish Group International, Inc.)
  • 25 percent – 40 percent of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
  • 50 percent of projects are rolled back out of production (Gartner)
  • 40 percent of problems are found by end users (Gartner)
  • Poorly defined applications have led to a persistent miscommunication between business and IT. This contributes to a 66 percent project failure rate for these applications, costing U.S. businesses at least $30 billion every year (Forrester Research)
  • 60-80 percent of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)
  • Nearly two thirds of all IT projects fail or run into trouble. (See Figure 1 for the results of the 2006 CHAOS Survey.)


Figure 1: Project Performance Track Record – The Standish Group 2006 Chaos Report

Until the creation of the professional BA, there was no one person responsible for ensuring that business requirements were accurately determined and managed throughout the lifespan of the project. Business sponsors often do not have the time or the technical expertise to provide oversight to projects on a day-to-day basis, and their role is best left to securing funding and resources and using their authority to help effect institutional changes in support of the project. Project managers are focused on delivering what was asked of them within time, cost and quality constraints, not constantly reevaluating and validating the business need.

The Future

The high-velocity change occurring in the business world today requires more than employees capable of completing assigned tasks. It calls for multi-skilled practitioners who are systems thinkers, comfortable in both the boardroom and the server room. As they seek to increase project success rates, more companies will include business analysts in their project teams, recognizing the added strategic value they bring to the table.