Posted on

Project Portfolio: Planning Under Pressure

As market dynamics increase, the selection of projects, which are important to align enterprise operations and strategy, face challenges from cost-benefit related conception, to criteria for project completion. Nearly all organizations have more project work to do than people and money to do the work. Trying to do too much causes all projects to suffer from delays, cost overruns, or poor quality.

Focus On Portfolio Performance

Common business pressures that serve as a catalyst to evolve a focus on portfolio performance can include:

  • Smaller or greater demand from your customers
  • Lack of available skilled resources needed for projects
  • Increasing risk exposure across project portfolios

In any of these cases, you may have to adjust your priorities for the next few months. Or, you may have to adjust your spend, where to spend more, where to spend less. Also, you may have to rethink your business strategy for the long term.That means adjusting your project portfolios. Some projects must be stopped, some paused, some adapted, some accelerated and some newly created. These are difficult decisions, which must be made with little certainty about the future, and, hence, potentially with more risk. The decision-making process can generate positive results while leading a company, or make a significant damage to an organization.

Project portfolio managers need a well-facilitated and structured approach to assess, reprioritize and effectively deliver the project portfolio that is needed in a tumultuous world. A process of analysis and judgment must occur in business on a day-to-day basis, and is an important component of managerial work on various hierarchical levels in the corporate environment.

Planning Under Pressure

Being compelled to select the “right project(s) next” is a most important opportunity, especially during crisis circumstances, that can:

  • Reduce the number of low-value projects, which will reduce the overhead of keeping track of them all and, even more importantly, increase the availability of resources for other high-value projects.
  • Better align project investments with your organization’s business strategies, e.g., growing overall revenue, and with your organization’s cultural values. Facilitated discussion among executives about better alignment will entail broader agreement on overall business objectives and strategies.
  • Improve balance and diversification of projects along key dimensions, which will entail broader agreement on such dimensions (such as, perhaps, revenue growth, product innovation, maintenance and compliance)

Follow A Two-Pronged Approach

In our experience at Group Atlantic, our clients enjoy best success by taking a two-pronged approach that emphasizes:

Top-down development of mindset, governance, and process—but not (software) tools—alongside education of relevant stakeholders, so that gradually a common enterprise-wide process for project approval, diversification and tracking is practiced. Purposeful organization development emphasized several important aspects:

  • Shared vision and mindset: (e.g., breaking down silos, alignment with strategies and business goals) rooted in our Business Value Points matrix approach.
  • Governance: where to house portfolio management responsibility and accountability in the organization, who can (not) make decisions about what, and related issues.
  • Process: working with top leadership (e.g., to formulate the “burning platform”, develop sponsorship and communications, develop policies and model desired behaviors) and working with other executives and managers (e.g., to communicate the change(s), cascade the change down the management hierarchy, identify and manage champions and resisters, develop training, and change incentives and performance appraisals).

Quarterly exposure of executives to strategic projects, their dependencies, and their value and impact on overall strategy and results, so that executives start to appreciate interdependencies, strategic (non-) alignment and (non-) effects on overall results. This second prong follows, at least informally, a rolling 12-month plan (perhaps with a multi-year look ahead), updated every three to six months, to better exercise strategic agility.

Achieve Lasting Value

It’s certainly not trivial to reprioritize a wide ranging project portfolio, with many projects already in process and multiple influential stakeholders seemingly inseparably connected to project. The pressures of time and resource constraints, along with uncertainty about the future, can add to executive stress. Reacting chaotically could lead to a disorganized response and an inefficient use of finite resources.

A systematic project portfolio management approach, expertly facilitated, is about getting the best outcomes despite planning under extraordinary pressure. Decision-making meetings are more collaborative, effective and efficient. Better ideas come with facilitated attention to proven portfolio principles, process and reliable techniques.

With a structured and well-facilitated approach, one can move quickly and carefully to build/rebuild and manage the project portfolio your company requires to face challenges today—while also laying the critical next steps for prosperity tomorrow.

