As John F. Kennedy put it, “everything changes but change itself.” This is particularly true in computer industry where things move faster than other industries. It’s further complicated when you also have dependencies that also move fast.
A good example is that your software project depends on another product which is also under development. Sometimes we call it synchronous development. The payoff could be huge if you can ship your product at the same time as the dependent product which presumably has bigger user base. You can then leverage the go-to market opportunity as first player in the bigger community.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
The problem is also obvious. If the dependent product gets delayed or cancelled, you are out of luck. All your investment turns up nothing, or you have to invest more. So naturally you have to think about risk management in such cases.
Generally speaking, you don’t want to bet on a moving target unless the vendor has demonstrated a track record to consistently deliver products on time. It doesn’t matter the dependent product is within your organization/company or not. You may think an internal project is more dependable than external ones. But when it comes to software project, it’s not likely true.
To be safe, you want to work on released products. Sometimes it may not be an option. For example, you develop a device driver for next version of Windows. The stake is too high for not to support it on day one with the new Windows.
I have to point out that even a product is there already, there are chances for it to be phased out or replaced by a new generation of products. But then the vendor will provide a migration path to ease the issue. Therefore there should be no immediate impact.
Now, if you have to chase moving targets, what are the effective strategies to mitigate the risks? Here are LID (Limit/Iterate/Diversify) strategies:
- Limit. You project is successful only if all your dependent projects are successful. Even all the dependent products are successful, there might still be issues for them to work together. The less moving targets you depend on, the higher chance for your project to succeed. While developing the open source vSphere Java API, I decided that it only depends on dom4j 1.6.1.
- Iterate. You don’t want to sync up with the dependent product after it’s released for sure. Instead, you get alpha, beta, RC builds so that you can try out and find potential risks early on. This allows you enough time to adjust your project plan, for example, reduce investment until the dependent products are ready. If it’s an internal project or open source project, you can have even more frequent interations.
- Diversify. This is the same wisdom as you spread your investment portfolio into multiple stocks. The techniques are however different in software projects. You want to have an abstraction layer to cover two or more alternatives. Like it or not, the abstraction layer is an overhead and requires more effort to develop. This diversification helps not only manage risk but also expand business opportunites into multiple and sometime competing ecosystems.
I summarize the LID strategies for software project management. The basic principals should be applicable for other non-software projects for risk management as well. Please feel free to give them a try.