Stakeholder management refers to establishing an understanding of stakeholders, relationships, expectations and objectives. Stakeholders are people or organizations who are affected by the outcome of an project, programme or other business activity.
Much has been written on the topic of Stakeholder Management covering stakeholder identification, analysis and management via tools such as Stakeholder Matrices, bubble charts etc. In Holistic Software Development we put the focus of stakeholder management on people, relationships and communication.
Stakeholder identification must be done as part of the elaboration of requirements from initial Customer Requests or Portfolio Requests. Day to day engagement with stakeholders will happen as part of the requirements, build, release and feedback cycles. Stakeholder management is critically important to Product Adoption and Business Change as well as Software Process Improvement and Adoption.
Stakeholders are often mapped onto a matrix formed by the axis of Influence and Interest leading to four classifications of Stakeholder:
We recommend actively managing relationships between teams, business representatives and customer representatives. Instead of plotting stakeholders where they are on the above scale we also think about where they need to be, and how we can get them there. To this end we find that qualifying relationships on a scale of “Conflict” to “Rapport” is helpful:
All communication between individuals, teams and organizations happens in the context of a relationship and can affect that relationship in positive or negative ways. Messages can be communicated in the clearest simplest ways when a state of rapport exists between people. Admittedly outright conflict can also be used to unambiguously communicate messages, however we do not promote negative communication and instead recommend conflict resolution and non-violent communication. When referring to rapport across an entire organization the term “Engagement” is often used synonymously with “Rapport”.
Combining this view of “Rapport” with the traditional stakeholder model, gives a way of focusing stakeholder management on either those who will be most receptive to a message and take less effort to move or alternatively focus on those who are most hostile and therefore need the most work to change their position.
Tracking changes in rapport is useful to identify necessary communications actions. For example, if a primary champion with strong rapport in the top left of the matrix has steadily declining rapport with the team a problem may be coming, such issues could even be identified as risks or Bubbled Up. Alternatively, moving people from a hostile position to being a supporter is difficult, if not impossible to do honestly, without gaining rapport.
Leaders are often described as good when they have strong rapport with the people they lead, regardless of the quality of their decisions. We recommend that Leaders use evidence based decision making and stakeholder management to achieve the best of both worlds. Moving into or assuming a leadership position (as a Business Leader, a mentor, consultant, manager etc.) does not automatically confer good rapport with related stakeholders, often the emotional baggage of previous leaders is projected onto the new leader so we recommend actively working on gaining rapport within teams, across teams and entire organizations.
Using HSD to improve rapport
Within teams we use the Team Forming practice to improve rapport.
Across teams we use the Product Forum practice to improve rapport.
Between teams and Customers we use regular frequent involvement, collaboration in planning and other decision making (often facilitated by the Product Forum practice, Requirements stack and demos, testing and trials of builds and releases through Definitions of Done) to improve rapport.
At organizational level we improve rapport between Business Leaders, Customers and Delivery Teams by creating a common focus on Business Value. This is used to align individuals throughout the organization (Establishing Pull) towards customer needs, promoting clear choices of evidence based decision making models, open and transparent Leadership.
The alignment of language, processes and practices using the Holistic Software Development framework itself can also improve rapport in an organization, using the Bubble Up practice as an escape valve.
The term “DevOps” refers to tight integration between the Software Development and Operations parts of an organization.
Holistic Software Development fully embraces close collaboration and a holistic approach to developing systems that involves all stakeholders, including developers and operations. As such HSD is a DevOps process however we do not treat Development and Operations as separate parts of an organization – instead we address the entirety of the Software Development Business that includes Development, Operations, Business Strategy, People issues, Quality Assurance, Portfolio Management etc.
The purpose behind the DevOps movement is to ensure that Operations stakeholders are engaged throughout a software development lifecycle so that operational requirements (especially Non-functional requirements) are included properly. In line with this idea Operations stakeholders, and Operational constraints, must be included in top level requirements and well represented throughout development activity. Operations work, like testing, happens throughout the software lifecycle, not afterwards. Operational stakeholders are involved in the Portfolio Build/Selection practice to ensure that the impact of new product development or maintenance decisions on current Operational positions, and Enterprise Architecture, are understood. Significant changes to current Operational positions are raised as Portfolio Requests so they can be properly costed and scoped.
Work aligned to the principles of HSD must by definition include addressing the needs of all stakeholders from any part of the business. If a divide exists between parts of the business, then the dysfunctional relationship (an example of Conway’s Law) needs addressing rather than process and tooling being introduced. Processes and Tools are helpful to gain agreement on a common approach and automate ways of working but not to solve dysfunctional relationships.
Since HSD promotes regular builds and releases in either iterative/agile or continuous flow models Operations stakeholders must be involved early and often in software development product delivery as a product is likely to be delivered frequently, or even continuously, and so will need transitioning activities performed repeatedly. We recommend treating transition to live environments as a top level Integration Stream and automating transition where possible.
- We promote trust, close collaboration and fast-fail. Most importantly we focus on flow and pull throughout an organization.
- Operational requirements are explicitly covered by non-functional requirements when examining Architectural Profiles.
- Environments and automation
- We strongly recommend automation of environments, build and deployment