Posted on

Seven Traits Good Project Managers Share: Do You Have Them?


Who’s the best project manager you ever worked with? This question, posed in a Q&A discussion after one of my recent corporate workshops, stimulated some fond reminiscing about all of the project managers I’ve respected through the years and what made them so good. It also probed into some comparison about what they all had in common. If you take nothing else from this post, do that … take some quiet time perhaps while sipping that second cup of morning rocket fuel, and develop a list of the project managers you’ve respected through the years. Then think about what traits they all had in common.

I’ve had the good fortune for decades to work with project managers in successful Fortune 50 companies and rapid-growth startups, ranging across many industries, including aerospace, telecommunications, finance, insurance, retail, information services, and manufacturing. From these experiences, the best project managers I’ve worked with seem to have the following traits:

They think for themselves. They have the self-confidence to make their own decisions. This isn’t to say they don’t coordinate with others when needed, or disregard other people and don’t heed advice … quite the contrary. They will make their own decision, factoring in their skills, their team’s skills and their assessment of the situation. For example, during a project problem-solving gathering where there may be some questionable risk factors, they’ll listen, engage, and attempt to facilitate to get a full range of ideas. And in the end, while factoring in what the group is doing, they’ll make their own decision.

They understand what the business domains value about the projects they manage. This knowledge helps them make good decisions, and when unusual things happen, they have an extra bit of insight that helps them out of a jam, whether it’s a difficult project launch, an unusual stakeholder demand, or a perceived mid-project crisis. Somehow their projects seem to deliver value more reliably, and fellow project managers around the “neighborhood” will peek over to see what/how they’re planning and tracking.

They take quality risks. Project success demands risk management. It’s about good decision making, a hallmark of good project management. The best project managers I’ve worked with have surprised me on both ends of the risk spectrum, sometimes with a very conservative decision, and other times with a decision that seemed to involve more risk than I would have accepted. An in-depth conversation with them usually revealed a deeper level of analysis than I had undertaken, and I usually walked away with a few more strategies to put in my risk management toolbox.

They welcome questions about their decision-making process. Of course, this can be influenced by how you question their decision. If you approach them in an accusatory or judgmental way, you may not find them receptive. However, if your intent is to understand the analysis and all they were thinking about, you’re likely to find an enjoyable and enlightening discussion; one in which they probe you back for your assessment of the situation, and what you would have done and why.

They are brutally honest about evaluating performance and maintain a focus on improvement. When you work with them, you’ll hear them acknowledge missteps or errors. In project post-mortems or sprint retrospectives, they don’t seem to brag much; they seem most interested in analyzing their mistakes and seeking knowledge or techniques that might help them. They didn’t become one of the best project managers you know by glossing over their weaknesses.

They enjoy gaining knowledge about project management. It’s been said, “Do what you love and you’ll never work a day in your life.” The best project managers I’ve worked with delighted in quenching their thirst for project management knowledge. Maybe it stems from their love of getting valued things done, so it’s not work for them to read up on the latest developments, or spend an evening after a long, difficult day in the office by attending a presentation by a thought leader at a professional gathering. They routinely stay abreast of project risk taxonomies that accurately mirror the concerns of real-world project managers.

They’re calm under pressure. Perhaps it’s a culmination of all of the above, but the best project managers almost seem to have been waiting for the critical moments. They don’t panic; they aren’t shocked. They seem to go into a zone where they just matter-of-factly take care of business.

Are you on your own list of best project managers? Are you on anyone else’s list? What is needed for you to master the skills and thought patterns to get there? Embark on the rewarding path to becoming one of the best project managers you’ve ever worked with.

Posted on

The Case for Vulnerability in Scrum Retrospectives


“Vulnerability is not weakness.”

— Brené Brown

Choose A Brave Willingness to Be ‘All In’

