There are basically two types of risks on a project. They are programmatic risks and technical risks. A project cannot meet schedule (hence cost) without resolution of issues that affect the schedule.   Events that impact the schedule are programmatic risks. These types of risks determine the risk level of the project. The assumption in making this statement is if the schedule cannot be made, then the project will be over budget.

Technical issues can cause schedule and cost impact but can be worked through. In other words, it is possible to recover from a technical issue. For example, applying more resources to the problem to solve the issue or performing more tests to determine the problem and then fix it.

Programmatic Risk examples

• Current IMS has little slack for schedule slips – There are always uncertainties and assumptions when creating a schedule. To mitigate these threats, additional time (or slack) is built into the schedule to mitigate them. If the added slack is insufficient, then the probability of a schedule slip or delay is high.
• Export License and release on time – An export license is required to import parts and documents from a foreign country into the United States. If the license application is not filled out enough time, your parts or documents will be held up impacting your project.
• Current subcontractor has no proven track record – Selecting an unknown subcontractor to provide critical components or services to your project is dangerous and risky. It is much more prudent to go with known subcontractors or at least ones that can show evidence of a successful track record.
• Not all supplier obsolescence issues addressed – Electronic components can become obsolete due to new better technology. To mitigate component obsolescence on your project, it is necessary to evaluate the components for your proposed design to ensure they have a long shelf life (will not be obsolete in near future). If you find an obsolescence issue on your project, it can be devastating.
• Current manpower insufficient for multiple shifts – It is prudent on production projects to make provisions in your schedule for a second or third shift if necessary, to recover from any schedule delay. To ensure this is a realistic approach, you need to be certain that sufficient staff will be available for the extra shift(s). If this is not the case, then the schedule will probably slip and your customer will not be happy.
• Faculties test equipment availability is spread across several projects – It is not uncommon for projects to share machines especially if they are special tools or equipment. To ensure this will not be a problem, a throughput capacity study should be done and kept current to ensure each project has sufficient time on the tool or machine to meet their schedule. If this is not the case, then the schedule will probably slip, and your customer will not be happy.

Technical Risks examples

• Weight requirement has little margin – Weight is a major concern on ships, space rockets, airplanes and many other applications., if there is insufficient weight margin in the design, chances are the weight requirement will not be made resulting in a costly redesign. Mitigation plan is to add weight margin.
• High content of new unproven technology – Too high a content of new unproven or little track record of success technology introduces low reliability and high risk.  This is not a prudent approach. For example, a company developed a new foil bearing where the rotating shaft rides on a film or air instead of metal to metal contact and high wear. The foil bearing was designed for high speed shaft rotation. It works well in the laboratory but has no production track record. The best option in this case, is to redesign your system with a lower rotating speed shaft and use a standard bearing to reduce risk.

• Software coding – On large complex projects with a high content of new software, there are usually many versions of the software that are made available to other disciplines on the project so they can start and work their tasks. Each version contains multiple changes or added functionality. This process can result in redesigns, schedule delays and cost growth. To mitigate this risk, you need to add sufficient budget and schedule time in anticipation of the multiple changes until the final version is complete.
• Software throughput and memory – During the proposal phase, an estimate is made based on analysis as to how much memory and processing is required to ensure adequate throughput and memory. The amount of throughput and memory is not known until the software development has progressed sufficiently. To mitigate the risk, margin needs to be added to the throughput and memory capacity to avoid a significant redesign.
• Weight, power, and cooling – It is important to add enough margin in the design for these areas to avoid cost and schedule growth.
• Cost, reliability, and quality – Reliability is built into the design. Many military systems have a very high reliability requirement because the mission it is supporting is critical to the defense of the country. An analysis can be generated to show if the system meets the reliability requirements. If not, there are several actions that can be taken to increase the reliability value to meet requirements by analysis. For example, add redundant subsystems such that if one fails the other kicks in. You can also eliminate single point failures. The analysis determines design features of the system that are required to meet the reliability requirement. Quality is manufactured into the product. This includes: type of materials; workmanship requirements; quantity of in process inspection and test points; and other considerations. Everything effects cost. It is very important for analyses and reviews that support these areas are done thoroughly, completely, and accurately.

SUMMARY

Every project is subjected to programmatic and technical risks. The project is not executable to schedule without resolution of issues that impact it. Technical issues can be worked through. A complete and thorough risk assessment and mitigation plan protects projects from programmatic and technical risks.

BIO:

Currently John is an author, writer and consultant. He authored a book entitled ‘Project Risk Management. He has written numerous risk papers and articles. He writes a risk column for CERM.

John earned a BS in Mechanical Engineering and MS in Engineering Management from Northeastern University. He has extensive experience with commercial and DOD companies. He is a member of PMI (Project Management Institute). John has managed numerous large high technical development programs worth in excessive of $100M. He has extensive subcontract management experience domestically and foreign.  John has held a number of positions over his career including: Director of Programs; Director of Operations; Program Manager; Project Engineer; Engineering Manager; and Design Engineer.  He has experience with: design; manufacturing; test; integration; subcontract management; contracts; project management; risk management; and quality control.  John is a certified six sigma specialist, and certified to level 2 EVM (earned value management).https://projectriskmanagement.info/

If you want to be a successful project manager, you may want to review the framework and cornerstones in my book. The book is innovative and includes unique knowledge, explanations and examples of the four cornerstones of project risk management. It explains how the four cornerstones are integrated together to effectively manage the known and unknown risks on your project.