- Separating Deliverables from Effort - How to Eliminate "Tossing Over of the Fence" Mentality
- Separating Deliverables from Effort - An Example in Real Life
- Separating Deliverables from Effort - Keys to Making It Work
- Separating Deliverables from Effort - Why it's Worth It
A classic problem: Someone's developed a solution and it gains the approval of the customer. The solution is passed on to you, the implementer. The solution is vaguely defined, hard to decipher, and committed to a deadline that isn't realistic.
It happens in almost every workplace. Nobody thinks this is the ideal situation, but we continue to grumble and accept this as necessary evil.
Why? Why does this happen time and time again?
A professional services team is comprised of people in multiple distinct roles (see my role breakdown in the last article). If we operate conventionally, the output of one role is the input of the next. A role would only concern itself about its own output, without a care of the other roles. This obsession on the local maximum blinds us to the problems of the global maximum. I call this the "Tossing Over the Fence Mindset", where we measure ourselves on the quantity of work we hand off to the next role. This problem manifests itself through a variety of symptoms:
- Team members grumble and complain that upstream roles (e.g. the solutioners) are cowboys and are able to do whatever they want with no regard for consequences. Conversely, team members equally grumble that downstream roles never deliver on time or on spec
- Solutions get reworked over and over again as they move from role to role because the solution didn't take into account implementation realities
- Timelines are missed because of additional scope creep that wasn't accounted for
- And so forth...
How do we mitigate the "tossing over the fence" mentality? I propose the notion of separating deliverables from effort with this simple mantra:
- Each role is uniquely accountable for their deliverables
- Every role shares the effort that drive the deliverables
What this means is that while the ultimate responsibility for crafting the deliverable belongs to a specific role, the process of which the deliverable is developed involves everyone on the team. I've found that participation in the development process strengthens the quality of the output (amongst other benefits (of which I'll cover in a later article).
Sharing effort ultimately improves buy-in when it comes time to hand output from one role to the next. Because the whole team has had a chance to fully participate and weigh-in, the everyone will feel that the solution is well vetted.
Here are a couple of real-life examples of separating responsibilities and effort:
- Solutioners, planners, and executors work together to develop a solution for a customer. Because the planners and executors had done work for another client with a similar pain, they are in an excellent position to guide the solutioner to craft a solve that has had success in the past, boosting chances of success for the current project.
- Planners and executors work together to develop a deployment roadmap. Because the executor is aware of the development capacity, the planner adjusts the rollout plan into phases to accommodate the capacity constraint. As a result, they are able to craft a roadmap for the customer that has a high probability of hitting milestones on-time and on-budget.
- Solutioners and supporters work together to develop a solution proposal. Knowing the client has had a track record of poor post-deployment follow up, the supporters craft a custom plan to support the customer and include it as part of the proposal. As a result, the customer feels less anxiety because they are well supported from the start of the project.
There are so many benefits to having the team work with each other, rather than deliver for each other. Yet so many organizations are content with having their own team members toss deliverables over fences. The oft-cited reason on why this doesn't happen is because "I just don't have the time to work with the others". If that excuse is being used to justify keeping fences up, then it's time to scale up to encourage collaboration.