“It’s often easy to assume our users are like us -especially if we consume the products we make. The reality is that we have a level of understanding and tolerance for digital ecosystem that our customers [and users] rarely share” 1
In the Prince2 glossary stakeholder is described as “any individual, group or organization that can affect. Be affected by, or perceive itself to be affected by, an initiative (program, project, activity, risk)” 2 . You can find further explanation about stakeholder types and engagement in the Organization Theme. 3 Stakeholders could be a part of the project management team as well as people or organizations such as trade unions, industry regulators, some external contractors etc that would be affected by the initiative. In theory users or customers can be also a part of the stakeholders however, in reality this terminology is often used to describe “influencers” on the project in the organization who directly or indirectly dictates “requirements” of the project. Some might also represent a type of user for the product or service but not necessarily.
As it’s mentioned before in my various other articles, while the traditional project management approach is organized around the process which is shaped by cost, time, and scope (the project management triangle), lean-agile product development approach is organized around the value which can be only defined by the user.
“the only person who gets to decide what the service is, is the person who has the goal they need to achieve – and that’s your user” 4
Therefore, in agile methodologies the “stakeholder” terminology is not being used in a way as it’s used in a waterfall environment. For example, in the Scaled Agile framework stakeholders are separated by customers [and users]. Although their needs help to define the vision alongside user needs 5 and some of them participate in a product development stream as Business Owners outside of the product team, it’s clearly stated that Customer Centricity and Design Thinking is at the heart of agile development. 6 Undoubtedly, Business Owners are important stakeholders that help us to understand the vision of the organization that we want to achieve.
Another lean-agile service and product development approach, GDS (Government Digital Services) puts understanding users and their needs at the beginning of the Service Standards as a first item in the service standards list. 7 Needless to say, we also need to understand stakeholders in the context of understanding the user’s whole problem and providing a joined up experience across all channels. 8
Why do lean-agile approaches put the user at the heart of their value creating activity? Because regardless how “perfectly” scoped and developed our solution is, if it doesn’t meet with user needs, in other words if it doesn’t resolve a problem that the user faces, then either they can’t use it in a way as expected or don’t use it at all. Either way it can’t deliver the value as intended. Therefore, the user and its needs sit in the centre of our product or service development stream.
Inconsistency and waste
However, sometimes (mostly at the beginning of a new initiative) stakeholders might widely represent our users. A close communication between engineers and stakeholders could be a good and effective way to develop early solutions at a fast pace. When the program or initiative is getting matured and progressed towards having more complex products, this developer led and stakeholder centred product development brings two major problems: inconsistency and waste.
We all understand the world around us based on our experience. Without a multidisciplinary product team which can deliver a user centred approach, our products gradually become a reflection of understanding of an individual developer from a “requirement” which was also given by an individual stakeholder based on her/his understanding of the user problem. The problem here, of course, is the inconsistency of human understanding of any issue or need. If we don’t have the right mechanisms in place for regularly verifying our understanding and solutions with users, we can’t avoid creating inconsistent products or service steps alongside some wasteful activities and products.
A Case Study: NHSE – Covid Vaccination Program Information Cell
“The answer is that collaboration is a privilege; not everyone has it. If collaboration was easy, we’d all be doing it. The reality is that it’s very hard to start, and even harder to continue.” 9
When we started our journey in the logistic pod to digitize the Vaccine Supply Planning and Ordering processes, we had challenges around how to improve our product development align with the vision of the program within very critical and challenging deadlines. Initially, we focussed on two improvement areas in GDS and NHS Service Standards that we believe if we target, we can get some early and quick improvements during the supply planning product development stage. We asked ourselves: “how we can improve user centricity and agile way of working”.10 In very early stages we quickly adapted user research into our products development stream, we also applied the GDS phased agile delivery approach as part of the agile way of working. By a Private Beta release we minimized the risk and maximized the learning and iterated the product.
We improved our process even further when we started the development phase for the ordering product. A very successful collaboration between stakeholders, engineers and other product roles made it possible to make significant improvements under a critical time pressure.
By the information cell leadership’s support, in a very short period of time, we managed to create a multidisciplinary scrum team which includes user researchers. This helped us to organise regular user research sessions as an organic part of our product development. We also managed to verify some of our assumptions by creating an MVP prototype (Alpha release). Again the Private Beta release for the ordering product gave us an opportunity to test our product and assumptions in very early stages with the users of the product.
This case study proved to us one more time that even for time critical product or service development streams, when a good collaboration between stakeholders, engineers and other product roles is supported by a vision and leadership of the program, it’s not only possible almost inevitable to make significant improvements towards user centred and product team led development.
1. Lean UX, Jeff Gothelf and John Seiden, 2018, page: 37 [words in the angle brackets are mine, US] ↩2. Managing Successful Projects with Prince2, Axelos, 2009 edition, page: 313 ↩
3. Managing Successful Projects with Prince2, Axelos, 2009 edition, page: 41 ↩
4. Good Services, How to design services that works, Lou Downe, 2020, Page: 27 ↩
5. https://www.scaledagileframework.com/vision/ ↩
6. https://www.scaledagileframework.com/agile-product-delivery/ ↩
7. https://www.gov.uk/service-manual/service-standard ↩
8. https://www.gov.uk/service-manual/design/map-a-users-whole-problem ↩
9. Good Services, How to design services that works, Lou Downe, 2020, Page: 118 ↩
10. https://www.gov.uk/service-manual/agile-delivery ↩
To download Google Doc version of the article: <<Please click here>>