Search This Blog

Showing posts with label Risks. Show all posts
Showing posts with label Risks. Show all posts

Sunday, June 15, 2025

Playing the CARD at Scale: Lessons from a Global Strategic Business Office

An opportunity presented itself for me to reflect on a mental model that I had developed a long time back. I had relied on this model to proactively sow the success seeds for any initiative that I worked on and also reactively address challenges as they surfaced. The opportunity came when I had a good friend who discussed with me about supply chain related failures for a drug portfolio where decision-making delays created strategic and operational challenges for a mid-level healthcare organization. 

While some early thoughts focused on teams lacking the capacity and capability, I didn't feel completely convinced. Over the years, as a VP leading a PMO with many project and program managers reporting under me, I noticed a recurring pattern: projects rarely failed because teams lacked effort or intelligence. They struggled because the realities of execution were not made explicit early enough. To address this, I often used a simple but powerful mental model called CARDConstraints, Assumptions, Risks, and Dependencies. Like a card in your pocket, it is something every mid-level manager should carry into planning conversations, steering committees, and day-to-day decision-making.

My thinking around CARD further matured significantly as my role evolved into VP of a Global Strategic Business Office (GSBO), where the PMO increasingly became a shared services capability rather than a standalone function. One arm of the GSBO focused on client-driven delivery programs, while the other governed the internal product and R&D portfolio across the organization. In this dual mandate—external execution and internal innovation—CARD became a pivotal enabler, helping us navigate strategy over a three-year horizon while still executing tactically at the project level.

Constraints are the non-negotiables of an initiative and strong managers surface them early and often. They act like the skeletal system defining the shape, structure, and boundary limits. The organization fails without the skeletal system and too much rigidity compromises agility. Beyond traditional limits like budget and timelines, constraints on a strategic side included leadership capacity, market timing, regulatory environments, and investment guardrails across portfolios. For client-driven programs, constraints were often contractual and immovable; for product and R&D initiatives, constraints showed up as funding thresholds, architectural decisions, or talent availability. 

In my GSBO initiatives, CARD helped ensure that constraints were explicitly acknowledged at the portfolio level, so teams didn’t overcommit locally and underdeliver globally. When surfaced early, constraints became tools for prioritization rather than excuses for delay. Every trade-off such as scope reduction, sequencing, and resourcing must explicitly reference which constraint is being protected. When constraints are invisible, teams make local optimizations that create global failure. Making constraints explicit creates realism, not pessimism.

Assumptions are where many plans quietly go wrong. These are statements we treat as true without proof. I view the assumptions as the nervous system and determines how the organization perceives the market and reacts to the signals. I found the assumptions were where the CARD created the most leverage especially in product and innovation work. Multi-year roadmaps are built on assumptions about customer adoption, technology maturity, data readiness, and organizational change. In the GSBO, we treated assumptions as testable hypotheses, particularly for R&D experiments embedded within the portfolio. 

Product managers and business analysts or the project and program managers were expected to articulate what must be true for success and define signals (triggers) that would invalidate those assumptions. Unchecked assumptions turn into surprise risks and surfaced assumptions turn into managed conversations. This discipline allowed leadership to course-correct portfolios early rather than defending plans that no longer matched reality.

Risks spanned both execution and strategy and provided the highest value in the GSBO. In fact, risks were the main thread that connects projects, programs, and portfolios in any enterprise. Risks differ from constraints and assumptions in that they are probabilistic events with a positive or negative impact! 

  • At the project level, risks were treated within the project's threshold but escalated when their cumulative and overall impacts exceeded the project boundary. 
  • At the program level, risks included benefit slippage, vendor reliability, and integration complexity.  The program level risks also were delegated to project level as needed. 
  • At the portfolio level, risks expanded to include concentration risk, innovation failure, market shifts, and opportunity cost. 
CARD helped management elevate the right risks that genuinely threatened strategic outcomes. More importantly, it encouraged explicit risk ownership and leadership decisions about which risks to mitigate/enhance, transfer/share, avoid/exploit, and finally which risks to consciously accept.

Dependencies were the connective tissue of the GSBO and are frequently the most underestimated element of CARD. Client programs depended on internal product roadmaps; product initiatives depended on shared platforms, data, and specialized skills; R&D experiments depended on leadership patience and protected funding. In my opinion, projects do not fail in isolation but across the integration points between teams, vendors, stakeholders, and systems. 

CARD forced visibility into these interdependencies and prevented siloed decision-making. For project and program managers, managing dependencies became less about tracking dates and more about orchestrating conversations, aligning incentives, and escalating decisively when assumptions broke down. It forced us to ask hard questions: Who do we rely on? Who relies on us? What happens if this slips?

CARD Element Body Metaphor Leadership Connection
ConstraintsSkeletalStructure, System, Boundary, Leverage
AssumptionsNervousInterpretation, Signals, relexive decision-making
RisksCirculatoryAwareness, Escalation, Flow
DependenciesConnectiveAlignment, Integration, Cohesion

Finally, CARD works because it forces clarity. Just like bad strategy may result from rigid bones and faulty nerves, execution can fail because of weak connective tissue and blocked circulation. So, constraints shape choices, assumptions test logic, risks demand foresight, and dependencies expose interconnections. When the management and leadership consistently apply CARD, status conversations become sharper, surprises decrease, and leadership trust increases. 

In my experience, you don’t need more templates or tools—just the discipline to play your CARD well, every time. What are your thoughts? How have you applied any of these thoughts? Please share your insights.

Friday, February 23, 2024

Demystifying Technical Project Myths

I had the opportunity to facilitate training for a graduate class where there was an interesting discussion about defining technical projects. Now, the discussions were really inspiring, and we discussed several different characteristics such as novel use of emerging 4th Industrial Evolution related technologies playing a critical role in creating a unique product, service, or result.  At the same time, there were also some definitions of technical projects that need to be debunked. 

Now, one of the promising unbiased definitions of a technical project is that technology is used in achieving project goals that otherwise are not possible or would take time. It is imperative that we don't limit ourselves to the "technology" itself as the use of "information technology". In fact, technology is broadly defined as the application of scientific knowledge or a structured approach to realize an objective. For instance, brainstorming ideas can apply the concepts of design thinking, Delphi techniques, nominal group technique or many other forms such as the 6-3-5 technique (Rajagopalan, 2020). In these brainstorming approaches, a technical tool can be used but it is not always necessary. 

A few things that I would like to consider incorrect for defining a technical project are the following:

  • Only technical projects have risks
    • Risk is any uncertain event that can positively or negatively impact a project. So, it does not distinguish whether the project is technical or not. If the wrong hypothesis was chosen as the null hypothesis in a scientific project, it is a concept risk that impacts the project's schedule.
  • Technical projects always have shorter timeframe
    • This idea comes from the application of adaptive approaches (e.g.: Agile or Scrum) in technical projects. The reason for shorter timeframe in adaptive approaches to facilitate faster feedback from the users who may not always know what they want or may have changes in the upcoming iterations. Progressive elaboration has been present in project management frameworks for quite some time and the amount of time given for feedback facilitation is up to the project. 
  • Using Jira makes the project technical
    • While Jira is an example here, the use of any tool for requirements, test cases, risks, defects, and any other artifacts used in a project does not make a project technical. By that definition, any project documenting its goals and objectives in Microsoft Word or even notepad should call that project as a technical project.
  • Non-Tech projects do not use technology
    • As mentioned before, technology is the methodical approach of using a technique. A project may use a technical tool like soil analysis to evaluate if a small campsite can be strongly established for training local students in agriculture. A business information modeling (BIM) tool can be used to design the intricacies of a building even before construction begins. Whether we classify such projects are technical or not, we can't say non-technical projects do not use technology. 
  • Non-Tech projects do not need special talent
    • This is a biased statement thinking that special talent applies to people with advanced computer technology, data science, etc. A plumber, electrician, auto-mechanic, creative artist, musician, linguist, journalist, or market research specialist are all equally qualified special talent. Let us not forget the numerous specialty vocational schools that prepare people for many skills and competencies we take for granted. 
  • Quality is not relevant in non-tech projects
    • This is a biased statement thinking manual testing, automated testing, robotic process automation, and several other quality control and quality assurance related professions that has emerged. Quality is a function of risk (Rajagopalan, 2023) and wherever there is a project, there is risk. So, to say that quality is limited only to technical projects and furthermore not relevant in non-technical projects is losing the foundations of total quality management principles.
  • Cost is not relevant to agile projects
    • This is a false thinking primarily because people don't incorporate cost-based decisions in their usual iteration/sprint planning. There is a cost to every iteration (Rajagopalan, 2019). Most often, people are not working freely in most of the professional projects except in the volunteer settings where people volunteer their time. Even in such cases, the opportunity cost of working on a feature that is less customer focused than the feature the customer wants is always at the epicenter of MVP (Minimum Viable Product) discussions as part of risk-adjusted prioritization in product planning. 

Thoughts? Love your comments.

References

Rajagopalan, S. (2020). Alternative Idea Generation: 6-3-5 technique. https://agilesriram.blogspot.com/2020/01/alternative-idea-generation-6-3-5.html

Rajagopalan, S. (2019). Agile iterations also involve cost. https://agilesriram.blogspot.com/2019/04/test-post.html

Rajagopalan, S. (2023). Quality is a function of risk. https://agilesriram.blogspot.com/2023/03/quality-is-function-of-risk.html