In today’s blog post we will start to look into the common symptom; “Contradictory/late requirement changes”. This means that the requirements sometimes are not only late they can be contradictory to the former ones as well.
Asking why, many times on “Contradictory/late requirement changes” gives these three symptoms on the same level.
- “Too many stakeholders that cannot agree”. This is a common problem especially in big organisations with many products connected to one or more big system products. Then it is difficult to agree about requirements that involve many products in the total system. The silo responsible are only interested in their own silo.
- “The customer need is not fully understood”. This is common especially for software product development where there already is existing hardware. Because the hardware is only a container for the software, and we can therefore build almost anything with the software. But, the problem is what to build.
Asking why on this symptom give us the very common new symptom “The customer do not know what to require”.
This is about the complexity and uncertainty that come with Customer Pull and the software product development in the 1990s, which the waterfall way of working cannot handle, see this blog post for details. And as we everybody know, to please the customer is not easy.
That means if we ask why again, we get the symptom “The complexity about the product is underestimated” - “The complexity about the product is underestimated”, we will get directly if we instead look into the hardware side, where we have much more of Technology Push, when the way of working does not favour experimental work to gain the needed knowledge to be able to realise the product. See this series of blog posts for a deep dive in a 25 year old regulator algorithm solution to a very complex software problem.
If we put the symptoms achieved so far in a picture structured like the Prefilled Problem Picture Analysis Map, it will look like this.
We continue to ask why on the symptom “Too many stakeholders that cannot agree”, and then we arrive in the root cause “We do not have control and responsibility over the system product’s architecture”. This is a common problem in silo organisations, since no silo manager can have control over another silo manager, due to the KPI settings per silo. This will be elaborated on in a later blog post.
Asking why on the symptom “The complexity about the product is underestimated”, we will get the symptom “Too slow feedback”. And when working with complexity, we need extremely fast feedback to gain knowledge as fast as we can, so we can enter the ordered domains where we know what to do with or without experts.
Asking why again will get the symptom “Too big batch sizes”, which of course will slow down our ability to get fast feedback.
Finally asking why gives us the root cause “The Integration Events/Aggregation Points are not timely”, which means that we must understand when we need to set our Integration Events/Aggregation Points, so we get just-in-time feedback.
A part of the Prefilled Problem Picture Analysis Map with the chain of symptoms for “Contradictory/late requirement changes” will then look like this:
This was all for this blog post, and in the next blog post in this series we continue with the next symptom, “We deliver customer value too slow”. C u then.