Guidelines For Effective Delivery Process Implementation
You've designed your new approach - now to avoid the hurdles and pitfalls as you implement it.
While this article can stand alone, it is also a follow up to an earlier post, Characteristics Of A Healthy Delivery Process. In that article we looked at what to focus on when designing a broad-based delivery workflow. Much of what we covered there would be applicable to any workflow or process.
In this post we’ll discuss how to implement a broad-based delivery workflow effectively and with a minimum of disruption, overhead and anxiety while maximizing value. Again, much of this will be applicable to any significant change initiative with many stakeholders and a broad impact.
When many think about creating or revising processes they tend to think about creating a list of rules (often in isolation) that others will simply follow to achieve the desired result.
In my earlier article, Characteristics Of A Healthy Delivery Process, we explored all of the nuance and collaboration that is appropriate to designing a broad-based process.
In this post we will explore all the nuance and collaboration involved in implementing that process.
The reality is, of course, that there will be material overlap between designing and implementing a procedure, as there should be. I chose to separate the two because in many ways the concerns of each “phase” are distinct and the success of implementation is in large part dependent on successfully addressing the concerns outlined in the prior article.
What follows are some characteristics of a successful implementation of an end-to-end delivery workflow with many participants and stakeholders.
Communicate, collaborate, plan and commit: This is point zero because, while they are the culmination of everything that follows, these items should be first in our minds.
Set Directional Goals: Early-stage goals that are too low-level encourage delay in implementation due to over-analysis and can also remove a sense of continuity over time.
Start simple: A key to minimizing disruption is make small initial changes that support your larger goal.
Start where the organization is: Another key to minimizing disruption and frustration is starting from how your organization currently works.
Iterate: If we have implemented the last two objectives (and recognize that processes need to be owned), planning on and communicating an iterative approach is the most effective way forward.
Learn by doing: This is implied by our iterative approach but is important enough (and overlooked enough) to call out specifically.
Iteration isn’t implementing a predefined plan step by step.
Iteration is understanding that we can’t know everything in advance so need to plan on building as we go based on lived experience, new learning and changing requirements.
Consistently add visible value: People are generally change-averse. Frequently adding demonstrable value helps alleviate this.
Enage: We don’t only want to be a spectator to the success or failure of our planning, leaving others to do the work. Find an opportunity to actively own some piece of what you are implementing to add value and get first hand insight.
Fire fight: Addressing active crises is a great way to “learn by doing” while also “consistently adding visible value” as immediately as possible. Implement change in a way that addresses immediate problems and reap the benefits of helping while having our theories tested under fire.
Defer tool selection and material financial expenditures as long as feasible: Picking a tool or other investment locks us and our colleagues into certain behaviors, interactions and workflows. We want to defer this investment until we are sure we understand how our organization naturally works most effectively and how a specific tool will support that.
0. Communicate, collaborate, plan and commit
Again, step zero because, while it’s the goal of the steps that follow, it should also be the foundation from which we approach all these steps.
Our implementation work should be viewed in the context of:
Communication:
We want to intentionally and consistently communicate where we are, why we are here and where we’re heading to all that are impacted by our work.
We especially want to speak to where our approach our outcome will not immediately meet the desires or expectations of individuals or teams.
We should plan on not only receiving feedback but also meaningfully responding to feedback either in terms of explanation, changes in planning, the addition of new goals or activities, moving forward strategy, etc.
We are not delivering platitudes to simply justify what we are doing - we are engaging as advocates for those who need more than we can do right now.
Critically, we want our teammates to understand that this is not a “one and done” activity and that we will be improving and refining as we go.
Collaboration:
Our work creates work for others and we never want to ignore that.
We want to solicit feedback about feasibility, timing, capacity, etc. and accommodate concerns as necessary.
We want team mates to feel they are contributing to this change, not being subjected to it.
Planning:
We have insights to goals, constraints, pain points and concerns of our team and have adjusted as appropriate.
We now use these insights to craft our implementation plan.
This plan should address everyone’s needs and, where ideals could not be accommodated, include intentional, proactive communication regarding why certain desired aspects couldn’t be addressed and, where applicable, a remediation plan for any negative impacts or where addressing them may fall on a future roadmap.
Another opportunity to remind folks that what we implement today will be refined based on their needs and feedback.
Commitment:
Now that we’ve planned we want to make public commitments.
They don’t need to be set in stone and can include caveats, reservations, and aspirational goals.
What is important is that some specific person says clearly “This is what the process looks like, this is what success looks like, this is what failure looks like and I am the person responsible.”
Part of this commitment demonstrates ongoing process ownership, reinforcing that we will continually improve based on our lived experience.
I think the frequent oversight (or even avoidance) of these elements is what contributes to resistance to change, and for good reason.
Also, since we are inheriting these biases we should expect to have to earn the trust and support of our colleagues. This is, quite appropriately, part of our work.
What we don’t want to do is just drop a list of new rules and working models on a large group of stakeholders and participants and just say “Ok, do this now.”
We don’t want this because:
It removes agency from our teammates and not only makes them feel disenfranchised but is, in fact, actively disenfranchising them.
It assumes we have put this model together already knowing everything (which we don’t!) and there is no room and no interest in the input for those we are affecting.
It messages a lack of collaboration, empathy, communication and planning abilities which immediately sows the seeds of distrust, resentment and resistance.
Implementing a broad based delivery process affects many people, most of whom will react differently, have different concerns and also have unique contributions that should be included in our delivery model and planned for in our implementation.
It is our responsibility as change agents to make room not only for the acclimation of our teammates but also to hear, receive, accept and respond to feedback to improves our initial design and address disruption concerns.
1. Set Directional Goals
We always want to set goals for ourselves and for the results of our work.
We want to be able to demonstrate our successes or own and improve on the results of our failure.
So we want to have defined goals and success metrics.
At the same time, we want those goals to be informed, realistic and relatively consistent over time.
Note I’m not talking about goals regarding our process implementation, I’m talking about the results of our process changes, which will be reaped over time.
I mean meeting the value proposition to the organization, teams and individuals for the work we’re doing.
I would construct the initial goals of any complex change initiative to be directional rather than specific1:
Increase revenue not Increase revenue by 10% in two quarters
Decrease tech debt not Eliminate all tech debt in year one
Increase team satisfaction not Design and implement 4 initiatives to improve morale
Decrease production defects not Bring production defects to 0
Beneath each “headline” can be the actions we’ll take or the aspirational success criteria, etc. but leading with the headline is key. As our processes mature and we learn more, we can confidently become more specific about what improvement and success looks like (up to and including committing to percentage increases over time and that sort of thing).
There are a few reasons for this
We want our goals to be informed, not arbitrary: at the outset of a change we know the least about what to expect from it. We are literally the most uninformed so being overly specific may simply be premature. We don’t want to set a goal simply to have a goal - we want it to be informed and realistic.
We want to set realistic expectations and encourage support and buy-in: If we say we will increase revenue by 20% and come in at 17% there are many who could view that as a failure where that increase may be remarkable in it’s own right. How we set expectations is key to whether what we do is perceived of as successful.
Better continuity and communications opportunity: Building goals like this provides better continuity in terms of reporting out to the organization. We can publicize those same Directional Goals quarter after quarter with increasing specificity as we learn and mature. As an example, we should always be able demonstrate progress on the Directional Goal, Increase revenue, on even a weekly basis (including what we are doing to add greater specificity to the outcome (e.g. 10% next quarter)
Reduced risk of analysis paralysis: For some organizations or individuals, committing to specific goals creates anxiety and spurs deliberation, debate and delay. We want to sidestep all that and get to adding value. When a house is on fire we don’t want to discuss how much water to throw, we want to quickly agree we should throw water. This approach helps get us there.
Consistent progress is often more important than creating goalposts: We want to establish the understanding that meaningful progress comes with consistent improvement over time. And that improvement is the result of consistent learning, evaluation and optimization.
We also want to establish that, as an organization, working on that progress over time is a job and piece of work as important as any other. Directional Goals with the ongoing discussion on progress against them, the development of detail beneath them and continuing increase in our ability to define, meet and exceed them supports that perspective.
Of course, if parts of our process were designed with very specific goals in mind, we have done the diligence to understand how we can realistically attain them there is no reason not to include those details. They were part of our commitment from the outset.
2. Start simple
Set and communicate the big value proposition but plan on implementing it simply and incrementally. Big shifts cause big disruption, small shifts consistently add value while minimizing disruption.
3. Start where the organization is
A way to start simply but add value?
To minimize disruption while adding value we should “fold in” improvements to existing workflows and sensibilities rather than dramatic changes. We begin where the organization is and incrementally move towards our gaol state. In that way our improvements don’t undermine current productivity and don’t negatively impact our teammates but add value.
As an example, I was responsible for designing a new delivery workflow process in a product-based tech company. The organization was managing their entire delivery pipeline in a spreadsheet that also contained bits of requirements information, some product value detail, a few features and random notes. It had no meaningful prioritization or timeline information, demand and capacity wasn’t planned for. The artifact had information but to even call it “a list” would be generous.
I knew the end state would be a completely different tool but I also knew that:
I didn’t have enough information to determine what the right tool would be and
that introducing a new tool at the outset would hobble current productivity and be frustrating to the team due to disruption, learning curve, change adversity, etc.
What I did was modify their current spreadsheet and approach using that same spreadsheet, additional spreadsheets and other zero learning curve tools like text documents, etc.
We pulled out any requirements information and segregated that to one artifact (with owner), any product team information to another artifact and then added things like prioritization, timeframes, etc. to the initial spreadsheet.
So now we’ve advanced of goal of improving our delivery process because we now had three discrete artifacts: one reflecting requirements, one reflecting product team concerns (market interest, etc.) and one reflecting planning (prioritization, desired timelines, etc). All in either a spreadsheet or document. All with owners who understood what information that document should contain and was organically engaged with that information on a daily basis.
As a result there was an mindful change in meeting focus so, where discussions on requirements, product design, prioritization and timeline had all been conflated they were now distinct - we could establish priority and timing and address team capacity with relatively high level discussions and then dig into the details of those items that were of immediate interest. Each meeting could also have a smaller group of participants.
That had a huge immediate-term efficiency and transparency gain with very little added administrative overhead and no disruption to workflow.
We iterated on that and, once we matured the process using existing tools this learning provided detailed requirements for precisely what features we wanted in a new tool, the workflow we wanted it to support and the gaps we wanted it to fill.
As I’ve previously stated, we want to be confident when we invest in a new tool but it also doesn’t need to be a lengthy process. In this case achieving that level of confidence only took a few months.
4. Iterate
So we’ve committed to certain achievements, we’ve started in whatever place the organization is and we’ve agreed to start simple. We also have overarching and longer term goals. How do we move forward?
We iterate.
Iteration is not incrementally implementing a plan that was defined and finalized in advance.
Iteration is realizing that we know the least at the beginning so should plan on defining next steps as we go.
What we aspire to is a nimble organization that is constantly self-evaluating, can anticipate and recognize the need for change and has developed the ability to change without disruption.. This requires ongoing ownership.
That owner can then manage the implementation in a way that maximizes benefit while minimizing disruption and also organize and management ongoing improvements over time as we learn more, receive feedback from our colleagues and the like.
5. Learn by doing
Anytime we engage in something new we are learning about ourselves even as we are teaching ourselves.
As we implement our delivery process we will learn where what we originally expected matches reality and where it doesn’t and we will adjust our approach accordingly.
As I said above, “iterating” isn’t implementing on a predefined plan in a step-by-step fashion. Iteration is understanding that we can’t know everything in advance so need to plan as we go based on lived experience and new learning.
It is important that this is part of our plan from the outset and is communicated clearly. If it isn’t many can feel “adrift” and directionless.
It can also seem like we have no plan and are making up as we go when, in fact, our plan recognizes that we do ourselves a disservice by proceeding as if we know everything at the outset and that learning by doing and iteration leads to the best outcomes.
So a critical part of our ownership includes synthesizing that learning based on our perceptions and feedback from our stakeholders and planning for and acting on that learning as part of the initial implementation and over the life of the process.
6. Consistently add visible value
Earlier we mentioned change fatigue and change skepticism.
Much of that is due to lack of accountability (which we addressed in point zero) and much of it is due to lack of visible results, which we’ll address here.
Our teams work hard and, simply put, change adds to that burden.
It’s important to consistently demonstrate value even as we’re altering their landscape (i.e., temporarily making it more difficult for the team to get things done). Putting a focus on helping rather than just “changing” not only adds practical value quickly but messages that team members are our priority as much as the work and also that we’re “in it” with them. It lets then know were on their side and are not taking our impact on them for granted.
When we plan our implementation we should be looking at how to apply our design in a way that, as quickly and consistently as possible, helps people get their work done and alleviates burdens, bottlenecks and pain points across all teams.
7. Engage
We don’t want to be “architects from on high,” simply issuing guidance and waiting to hear feedback from others on where our model works, where it doesn’t and where our mistakes are. We should seek to own some work that utilizes our new processes or some aspect of their implementation.
We want to spend time in the trenches.
Then we not only add value and learn by doing but also have invaluable first hand experience in how our theories and designs align with reality.
As well, our active engagement adds an additional set of hands to the ongoing work. This has a few benefits:
It alleviates some of the burden on the team of the changes we’re making because we will handle them on their behalf (with their feedback, of course!).
Our participation adds another person to the team doing the work, adding value to the effort beyond our process implementation.
We again demonstrate our interest in directly helping our team mates and in adding value quickly which will be recognized and appreciated.
8. Fire fight
An effective way to engage, add value quickly and demonstrate our commitment to supporting our colleagues is to look for where problems exist and plan on implementing there first. That not only stress tests our theories but adds helps out team members in crisis by adding our hands to the fire brigade.
We, of course want to be selective, looking for fire-fighting opportunities where we will add more value than disruption but if we have designed our processes and planned our implementation well there should be clear candidates.
9. Defer tool selection and material financial expenditures as long as feasible
I covered this in my earlier article Characteristics Of A Healthy Delivery Process, but I think it’s worth repeating.
A new tool is an emotional, reputational, financial and practical investment. Once a tool is picked someone has approved it, someone has paid for it, teams are trained on it and people are committed to it. It is extremely hard to back away from that regardless of any inefficiencies.
The result is that you may end up with a tool that doesn’t reflect how your organization wants to work organically and is instead a tool that is forcing your organization to work in a way that isn’t natural to it.
But now you own it so are married to using that tool.
And slowly your working model dysfunctionally adapts to the requirements of the tool rather than the tool supporting your organization exploring and determining its unique needs.
For these reasons I suggest postponing the investment until you are certain you understand your organizations requirements and workflow and fully understand the value you’re looking for.
And this needn’t be arduous. I’ve successfully gone from sloppy spreadsheets to lovely portfolio management tool reports in a matter of months. But we need to have the right order of operations in place. Understanding your org and how they work absolutely comes before selecting and investing in a new tool and the implied workflow and limitations that come with any tool.
Well, so that’s it.
Between my earlier article and this one everyone should now know everything they need to design and implement and and to end delivery workflow.
Of course I’m kidding.
My intent was to provide some broad strokes regarding what to be attentive to when doing this kind of work. I’m sure there are considerations I didn’t address even at that level or things that are job, industry or role specific that I missed.
Please jump into the comments - I want this to be a community and a discussion, not just a monologue My future articles will be largely based on those questions, comments and discussions.
Look forward to hearing from you!
There are, of course, initiatives that are specifically undertaken to Improve X by Y in Z timeframe. There is absolutely nothing wrong with that. This is for work that doesn’t have that requirement but where we still what to set goals for ourselves, our progress and the value of our work.