Now Reading: When it comes to Discovery, make speed not haste
-
01
When it comes to Discovery, make speed not haste
What’s the difference between speed and haste?
It’s all about readiness and efficiency. Importantly, working with great haste will often reduce overall speed.
This is because there are important efficiencies that can be gained or lost during the discovery and design phase of a project. Failure to recognise this and skip to implementation can result in spiralling complexity, technical debt and a high ‘churn’ of requirements.
In this article I want to focus on three key things that should come out of the discovery phase before you should begin implementation.
1. The Overall Operating model
2. The User Stories
3. Is the Juice Worth the Squeeze?
What is an operating model and why is it important?
A digital solution can be a wonderful thing, but it doesn’t exist in a vacuum. Ultimately, a digital solution supports a business operating model. That is its reason for being.
An operating model is just fancy way of saying business process, or in plain English, how the organisation ‘does’ its work.
Understanding that it becomes clear why we need to understand the operating model before we start building a solution. The solution must support the business in its operations.
But it goes further than that, we need to understand the operating model before we even gather requirements.
Why should the operating model come before requirements?
It’s important to understand that the operating model sets the context in which all requirements are written. The requirements flow from the operating model. If the operating model sets out how the business operates, then user stories are the features the solution needs to support those operations.
Within the context of a low-code solution like Dynamics 365, this becomes even more important. The reason is that Dynamics is a product that should be adopted rather than adapted. Whilst it certainly can be adapted, it isn’t indefinitely configurable, it’s bounded by its architecture. It’s important to assess if the product will support the organisations operating model and the requirements that flow from it before embarking on a journey that we can never reach the end of.
Is the juice worth the squeeze?
It’s often a given that the project will proceed to implementation after discovery, which can be an expensive assumption. The most important output of any discovery is to ascertain if there is sufficient business value in proceeding to implementation.
To make that assertion correctly, the discovery needs to be given time understand the operating model, the user stories and to design a solution to meet those needs, in order to calculate if the perceived business benefit offset the estimated costs.
This is a crucial question and one that if asked at the proper time can save a lot of wasted effort and cost.
What happens if I just start building anyway?
There are a few predictable outcomes that follow from this.
The first is that as the operating model emerges, the project will need to pivot to support it. This often introduces a lot of change requests, rework and technical debt. This means you will likely have spent budget on developing features you didn’t need to develop and incur the double whammy of having to spend further budget on removing those features too!
For low-code platforms like Dynamics 365 and Power Apps, this is even more important as change often takes longer to implement than developing new functionality. This is because the development environment is ‘managed’, the very thing that makes it quick to build slows the process of making changes by managing dependencies.
For example, if you want to change a fields type from a text box to a choice field, you must delete that field first. To delete that field, you need to remove it from every view, form, report and business rule in which it exists.
Effectively, you need to disassemble a lot of the functionality you have built to remove those dependencies, it isn’t code that you can just search and replace.
On deleting that field, any data stored within it is lost, unless you migrate it first and finally, after deleting and recreating the field, you then need to manually add it back to all of the views, forms and business rules you just removed them from. Phew!
And if the above sounds like a lot of work to implement a simple change, you then must consider the documentation. User stories will need to be updated and the test scripts based on those stories will also need to be updated along with the data dictionary.
In practice what usually happens is that you introduce technical debt and the documentation gets out of synchronisation which absorbs a lot of time. For example, you often get conflicting user stories.
You must understand that a user story has a temporal element. It isn’t the requirement; a user story is simply a snapshot of a requirement at a fixed point in time which can be changed by a later user story.
This becomes clear during regression testing, as existing test scripts developed against the original user story are testing for something that is no longer valid leading to false bugs, which all take time to resolve.
In some cases, a specific change in the operating model may invalidate all previous testing. For example, should the model change from a local processing model to a HQ model, then key security roles will need to change. At that point, no guarantee can be made that the system will continue to function as it did without a full regression test, which can be a lengthy procedure.
In some cases, the degree of change is so great people in the team lose track of what the latest position should be, or why a function works the way it does. This is particularly true when developers are asked to make changes directly to ‘speed things up’. Sometimes you can remember several decisions about the same topic but can’t recall in which order they occurred and the latest decision.
There are strategies to address the temporal instability of requirements I’ll cover in another post, just be aware that change can create a lot of confusion.
Why do so many businesses ‘skip’ to the build phase?
There are a couple of reasons companies exit discovery too early and it’s a recurring theme. Mostly its due to the perception that unless you are building something, the project isn’t demonstrating value.
This is particularly true where the implementation team is stood up from the beginning at the start of discovery. With a team of developers, testers and an Architect on board, the burn rate or how much it costs to run that team can be expensive. It creates an underlying pressure to start building. To build anything.
A recurring argument is ‘anything is better than nothing, and we have to start somewhere and then iterate’. Whilst this often appears sensible, it’s not logical. It assumes the implementation work is carrying you vaguely in the right direction, when it could close off avenues and shortcuts that would have let you reach the required outcome earlier or at the very least, cause you to have to spend effort undoing work that was carried out in haste.
What should you take away from this?
1. The first key take-away is to understand the difference between haste and speed. Slowing down at the beginning of any project to fully understand what you need to build can increase the overall speed of the project by minimising wasteful change. This is particularly true for platforms with managed environments such as Dynamics 365 and Power Apps.
2. The second thing is that understanding the operating model before you begin gathering requirements isn’t the gold standard. Its part of the minimum entry criteria for a successful business outcome. Everything you assume, define and build is based upon it.
3. The third thing is not to assume a project is worth pursuing. By adopting this ‘wait and see’ mindset you can also avoid the mistake of ramping up the development team too early, creating underlying pressure to start implementation before you are ready.
4. The decisive point is that time spent in discovery is never wasted. For any solution to deliver business value you will need to understand your operating model and requirements. Your only real choice is whether you take the time to understand those before you build the solution, or afterwards when you realise it doesn’t meet your business needs. As any good carpenter would say: “You should always measure twice and cut once”.
If you want to learn more about the Microsoft Team here at Capgemini, take a look at our open roles and consider joining the team!
When it comes to Discovery, make speed not haste was originally published in Capgemini Microsoft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