For a scrum team to be successful, it is important to learn of and solve problems as they occur. As we work together, we express how we’re doing, what’s in our way, and our concerns so they can be addressed. It’s an ongoing process of improvement from sprint to sprint. A retrospective session is most effective when everyone on the team is forthcoming about what went well, and also what didn’t. At this meeting, each team member should take time to quietly reflect and answer those two questions as it pertains to him or her. There are as many team dynamics as there are teams, so sometimes getting started is awkward if people feel uncomfortable opening up. Sustained success demands a brave willingness to be ‘All-In.’

To be ‘All In’ during a sprint retrospective, often we must dare greatly. I believe Brené Brown’s book, Daring Greatly,  has meaningful implications for Scrum culture in the workplace. Brown writes about interviews she conducted on how people experience shame in their lives. These were the subjects’ answers that, as a Scrum Coach, I found alarming: “Revealing any weakness is shaming…Showing fear is shameful…You can’t be afraid—no matter what.” This is bad news for those of us who seek success through an agile approach to getting work done. If the team culture views weakness as shaming, then that means team members may tend to cover up weaknesses. If during a retrospective we perceive that we can’t talk about the things that trouble us, because of the fear of being viewed as weak or not having the “right stuff,” then how in the world are we going to achieve substantial and sustained business performance improvements, improvements that deliver greater value? 

Brené Brown is a popular author, public speaker, and research professor at the University of Houston. She has written four number-one New York Times bestsellers. Her Ted Talk “The Power of Vulnerability” has received nearly 36 million views to date. The core of her research is this: People who live happy, wholehearted lives are those who have the courage to let their most authentic selves be seen. They are not paralyzed by a fear of failure. Rather, they have the courage to be vulnerable. For most folks, however, vulnerability is something we avoid at all costs because of the fear that if we allow ourselves to be truly seen, we will experience loss of respect, loss of connection, and shame. According to Brown, “Shame–the intensely painful feeling or experience of believing that we are flawed and therefore unworthy of love and belonging–breeds fear.”

Brown’s work would suggest why we’re sometimes reluctant to reveal to the team important ground truths about what happened in the sprint, because we don’t want anyone to know we’re weak in that area—and also a little fearful of being embarrassed by our weakness or appearing foolish before others. But unless we embrace the need for discussing it, without any guarantee of comfort, then the team productivity isn’t likely to systematically improve. I’m not talking about some coerced Kumbaya retrospective moment. I’m just encouraging a little healthy introspection,  to look back on the sprint and sift through our memories in order to more clearly see the business consequences of our relationships, challenges, frustrations, and feelings that we are experiencing. That might also occasionally lead to grabbing a Scrum Coach as an objective third party for guidance.

Choose Excruciating Vulnerability

That’s not to say that everyone participating in a Scrum team is afraid of vulnerability. As a coach, I’ve observed great progress in improved productivity when even one team member chooses excruciating vulnerability and with courage openly talks with their team about their own mishaps as well as near misses in hopes of making it a learning experience for all. This behavior tends to happen when that team member acts with a courage born of a sense of their own worthiness, and a sense of professionalism. And once one opens up with courage, others if not all are more likely to follow by speaking up. The absence of shame is the key to reporting the ground truth.

We could make our work more joyful if we’re only willing to do two things. First, we have to stop playing Monday morning quarterback when we hear about the sticky situations into which other team members have gotten themselves. Yes, there is a place for objective mishap/near-miss analysis, but criticism merely for the sake of making ourselves feel better than the other guy benefits no one. The second thing we can do is share our stories, and be candid and forthcoming about our weaknesses and fears. Transparency will go a long way toward everyone’s goal of higher business performance. In the words of Brown, “Vulnerability—the willingness to be ‘all in’ even when you know it can mean failing and hurting—is brave…Courage is contagious. Every time we choose courage, we make everyone around us a little better.”

Posted on

Bridging the Gap Between Systems Engineering and Program Management via a Risk Aware Framework

Risk Aware Framework

