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 SmartSheets or MS Project. Next, we move to sprints and measure critical activities.

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

Other critical dependencies 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., software, test)

  • Software Delivery to all teams (e.g., 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., SmartSheets, 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., a change in the critical path, schedule, corrective actions…).

Agile/Scrum

Each sprint has a planning phase driven by estimates. Critical metrics, like burn downs and sprint velocity, are used to report the plan's quality, assist in sprint progress, and serve as a benchmark to support 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 (even for multi-month projects) are created. Daily standup blockers are critical information to track since they may result in an early warning of risk. From the TPM perspective, utilizing scrum standups is an excellent opportunity to mitigate risk as blockers surface. The TPM attempts to remove the risk by unblocking 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 are worthy of Root Cause Analysis (RCA). Why does this class of risk keep materializing? Whether eliminated or mitigated, significant effort and interruption impact teams' progress caused by 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

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

Previous

Shift-Left!!!
Next

Requirements Engineering