Although software development is a well thought-over and highly formalized area, how to mitigate and manage risks remains one of the most burning questions. In other words, many businesses are unaware about how to manage effectively perceptions, uncertainly and random variables.
Optimists believe all risks can be classified and can become predictable. In case of software development, project managers (PMs), business analysts (BAs) and risk managers are trying to foresee which project milestone will cause most issues, at what project stage it'll happen, who'll be the weakest link in a team, what features will be delayed, etc. Any average PM will agree that it's really hard to predict which features the client will want to have re-vamped or added while the project development is in progress. Yet, high-caliber project managers are able to make such forecasts and spec out features that are likely to be requested by the client at later stages of development. Your client may not even know yet they're going to need this feature and voila - it's already in the specification! Any customer will be impressed with such a vendor's approach! This is one of the human factors that is essential for any custom project success.
Do you know what any PM or Product Owner fears most of all? Loss of key team players! The risk of having a critical role resign while the project is being underway horrifies all project stakeholders. That's another critical human factor to deal with during software development.
Considering dozens of other risks facing businesses today (e.g. security, national or global economic issues, currency fluctuations, changes in demand/supply balance, failed deals, etc), it seems like there's no way companies can manage risks effectively without going paranoiac.
Most of the above-mentioned risks can be managed with Agile methodologies. But what if the problem is with risk or ALM managers who are 1) not competent enough, and 2) not motivated enough to adhere strictly to the adopted methodologies.
No doubt, different risks emerge at every single stage of software development: at ideation and estimation, the risk of wrong estimates and wrong priorities is high, while the risk of critical usability errors is high at UI / UX design stage. In early iterations many developers are tempted to move too many tasks to the next iterations, and the risk is high that something will go wrong at release stage.
It's no coincidence that we usually associate risk with temptation. Software programmers are human beings who can't be 100% effective! Every day, we're lured to postpone something for tomorrow, leave work earlier or come later, and all of these lures eventually build on each other creating a snowball effect. If your team programmers allow themselves to be trapped by their daily temptations, brace yourself for low team morale and highly unproductive team.
That being said, even a slight deviation towards human weaknesses can lead to significant lags in project. So how can we predict to which team member will grow tired and when? And how many risk managers do you need on your project to oversee each potential hazard?
And what if your team members just won't get along well? Is it possible to predict to team conflict? That's another human factor that can break or make your project. And yes, each team leader should be a hidden psychologist and should be able to evaluate people against many possible scenarios including conflicts in the workplace. The more time your tech lead spends with the team, the lower the risk of human factor. But while it's possible for a tech lead alone to predict to interpersonal issues on small teams (of up to 10 people), how can we do it on large and robust projects as effectively as on small teams?
Each IT company should be seeking its own golden middle. But as long as we have such undetermined mechanisms as people build our projects, the human factor will remain the major risk.
So, the question is - can we somehow reserve a spot for human factors in our project risks list and learn how to manage them properly? Yes, we can, and here're the following solutions:
1. No one is indispensable
Utilize the following approaches to turn your software development team into a single living organism with interchangeable functions: pair programming and testing, regular code review, employee rotation among heterogeneous tasks, collective brainstorming sessions, etc. Also, reserve sufficient time for task completion with consideration of all adjacent risks.
2. Build a team with a strong morale
Invite a professional coach to do motivational workshops and training for your project team. These and other events should be aimed to develop shared project vision within the team and foster communication and knowledge sharing. The better you articulate your company / project mission and values to your team, the more committed and success-driven they'll become.
It's highly recommended that these two approaches are used together for higher efficiency and better risk management.
3. Hire highly paid senior developers skilled in issues management and conflict resolution
While this one sounds a bit naive, it can be effective indeed! Senior guys with extensive teamwork experience and great interpersonal skills can help you minimize the risk of human factors. The more competent the developer, the slimmer the chance of human error. Yet, finding, recruiting and retaining such Ivy-League IT workforce is a real rocket science and only professional IT staffing agencies are apt to source and headhunt such professionals correctly and pretty fast. Many startups are on a hunt for such IT gurus because they know that junior or inexperienced guys will most likely destroy their project without being able to identify human factor risks and address them in a timely manner.
Speaking about startups, it should be noted that they treat risks differently from established brands. Most of startup projects are developed in very uncertain conditions. And the chances are equal that both an ugly and inconsistent code, and a well-written code with a beautiful syntax adherent to the latest coding conventions and styles can affect the failure or success of the startup project.
More serious and rigid approaches to human factor risk minimization often lead to the enhanced surveillance of employees, strict access control systems and corporate policies, launch of penalties and employee control and other repressive and regressive methods. By the way, many companies today still refer to such totalitarianism as their corporate culture! Hope you aren't one of them!
The key demerit of this approach is that employees don't engage in self-reflection about what's holding them back from stellar performance. Nor does this approach allow for changing the destructive work conditions. The other way round, it protects procrastination and other temptations I mentioned above in this post. In this case the formula of success is simple - Just follow the instruction! This approach is typical of large IT companies with strict hierarchies and top-down management. For them, stability remains the key value. In this context, not following the instruction poses a huge risk of human factor. Not following the instruction is oftentimes perceived as a direct threat to the corporate system integrity, and such developers are penalized and / or are expelled ignominiously.
Another huge disadvantage of this approach is that no matter how outstandingly you work, you'll always be just a cog in a huge corporate machine.
If you feel your software project is at a daily risk of failure, be ready to have a highly demotivated team. However, you can take advantage of this situation to mobilize your workforce and encourage them to be more effective. Any software company must be familiar with a situation when their developers start thinking out of the box, ignore the instruction and create some non-trivial workarounds to deliver the milestone on time. So pressuring people to submit work on time can be effective, too!
While many companies don't welcome such improvisations, they normally accept them as long as they help get the job done faster and better. So, on the one hand, such employees present a risk for the company, but on the other hand, they help save the project and, thus, help the company minimize financial risks and risks of unhappy customers.
That being said, strict methodologies and canons always fade out in front of talent and out-of-the-box thinking.
From the viewpoint of risk management, it's crazy. The more efforts you're putting to save your project from failure, the greater the risks for the company. However, besides its negative features, human factor can give the company a very powerful weapon against threats - knowledge and experiences which are invaluable!
As the company grows, it organically gains more experience and predictability, which results in preventive decision making and better trained staff in terms of risk management. As any living organism, your organization is able to evolve into an efficient self-organizing entity, and human factors are essential here!
If you have a specially designated role for risk management within your project team, the human factor can play against it. Many of such risk managers are used to manually control the processes that are normally automated in companies that tend to be innovative and technology-driven. By interfering with the natural course of things, risk managers can 1) face resistance from other team members, and 2) overload the team with hypothetical issues they never handled before.
The "forewarned is forearmed" principle doesn't always work. Knowing about potential risks, the companies can spend a lot of time modeling and simulating issues resolution. But once they stumble into the actual real-life issues (when there's no time left to brainstorm and think over problem solving), they can make an intuitive decision that can be unprecedented in some cases. And this can be the best decision ever made no matter how risky it is.
As one of the key risks pertaining to software development, human factor can help boost the company business growth and technological maturity. By overcoming challenges, each software developer (just like any other specialist) gains more skills and experience and learns how to make predictions and mitigate risks. As such, own risk management based on personal experience will make a huge contribution to building a collective experience.
No, no, I'm not speaking about re-inventing a bicycle here! What I mean is that it's quite easy to acquire and adapt to standard rules and elementary precautions, while issues that require non-trivial resolutions often require accumulation of own experience rather than just copying established best practices. Do you agree?