Complex engineering systems are prone to schedule slips, budget over runs, and a variety of challenges that compromise delivered value. These challenges are a sign of failure on the part of both management and technical roles, but can be overcome through a Risk Aware Framework that integrates the roles into a cohesive systemic and systematic approach to delivering high-value business outcomes.

This article shows how your organization can become more effective, more efficient, more responsive, and enjoy better business outcomes by bridging the gap between Systems Engineering and Program Management via a Risk Aware Framework. Beginning with an overview of key concepts, this article details the challenges faced by System Engineering and Program Management practitioners every day. The practical framework that follows describes how a principled process can be integrated successfully to streamline project workflow. A case study details how a real-world company successfully implemented a risk framework to improve cost and schedule performance, while improving the likelihood of success of your organization’s own strategy.

This article describes a proven framework to:

  • Overcome challenges and improve cost, schedule, and business performance
  • Assess current capabilities and build to the level your organization needs
  • Manage risk throughout all stages of a Project Life Cycle
  • Deploy best practices for teams and systems


How’s this for a system engineering truism? “The best system engineers possess the superior judgment to avoid situations requiring their superior skills to survive.” While arguably more true than a whole wealth of truisms, it doesn’t provide much guidance in our quest to become one of those wiser and more-capable system engineers, especially when we find ourselves in a position of leadership. Which raises an obvious question: How does one develop such profound judgment?

Regardless of our degree of skill and experience, the trick to safely nudging the envelope comes in knowing as much about what we don’t know as what we think we do know and weighing those factors wisely before we venture forth. The process of evaluating those elements before taking action is a process known as “risk management.”

This is an era in which risk-taking is rewarded, leaving companies that run away from risk as plunder to be divided up by the others. Risk is inherent in all activities. It is a normal condition of existence. Every day, companies are exposed to various types of risk. They can be connected to property, liability of third parties, staff or decisions; risk is the usual companion in every business and with direct influence on result. But what is a useful way to think about risks and risk-taking in today’s environment?

Risk is the potential of loss resulting from a given action, activity and/or inaction. Usually we have a choice having an influence on the outcome. Exact definition of risk is given within the ISO/IEEE Standard 16085:2006 on software and systems engineering risk management. 

Risk is not a problem. It is an understanding of the level of threat due to potential problems. A problem is a consequence that has already occurred. Risk is defined by two characteristics of a possible negative future event: probability of occurrence (whether something will happen) and consequences of occurrence (how catastrophic if it happens). If the probability of occurrence is not known, then one has uncertainty and the risk is undefined. 

The computerization of the workplace and the levels of IT dependency that now exist means the risks associated with the failure of IT systems are one of the most potent sources of operational risk within any organization. Systems engineering management related risks could be related to the system products or to the process of developing the system. Risk management in quickly changing environment is a requirement, for it contributes to reaching strategic advantages of a company. Inadequate attention to risk, especially at the early stages of a systems engineering project, is often the reason behind cost overruns, schedule delays, and poor technical performance.

Consider the Future of Your Present Decision

The purpose of risk management is to make decisions, not to admire the risks. No behavior goes more to the core or soul of a company than how it makes decisions. 

Making the right decision means performing risk analysis. Risk analysis is systematic use of available information to determine how often specified events may occur and the magnitude of their consequences. The goal of any of these methods is to help the decision-maker choose a course of action, given a better understanding of the possible outcomes that could occur. By exploring the full space of possible outcomes for a given situation, a good risk analysis can both identify pitfalls and uncover new opportunities. Risk analysis can be performed qualitatively or quantitatively. Qualitative risk analysis generally involves assessing a situation by instinct or feeling and is characterized by descriptive statements. Quantitative risk analysis attempts to assign numeric values to risks, either by using empirical data or by quantifying qualitative assessments.

Three Essential Elements for Success

Bringing risk management to an organization is a change in language and attitude towards risk and its link to decision making. Behavior changes at all organization levels and requires at least three elements:

  • A repeatable process with defined steps and artifacts supported by applicable methods and tools.
  • Widespread access to adequate knowledge sources to fuel the process.
  • Functional behavior including human interactions, motivators, perceptions, communication, decision making processes and risk tolerance.

These are not independent elements; there are strong interactions that must be accounted for in implementing and sustaining risk aware management. Process and knowledge sources, while necessary, cannot by themselves change behavior. The last element is the key and yet it has received little attention. Although change management is a discipline in its own right, there are special considerations for risk management.

To introduce effective risk management practice in an organization requires the role of all three — process, knowledge and behavior — must be understood. However, it is the issues involving functional behavior that will determine whether a risk management practice can be successfully sustained.

Case Study: Rockwell Collins

One company that has thrived with risk is Rockwell Collins (now Collins Aerospace). An independent audit revealed that due to risk management practice, Collins achieved double digit improvement in Cost Performance Index and Schedule Performance Index.  Enterprise Risk Management (ERM) at Rockwell Collins comprises two dominant threads that wind around a central decision process, as well as each other, forming a strong organizational risk culture. The central decision process at Collins is a phase gate model that covers the entire lifecycle of a business opportunity. The decision process directs a compelling set of business questions at key points in the lifecycle of each endeavor. It ensures productive interrogation and structuring of the company’s discretionary investments. As an organization, Rockwell Collins minimizes surprises, provides relevant, objective and timely information to decision-makers, and focuses on asking the right questions. Seven key questions that are regularly and rigorously answered are:

  1. What are today’s risks – are they higher or lower than before?
  2. Are the risks likely to get higher or lower in the future?
  3. What is being done to reduce risks, to monitor risks and to prevent risks in the future?
  4. Who is responsible for the aversion measures – who can I call if things are not correct?
  5. How will I know the aversion measures are being put into place?
  6. What is the timetable for the aversion measures?
  7. How and what should I communicate concerning risk internally, to suppliers, and to the customer?

Focused through the phase-gate decision process, the complementary decision processes of management of risk and risk management allow Collins to address risk in a systemic, multidisciplinary manner that weaves business strategy, finance, program and project management, etc., into a comprehensive and unified whole.

Communication of risks is one the most challenging tasks in risk management. The people in the position to best recognize many of the risks are typically system engineers working on the project. For a variety of reasons these people may not be willing to communicate the risk. Collins’ success is in part to creating an environment that generates information pull. System engineers and their managers must learn that merely identifying a risk, placing it into a risk register, doesn’t mean it will occur (and ignoring it doesn’t mean it won’t). 

At Collins, one means of creating information pull is to condition people at all levels to ask questions that elicit risk causes and characteristics. For example, my long-time associate at Rockwell, the late Art Gemmer described[1] how his organization coached managers to consider certain questions in response to cues, some of which are listed in the table (From “Risk Management: Moving Beyond Process” by Art Gemmer in IEEE Computer, May 1997) below. 

Four Types of Risk 

Successfully answering key risk aware management question demands a widespread access to adequate knowledge sources to fuel the risk aware process. It involves four types of risks: 

Programmatic, Organizational, Economic and Technical. Classification of risks is helpful in order to group those with similar risk characteristics, and is fundamental to any engineering system in order to evaluate them.

Product risks include both end product risks that relate to the basic performance and cost of the system and to enabling products that relate to the products that produce, maintain, support, test, train and dispose of the system. Risks relating to the management of the development effort can be technical management risk or risk caused by external influences. Risks dealing with the internal technical management include those associated with schedules, resources, work flow, on time deliverables, availability of appropriate personnel, potential bottlenecks, critical path operations and the like. Risks dealing with external influences include resource availability, higher authority delegation, level of program visibility, regulatory requirements and the like.

Programmatic Risk:  This is the risk that a major change initiative could fail or the benefits expected of it might not materialize. With an increasing use of projects and programs to drive through change within organizations, this type of risk is often closely associated with strategic risk, as failure can have significant impacts on the organization. Moreover, with the increasing complexity of organizations, managing this type of risk is fast becoming an essential skill.

Risk drivers include: project purpose and need is poorly defined, project scope definition is poor or incomplete, project scope, schedule, objectives, cost and deliverables are not clearly defined or understood, no control over staff priorities, too many projects, consultant or contractor delays, estimating and / or scheduling errors, unplanned work that must be accommodated, communication breakdown with project team, pressure to deliver project on an accelerated schedule, lack of coordination / communication, lack of upper management support, change in key staffing throughout the project, inexperienced workforce / inadequate staff / resource availability, local agency issues, public awareness/support, agreements.

Organizational Risk: Risk drivers include: inexperienced staff assigned, losing critical staff at crucial point of the project, insufficient time to plan, unanticipated project manager workload, internal “red tape” causes delay getting approvals, decisions, functional units not available, overloaded, lack of understanding of complex internal funding procedures, not enough time to plan, priorities change on existing program, new priority project inserted into program, inconsistent cost, time, scope and quality objectives. 

Economic Risk: This covers those risks that can affect the business in terms of its general financial viability. It includes risks associated with the market in which the organization operates (market risk), as well as the ability to finance growth through loans (credit risk). These risks are generally well understood, with a large number of financial instruments and techniques available to the risk manager.

Technical Risk: This is different from operational risk in that it is associated with bringing new technology products to market and introducing new technology into the organizational setting, both of which are high risk ventures. Risk drivers include: design incomplete, environmental analysis incomplete or in error, unexpected geotechnical issues, change requests because of errors, inaccurate assumptions on technical issues in planning stage, surveys late and / or surveys in error, materials / geotechnical / foundation in error, structural designs incomplete or in error, hazardous waste site analysis incomplete or in error, need for design exceptions, consultant design not up to department standards, context sensitive solutions, fact sheet requirements (exceptions to standards). 

A Repeatable Process With Defined Steps 

A widely recognized risk management framework (see below) depicts the different activities involved in the risk aware management associated with system engineering. The framework is represents a dynamic, continuous and highly-iterative process, while the arrows show the logical flow of information between the activities. From this framework, a project may structure a risk management practice best fitting into its system engineering project management structure. 

Dis-functional Behavior: Risk Arrogance

Francis Bacon is quoted as saying, “Man prefers to believe what he prefers to be true.”

Organizations may think that effective risk management will follow merely from a repeatable process and widespread access to adequate information about risk management. However, as my associate the late Art Gemmed said, “Following a repeatable process may mean we are just systematically managing risk poorly. Likewise, having adequate sources of knowledge doesn’t necessarily motivate people to use them correctly.” 

Companies that seem to understand the necessity of risk-taking are sometimes prone to the following strange behavior: They try to emphasize positive thinking by ignoring the possible unfortunate consequences of the risk they’re taking. This is an extreme variant of the can-do attitude. After all, risk awareness involves at least a bit of can’t do thinking, they reason, so it can’t be good. In order to stay positive, they steadfastly refuse to consider much of the downside. If there are things that could go wrong, that would make your project a total fiasco, for example, they would just have you not think about those things at all.

Denial is a major reason risk management is not usually done as part of project management: as my associate Dr. Robert N Charette said, “software project success is based upon minimizing the thought of possible failure.” Typical organizations are focused on the success of a project. Owning up to risks is all too often considered defeatism. The problems created by a “can-do” attitude, paradoxically, increase with the exposure and difficulty of a risk. 

It’s not only managers who are subject to such hubris. If you’re a younger and less experienced system engineer, not only might you be unaware of the risks confronting you, but you may truly believe that any such risks that might emerge can be overcome, because you’re real smart and you’re willing to work real hard.

Many organizations in fact foster such attitudes as part of the can-do ethic. Risk averse and arrogant attitudes lead to system engineering dominated by crisis management and heroics. The organizational incentives are often structured to reward heroics and “can-do” employees. This positive reinforcement further ingrains these destructive attitudes. 

Among aviators there is a saying, “There are old pilots and there are bold pilots, but there are no old bold pilots.” Few experienced system engineers are so foolish as to ignore all risk. When people ignore risk, they do it selectively. The way it typically works is, they take elaborate care to list and analyze and monitor all the minor risks (the ones they can hope to counteract through managerial action) and only ignore the really ugly ones.

Create A New Functional Behavior

Here’s a credo that describes the risk-related functional behaviors for which we should strive.

Manage risk as an asset. We choose the types of risks we face to match our business needs. We understand and anticipate our customers’ and competition’s opportunities and risks as well as their problems. We manage this knowledge as a strategic competitive advantage.

Treat decision making as a skill. Decision-making is a critical skill that we teach, practice, and constantly strive to improve.

Create a pull for risk information. We ask the right questions to obtain risk formation. We actively seek it. We conduct meaningful discussions of our risks and act on the results.

Seek diversity in perspectives and information sources. We seek information from the political, cultural, economic, environmental, and technical realms. We involve multiple disciplines. We listen for and learn from divergent viewpoints.

Minimize uncertainty in time, control, and information. We systematically search for uncertainty wherever it may be. This search is the heart of a learning organization.

Recognize and minimize bias in perceiving risk. We make decisions based on sound information that is derived from an adequate analysis of the situation.

Plan for multiple futures. We plan for the best case, worst case, and several most likely scenarios.

Be proactive. We act before things go wrong. We attack root causes. We look for and address systemic risks.

Make timely, well-informed decisions and commitments. The purpose of risk management is to make decisions, not just identify risks. We understand when decisions must be made. We manage the risks and understand the chances of success before we make commitments.

Reward those who identify and manage risks early, even if the risks become problems. Even prudent risk takers will realize some problems. Our heroes are not just those people who solve problems, but also those who intelligently avoid them.

Be Prepared to Slay a Sacred Cow

A huge obstacle to risk aware management is organizational memory. The memory of “how we’ve always done things around here” is an ad hoc truth that substitutes for “doing things the right way around here.” The root is fear. People don’t want to make mistakes, and the best way to avoid making a mistake is to continue doing things exactly as they’ve always been done.

Organizations get trapped in a kind of circular logic: “We do what we do because it’s the best thing to do. And it’s the best thing to do because it’s what we’ve always done.” Unfortunately, this is a comforting fantasy for too many. What you end up with are sacred cows — things that you take for granted; pro forma (“tick in the box”) risk management processes that you have come to believe will help you get things done. In reality, all they do is get in the way of getting things done. You must be prepared to slay a sacred cow. The greatest challenge may be finding the courage to candidly answer the question, “Are we ready to hear the ruthless truth about the risks of our system engineering decisions?”

The truth is that significant, lasting performance improvement in risk aware management may require a courageous change in your organizational culture even  before driving ongoing, institution-wide initiatives to optimize performance. Progress will occur in your organization when (and only when) a positive vision for the future multiplied by dissatisfaction with the status quo is greater than the natural human resistance to change (and resistance to the truth). Be prepared to challenge yourself to commit to evidence-based risk aware management as a way of organizational life.


Risk aware management is a vital part of successful systems engineering and project management. Although most system engineering managers know what to do, sometimes they just don’t do it. Some of the factors that contribute to this behavior include deficient system engineering processes, failure to adopt a risk aware management process, risk-averse or reckless attitudes, and failure to consider organizational context. 

While there are many possible steps to improve risk management in an organization, some of those that appear to have the most potential for success include training managers to elicit risk information through checklists and improved communication methods, aligning rewards and incentives with risk management activities, examining risks in the context of the organization, and managing risks across an organization. These techniques are not typically part of risk management processes. And therein lies perhaps the most important lesson: Risk Aware Management is more than a process; it requires the right information and the right behavior to bridge the gap between Systems Engineering and Project Management.