Originally presented at SoFloDevCon 2022, this article explores different strategies internal and external teams can use to communicate budgets and roadmaps to stakeholders.
We are a custom software development company (https://tsl.io/), so I’ll use the term “client” a bit more than someone who works for an enterprise making internal tools. Other types of enterprises of course have clients, but the relationship between their projects (software or otherwise) has people called “executives” in the decision-making roles. I will try to use “executive” but for this presentation, they mean the same type of person or committee.
NOT because it is better than waterfall - waterfall works great in many industries. If we lived in a waterfall-friendly environment we’d be having a discussion about Six Sigma right now.
NOT because it is fashionable ;)
NOT because it empowers teams, but just the act of having a retrospective with the people who do the work and acting on the issues brought up is almost transgressive in some other environments.
BECAUSE we live in a complex, ever-changing world and we need a framework that allows us to embrace change as a part of life.
This is not a discussion about “how to be a change agent”, this is going to be a discussion about the realities of planning projects in a Volatile, Uncertain, Complex, and Ambiguous (VUCA) world.
Example: A team might have a definition of done that everyone agrees to, but if “who’s paying” is running low on money, items that were done six months ago might suddenly find their done-ness challenged.
Executives/clients want to know “how much everything will cost”. They don’t like being told that this is literally unknowable unless you can see the future, so we have to do our best to try to get them to define “everything” and use the tools relevant to your organization to:
Organize a planning document describing the roadmap to an MVP, prototype, first phase, or whatever the relevant term is for the first milestone (major or minor).
Depending on your organization's resources, you may use some combination of:
Ask a representative from all stakeholders for feedback, prioritization, and questions:
Depending on the culture of your organization, this document might be very large with many images and design files and flow charts, or it may be a list of bullets.
In any roadmap, there’s a risk of hand waving away a huge black hole of complexity and expense.
This is just a planning document, because something is “just a button” on a mockup, or just a box on a UML doesn’t mean it won’t take a team of PhDs to develop the feature.
What an MVP should be:
A meaningful viable product that takes the project into a version of viability with an acknowledgment that it might not be the scalable final product it will grow into
What the “Executive” hears:
How many features can I get with this amount of money? I don’t really need an “MVP”, I want the whole thing, and an MVP sounds like paying for a half-baked solution. They’re literally telling me it won’t be “done” at the MVP level. I would have bought off-the-shelf software if it were available, but now I have to build this custom thing.
If the Executives do not accept the concept of an MVP, don’t call it an MVP - call it “First Milestone” or “Version 0.1”.
After all, an MVP is just the first step on a longer journey, and it will signal to the executives that their budgetary concerns are being taken seriously and that you will be estimating beyond the MVP.
At this point, you will have to take some time to define the next phase after the MVP as much as is reasonably possible.
If the executives do value iteration, we can plan for the phases after the MVP, but know that our executives will understand that as we learn more about the project we are building, we will be able to give better estimates for future features.
**Warning** This will be different for each organization
Using whatever metrics your team uses for estimating complexity and translating this into time or money, address each item of the MVP backlog and add these to the first version of the budget.
If any of the backlog items will require research or experimentation, try to address these tasks ahead of time with the executives. Although it is often the case that research has to be done “just in time”, the time spent on researching doesn’t have to be a surprise.
Every third-party integration has the potential to make your development flow more complex.
Add a realistic buffer for bugs (or “bugs”), firefighting, “emergency changes from the sales team” and other miscellaneous tasks
Using your estimates, knowledge of how the work is valued (in money), and the team’s estimated velocity, create a budget and timeline, describing deliverables at each stage.
They approve the whole thing and the team starts working. About halfway through, the team realizes that integrating with one of the third-party dependencies, a task that should have taken a week to complete and test, is taking a lot longer than expected and is still not done.
Armed with the budget, the team and the executives re-prioritize tasks (some items are not worth the cost) and sync up to see where the disconnect is. The process begins anew.
time passes ...
We talk a lot about the “definition of done” at the team level. In organizations with a robust UAT scheme, it is usually clear across the board when something is considered officially done.
However, it does occur that a stakeholder who previously considered certain items to be “done” is now complaining about things not being done. This may be a symptom of:
Hopefully, this was useful! Check out more of our Agile articles.
Photo by Niklas Bischop on Unsplash