The kind of accountability most of us are familiar with is direct accountability: a role is assigned a task and is directly accountable for their result. The role understands the quality, quantity, timeframe, and resource constraints of the deliverable and has the authority to implement plans to achieve it. When completing a RACI this is what we mean by accountability.
Ideally, the individual with direct accountability has the context to understand the limits in which they must work and sufficient knowledge about all of the factors that must be considered to make good decisions. However, that’s not always the case, and for this reason, organizations need to establish lateral roles of indirect accountability to ensure these factors are brought to the attention of the role with direct accountability.
Indirect roles are responsible for initiating action toward directly accountable roles. Indirect roles may be responsible for:
Informing: being aware of the factors surrounding the direct and initiating contact to offer advice and recommendations.
Persuading: persuading the direct to adjust their actions when there is a risk of undermining process control or when multiple roles fail to work together effectively.
Instructing: ordering the direct to stop when working outside of limits and/or take prescribed action to mitigate a catastrophic event.
Responding: Provide the direct service and support
Often these indirects are accountable in a supporting process.
In the post “Review of Process/Procedure” I mentioned how the document draft and review cycle can be seen as an iterative design cycle. In this post I want to expand on the design lifecycle as a fundamental expression of PDCA that sits at the heart of all we do.
PDCA, a refresher
PDCA (and it’s variants) are a pretty tried and true model for process improvement. In the PDCA model a plan is structured in four steps: P (plan) D (do) C (check) A (act). The intention is create a structured cycle that allows the process to flow in accordance with the objectives to be achieved (P), execute what was planned (D), check whether the objectives were achieved with emphasis on the verification of what went right and what went wrong (C) and identify factors of success or failure to feed a new process of planning (A).
Conceptually, the organization will be a fast turning wheel of endlessly learning from mistakes and seeking to maximize processes in order to remain forever in pursuit of strategic objectives, endlessly searching for the maximum efficiency and effectiveness of the system.
This design lifecycle just takes the PDCA spiral and spreads it across time. At the same time it breaks down a standard set of activities and recognizes the stage gates from moving between startup (or experiment) and continuous improvement.
Identifying the Problem (Plan)
At it’s heart problem-solving requires understanding a set of requirements and building for success.
I always go back to the IEEE definition of “A requirement is a condition or capability needed by a user to solve a problem or achieve an objective; a condition or capability that must be met or possessed by a system or system component to satisfy a contract ,standard, specification , or other formally imposed document; a document representation of condition or capability “
A requirement can be explicitly stated, implicit, inherited or derived from other requirements.
The first place to look for requirements is the organization itself.
The cultural needs of the organization drives the whole problem-solving and requirement gathering activity and it starts by being clear on Strategy and understanding the goals and objectives and how these goals percolate to the different business processes that we are improving. This gives a good starting point to focus on what opportunities to be explored and what problems to be solved.
It is not uncommon in the problem-solving phase that the objectives/needs are not known, so we must work our way through figuring out what the initial need is. Go back to the fundamentals of understanding the business processes “as-is” and review existing regulations, standards, guidelines and other internal sources of requirements followed currently. This is the time to interview stakeholders and go the GEMBA.
We state the problem, and re-frame it. And now we can move on to Requirement Elicitation.
Requirement Elicitation is the process of probing and facilitating the stakeholders to provide more clarity and granular details pertaining to the (usual) high-level requirement gathered so far. This is a discovery process, exploratory in nature, focusing on finding enough details so that a solution can be envisioned and developed. Elicitation is not an isolated activity, and has been happening throughout the process by all the discussion, interaction, analysis, verification and validation up to now.
You should be engaging with knowledge management throughout the cycle, but ensure there is specific engagement here.
It is a progressive process where the requirement clarity ushers in increments and may need multiple rounds of probing/discussions. As the new details are uncovered the requirements are further elaborated and detailed. There are a whole toolbox of elicitation techniques and like any engagement it is important to properly prepare.
Requirement Analysis pertains to extracting the requirement out of the heaps of information acquired from various stakeholders and communicated and turned into documentation in a form that is easily understood by the stakeholders, including the project team. Here we are engaging in requirement refinement, modification, clarification, validation & finalization and engaging in extensive communication.
In this design process, we address and use empathy to acquire insight into users’ (stakeholders) needs and inform the design process and create a relevant solution. Using an approach informed by cognitive empathy, we apply different methods to build up that competence and insight, enabling us to prioritize the needs of the users and make the results of the process more desirable.
Every change (and lets be frank, most everything involves change) requires understanding the individuals and groups that will participate or are affected – directly or indirectly.
Stakeholder analysis involves identifying the stakeholders and analyzing their various characteristics. These characteristics can include:
Level of authority within the organization and the domain of change
Attitudes toward or interest in the change
Attitudes towards the process
Level of decision-making authority
The goal of stakeholder analysis is to choose the best collaboration and communication approaches and to appropriately plan for stakeholder risks.
There are a variety of mechanisms for doing this and then mapping it out.
Start by brainstorming a list of the stakeholders by answering these questions:
Who will be impacted?
Who will be responsible or accountable
Who will have decision authority
Who can support
Who can obstruct
Who has been involved in something similar in the past?
Map these on a stakeholder matrix based on relative power and interest. This should be an iterative process.
High influence/High Impact: these are key players and effort should be focused here to engage this group regularly
High influence/Low impact: these stakeholders have needs that should be met so engage and consult with them while also attempting to increase their level of interest.
Low influence/High impact: these stakeholders are supporters and potential goodwill ambassadors. Engage the group for their input and show interests in their needs.
Low influence/Low impact: the stakeholders can be kept informed using general communications. Additional targeted engagement may move them into the goodwill ambassador quadrant.
Another way to look at stakeholders is though an onion diagram.
A RACI is another popular way to look at stakeholders.
Once stakeholders are identified is is important to define how communication and engagement will achieved. There is usually no one sized fits all approach and it is important to meet the needs of each stakeholder group to ensure their interest and involvement is maintained. Some considerations include:
timing and frequency
delivery methods (in-person or virtual)
preferences of the stakeholders
geographic considerations or impact
Document this in a communication plan, including:
what needs to be communicated
what is the appropriate delivery method
who the appropriate audience is
when communication should occur
frequency of communication
level of detail appropriate for the communication and stakeholder