Characteristics Of A Healthy Delivery Process
Efficiency, complexity, nuance and people
The words “delivery” and “process” mean different things to different people so I want to state specifically what I mean by “delivery process” here.
When I use that term what I mean is the entire workflow that begins with an idea that is then evaluated and either turns into effort or is discarded.
An idea can come from anywhere; that is entirely dependent on the organization.
It can originate from a sales team, a product team, an executive luncheon or an individual who drops a slip of paper into an “Idea Box.” There is no right or wrong way to originate work and no right or wrong place from which an idea can be spawned.
There are, however, more or less effective ways to handle those ideas.
The purpose of this piece to help those who need to align how all teams, each set up to work at their most efficient, can interact to deliver efficiently, consistently and predictably and without stress, with happiness and despite other co-dependent teams being very, very different in every way.
What follows are characteristics of an effective delivery process. I have not attempted to dictate process specifics as I believe these are unique to each organization based on its needs, skill-sets, culture, organizational structure and goals.
My definition of a delivery process
Includes management of demand and capacity across all affected teams
Includes prioritization of work that is aligned on across all teams
Includes the process(es) required for all involved teams and stakeholders to work together effectively
Includes recognizing and structuring how each team interfaces (including information needed and delivered, what hand-offs look like, etc.) to work together efficiently
Does not include how each team works internally - it is up to them to work as makes sense for them
(Note: I’ll be publishing a follow-up describing the characteristics of a successful process implementation shortly. It will outline actionable steps to implement broad based process change in your organization)
Below are 10 characteristics I consider key to an effective delivery process. Elaboration follows.
Owned: The process needs an owner to lead initial design and implementation of the workflow and to solicit and implement feedback for improvement over time.
Holistic: The delivery process should be a single conceptual flow from inception/ideation through execution and delivery. Simply lining up adjacent processes or groups is not enough - it’s the interactions that are key.
Transparent: All process participants can view up- and down-stream planning and have insight to the entire workflow, even work they are not directly involved in.
Adaptable: The process must be able to change if and as needed based on new learning, organizational changes, shifts in business goals, etc.
Loosely Coupled: The goal isn’t to force each team to work the same way - the goal is to ensure the proper connections between how each team works so all teams work together without friction despite their differing work methods.
Human: People directly working together - meeting, discussing, exploring, creating - are uniquely effective at building and problem solving. The goal isn’t to design direct interaction out of the process (e.g., eliminate all meetings) but to maximize the power and efficiency of planned collaboration.
Recognized: From its inception a new process needs to be announced and communicated. The team needs to be aware of the process and its purpose to both derive value from it and to contribute to its improvement.
Useful: How these methods help people and teams accomplish their specific goals directly and indirectly must be clear. How it serves each discretely is critical - it is being in their service that allows the goal overall workflow to be met.
Lean: We must be ruthless in ensuring that there is no unneeded overhead and that every step in the process adds demonstrable value.
Tool agnostic: Tool selection should follow the process definition, not vice versa.
1. Owned
This may seem obvious, but someone needs to own a delivery process (or, really, any process).
Not only for the initial design and implementation but throughout its existence. As business needs, ways of working and organizational structures change so, too, must the delivery process.
As well, there will always be new learning gleaned from the process being in use. Someone needs to monitor the accumulation of this new knowledge to use it for continuous optimization and improvement.
This doesn’t need to be a full-time role or a formal title by any means, but it does need to be a formal responsibility (even if it only requires a few hours a quarter). People in the organization need to know who to contact and that individual needs to recognise that they have that responsibility.
I have seen many instances where companies felt that setting up a new process was a “one and done” activity. The diligence and design would be done, the process implemented and whoever was responsible would just fade away, either back to their day job or back to their consultancy with no one to replace them. It was never long before the process fell into disrepair and was abandoned.
Worse, while the typical claim was that the process “was never right” or “never worked” or “wasn’t needed,” the truer statement would be that a change successfully initiated for valid reasons failed due to neglect. That misperception breeds organization cynicism of similar change initiatives
2. Holistic
One needs to view a delivery process holistically - from beginning to end, recognizing all the teams, individuals and workflows it affects.
It’s important to realize that each group that contributes to “delivery” has its own sensibilities, priorities, ways of working and ways of measuring success.
For example:
Success in sales can equal number of deals closed
Success in engineering can equal delivering on time without introducing tech debt
Success in product development can equal introducing features and functionality that stays ahead of the competition
Success in customer support can equal the number of calls or tickets successfully closed
Even a cursory glance highlights a troublesome truth: many of these success criteria are in conflict.
As an easy comparison, the ideal for engineering would include taking as much time as possible to understand the problem domain, design a solution and implement that solution as elegantly and robustly as possible.
The ideal for sales, on the other hand, is to close the deal and lock in a customer as fast as possible. And that often involves making quick commitments with limited information.
To be clear, both of these teams and approaches are right in their perspective and both of these teams and approaches add immeasurable value to the organization.
Our work, as architects of our delivery process, is to serve both these interests (and all others affected) equally. We need to take into consideration not only what the process needs from these teams but also (primarily!) what these teams need from the process for success.
3. Transparent
It’s critical that the entire process and what it contains be completely transparent to everyone it affects.
What that means is that a QA tester in the engineering group has access to the exact same view of the work as a rainmaker in the C-Suite.
This is important not just for practical reasons like ensuring common understanding of initiatives and goals and the like. It is also important for cultural reasons - a shared view starts to illustrate the impact of disparate teams on each other; it starts to develop an organizational understanding that it’s “we” not “me.”
Teams and individual stakeholders can see the upstream and downstream impacts of events and decisions.
Management can see the impact on the delivery teams due to shifting priorities or delayed decisions as measured in extended timelines for previously scoped work.
Engineering teams can see the impact to the future roadmap (and potentially revenue!) due to delivery delays tying up resources planned for other work.
4. Adaptable
When we put together a process or workflow or methodology we need to understand that we don’t know everything at the outset and that we also don’t know what we don’t know. And part of what we don’t know is how our new process will affect the teams and stakeholders involved. We’ve done our diligence and research, we’ve talked to people and sought feedback, we’ve planned and analyzed and all the other things that effective change agents do, but the result of that is still only a (hopefully) well-informed and (certainly) well-intentioned theory.
So the process we implement needs to be adaptable - we need to be able to change based on what we find as we roll this process out. Those changes may be to eliminate flaws we uncover with our initial design but, over time, we will certainly find opportunities for improvement and optimization that we could note have foreseen before “living” the process.
5. Loosely Coupled
Before we discuss “loose coupling” I want to provide a conceptual mapping of a delivery process.
Rather than being a single monolithic workflow it’s best to view a holistic delivery process as the mindful and efficient joining of a group of relatively unrelated workflows.
The sales team has its own processes with inputs and outputs.
The product team has their own workflow, inputs and outputs.
The same for engineering, infosec, finance, et. al.
Even executives initiating delivery work as individual contributors can be viewed through this lense.
So the goal of our Delivery Process is to align the work, inputs and outputs of these teams in a way that maximizes the benefits each team provides to the others while minimizing the inefficiency that can occur when different groups with different goals depend on each other.
So when I say our delivery process should be loosely coupled what I mean is that, while we want to beneficially join these workflows we also want to ensure that each group also has the flexibility to work as is most efficient for that group, its culture and its goals.
Importantly, loose coupling also allows each groups’ processes and methods to independently evolve to maximize that group’s effectiveness with minimal impact to other teams.
We want Sales to be able to work as best suits them and also interact with their adjacent teams in a way that best suits those teams. To this end we want to look at those “interfaces” closely while being mindful of giving the groups the autonomy to support those interfaces how best suits them.
So, for example, we may say that the function of Team A is to define specifications and they need to provide those specifications to Team B.
The delivery process doesn’t care how Team A determines those specifications, only that it does.
Further, we would like the way that Team A provides those specifications to be as minimally disruptive to their internal workflow as possible. There is, of course, always some overhead to collaboration but we want to be intentional about minimizing that overhead so that the benefits outweigh the gains.
From Team B’s perspective, we want to ensure that what Team A creates (the information, the format, the method of hand-off, etc.) meets their needs without undermining the needs of the other team.
This same evaluation holds true for all participants - it can be very straightforward but unexpected (or fully expected!) complexities and conflict can emerge.
Balancing these competing needs and aligning on a solution is where the creativity, collaboration and perseverance of our role comes in.
6. Human
People, individuals, are almost infinitely flexible and adaptable and can operate well on limited or incomplete information and on shifting sands. When together we are also extremely efficient at sharing information.
When we are together we also learn to consider the concerns of other groups or individuals in a way that automated or process-based communication alone can’t provide.
In a time of increasing and valuable automation opportunities it’s important to intentionally consider the unique efficiency and value of human interaction and be comfortable incorporating it into our process rather than looking for the process to eliminate the need for that interaction.
This interaction also helps foster a “we” over “me” perspective.
Not all meetings are bad and not all interactions should be considered signs of inefficiencies.
7. Recognized
Simply put, the organization and its people must realize that these procedures exist, understand what they are for, understand the value to them and the company at large and know how to engage with the process if and when needed.
We want to ensure that members of the organization don’t unintentionally circumvent or undermine the process because they weren’t aware of it’s existence or didn’t know how to engage with it.
This may seem obvious but I think many of us have been in a situation where we’ve found out about a process, service or center of expertise that, while valuable to us, we somehow never knew existed.
So communication is key: the organization should be aware when the delivery process is being put together, why, and who is affected.
After implementation the results of this process should be published - improvement in outcomes, morale, efficiency, etc. should be made known.
Over time the efforts at improvement should be communicated, the desire for stakeholder feedback made known and the iterations publicized.
8. Useful
First and foremost the process must provide demonstrable value to all impacted aside from the goal that initially drove the process change. Teams and individuals need to see and understand that the effort they put into the process pays dividends to them either directly or indirectly (ideally both).
So, for example, while the stated goal of a delivery process change may be to better plan for capacity constraints in our engineering team we can’t simply throttle the incoming work. That would have negative effects on, for example, the sales team whose goal is to deliver on deals made. So, even as we work on our primary goal we must also ensure we are serving all stakeholders (individuals and teams) impacted by our procedure and their goal.
We must create a process that stakeholders feel and see serves them rather than a process they feel they are being forced to serve.
This outcome is directly the product of the concepts we discussed under Holistic.
9. Lean
At every step we want to be ruthless in ensuring that the effort adds no more overhead or additional work for anyone than is absolutely necessary and that that work provides tangible benefits. We must provide materially more value than the cost of maintaining and engaging in the process itself.
Ensuring that this workflow is as low overhead and lean as possible goes a long way towards ensuring this value proposition.
10. Tool agnostic
Tool selection should be one of the last steps of process design and possibly not even addressed until sometime after initial process rollout when the methods we developed have been in use. At that point we will have had the opportunity to gauge feedback, refine our initial thinking and assumptions and modify our methods and workflow. It’s really only after that has happened (or in its late stages) that we want to begin evaluating tools because we then risk baking false assumptions into our tool requirements and consequently our workflow.
We don’t want a tool to dictate our process for a few reasons:
If we begin with a tool then we design our process to support the capabilities of the tool, not the people in our organization.
Once someone or some group has identified a tool there is a lot of emotional investment in keeping the tool and it can become difficult to move away from it even if it isn’t the best solution.
Once an organization has made a financial investment in a tool there is a strong bias to keeping it and “making it work.”
If we design our process around a tool then we will gain great insight to how the tool can work but limited insight to how our organization wants to work.
Consequently, as our needs evolve we will have limited ability to imagine an ideal improved future state for our organization beyond what the tool (or similar replacements) can offer.
So there it is - 10 characteristics of a healthy delivery process.
Could you expand it to 20? Sure. Combine it to 10? Absolutely.
This essay wasn’t intended to be comprehensive, but directionally helpful and with enough detail for the reader to have a sense of the goals and potential pitfalls in putting together a process like this as they go through their own planning.
In my next post I will be discussing the characteristics of successfully implementing processes like this that have a broad stakeholder base and impact.
Stay tuned!