A project manager’s dream is a job that is well-planned, meets all specifications (including features added mid-project), is completed on or before the deadline, is finished without cost overruns and is well documented. Ideally, this includes smiles all around — customer management, stakeholders, end-users, and developers. Satisfied customers and stakeholders mean word-of-mouth referrals. Satisfied developers mean eager talent anxious to help on the next project.
Good project management can reduce the risks to a happy minimum and this brief article tackles the most critical aspects of minimizing such problems.
Perhaps the single biggest risk in any project comes from poor planning. If the initial plan does not anticipate the greater percentage of problems, plus the potential risks and alternate solutions, it leaves the entire enterprise open for nasty surprises. What kind of surprises? Here are some examples:
- What if one of our developers gets hit by a bus and takes with him or her vital knowledge critical to the success of the project?
- What if new technology is used on the project and some aspect of that technology is incompatible with the project or one or more of its features or requirements?
- What if the customer discovers that ten other costly features are critical to making the finished software work — something they could not have anticipated until the prototype was demonstrated?
The first item on the above list captures one of my own pet peeves — an uncomfortable state of affairs that is eliminated by cultivating in the team members the attitude of replaceability. Everyone likes to think of themselves as indispensable, but such an attitude can prove costly to a team and a project. A truly professional team member earns their indispensability and never abuses it. I remember one employee hoarding their knowledge, thinking that secrets could help them keep their job. When a vice president of the company found out that a production bottleneck traced back to her and her selfish attitude, he fired her on the spot. The loss, he figured, could be made up by someone with a more team-oriented and proactive attitude. His estimate proved to be accurate. By putting the team and the project first, a team member shows they can be trusted with big responsibilities. If they are so insecure that they have to protect their job with such artificial methods, we really don’t want them on our team.
The obvious solution is to have important information documented within the project as it is discovered. We’ll look at the other two items and more as we dig into this topic of mitigating risk in software development.
Key risks to avoid or reduce
Agile methodology for development projects was created with risk mitigation in mind. A core principle is the short, iterative development cycle that constrains scheduling mishaps to a relatively short period — typically two weeks, called a scrum “sprint.”
In order to understand the importance of any such methodology, it helps to appreciate the full scope of possible risks on a software project. The following lists the more common risks we might expect to encounter.
- Poor planning — Every project needs careful design time to consider the best way to approach the overall problem. As a developer, I know the seductive lure of jumping into the coding before doing the planning. Also, getting the scheduling right remains a vital concern to reduce risks later in the project and to ensure it comes in on schedule and under budget. When we’re creating something new, there is a great deal that remains unknown until we actually do it. Someone who has been on several development projects will likely have a better idea about the time required for specific features, and may even have a pretty good idea how long it will take to plan the project adequately. But even seasoned project team leads won’t be able to predict every possible problem and the time required to solve it.
- Significant changes in requirements — This includes not only “requirements inflation,” but also the dreaded re-design that may have nightmarish consequences rippling through most every aspect of a project. Sometimes additions or changes are unavoidable, especially when the customer realizes that the end-product won’t work without the additions.
- Employee turnover — A key person doesn’t necessarily have to be hit by a bus for our project to suffer a potentially lethal setback. They could quit. Something could turn them into the disgruntled employee from hell. We certainly don’t want them destroying existing work and we don’t want them walking out the door with vital information they didn’t bother to write down.
- Specification breakdown — At some point during the actual production, we discover that the specifications are not as clear as we thought they were. Something about them is suddenly ambiguous. Or we realize that one set of requirements conflicts with another set.
- Poor productivity — This could adversely affect the project timeline.
- Gold plating — I used to call this “overkill,” but while researching for this article, I ran across this new term which fits this type of risk far better. It’s all about doing far more than is necessary for the required work. This may end up with a resource drain, a performance shortfall, or may merely take far more time than estimated because the developer is showing off.
- Technical risks — This can include the use of unfamiliar or unproven new technology. It can also include the use of new tools that require team members to learn and to gain a certain measure of proficiency. Misunderstandings in the use of such new technology can easily derail a project, causing lots of erroneous work and lost time.
- Unavoidable and unpredictable risks — This is the wild card that no one could have seen coming.
Next, we look at potential solutions to each of these areas of risk.
Poor planning
There are two aspects to poor planning: poor design and poor scheduling.
On the first of these, it remains vital to resist the urge to code before the overall plan is done. Early coding can easily be a wasted effort before the requirements of the project and their implications are fully understood.
After we have mapped out the various areas of responsibility and have made assignments, get our team members to estimate the length of time required to do each aspect of their upcoming work. This is in addition to the estimating we’ve already done. By comparing our estimate to theirs, we may learn something new. They may have a different way of tackling their task that could be more efficient. Or we may see some flaws in their understanding of the task. Such an exercise not only helps to ensure everyone is on the same page, so to speak, it also gives us an opportunity to improve our estimation of the time required to complete each module, feature or block of code.
Allowing for some unpredictability in our plan also gives us a little wiggle room for catching up if we run into an unforeseen snag or pesky bug.
This can help reduce the possibility of missing deadlines.
Significant changes in requirements
Additions are one thing, but changes to existing features or requirements can be like the proverbial monkey wrench (or “spanner”) thrown into the machine. Who knows where all the damage will occur?
Because planning is such a critical phase of any project, such changes frequently require a new plan. In order to whittle this mid-project planning down to a manageable task, we really should recruit all team members onto our planning committee. Perhaps a brief meeting is all that is needed to kick off the new plan, but each team member needs to review the changes and additions to the requirements and to report back on the impact, if any, these changes will have on their area of responsibility. They should also report any ideas for smoothly incorporating such changes into the work already done, and should voice any concerns they have. We may end up doing the actually planning, but their input may prove crucial to our creating the most informed plan possible.
Employee turnover
Sometimes we can’t avoid this. Do we demand a risk-free lifestyle while working on the project? No skydiving? No scuba in shark infested waters? Each team member is a vital part of the development “machine.” Replacing any one of them in the middle of the project could prove costly and perhaps even somewhat disruptive, even after the new person settles in. The new talent will have to be brought up to speed on every aspect of their responsibilities so that their portion of the project doesn’t fall too far behind.
Poor productivity
I hate to say it, but procrastination is an ugly beast that seems to bite everyone at some time in their career, if not on a regular basis. It seems human nature to take a relaxed approach to a huge project with a deadline months in the future. This is one good reason an iterative approach to software development is so important to the project staying on schedule.
After the first sprint, anyone who is falling behind could jeopardize the entire project. This is a good opportunity to put the fear of failure in their bones. This may not be necessary, though. A short deadline of a week or two for the first batch of coding is a real enough incentive for most seasoned developers. This by itself could keep them well-motivated.
Gold plating
I’ve been bitten by the “gold” bug myself. I know what it feels like to want to do something “special” for a particular batch of code. This might include some kind of animation for the software’s splash screen. If the specifications don’t explicitly require this, spending the extra time on it could set the wrong tone for the rest of the project. All the little extras could end up causing slippage in the schedule. Or it could end up slowing down the software, becoming a performance issue. Let our team know up front that if they want to add something not explicitly in the specifications to see their team lead about it, first.
Technical risks
When trying out new technology on a project, include some extra time for the learning curve and for brief meetings early on to discuss the specifics about the new tech so that everyone is aware of the same issues, difficulties or nuances in working with the innovative tool or technology. After they’ve had a chance to work with the new tech, we might even include a little brainstorming to see if we can weed out potential problems early on. Ask, for instance, “What disasters could result from using this new tech?” The answers we receive could prevent future headaches.
Unavoidable and unpredictable risks
Naturally, if I knew what these were, I could give us specific recommendations to mitigate each risk. I can, however, give us some general suggestions. Allow in our scheduling the possibility for these unknowns. If none of them show up, we may well finish the project ahead of schedule. How nice would that be?
Mitigating the risk of the unknown is something we need to keep brainstorming, either in a group or solo. If, for instance, our team is based in earthquake-prone California, we might consider doing daily backups at a location on the other side of the continent. If we use the cloud, make certain the hardware is not geographically close.
Any potential risks we can imagine likely have a wide variety of possible solutions. Assess the costs and benefits of each, including ease of implementation and recovery. But no one can think of everything. For that burdensome reality, we need a cool head on our shoulders, a positive attitude and the certainty that a solution exists, even for the thorniest of problems.
Risk mitigating strategies
Besides the actions taken directly to mitigate specific risks, we can also manage the risk topic by applying certain strategies to risks in general.
Each project involving at least several developers needs to have a risk list. In order to build and manage this list, we need to do the following:
- Recognize and write down each risk and the things that may trigger them.
- Categorize and prioritize each risk.
- Build a plan that correlates each risk to a set of mitigation actions.
- During the project, monitor for each risk trigger.
- If a potential risk shows up, activate the appropriate mitigating strategy.
- Communicate to team members and stakeholders the status of risks throughout the project.
Some risks may be small enough simply to accept as-is, especially if the cost of mitigation is large compared to the small payoff. Other risks we may want to avoid at all cost simply because they could kill the project. Such avoidance might include the strategy of finding a better, more risk-free approach in the planning stage.
Some risks can be better controlled by dividing them into more manageable pieces. Naturally, if ever the risk status changes, the very least we need to do is to continue monitoring the situation.
One kind of risk needs special mention. This involves the decision-making process for resolving problems with the project specifications. If we pinpoint something ambiguous in the specifications, or find one spec that conflicts with another, we don’t want the problem going to some committee that will be difficult to assemble. Establish early on in the project a go-to person who will be given the authority to make spot decisions regarding such problems that could otherwise hold up the project.
Whatever happens with risks during a project, communication with those who need to know remains a vital element that must not be overlooked. If a risk blows up and becomes a very real problem, we need to notify not only our developers and quality assurance crews, but also managers, stakeholders, marketing and the customer representatives. This may be the most uncomfortable part of risk management, but not taking care of timely notification could become far more uncomfortable. And that’s a risk we should simply never take.
Ready to take the next step, and launch your MVP? Drop us a line. Our team of ex-Googlers can help you every step of the way, from design, to engineering, and all the way through product-market fit.
