Risks in Project Development

Risks!!! Part of every project, new or old. There are no projects (past or present) which did not have any risks identified. If there were no risks identified, the Project Manager must be joking or he/she has no clue on what risks are.

Risks are generally pointers on events that might occur, which will be detrimental to a project when they do happen. Risks have to be identified in any project at all times by the stakeholders of the project, not just the Project Manager. Of course, the PM will be expected to have the control over the Risks unless there is a person designated specifically to tackle risks in a project.

Organizations that do software development in a haphazard manner will see that the same risks appear in all projects on a regular basis!!! Examples of these would be project overruns (improper estimation, lack of adequate skill-levels, unclear scope), technologies (latest, unstable, lack of adequate resources), improper planning, etc. Having a Risk repository will help – most of the Project Managers will benefit by having access to the available repository. External reviews by competent Managers will also help.

Risks do appear in a project life-cycle – it takes some amount of training and experience to see the ‘alerts’ when they happen. Based on the type of risks, one can take appropriate strategies. Traditionally, the four types of risk treatment are Avoidance (eliminate), Reduction (mitigate), Transfer (outsource or insure), Retention (accept and budget).

Proper Risk planning will ensure that a project can continue on track. For each risk identified, one can take the following actions:

  • Identify the probability of the risk. Is it almost sure that the event (of risk) will occur? Or is it similar to having a thunderstorm in a desert?
  • Identify the stakeholders who will be impacted by the risk, if it occurs – It could be the development team or the design or the architecture team (which might further cascade to the rest of the team). This will determine the team who will work on the Risk-action plan and what artifacts will be impacted.
  • Estimate the time available for the team to continue their tasks before an action has to be taken (or not) on the risk. This will determine when is the deadline for the Risk-action plan.
  • Chalk an action-plan (as part of the overall Project Plan) for the Risk-action. This needs to be tracked regularly.

By following the steps, one can be sure that the risks in a project are regularly reviewed (if it is part of the project plan, you can be sure that it will be tracked closely) and closed.



2 Responses to “Risks in Project Development”

  1. Managers, keep your boss informed about the project « My Thoughts on Technology, Management, … Says:

    […] Front Page ← Risks in Project Development […]

  2. Collective Project Planning « My Thoughts on Technology, Management, … Says:

    […] de-risk the project […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: