Survive high risk projects using intelligence methods
Survive high risk projects using intelligence methods
30 June 2022
High risk projects can be managed. Intelligence-led project management treats project failure like a terrorist threat. It extends agile project and delivery methods.
Its core mechanism is to move unknowns into manageable risks, or to dismiss them. It does this by chunking uncertainty into small elements that can be individually researched and analysed.
For exploring unknowns, a rapid cycle is used, that can be from 1 day to 2 weeks long. At the end of each cycle, there’s a choice of what to do next.
The upside is it’s possible to handle high risk projects that are critically important. The downside is it’s demanding and only works if all the preconditions are met.
The method extends the scope of professionalism to cover areas that were previously ignored. The cycle has been adapted from the intelligence profession and its “action-on all-risks intelligence cycle”.
The intelligence cycle for handling unknowns in high risk projects
Who benefits from adding an intelligence cycle in a project?
The project owner, who can avoid abandoning a project because it is too high risk … or not abandoning it, and facing disaster.
Project managers, who can manage unknowns and a fast moving environment.
The team members, who have defined roles and a level of insulation from the turmoil of high risk projects.
Internal stakeholders who can see high risk steadily being reduced.
External customers, who can get the results of the project.
The intelligence cycle for investigating unknowns
The intelligence cycle adds to the portfolio of tools for agile project management. It’s purpose is to make an incremental step forward in researching or managing an unknown, risk or problem.
Large and ambiguous unknowns are broken into smaller challenges that can be addressed within an intelligence cycle. Ultimately all aspects of the large question are resolved, following many intelligence cycles performed by many teams. Within the agile methodology, the challenges are addressed within stories or spikes.
Below are four types of challenge that can be addressed by introducing intelligence methods.
Guessed assumptions
Every project has assumptions. Some are listed, most not.
At the start of projects, and for sometime within them, we make assumptions based on best guesses. Some of these assumptions later turn around and bite us (metaphorically).
Where there is a suspicion that an assumption is invalid, it’s perceived as good practice to check it. But checking an assumption involves research, and potentially analysis – an intelligence cycle. There’s a cost. It’s idealistic and unrealistic to think large numbers of assumptions can be checked when the project is already racing. It’s good practice to do it, and good finance not to. A contradiction.
And if someone has been enthusiastic at documenting all assumptions by using checklists, the large list of assumptions becomes a vast list.
The dilemma in professional priorities is impossible to reconcile. Pragmatism is needed. Individual assumptions are checked because someone has a suspicion of something anomalous, or a fear based on previous experience.
Unknown unknowns
These are the surprises – assumptions that seemed safe, or had not been considered.
The earlier these can be detected, the easier it is to manage them. One technique for finding unknown unknowns is to recognise symptoms that have no reasonable explanation. The intelligence cycle can be used to explore these symptoms, to see if they are real or just a false lead.
It’s not enough to have a solution to a risk. The people who help with the solution will need to understand why it happened and why it’s a risk. The explanation is needed by the delivery teams, the management and finance teams, and business stakeholders outside the project.
Providing an explanation requires analytic techniques to interpret the broader context, and it frequently involves additional research to resolve questions within the analysis.
The upside: if you can explain a risk then you’re frequently a step closer to being able to manage it.
“Unmanageable” risks
There will be cases of potential problems (risks) that appear unmanageable.
Appearance can be deceptive. We need smart ways of seeing the risk, and we need to be inventive. That means looking at alternative ways of doing things, or negotiating different results for the project that deliver a similar business outcome.
Innovation involves thinking laterally. It is also heavily dependent on understanding the broader context of the business, technology and customer’s needs. That needs the right kind of people supporting the project, even if they are not regular members.
Is it professional to worry about suspicions and rumours?
As a Chartered IT Professional, I ponder about the “professionalism” of this approach. Some thoughts below, and as a professional, I’ve added a counter-argument for each.
Economically, yes, because risks avoided early are cheaper than problems that occur late. (Counter argument: it comes at the price of lost commercial opportunity, because of the expertise and resources needed to explore the suspicions and rumours.)
Scientifically, yes, it’s professional because it’s about moving towards testable hypotheses. (Counter argument: hypotheses appear anyway, without help.)
As an engineer, yes, because this is a manageable process. (Counter argument: being manageable, does not mean it’s a good process.)
As a team leader, yes, because it demonstrates that ambiguous threats can be managed. (Counter argument: there are also other ways of managing a team’s worries.)
As a senior exec, yes, it’s professional because this is the same process of following-up hunches and new initiatives. (Counter argument: executive intuition is used to drive investigations, and should not be used to make decisions.)
And as a humanitarian, yes, because it helps the team rationalise and live with the fears and pressure of high risk projects. (Counter argument: they shouldn’t be put in this situation.)
The action-on culture: 6 downsides of managing high risk projects
The intelligence cycle must be embedded within the way the project works. The culture comes from attitudes as well as process, and from what your organisation is capable of achieving.
1. Relentless pressure. There are multiple challenges open at the same time, with a continual flow of more arriving as fast as these are resolved. This needs a positive attitude, strong team bonding, and flexibility to handle cover for colleagues. Mental wellbeing is critical. Everyone needs to be watching and supporting their colleagues – no one is left behind. And it’s important to know there’s an end in the near future, because there’s a beautiful world beyond high risk projects.
2. The demand on specialists. Intelligence-led project management has a similar demand on expertise to the intelligence practices on which it is based. The research pulls on people from outside the project who have critical skills. And the analysis involves a continual load on specialists. The kind of people who usually help start a project and then leave, find themselves involved from start to end. It’s a challenge for them to find time from their own existing agendas.
3. Indirect costs. Relating to the above, the project will involve people who are not being charged to it. Fighting major threats engenders a culture of buy, beg, borrow or steal. The inevitability of these hidden costs should be understood when undertaking a high risk projects.
4. Broad and open engagement. There’s a broad network of “stakeholders” outside the project who need a partial understanding of what’s happening. There will be challenging periods with their confidence, especially from the unknowns that can’t even be described properly. The stakeholders have specific worries (unknowns), and they need to hear messages from people they trust – project liaisons. Rather than try and centralise all messaging, intelligence-led project management centralises a core of truth (as it is now), and the liaisons adapt it to each audience.
5. Training is needed on how intelligence-led project management differs from agile project management. For the executives and stakeholders outside the project, there needs to be explanation and reinforcement – in meetings and in 1:1’s. For those team members who are accustomed to working within agile development, they need to adjust to an increase in spikes, and open discussion about unknowns, and an increased emphasis on controlled messaging. For team members who are not used to agile methods, they need peer mentoring and an increased attention on their mental wellbeing.
6. Measures of total risk become unreliable. The conventional methods of tracking project risk are misleading when there are unknowns that can’t be measured and change faster than they can be assessed, and when the team is so busy fighting challenges that they maintain only simple risk registers. It’s also misleading because the number of risks rise as the team dives into detail, and then the number of new risks roughly corresponds to the rate that existing ones are removed. One way of looking at total risk is to focus on a high level “summary” of broad, risks and comparing them to how they were a month or two ago.
If you are not ready to handle the downsides of a high risk project, it’s dangerous to proceed.
Check you can handle all 6 of the downsides.
Comparison against conventional project management
Three differences below.
Handling the unknown
Intelligence-led project management spans from unknown unknowns through to visible problems. It supports concerns that can’t be described accurately, such as from technologies that have not been fully researched, market changes that are only partially understood.
Sequence by which an unknown unknown becomes a risk or problem
Focus on outcomes
Intelligence-led project management also supports projects that are driven by a vision or overriding ambition. With that comes ambiguity in the detailed objective and priorities. To comply with “professional” project management, the project has listed outputs and success criteria. But in a squeeze, these are negotiable – swapping for different outputs that have an equivalent business outcome and benefit.
Project management culture uses risk registers of potential problems, and issue lists of actual projects. It’s a technique dating back to work by the Association for Project Management, over 1995-1997. It relies on quantitative sizing of each risk.
With intelligence-led projects we can track all the open questions, we can indicate whether they are green, amber or red. But we can’t put meaningful numbers to the unknown. All we can do is track the quantity of open and closed challenges, and compare them against previous patterns.
Culture
There’s a culture change, as highlighted above in the “6 downsides”.
Search for agile project management using your favourite search engine. I’ve worked with a variety from Kanban, through classic scrums, to the Scaled Agile Framework and DSDM – they can all be extended to intelligence-led project management..
For ideas relating to leading these cycles, there are ideas within “Leading Intelligence Analysis: Lessons from the CIA’s Analytic Front Lines”, by Bruce E Pease, 2020. (See more at https://us.sagepub.com/en-us/nam/leading-intelligence-analysis/book258717 .) It’s only partly relevant, because there are a lot of differences between CIA activities and high-risk technical projects.
The description of the intelligence cycle, is derived from chapter 5 of “Securing the State”, by David Omand, 2011. (See more at https://www.hurstpublishers.com/book/securing-the-state/ .) Chapter 6 is also useful for understanding the weakness in intelligence to which we’re susceptible.
And most inspiring of all for managing extreme risk in difficult situations, there is “Risk, a User’s Guide”, by General Stanley McChrystal (rtd.) and Anna Butrico, Penguin Business, 2021. (See more at https://www.mcchrystalgroup.com/library/risk-a-users-guide/ .) He applies his experience of army and intelligence to risk management in finance and industry.
McChrystal tells the story of the Battle of Monongahela, 1755, when a British expeditionary force was defeated by the French and Native Americans with inferior equipment and smaller numbers. The reason? General Edward Braddock refused to adapt. The same applies to leaders who take on high-risk projects and blindly hope that conventional project methods will work without adding intelligence methods. It’s a recipe for disaster.
The non-necessary cookies are to retain statistics about visitors, using Google Analytics. This helps us improve existing content and identify what new content to create. (There is also a non-necessary cookie to aid with caching pages, to improve website performance.)
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Survive high risk projects using intelligence methods
High risk projects can be managed. Intelligence-led project management treats project failure like a terrorist threat. It extends agile project and delivery methods.
Its core mechanism is to move unknowns into manageable risks, or to dismiss them. It does this by chunking uncertainty into small elements that can be individually researched and analysed.
For exploring unknowns, a rapid cycle is used, that can be from 1 day to 2 weeks long. At the end of each cycle, there’s a choice of what to do next.
The upside is it’s possible to handle high risk projects that are critically important. The downside is it’s demanding and only works if all the preconditions are met.
The method extends the scope of professionalism to cover areas that were previously ignored. The cycle has been adapted from the intelligence profession and its “action-on all-risks intelligence cycle”.
Who benefits from adding an intelligence cycle in a project?
The project owner, who can avoid abandoning a project because it is too high risk … or not abandoning it, and facing disaster.
Project managers, who can manage unknowns and a fast moving environment.
The team members, who have defined roles and a level of insulation from the turmoil of high risk projects.
Internal stakeholders who can see high risk steadily being reduced.
External customers, who can get the results of the project.
The intelligence cycle for investigating unknowns
The intelligence cycle adds to the portfolio of tools for agile project management. It’s purpose is to make an incremental step forward in researching or managing an unknown, risk or problem.
Large and ambiguous unknowns are broken into smaller challenges that can be addressed within an intelligence cycle. Ultimately all aspects of the large question are resolved, following many intelligence cycles performed by many teams. Within the agile methodology, the challenges are addressed within stories or spikes.
Below are four types of challenge that can be addressed by introducing intelligence methods.
Guessed assumptions
Every project has assumptions. Some are listed, most not.
At the start of projects, and for sometime within them, we make assumptions based on best guesses. Some of these assumptions later turn around and bite us (metaphorically).
Where there is a suspicion that an assumption is invalid, it’s perceived as good practice to check it. But checking an assumption involves research, and potentially analysis – an intelligence cycle. There’s a cost. It’s idealistic and unrealistic to think large numbers of assumptions can be checked when the project is already racing. It’s good practice to do it, and good finance not to. A contradiction.
And if someone has been enthusiastic at documenting all assumptions by using checklists, the large list of assumptions becomes a vast list.
The dilemma in professional priorities is impossible to reconcile. Pragmatism is needed. Individual assumptions are checked because someone has a suspicion of something anomalous, or a fear based on previous experience.
Unknown unknowns
These are the surprises – assumptions that seemed safe, or had not been considered.
The earlier these can be detected, the easier it is to manage them. One technique for finding unknown unknowns is to recognise symptoms that have no reasonable explanation. The intelligence cycle can be used to explore these symptoms, to see if they are real or just a false lead.
Lack of explanation
It’s not enough to have a solution to a risk. The people who help with the solution will need to understand why it happened and why it’s a risk. The explanation is needed by the delivery teams, the management and finance teams, and business stakeholders outside the project.
Providing an explanation requires analytic techniques to interpret the broader context, and it frequently involves additional research to resolve questions within the analysis.
The upside: if you can explain a risk then you’re frequently a step closer to being able to manage it.
“Unmanageable” risks
There will be cases of potential problems (risks) that appear unmanageable.
Appearance can be deceptive. We need smart ways of seeing the risk, and we need to be inventive. That means looking at alternative ways of doing things, or negotiating different results for the project that deliver a similar business outcome.
Innovation involves thinking laterally. It is also heavily dependent on understanding the broader context of the business, technology and customer’s needs. That needs the right kind of people supporting the project, even if they are not regular members.
Is it professional to worry about suspicions and rumours?
As a Chartered IT Professional, I ponder about the “professionalism” of this approach. Some thoughts below, and as a professional, I’ve added a counter-argument for each.
Economically, yes, because risks avoided early are cheaper than problems that occur late.
(Counter argument: it comes at the price of lost commercial opportunity, because of the expertise and resources needed to explore the suspicions and rumours.)
Scientifically, yes, it’s professional because it’s about moving towards testable hypotheses.
(Counter argument: hypotheses appear anyway, without help.)
As an engineer, yes, because this is a manageable process.
(Counter argument: being manageable, does not mean it’s a good process.)
As a team leader, yes, because it demonstrates that ambiguous threats can be managed.
(Counter argument: there are also other ways of managing a team’s worries.)
As a senior exec, yes, it’s professional because this is the same process of following-up hunches and new initiatives.
(Counter argument: executive intuition is used to drive investigations, and should not be used to make decisions.)
And as a humanitarian, yes, because it helps the team rationalise and live with the fears and pressure of high risk projects.
(Counter argument: they shouldn’t be put in this situation.)
The action-on culture: 6 downsides of managing high risk projects
The intelligence cycle must be embedded within the way the project works. The culture comes from attitudes as well as process, and from what your organisation is capable of achieving.
1. Relentless pressure. There are multiple challenges open at the same time, with a continual flow of more arriving as fast as these are resolved. This needs a positive attitude, strong team bonding, and flexibility to handle cover for colleagues. Mental wellbeing is critical. Everyone needs to be watching and supporting their colleagues – no one is left behind. And it’s important to know there’s an end in the near future, because there’s a beautiful world beyond high risk projects.
2. The demand on specialists. Intelligence-led project management has a similar demand on expertise to the intelligence practices on which it is based. The research pulls on people from outside the project who have critical skills. And the analysis involves a continual load on specialists. The kind of people who usually help start a project and then leave, find themselves involved from start to end. It’s a challenge for them to find time from their own existing agendas.
3. Indirect costs. Relating to the above, the project will involve people who are not being charged to it. Fighting major threats engenders a culture of buy, beg, borrow or steal. The inevitability of these hidden costs should be understood when undertaking a high risk projects.
4. Broad and open engagement. There’s a broad network of “stakeholders” outside the project who need a partial understanding of what’s happening. There will be challenging periods with their confidence, especially from the unknowns that can’t even be described properly. The stakeholders have specific worries (unknowns), and they need to hear messages from people they trust – project liaisons. Rather than try and centralise all messaging, intelligence-led project management centralises a core of truth (as it is now), and the liaisons adapt it to each audience.
5. Training is needed on how intelligence-led project management differs from agile project management. For the executives and stakeholders outside the project, there needs to be explanation and reinforcement – in meetings and in 1:1’s. For those team members who are accustomed to working within agile development, they need to adjust to an increase in spikes, and open discussion about unknowns, and an increased emphasis on controlled messaging. For team members who are not used to agile methods, they need peer mentoring and an increased attention on their mental wellbeing.
6. Measures of total risk become unreliable. The conventional methods of tracking project risk are misleading when there are unknowns that can’t be measured and change faster than they can be assessed, and when the team is so busy fighting challenges that they maintain only simple risk registers. It’s also misleading because the number of risks rise as the team dives into detail, and then the number of new risks roughly corresponds to the rate that existing ones are removed. One way of looking at total risk is to focus on a high level “summary” of broad, risks and comparing them to how they were a month or two ago.
Comparison against conventional project management
Three differences below.
Handling the unknown
Intelligence-led project management spans from unknown unknowns through to visible problems. It supports concerns that can’t be described accurately, such as from technologies that have not been fully researched, market changes that are only partially understood.
Focus on outcomes
Intelligence-led project management also supports projects that are driven by a vision or overriding ambition. With that comes ambiguity in the detailed objective and priorities. To comply with “professional” project management, the project has listed outputs and success criteria. But in a squeeze, these are negotiable – swapping for different outputs that have an equivalent business outcome and benefit.
This focus on outcomes and vision is similar to a vision-driven programme, such as described in Managing successful programmes https://www.axelos.com/certifications/propath/msp-programme-management .
Risk tracking
Project management culture uses risk registers of potential problems, and issue lists of actual projects. It’s a technique dating back to work by the Association for Project Management, over 1995-1997. It relies on quantitative sizing of each risk.
With intelligence-led projects we can track all the open questions, we can indicate whether they are green, amber or red. But we can’t put meaningful numbers to the unknown. All we can do is track the quantity of open and closed challenges, and compare them against previous patterns.
Culture
There’s a culture change, as highlighted above in the “6 downsides”.
Related reading
Search for agile project management using your favourite search engine. I’ve worked with a variety from Kanban, through classic scrums, to the Scaled Agile Framework and DSDM – they can all be extended to intelligence-led project management..
For ideas relating to leading these cycles, there are ideas within “Leading Intelligence Analysis: Lessons from the CIA’s Analytic Front Lines”, by Bruce E Pease, 2020. (See more at https://us.sagepub.com/en-us/nam/leading-intelligence-analysis/book258717 .) It’s only partly relevant, because there are a lot of differences between CIA activities and high-risk technical projects.
The description of the intelligence cycle, is derived from chapter 5 of “Securing the State”, by David Omand, 2011. (See more at https://www.hurstpublishers.com/book/securing-the-state/ .) Chapter 6 is also useful for understanding the weakness in intelligence to which we’re susceptible.
And most inspiring of all for managing extreme risk in difficult situations, there is “Risk, a User’s Guide”, by General Stanley McChrystal (rtd.) and Anna Butrico, Penguin Business, 2021. (See more at https://www.mcchrystalgroup.com/library/risk-a-users-guide/ .) He applies his experience of army and intelligence to risk management in finance and industry.
McChrystal tells the story of the Battle of Monongahela, 1755, when a British expeditionary force was defeated by the French and Native Americans with inferior equipment and smaller numbers. The reason? General Edward Braddock refused to adapt. The same applies to leaders who take on high-risk projects and blindly hope that conventional project methods will work without adding intelligence methods. It’s a recipe for disaster.
Contents
Related Posts
Obsessive secrecy in intelligence agencies – the dangers
“Today will be different” – an example of too many unknowns
“Fightback” – manage a technology failure – a case study