« 10 Project Management Terms Customers Love to Hate
The Project Manager »

Sources of Hidden Risks in the Projects

December 5, 2011 | Author: PM Hut | Filed under: Risk Management

Sources of Hidden Risks in the Projects
By Girish Deshpande

The risks are inevitable in any projects. One cannot avoid risks and hope for smooth project execution. You can only accept this fact and brace yourselves for the imminent risks. Often the risks are well hidden and lurking in unlikely (as per project team) places.

Project managers look for risks in known places or depend entirely on prior experience when identifying potential risks in their project. Their risk repository improves as they gain more and varied experience. But this education is extremely costly for the project and the project sponsor. The rigor of systematic exploration of risks in known problem areas must be de rigueur in any project. Such exploration should be systematic and should be done using checklist. We cannot leave this critical aspect to the memory of the project manager. And such checklist should be living document and should get updated when new facts or knowledge is made available upon the execution of many projects.

The below is some of the areas that need to be explored (at least visited) in order to check if there are any risks lurking inside.

  1. Scope related risks - Potential scope creep because the project requirements are not defined clearly. Is performance criteria well defined? Are all boundary conditions defined? Where does your work start & stop? Have you defined responsibilities of each party in different phases of the project? Have you defined and explained scope change management process in the SOW?

  2. Schedule and effort related risks - The scope creep is major risk for schedule and cost but poor quality estimates in the first place is also a significant factor. The lack of prior experience, subject matter expertise, lack of adequate reviews and verification are the causes for inaccurate estimates. It pays to be pessimistic and paranoid when it comes to project estimation. The optimism often kills.

  3. Assumptions related risks - Are all project assumptions clearly defined in the statement of work (SOW) ? Do they cover all important aspects and phases of the project? Have you documented recourse that will be taken if an assumption is proven wrong and has turned into the project risk? Has your customer/sponsor reviewed and agreed with your assumptions and contingencies for each? Ideally all assumptions should be listed down and visited in every status report and project review.

  4. Dependencies related risks - The project is dependent on many stakeholders. For example, customer/sponsor, vendors, contractors, external agencies etc. There are associated risks for each dependency. Have you clearly documented all the dependencies in your statement of work? Have you listed the deliverables from each party? Have you mentioned the time line by when they should deliver their part of commitment? And have you mentioned what is contingency of the risk materializes if commitment is not met by stakeholder? Ideally all dependencies should be listed down and visited in every status report and project review. Some examples of such risks are – supplier delays, visa problems, sub-contractor issues, customer delays, shipment delays, customs delays etc.

  5. Constraints related risks - Almost all projects have some or other constraints and there is hardly any project without constraints. The example of such constraint might be… limited memory or CPU power on board, target Bill of material (BOM) cost for the product, tight timelines, necessity to interface with certain proprietary products, necessity to retain old modules, lack of documentation in migration project, multi-year field warranty support for the product etc.

  6. Technology related risks - The chosen technology can pose risks depending on its limitations. This is especially true if the technology is unproven or not well supported if you need technical support. The technology limitation can also inhibit interoperability with other systems in future. The same technology can pose problem if you are stuck with older version while the vendor has moved onto newer version. Parts obsolescence is major risk in electronic embedded product development especially if you need to support these products in the field for many years. This is true for many industrial and Energy products.

  7. Acceptance criteria related risks - Vague or undefined acceptance criteria in the contract is major cause of grief for the project manager. This is also most difficult aspect to nail down in the early stage of the project when the statement of work is signed off. If the previously defined acceptance test plan is available then that can become the criteria but if such plan is not available then you need to quickly prepare one when the requirements are frozen and high level architecture is done. In some projects this important matter is not addressed till late in the project. This leaves the project exposed to unacceptable risk.

  8. Regulatory risks - The project team needs to carefully evaluate the regulatory and certification requirements for their product and assess its impact on the staffing, product design, project schedule and cost. If the project team has not handled any aspect of certification for the project then this should be treated as big risk and should be tracked regularly. Such risks have very high impact on the projects. They impact both project cost & timelines and can severely impact customer/sponsor & hence their satisfaction.

  9. People related risks - This includes attrition, lack of skills, experience, morale, commitments, team relations etc.

  10. Skills and Expertize related risks - The availability of subject matter expert (SME) can be an important requirement for many projects. This expertise may be regarding industry domain or technology domain related. The project may need such experts to design the system that is reliable, can pass certification tests & satisfy end user needs. If any such specialized knowledge is needed then it develops dependency and associated risk. The attrition of such SME can debilitate the project. It is also possible that there is nobody else in the organization to assess the quality of the work done by SME.

  11. Political risks - We cannot overlook this important aspect in any project. Doe this project have adequate buy-in from important constituencies in the organization? Does the project sponsor has an adequate support and funding from the management? Who will get impacted by this project? And is their cooperation needed during execution? What precaution should be taken if any important stakeholder in the customer organization refuses to cooperate? Whom does the customer contact if he wants to raise any escalation? Have you depicted project team organization as well as relevant org chart in the customer organization in the statement of work? Is there single point of contact (SPOC) on both sides? Is the escalation path defined above these two people in respective organizations?

  12. IP related risks - As Apple Vs Samsung battle over IP violation shows this can become risky if not addressed in the very beginning. If you are using open source components then you need to assess its impact. Do you need to publish part of your work to open source community? Is it acceptable? Have you verified, with help from the patent attorneys of course, that your design does not impinge on anybody’s patent and IP rights?

  13. Warranty related risks - Different contracts have different warranty clauses. The project plan must take into consideration and plan for the warranty terms defined for this project. Warranty clauses should ideally describe what kind of support that will be provided to the customer/sponsor during the warranty phase. It is not unusual to see multi year warranty clauses and they pose big risks. How do you retain the knowledge and team in this period so you can meet the commitments? How do you retain the licenses and AMCs for the tools during this period? How do you handle obsolescence of vital tools and equipment?

  14. Penalty related risk - Many contracts include penalty clause for the performance of the project team. The penalty may be imposed on the design house if the project is delayed beyond certain limit or deliver poor quality product. Your initial estimation should take such potential penalties in account. You may want to factor in possible loss of revenue in your estimation contingency (additional margin).

  15. Quality related risks - What can go wrong in terms of the quality of the product? The examples of poor quality are poor performance, hard to use interface, badly designed product, poor reliability etc. It helps to define CTQ (critical to quality) parameters for the product very early as part of scoping and then measure the product quality against this criterion.

  16. Market risks - You have built the product but the market can pose significant risks if the product has wrong features, poor quality, higher cost, is difficult to use, fails the certification tests, is difficult to produce, is difficult to maintain or whose market introduction is delayed etc.

  17. Natural disasters - These risks are often ignored by the project manager because they seem to be beyond her sphere of influence. But these risks need to be factored into the planning of big contracts and programs. The risk response plans need to be documented and in place so the team can respond in the event of any disaster. The goal here is to minimize the damage as much as one can and the total elimination of risk may not be feasible. The mitigation for such risks are geographic diversity, robust knowledge management and up to date documentation, effective communication mechanism so all are in sync all the time, trustworthy configuration & version management system, centralized issue tracker etc.

Do you know any other major risk categories that one can consider while identifying the risks in the project? Which risks are routinely ignored or underplayed by the project managers? What would be top 5 risk sources in your opinion?

Girish Deshpande is a Program Director at MindTree Ltd. You can read more from Girish on his blog.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Monday, December 5th, 2011 and is filed under Risk Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

Excellent post, but the above are not only the sources of hidden risks in projects, they are the sources of ALL risks (perhaps the title should be modified)?

Jenny Mortimer wrote on December 5, 2011 - 3:33 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories