System thinking in action: How Level 3 exposes hidden technical risks
A well-structured project plan can still fail if it’s built on a technically unstable foundation. That’s why the most effective PMs don’t just focus on budgets and timelines—they take a look at the system itself. Level 3 of the Project Diagnosis Framework provides a structured way to assess whether the product, system, or service design is strong enough to carry the project forward without late-stage surprises.
Why technical issues stay invisible—until it’s too late
Most PM frameworks focus heavily on timelines, budgets, and scope. But what if the architecture itself is flawed? What if the system design can't handle upcoming variants, or if integration points are poorly defined? Level 3 brings structure to surfacing these issues early, when they can still be corrected without major cost or timeline impact. It forces a PM to ask not just, “Are we on track?” but “Is what we’re building actually buildable?”
Foresight is a wonderful but necessary part of the rapid development of complex systems. Also, the sequencing of design and verification tasks are part of the product development strategy, which must, of course, be integrated into the project plan. Technical risks must be conducted along with project risks, and also resultant business-level risks.
Here, it helps enormously if the project manager and the development team have a pre-defined checklist or diagnosis template and procedure. This allows rapid assessment of risks and the identification of targeted feasibility checks and deeper level analysis.
What is the opportunity for concurrent engineering on this system development? That is a crucial question for compressing the development timescale. Here again, forethought, early ingenuity and analysis are the foundation of project success.
From architecture clarity to system readiness: The Level 3 checklist
Level 3 focuses on identifying system-level technical risks before they become project-breaking issues. Here's the checklist Super PMs use to diagnose the technical backbone of a project:
System architecture clarity – Is the overall system architecture clearly defined, stable, and reviewed by all relevant stakeholders? Lack of clarity here leads to mismatched assumptions, hidden complexity, and poor downstream coordination.
Interface definition and integration readiness – Are major subsystem and external interfaces clearly documented and understood? Unresolved interface ambiguity often causes rework, delays, and missed integration milestones.
Variant and configuration management complexity – Will the system need to support different versions, platforms, or market-specific features? High variant complexity adds risk to requirements, test planning, and verification, especially if not reflected early in design. Variants also need to be verified and validated - often overlooked.
Manufacturing and test readiness – Have manufacturability and testability been considered in system and component design? If not, the project may encounter major design churn late in the development lifecycle.
Compliance and safety alignment – Are compliance, certification, or safety-critical requirements part of the system? If these are not addressed early, the team risks missing key regulatory gates and launch commitments.
Engineering maturity and uncertainty – Are we building with well-understood technologies, or are critical parts still evolving? Technical uncertainty or early-phase R&D can dramatically shift project timelines and planning assumptions.
Do we have enough compute power? - Simulation, verification, validation and physical design of large-scale systems need tremendous computational power. Do we have enough machines, memory and licenses to execute all of that within the required project schedule?
Failure mode analysis - How might the physical system fail? Have we analysed the DfX (Design-for-eXcellence) considerations, like design-for-thermal dissipation, design-for-crosstalk elimination? Can algorithm execution end up in a lock-state? Do we need to conduct a D-FMEA (Design Failure Mode Effect Analysis) exercise?
Each of these areas represents a potential delivery constraint, not just a technical concern. Super PMs use this checklist to spot structural risks early and translate them into planning, sequencing, and mitigation strategies.
Personal Story: Re-designing an Infeasible Architecture
About 3 years ago I won a contract with a major IP development company serving the silicon chip industry. I became a contract Engineering Programme Manager. The project I inherited was a massive-scale Ethernet Packet Switching IP block for automotive applications. I had around 60 engineers assigned to the project.
The major resource group was a functional digital design team. They designed and verified large-scale functionality targeted at 6nm silicon - extremely fine silicon geometry for very large-scale integration. Their first customer was a Chinese automotive chip developer. The timescale was extremely aggressive and the business stakes were sky-high. As always, the pressure was on.
Unfortunately, the core engineering team of around 40 engineers had a major weakness - they were uni-disciplined and not multi-disciplined. Successful IC design requires a multi-disciplinary skill-set. Whereas, they were expert in structural or functional design, they had insufficient experience in physical design. They did not realise that they had a showstopper problem dead-ahead. When the structural design is handed over to physical design, the layout processing time would take an exponentially increasing amount of time.
Although the team had seen similar trends on more moderate designs, they had not consulted the physical design team. Looking ahead in the project and discussing the physical design task, it became evident that a single layout run, even without repeated optimisation, would take 6 months to execute. This blew the project schedule to smithereens!
To cut a long story short, the structural design had to be re-architected into 6 partitions in order to make the physical design possible. The layout on each could be done on the 6 partitions concurrently, but with an execution time of 10 to 14 days per run. The penalty for back-tracking on the architecture was 6 weeks of high-stress work. This made the overall schedule feasible within a reasonable time scale.
Explaining the 6 weeks’ unavoidable delay was an extremely hard sell to a very unhappy customer was a very difficult task. I had to bear the tidal wave of criticism on behalf of the company - not easy, but the only way forward. Lessons learnt - use foresight and consult all technical parties involved in the development. Perform a technical diagnosis of the development project at the outset.
Conclusion
Timelines and budgets can look healthy even while the system is quietly falling apart. That’s why Super PMs never stop at surface-level plans—they dive into the technical core using Level 3. By asking the right system-level questions early, you protect your schedule, your budget, and your team from preventable surprises. Because what you don’t diagnose at Level 3, you’ll pay for later, when it’s too late to adjust.
