Mitigate project risks up front
I’ve seen my fair share of successes, hiccups and failures in software projects over the last 20 years. In my younger days, risks were mostly mitigated by brute force. Late-night coding sessions fueled by IV-dripped coffee would tackle any software issues thrown at us. Planning was for the “old-school engineers” and risk management was something you only talk about in one of those soul-sucking CMMI certification seminars.
Now that I’ve got a few more grey hairs and have a hard time staying awake past 11 pm, I’m all about minimizing risks up front so that projects are delivered as we had planned without burning out our team.
Here are four key practices we take to help reduce risk up front.
1. Click-through Prototypes
For projects with a user interface, it is best to invest time during the discovery phase to create a click-through prototype. These would be static screens of the product made interactive with user’s click to transition between them. Having such a visual and interactive prototype would help us refine the user experience and sets the expectation for the finished product. There are many software on the market for creating click-through prototypes. Our favorite is InVision for high-fidelity prototype and Balsamiq for early-stage rapid prototyping.
2. Feature and Technical Briefs
Talk to any software engineers and most will tell you how much they hate writing documentation and would rather go straight to coding. That may work for a one-person team but the risk is high when we’re working with a team of product managers, engineers, testers, and stakeholders. We call it “brief” because we don’t want to spend too many resources writing up detail requirements and technical documentation just for the sake of producing awe-inspiring documents.
Our feature brief, combined with the click-through prototype, should be able to convey to our team what they need to build. The finer details would come in the form of development tickets during the development sprints.
Our technical brief, with a pre-defined list of topics to cover, is a way to remind our lead engineer to consider all aspects of the project implementation. For instance, the brief has to lay out all the external integration points and discuss the risks associated. It also has to identify possible single-point-of-failures and ways to mitigate them.
Most projects would require external software libraries or third-party services to integrate with. These are usually areas of higher risk given that our team may not have used them in prior projects.
Documentation can be a good place to review and see if it’d fit what we need, and for open source projects, the level of activity in the code by contributors could be a good indication if it’s actively supported. Once the integration points are identified, we’d experiment with them by coding up a simple program just to test the normal path of the functionalities in the library/service that we need. This would usually give us enough information to gauge the risk level of the integration.
4. Be Pragmatic
It takes a unique blend of the left (analytical) and right (creative) brain to be a good software engineer. Sometimes our right brain gets the better of us, leaping into “cool” technology that’s getting a lot of hype in the community and promise to solve all the problems previous tech presents. Sometimes they do pan out and indeed achieve what it’s cracked up to be. Other times, we’d run into stability or simply lack certain basic features.
Whenever a new piece of library, framework or external service was to be included. We’d require our team to do a quick cost and benefit analysis to make sure it’s well worth the effort and risk to use it. They’d also be required to test it out with a simple program as discussed in the previous point.
Last but not least, the old adage of keeping it simple, stupid stays true as always. If it takes too long to explain how it’s going to get done, it’s likely too complex to begin with. Time to simplify it further.