Delivering enterprise scale IT change poses a huge array of challenges. For the Business Analyst one issue that often arises is ensuring that a customer’s requirements and expectations amount to the same thing.
In traditional project approaches there can often be a significant time gap between the up-front gathering of requirements and a user’s first hands-on interaction with a system. For any team with a passion for delivery this can be a nervous wait and there is nothing more demoralising than hearing “this isn’t what I wanted” from a customer.
There are a number of factors that can contribute to this happening, the most common being:
The longer the time period between the gathering of requirements and delivering to them, the higher the chance of a customer’s expectation deviating from the agreed requirements. This might be as simple as not recalling what was agreed six months previously during a dim and distant workshop or it may be more fundamentally that the business requirement has evolved in that time.
As technologists it can be easy to get caught up in a technical solution and forget to focus on the purpose of what is being developed – to generate business value. By writing requirements from the user perspective and focussing on what business value is being delivered rather than how, it allows requirements to be more relatable to a customer and therefore align better to their expectations.
How requirements are documented can be just as important as what is documented. When it comes to signing off requirements, reading through a dry list of bullet points can lead to a lack of engagement and a lack of understanding of what is ultimately going to be delivered. In order to align a customer’s expectations with the requirements being documented it is important that a shared understanding of the purpose of any change is gained.
So that’s the easy part done, the problem has been identified. The difficult step is understanding how to address these issues and ensure that analysis serves to deliver to a customer’s expectations.
BJSS Enterprise Agile takes the core tenets of the agile approach and evolves these to best fit large scale enterprise change. In doing so it seeks to address these issues in terms of both methodology and application.
Be Agile, Fail Fast, React
The iterative approach is the cornerstone of agile delivery and the key to addressing the degradation of requirements over time. Customers are continually involved during delivery through the prioritisation, testing and show and tell processes, allowing the deviation of expectation from requirement to be identified as early as possible in the delivery lifecycle. By failing fast and allowing the delivery team to react to this as quickly as possible, unexpected behaviour does not become baked into an application and the cost of change can be minimised. This continued interaction also builds the trust relationship between the client and the delivery team and fosters the shared understanding required to deliver effectively.
This is neatly illustrated by the lean thinking learning loop:
Take the Customer Perspective
The User Story format focusses requirements back on the customer by clearly identifying the who, what and why of any given change. This format moves away from monolithic requirements documents and presents requirements in easily relatable chunks making comprehension and prioritisation much simpler.
The detail required to deliver stories effectively is captured in the acceptance criteria. By using a scenario based approach to documenting acceptance criteria even the fine-grained detail of the requirement can be written in a user-centred manner. By aligning these with other artefacts such as wire frames and personas and socialising these with users through mock-ups and story boards, requirements can be brought to life for the customer which immediately embeds their expectation into the end product.
Useful or Usable?
User centred design is no longer a new concept and it’s no secret that having a strong relationship between customer and delivery team leads to an end-product with better usability that aligns with a customer’s expectations. But what is the value in delivering a highly usable system if it fails to meet the core goals or, in essence, it is not useful.
At this point we enter the semantics of what is meant by meeting a customer’s expectations. It is possible to meet expectations but still not deliver a useful system. Addressing this challenge requires another article entirely as we enter the realms of user experience.
So what is the take away? How do we address the gap between requirements and expectation?
Involve the customer – don’t leave requirements to pass their sell by date, fail fast and react quickly.
Put yourself in the customer’s shoes – focus requirements on the business value they add not the technical change.
Challenge the solution – make sure the goal is clear and that requirements address the goal in a manner that is both usable and useful.
BJSS Business Analysts played a central role in the delivery of Crisis Hub, working closely with the FCO to prioritise the scope of the application, and decompose the requirements in a way that supported a fully Agile, Cloud-based delivery.
Using the proven BJSS Enterprise Agile approach, a set of fully-traceable requirements were delivered, from benefits case to test criteria, that could be dynamically reprioritised as the scope of the application developed through each sprint.
BJSS assumed responsibility for the leadership of the client’s Architecture and Design team. The team was introduced to a more Agile way of working and best practice artefacts and standards were employed.
Leading from the front, BJSS shortened the design phase and reduced the amount of documentation-lag. The second release was delivered across multiple countries simultaneously with a significantly lower defect count.