The BA and Expectation Setting

The expectation gap

Expectations can destroy a project.  If the stakeholders have inflated, unrealistic expectations, regardless of the projects final deliverable, it will be classified as a failure.  The stakeholders will be disappointed and the project team will be demoralized.  The BA must play the role of project realist and ground the stakeholders, tethering them to the true idea of what the final deliverable will be.  The BA is uniquely positioned to fulfill this “Expectation Enforcer” role because of their requirements gathering responsibilities.

In my current BA role implementing a SaaS product, this is particularly critical.  I am the face of the company and product following the successful sales cycle, where they have been courted and wooed with the promises of time and cost savings and a great user experience.  During the 2-day requirements gathering meeting which follows the sales to implementation hand-off, one of the big parts of my job is not just gathering functional requirements and building the stakeholder relationship, but also gradually and carefully grounding those expectations which are often floating in the stratosphere.

This is a very tricky, balancing act that requires the BA to use all the soft skills they have at their disposal.  The customer’s enthusiasm and eagerness needs to be maintained and nurtured. Kill that now and you set up a long and difficult road for the project.  But let them run free and unchecked and you have a bigger problem and will set up the project to fail.

Expectation setting must not mean be negative.  The chips and knocks to their ideal of the project must happen organically and naturally as the conversation develops and the requirements are gathered.  It is because of this that I feel the BA is perfectly suited to the “Expectation Enforcer”.

With each requirement elicited comes the opportunity to gauge what the customer is expecting.


The BA must address each and every one of these expectations.  Probing, questioning, and resetting the scene to approach the problem from a new perspective, just as you would for a functional requirement.  As this discussion progresses you must latch on to what to what is possible, and enthusiastically confirm that assertion.  As we all know, start with a positive before delivering less favorable news.  Then carefully bring the customer down out of the cloud, ensuring they understand the realities of the project.  Whether that be the customization limitations of an existing SaaS product, or the constraints of a new development project, where cost, time or scope may mean their expectation cannot be met.

As is so often the case, using visuals greatly assists the process.  Working with a SaaS product, I use the requirements meeting to run demos in a test database, and show exactly what it is they are getting at every turn.  This works really well at transferring the enthusiasm from the ideal in their head, to how it will actually look and work.

Often the functionality is as they expected, it just works in a different way to the mental model they had developed during the sales cycle.

If working on a new development project, the principles of Agile and User Centered Design will play a big part in reigning in the expectations also.  Delivering working products quickly, soliciting constant stakeholder feedback, testing and iterating, will make sure that the customer understands quickly the realities of the project.  If you are working on a waterfall project (I feel for you), showing prototypes and using whatever visuals you have to hand as the project develops will help fend off the “this isn’t what we expected” comment when the product is delivered.

I would love to hear other BA’s opinions on this topic, particularly those working on new development projects, and how you approach this critical issue.

Thanks as always for reading.

The BA and Expectation Setting

Case Study Part 1: Adding a process flow diagram to a Q & A driven requirements process

I recently suggested to my boss a way to incorporate a process flow diagram technique in to our requirements gathering process. She liked the idea and allowed me to run a pilot at my last requirements gathering meetings. This is Part one of two articles documenting my experience.

As an Implementation Consultant for a SaaS product, the big kick-off for each project is a 2-day meeting at the customer site. This is a requirements gathering session driven entirely by an online tool that ensures I ask all the critical questions so I can generate the Business Requirements Documents and have the product configured. This question & answer, tool driven process is part of a broader Six Sigma, repeatable and reliable implementation path that the company has invested heavily in over the recent past. This in turn generates lots of data points, measurable and reportable milestones which the QA team use as a stick to beat us lowly Implementation Consultants with when we don’t meet them 🙂

However I felt as though this drive towards fully quantifiable actions and processes had resulted in a very stale and un-engaging requirements meeting. The tool forced the meeting away from a qualitative semi-structured discussion, in to a repetitive question and answer session…for two days!!

  • Where was the consultative approach our implementation procedure and job title highlights?
  • Where was the business process analysis?
  • Where was the free-flowing discussion and use of more traditional BA methods of enquiry and elicitation?

My concerns at this particular issue possibly taps in to a broader problem of operational efficiency programs, such as Six Sigma, throttling fuzzy, qualitative procedures, but that was not my problem to address.  However I saw a great opportunity to include a visualization technique to capture the customers existing workflow that would be directly affected by the new software I am implementing. What I proposed was a business process diagram method, but what that would look like I had no idea at the time.

The key objectives were:

  1. It must be quick and simple to draw / develop in real-time in front of the customer.
  2. It must generate discussion and allow the customer to walk through the process, as it exists today, with no consideration for how it will change with the new software, or more in-depth technical considerations.
Process Flow Diagram Example
Process Flow Diagram Example

This is the example I developed after some online research (thanks to David Morris @GreySkinnedBoy on Twitter for pointing me to the BPMN) and showed to my boss. It builds on a swim lane type method although it will not conform to the linear timeline aspect normally the case with swim lane diagrams.

My hope is that this high level overview and story telling on the customer’s part will elicit requirements that would normally go undiscovered until later in the process. I also want to create a then and now document so the customer will know how the process will look at the end of the implementation, as well as a proposed process flow diagram if efficiency saving options are open following analysis after the meeting.

Overall I hope the introduction of a visual artifact will offer both value to the customer, improve the requirements gathering process and offer more opportunity for real value add consultative work.

Look out for Part 2 next week to see how the pilot went.

Case Study Part 1: Adding a process flow diagram to a Q & A driven requirements process