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 2: Process Flow Diagram Analysis

The diagram was a challenge but I will persevere!

 Well it took me longer than a week to post the results of my process flow diagram experiment and for that I apologize. I will not bore you with excuses. 

A quick recap for those who did not read Part 1 of this Case Study.  I submitted a proposal to my boss to add a process walk through conversation with the customer during the project kick-off, 2-day discovery meeting.  This meeting is currently driven almost exclusively by a question and answer tool and resulted in a very stale and stunted meeting.  My aim was to engage the customer by asking them to tell the story of their current process, which I would capture using a swim lane type model I had developed, for delivery with the Business Requirements Document. 

The pilot overall went well, however it was a challenging meeting as the customer was not engaged in the process and had provided little documentation beforehand to help me lead the discussion.  But it did achieve some of the goals I had set for the experiment, which were: 

  • Provide a framework for a free-flowing discussion.
  • Elicit requirements that are missed by the basic question & answer format.
  • Allow the diagram to be constructed as the discussion took place.

The challenges I experienced were: 

  • The customer was small and the process being described, although with many parts, was all conducted by one person.  Therefore the customer found it difficult to talk through the process in a more abstract way, linking one section to another.  This highlighted that I had designed the process with a larger customer in mind and would need to tailor it to a small company setting.
  • Creating the diagram neatly, on the fly, was difficult.  The meeting was conducted in a restaurant and I had to do the diagram just with a pad and pen.  I had not prepared for this correctly, not knowing the setting of the meeting until we arrived, and needed a portable whiteboard, or just plain paper and a pencil would have been better.  I will certainly be more prepared next time. 

I will persevere with this method however and continue to work on refining it.  My boss is still certainly on board with the idea. 

Once again it demonstrates the power of iteration, and learning from your experiences.  I will do this again at the next meeting and I will now have these lessons learnt and will start from a stronger position.  I am striving to make sure I personally review my work  and learn from my mistakes.  An internal heuristic walk-through of my work output if you will.  I must embrace my mistakes and challenging experiences and see them as a valuable part of learning. 

Thanks again for reading!

Case Study Part 2: Process Flow Diagram Analysis