Uncertainty is a huge risk factor for any given software project.
One risk is that of the unknown: we know there are things about the projected outcome that can turn out differently. As we will see, this one is easier to mitigate.
Then there is the risk of assuming too much, the risk of hubris. We are sure our roadmap is pointed in the right direction and keep walking, only to realize the direction is wrong.
It does not help that it's surprisingly challenging to communicate the business owner's vision to the vendor and their implementation team. The risk of miscommunication is always present but not apparent if either party assumes too much about being on the same page.
How to deal with these? Let's break them down and find ways to identify, contain, and eventually minimize these risks.
Dealing with uncertainties about the vision
We don't know what the future will bring. As business owners, we have to place our bets.
We bet on the future outcomes. And they can turn out differently.
How to make out bets more informed?
I would be lying if I claimed I had the ultimate answer. There are entire disciplines, scientific and less so, dedicated to making the future more predictable. And every failed enterprise and every market crash demonstrates that the search is still in progress.
There is one way to tame the future, though. When you limit the scope of what you want to achieve at first, you can dip your toes in the future, so to speak, without losing the whole leg if there's an alligator underwater.
Making a smaller bet means the downside is also small.
A practical example: instead of rolling out an enterprise-wide implementation of an expensive CRM software, start with something small and contained.
Do a proof-of-concept with your salespeople. Maybe using just an Outlook plug-in. Observe and confirm that the automation works in this microcosm. Measure it if you can.
This way, you have some real-world learnings you can then use to extrapolate when you want to make a bigger bet.
Work in phases, each one building on the previous one.
The world is full of overly ambitious projects that failed to deliver because the vision didn't materialize. You want to avoid this fate by testing your vision early and often.
Dealing with implementation risks
Let's assume all vendors have your best interests at heart. You'll know when yours doesn't soon enough.
There's a risk that's being constantly downplayed. It stems from the surprising difficulty in communicating the vision between the parties.
The software industry has produced many methodologies to reduce this risk.
There is the so-called "Waterfall," which starts with a detailed definition of requirements. It follows rigid, linear steps toward launching the product at the end.
Then there's the "Agile" family of methodologies, which said goodbye to requirements and focused instead on regular collaboration between the business owner and the implementation team.
The latter is certainly closer to the right solution. In my experience, it's often agile only in name and not spirit. The bigger the company is, the more its agile methodology resembles the original "Waterfall."
Since these methodologies came from software people, they primarily deal with the needs of software people.
As I wrote in Work inside out, there is no substitute for the initial phase when both the business owner and the vendor have to listen and talk and listen and talk until both are sure they understand each other.
Yes, it can be overwhelming and tiring, especially if you are explaining the same thing for the hundredth time. But, this vendor wasn't in the room when you explained it for the 99th time. And vice-versa: this business owner knows nothing about integration testing and how it contributes to the software quality. Assume nothing!
You will know when you are on the same page when either of you can complete your partner's sentences. I would call this the "marriage readiness test." Fortunately, we don't have to take the marriage analogy any further.
What now?
Let the vendor run their shop as they see fit. If they use Scrum, so be it (we don't.) Instead, establish a few ground rules rooted in the principles we have discussed in the previous section:
- Start with a smaller bet. Test the vendor with an assignment limited in both ambitions and financial downside. I don't mean like and exercise: break down your project into phases and make the first one small. Does it work? Does it make valuable things? Observe and measure.
- Establish a hotline. The communication does not stop in the getting-to-know-each-other initial phase. There will be questions coming your way. Answer them. Have people on your team, your captains, ready and willing to fill any gaps in understanding.
- Document everything. All decisions, all changes. Ideally, you'd have a "living document" that you created together with the vendor in the initial phase and that you keep up-to-date continuously. Leave worrying about "backlogs" and "tickets" to the implementation team. That's a technicality. Your document should be the only source of truth for the project.
Another word for phases that software people use more often is "iterations." They are the same thing. Slicing the project into iterations is something you should do together with the vendor.
If possible, make them count. This is why we don't do Scrum sprints: two weeks is often not enough to produce anything meaningful. But a month or six weeks can be, and indeed, must be!
What you want to have each phase become part of your production toolkit. The software isn't ready for showtime just because it's technically complete: only when it starts contributing to your vision is it complete.
Summary
None of the above is news. It's not a new methodology; it's not a new process. These ideas have been circulating in the industry for decades.
Chances are good that you are not a lifetime member of the industry, however.
If that is the case, the above principles should be helpful.
There are no good reasons software projects should fail at the rate they still are. This is not rocket science.
At the same time, software is made out of bits, which are infinitely more malleable than atoms. Hence, the same mistakes are still being made in planning and execution.
The first step is to realize there are many more unknowns in the world of bits than in the world of atoms. And yet, we already have the tools for dealing with them, taming them:
- Making bets that are initially small and eventually grow is one, provided that your feedback loop is tight.
- Documenting your vision and exhausting all conversation topics with your vendor.
- Mapping the project milestones to the bets you've made and ensuring the follow-up phases are informed by the learnings you have made from the product being already live, if only partially so.
You can never eliminate all the risks, but you stack the odds heavily in your favor.
photo credit: Md Mahdi