Risk Management

Written By Dave Tavares

Risk Management Overview:

My approach to risk management starts with the planning phase, which includes a complete Gantt chart for the project(s) using Smartsheet or MS Project. Next, we move to sprints and measure critical activities.

The Technical Program Manager (TPM) must track progress, blockers, and delays in dependencies.

An example of critical dependencies that need to be managed in a cross-functional engineering organization:

  • Hardware delivery to all downstream engineering teams (e.g., software, firmware, test, field service, customer service)

  • Firmware Delivery to all downstream engineering teams (e.g., system, software, test, system)

  • Software Delivery to all teams (e.g., system, firmware, software, test, service)

  • Release candidate delivery to all test teams and service teams.

Dashboards and meeting minutes are critical to support stakeholder transparency. Collaboration with team leaders, managers, and directors assists in risk notification, elimination, and mitigation.

Planning phase — Gannt Charts

Risk management starts during the planning phase, with a Gannt chart that allocates dependencies and clearly shows the critical path (e.g., Smartsheet, Microsoft Project). The plan is reviewed and maintained. The program manager is responsible for keeping the plan current and notifying of critical changes (e.g., delays that result in a change to the critical path, schedule, corrective actions…).

Agile/Scrum

Each sprint has a planning phase driven by estimates. Critical metrics, such as burndowns and sprint velocity, are used to report the plan's quality, track sprint progress, and serve as benchmarks for subsequent sprint planning.  

When issues surface that affect the plan, they are analyzed and either removed (risk is eliminated for now) or mitigated (risk has materialized, and we reduce negative impact).

Jira and Scrum sprints are created (even for multi-month projects). Daily standup blockers are critical information to track, as they can signal early risk. From the TPM perspective, utilizing scrum standups is an excellent opportunity to mitigate risk as blockers surface. The TPM aims to mitigate risk by resolving the issue and escalating where necessary. If the risk cannot be eliminated, the TPM mitigates risk by reducing negative impacts.

Removing/reducing classes of risk:

Recurring issues warrant Root Cause Analysis (RCA). Why does this class of risk keep materializing? Whether eliminated or mitigated, significant effort and interruptions impact teams' progress, requiring analysis to remove the risk or reduce the impact.

Dave Tavares

Initially, I was a software developer for the Department of Defense (DoD) through defense contractors. I understood that the software could not fail because lives depended on it (extreme safety concerns). I quickly took steps to ensure that my software was highly reliable and easy to maintain.

Due to the quality of my software deliveries, I was promoted to software engineering leadership.

By request, I was responsible for leading a Quality Engineering (QE) team where the team was not meeting client expectations for a highly critical solution requiring the removal of as many bugs as possible before going live with accuracy and extreme stability (i.e., air traffic control). I had a leadership and hands-on role. Safety was paramount. We succeeded due to Cyclomatic Complexity path test coverage > 85%. I tracked the first ten years of this solution required for range control, and the software never failed and always worked as expected.

I then moved into high-tech industry testing (broadcast, health care, smart grid, IoT, semiconductor software design/software test tools, and autonomous driving, to mention a few).

During my QA/QE phase, my software quality engineering responsibilities at the contributor level included manual, automated, and comprehensive testing. I brought innovative practices to match the SDLC, CMM, and ISO 9001 target goals at the Quality Engineering Lead and Director levels, satisfying their customer base. I was responsible for setting processes, procedures, templates, and checklists for all phases and types of testing. Quality was improved, resulting in a maximum of 90% reduction in customer bugs. I was also a lead assessor for CMM and ISO 9001 during this time.

In my most recent role as the Staff Technical Program Manager, I moved into engineering hands-on training, driving engineering standards compliance and assisting engineers with compliant artifacts. I translated standards into system/software/firmware engineering processes, practices, and templates. Standards included ASPICE, ASIL, and applicable portions of ISO 26262. By developing end to end plans with complete dependencies I have effectively removed the set of risks caused by lack of dependency and complete monitoring of schedule slip impacts.

Finally, I have worked with agile, highly iterative, and waterfall models and assisted teams in migrating between different models.

https://www.davetavares.com
Previous

Shift‑Left as a Systems Strategy — Not a Slogan
Next

Requirements Engineering