You are the Delivery Manager. There are 1,000 people in your organization. Twenty-five of them are on your project. Of the 25, six defined "done" for this deliverable. In your opinion, you delivered some of your best work. Twelve people, not on your project, come out of the woodwork telling you things are missing from the deliverable. You're surprised. The project sponsor is mad. Your big boss wants answers. And the delivery team wonders why you're letting people say harsh things about the deliverable and team without a fight. The deliverable cannot go to market until you get this figured out. What happened?
Many people suggest this is a problem with the Delivery Manager. Some suggest that stakeholder requirements were not identified and managed correctly. Others blame tools, processes, procedures; some notice internal kingdom-building, protectionism, and turf wars. A few even suggest the technologists who built the system are basement-dwelling anti-social figures of darkness who deliver what they want and don't seem to know or care about business needs. While these conversations may be entertaining, in the end, finger-pointing conversations don't solve the real problem.
The answer is simple and accessible.
The problem starts inconspicuously at the beginning of the project when people are classified as one of two groups: requesters and builders.
After that, requesters are decomposed further into three groups – now, later, never.
From above, the "deliver now" requests are then prioritized even further into:
It seems deductively logical and very efficient.
Grooming a backlog is a learned skill. And when done well, it enables team focus and success, manages project risk and reward, as well as provides iteration upon iteration of value to the targeted stakeholders. A single, frequently curated, and prioritized backlog is a healthy core behavior of successful projects.
Over-zealous backlog grooming may also be why you're missing expected functions, features, and attributes when projects are delivered. The project team thinks they are done, and yet things are missing.
Have you considered that teams are so efficient at curating the backlog that stakeholders and requirements are collateral damage?
Create a cross-functional strike team responsible to securely operationalize the planned project deliverable – from inception to delivery. A project is not just documents and code. Projects operationalize ideas to serve clients, expand opportunities for growth, and generate revenue.
To securely operationalize requires a complete end-to-end cast of people from project sponsorship to design, develop, test, inspect, and secure to back-office operations including finance, procurement, sales management, and support services.
Then as a team, perform the following steps incrementally and iteratively through the course of the project – and support – efforts:
To have the highest probability of delivering something useful to most, we need to know what they want by including more people, more roles. Conversely, to have the highest probability of dissatisfaction with the deliverable, exclude people and guess on their behalf.
You may be wondering, if there are going to be higher numbers of stakeholders and higher amounts of requirements, how are we going to get this done without lengthening the project, increasing the cost and adding to staff?
Enter the role of automation.
Developers are expected to do many things. Writing code is a means to an end, not the deliverable itself. To deliver more value, minimize context-switching, and increase flow, developers seek optimizations.
For some, optimizing means cutting things out and kicking them down the road. For many others, optimizing means automation.
What do I have to do?
What can I aggregate, separate or eliminate
What do I have to do manually?
What can I automate?
A fantastic result of developers who seek efficiencies through automation is that those same efficiencies can be used all along the delivery pipeline and out into general availability/production.
For some great examples of how developers seek to simplify through automation, look to Will Rubel, and his four-part series on test automation in delivery pipelines.
What about all of this makes automation and continuous delivery inclusive?
Remember the cross-functional strike team previously discussed? Many times, stakeholder numbers are minimized to control scope, time, cost, risk, and complexity because the developer, respectfully, is the constraint.
Automated continuous delivery pipelines change the math regarding how many stakeholders, requirements, and developers are required to deliver value.
With automation, we decouple the dependency between requirements and the capacity to meet them.
There are three keys to moving into this new paradigm:
Cross-functional teams contribute to the discovery, definition, and prioritization of roles, capabilities, and attributes in the backlog and participate in demos to verify value. The smaller strike team who makes the code commit, builds, verifies, and delivers the solutions also creates automated tests along the way.
Together, they rely upon definitions of done, automation, and the continuous delivery pipeline. Together they deliver a solution.
We don't need to run from, defend against or hide from stakeholders and their expectations. Instead, invite them. Then continuously curate, prioritize, and automate their feedback.
If you're perplexed by delivery teams saying they are done, but the solution delivered seems short on features, functions, and value, the conversation more likely lays around how software is being defined and delivered instead of what.
Their answers point you to your next steps.
Trility joined Bâton Global for a podcast series on Human-Centric Transformation. In the four-part series, they discuss how leaders and technology can simplify and automate processes for team members, stakeholders, and customers. Before you listen, view our companion infographics highlighting key takeaways as these organizations discuss how to better respond to industry headwinds and pressures.