The project recovery process

Projects fail for a variety of reasons. Especially technology projects have a low success rate. Typically more than half of them are considered a failure. But it does not have to end that way.

As soon as a project is identified as in trouble you can start thinking about project recovery. This sentence already states a very important precondition for a successful project recovery process, namely identifying a project as troubled. It takes a great deal of political savvy and courage to admit that a project is in serious trouble.

Results of a project recovery

A project recovery process can have three possible outcomes:

1) Delivery of the project without significant changes in scope, time and/or costs. This is very rarely and only possible when trouble is identified early and action is taken immediately. 

2) Delivery of the project with significant changes in scope, time and/or costs. There will be an impact on the business case. 

3) Termination of the project because costs and benefits or value are no longer aligned. Note that termination does not necessarily mean that everything done up to this point should be written off as sunk costs. Some part might be salvageable.

The project recovery process

A typical project recovery process consists of the five phases below.

1) The mandate phase

The purpose of the mandate phase is simple. The project should be identified as troubled, and a project recovery manager should be identified. The mandate of the project recovery manager should be defined clearly. Especially when the recovery manager is working with the current or new project manager instead of replacing him/her. Afterwards, the project recovery manager and his/her should be introduced to everybody that needs to know. The project recovery manager can be an internal role, but there are a number of good reasons to hire an external project recovery manager.

2) The review phase

Now that we have a clear mandate, we enter the review phase, which is a critical assessment of the project's existing status. You will look at what went wrong and what can be corrected rather than looking for someone to blame. A project review is all about the probability of project success. A project review will give you a good understanding of the current status of the project and how it is on track to deliver against your definition of project success on three levels:

1) Project delivery success

2) Product or service success

3) Business success

You will find a detailed outline of such a review under my project review service. Note that if the project has a technical component, the project recovery manager should have a strong technical background so that he or she can talk with the technical team on its own level, gaining trust as someone who understands the challenges. This must be coupled with an independent critical eye questioning the direction. Many aspects of technology development can contribute to, or even cause trouble on a project.

3) The tradeoff & negotiation phase

Hopefully, by this point, you have the necessary information for decision making as well as the team's support for the recovery. It may be highly unlikely that the original requirements can still be met without some serious tradeoffs. You must now work with the team and determine the tradeoff options that you will present to your stakeholders.

When the project first began, the constraints were most likely the traditional triple constraints. Time, cost and scope were the primary constraints and tradeoffs would have been made on the secondary constraints of quality, risk, value and image/reputation. When a project becomes troubled, stakeholders know that the original budget and schedule may no longer be valid. The project may take longer and may cost significantly more money than originally thought. As such, the primary concerns for the stakeholders as to whether or not to support the project further may change to value, quality and image /reputation. See "The reverse triple constraint of troubled projects" for more background on this.

After defining the tradeoffs, the project recovery manager is ready for stakeholder negotiations provided that there still exists a valid business case. If the review phase indicates that the recovery is not possible and a valid business case does not exist, then there may be no point to negotiate with the stakeholders unless there are issues with which the project recovery manager is not familiar.

4) The intervention phase

Assuming the stakeholders have agreed to a recovery plan, you are now ready to start the intervention phase of the project. This means: 

- Briefing the team on the outcome of the negotiations 

- Making sure the team learns from past mistakes 

- Introducing the team to the stakeholders' agreed-upon recovery plan including the agreed-upon milestones 

- Introducing any changes to the way the project will be managed 

- Fully engaging the project sponsor as well as the key stakeholders for their support

- Identifying any changes to the roles and responsibilities of the team members 

- Restore team confidence 

"We cannot solve our problems with the same thinking we used when we created them." - Albert Einstein

The way I set up the delivery part of the project with my team(s) at almost every intervention phase I start I described in "A simple and effective project delivery framework". 

5) The transition phase

As soon as the project is in a normal state again the project recovery manager (when he/she does not have the project manager role) can transfer the responsibility for the recovered project and closes the recovery process. When the project recovery manager also has the role of project manager he/she can decide to close the recovery process and manage the project as if it was a freshly started project or keep the project in a recovery process until the project is finished. 

Read more…

10 Leading indicators of troubled projects

In project management, we often talk about “lagging” and “leading” indicators. Lagging indicators are typically “output” oriented, easy to measure but hard to improve or influence. Leading indicators at the other hand are typically "input" oriented, harder to measure but easier to influence.

Let me illustrate this with a simple example. Let's imagine you are responsible for managing a customer support team, and your goal is to resolve any high priority incidents within 48 hours. Currently, you only succeed in 70% of such incidents.

The output is easy to measure: You either solve these incidents in 48 hours or not. But how do you influence the outcome? What are the activities you must undertake to achieve the desired outcome?

For instance: Make sure your team starts working on such incidents immediately when they occur. Make sure that incidents are assigned to the right people with the right skillset and that this person isn’t already overloaded with other work.

This could be translated into the following “leading” indicators
- % of incidents not worked on for 2 hours.
- % of open incidents older than 1 day.
- % of incidents dispatched more then 3 times.
- Average backlog of incidents per agent

When you would start measuring these indicators on a daily basis and focus on improving these, I would think it is extremely likely to see an improvement in reaching your goal.

Lagging indicators for projects

As I have written many times before, it's essential to work actively with the organization that owns a project to define success across three levels before you start a project:

1. Project delivery success is about defining the criteria by which the process of delivering the project is successful. Essentially this addresses the classic triangle "scope, time, budget". It is limited to the duration of the project and success can be measured as soon as the project is officially completed (with intermediary measures being taken of course as part of project control processes). 

2. Product or service success is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.). These criteria need to be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured immediately at the end of the project itself.

3. Business success is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (market share won, technology advantage), etc.

One way to do define these criteria is using so-called OKRs (see Using OKRs to define Project Success). All the measures mentioned above are lagging indicators. A lagging indicator is a measurable fact that records the actual performance of a project. They all represent facts about the project, the resulting product/service and the benefits of it to the organization.

But things can start to go wrong in a project well before the performance measure turns the traffic light on the scorecard red. Using metrics that measure past events is like driving while looking through the rear window. It’s easy not to see an opportunity or threat on the road ahead until you’re upon it.

Leading indicators for projects

A leading indicator is a measurable factor that changes before the project starts to follow a particular pattern or trend. Leading indicators are used to predict changes in the project, but they are not always accurate.

Examples of leading indicators for a project’s success:

1. Poorly defined (or undefined) done: Project failure starts when we can’t tell what “done” looks like in any meaningful way. Without some agreement on our vision of “done,” we’ll never recognize it when it arrives, except when we’ve run out of time or money or both.

2.  Poorly defined (or undefined) success: A project can only be successful if the success criteria are defined, ideally upfront. Therefor the lack of these definitions on the three levels as described above are a great leading indicator for project trouble.

3. Stability, quality and availability of project team: a lot of change in the project team is a good leading indicator for trouble. The same for missing skills and experience. Also team atmosphere is a great leading indicator. See "How to do a project delivery team review".

4. Engineering practices: the practices that are implemented are a good leading indicator for engineering quality. See "How to review your team’s software development practices" for a comprehensive list of such practices.

5. Risk management: the presence or lack of risk management is a great leading indicator for the impact of negative surprises. See "Risk Management Is Project Management for Adults".

6. Availability of up to date RAID lists: the quality of these list are a great indicator for awareness of trouble. See "Proactively manage your project with RAID lists (Risks, Assumptions, Issues and Decisions" for tips on how to set up these lists.

7. Engagement of stakeholders and Steering Committee: When the stakeholders do not care about your project, then why should you? See "10 Principles of Stakeholder Engagement" and "How to establish an effective Steering Committee (and not a Project Governance Board)" for tips on how to manage this.

8. Runway: the burn rate of a project is a lagging indicator as it describes how many money is spent (or lost) for any period of time. The runway is a leading indicator as it predicts how long the budget would last with a specific burn rate.

9. Milestones: missing or achieving the deadline on a milestone is a lagging indicator. But it is also a leading indicator for following milestones.

10. Project size: the bigger the project, the higher the probability it fails.

All leading indicators can be used for identifying troubled projects before it is too late to do something about it. Just be aware that because a leading indicator is positive, it does not mean the final outcome will be positive. Nor will a negative leading indicator means automatically a negative outcome.

Read more…

Effective strategy execution in 10 steps

After you have defined your strategy you can start implementing it. This is also called strategy execution. As explained in a previous article on strategy execution, I fully agree with the approach of Jeroen Flanders who defines this process as “helping people make small choices in line with a big choice”. This article gives a 10 step approach on how could you achieve this in your organization.

Step 1: Visualize your strategy. One of the challenges of strategy execution is simply understanding what a strategy is. An effective way to improve this understanding is to visualize the strategy via an illustration that shows both the important elements of the strategy and how each relates to one another. Frameworks such as the Strategy Map by Kaplan and Norton, the Activity Map by Michael Porter, or the Success Map by Andy Neely can help you with this.

Step 2: Measure your strategy. Key elements of your strategy should be assigned an easily understood performance measure. The full set of strategic performance measures can be organized into a dashboard, a Balanced Scorecard, or some other framework like OKRs, so everyone can determine if progress is being made toward executing the strategy.

Step 3: Communicate your strategy. It is close to impossible to execute your strategy when the strategy itself isn’t well understood, or performance relative to it is not communicated. Leaders must communicate their visualized strategy to the organization in a way that will help them understand not only what needs to be done, but why.

Transparent and easy-to-understand communication creates the necessary understanding and engagement for the new/adapted strategy. It is essential to use all available communication platforms. One big strategy event and a single strategy e-mail are not nearly enough. Use other meeting platforms, discussion groups, informal and formal encounters, performance management sessions, intranets, websites, screensavers, coffee corners, billboards, etc. to communicate the strategy.

Step 4: Review your progress. In the same way that financials are reviewed monthly, your strategy should be reviewed regularly. The focus of these reviews should  be determining if the strategy is producing results, and not controlling performance. Your business strategy is a hypothesis. It’s your best estimate of the route to success … but it’s still an estimation. It’s crucial to take some time at the end of a cycle to go back and check your hypothesis. To check your strategy against reality.

Step 5: Make decisions. Strategy execution is much like sailing a boat toward a planned destination. A defined course and a full complement of navigational charts will never eliminate the need to remain vigilant, to assess the environment, and to make corrections as conditions change. As part of the regular strategy reviews (Step 4) you must make ongoing strategic decisions to keep the strategy current and on course.

Step 6: Identify and categorize all your projects. Organizations may have many, if not hundreds, of projects ongoing at any point, but they rarely have a firm grasp on the type and range of these projects. The first step in improving project-oriented strategy execution is to capture and categorize all projects that are underway in and planned throughout an organization.

Once strategic goals have been defined, which is itself a nontrivial process, linking them to project proposals and your existing projects is relatively straightforward. Each project can be examined to see the extent to which it supports each of the strategic goals. See my articles on Demand Management and Categorization for ideas on how to implement this.

Step 7: Evaluate and align your strategy projects. Once projects are captured they must then be aligned to the strategies or goals for the organization. This step entails comparing each project, either proposed or ongoing, to the strategic goals to determine if alignment exists.

This is the activity in which your dreams run up against reality, your business strategy meets operations, and resources are added to the strategy formula. This is one of the most difficult steps in strategy execution − and so it’s also where execution quite often goes wrong.

It is all about selecting, prioritizing and executing the right projects. The goal is not to choose the 10 project proposals with the highest return on investment, but to ensure that the projects map to the strategic goals of the business. See my articles on Portfolio Evaluation and Portfolio Alignment for ideas on how to implement this.

Step 8: Deliver your projects. Organizations must develop a capability in project management and execution in order to execute strategy effectively. A project not delivered means benefits not delivered, and for strategic projects this means (parts of the) strategy not executed.

An important goal of your strategy execution should be to have a high project throughput. Get projects delivered fast so you start reaping your benefits, and your organization is freed up for new projects to deliver additional benefits.

For a typical organization this means three things;

1) Doing fewer projects (in parallel). On average only half of what you are doing now.
2) Focus on doing the right projects.
3) Focus on improving your project delivery capability.

Step 9: Align individual roles. Employees want to know they are making a meaningful contribution to their organization’s success. It’s up to senior leaders to ensure that employees at all levels can articulate and evaluate their personal roles toward achievement of specific strategic goals. This is perhaps one of the most critical aspects of the execution process.

Step 10: Reward performance. In strategy execution, as in any other area of management, what gets measured gets done. Taking this one step further, what get measured and rewarded gets done faster. After explaining the strategy and aligning your organization to it, senior managers institute the incentives that drive behaviors consistent with the strategy. Link individual objectives with the strategy at the organisational level.

Conclusion

Strategy execution is difficult in practice for many reasons, but a key impediment to success is that many leaders don’t know what strategy execution is, or don't know how to approach it. While this 10-step approach won’t guarantee strategy execution success, it will greatly improve your odds.

Read more…

Strategy execution as a decision-making process

In my last article, I wrote about what strategy is, and what not. And although strategy is important, it is pretty much worthless without execution. So what is strategy execution?

Strategy execution as a process

The most notable book to date on strategy execution is “Execution: The Discipline of Getting Things Done”, by Larry Bossidy and Ram Charan. Bossidy, a retired CEO, and Charan, a renowned management consultant, make the case for execution as a discipline or “systematic way of exposing reality and acting on it.”  They explain that “the heart of execution lies in three core processes":

1)  People
2)  Strategy
3)  Operations

They explain the processes and descriptions managers use to successfully drive business results.

Strategy execution as a system

The information presented in the aforementioned book is certainly useful, but the authors don’t fully explain how an organization can implement their three core processes to achieve strategy success. There have been significant advancements in this area since Execution was published in 2002.  In 2008, Harvard Business School Professor Robert S. Kaplan and his Palladium Group colleague David P. Norton wrote "The Execution Premium: Linking Strategy to Operations for Competitive Advantage". In it they present their management system, which houses six sequential stages intended to help organizations capture what they call an “execution premium”—a measurable increase in value derived from successful strategy execution. They outline six stages in this system:

1) Develop the strategy
2) Plan the strategy
3) Align the organization
4) Plan operations
5) Monitor and learn
6) Test and adapt

Through detailed subactivities—26 in total— Kaplan and Norton explain how organizations have successfully executed strategy via application of their management system.

Strategy execution as a decision-making process 

Both of the models outlined above are important and anyone serious about the practice of strategy execution should be familiar with them. But both are not focusing what is the most important in my opinion. The one definition that sofar resonates most with me is the one of Jeroen de Flander. His explanation of strategy execution starts with a famous Mintzberg quote.

“Strategy is a pattern in a stream of decisions.” - Henry Mintzberg            

First, there’s the overall decision—the big choice—that guides all other decisions. To make a big choice, we need to decide who we focus on—our target client segment—and we need to decide how we offer unique value to the customers in our chosen segment. That’s basic business strategy stuff.

But by formulating it this way, it helps us to better understand the second part, the day-to-day decisions—the small choices—that get us closer to the finish line. When these small choices are in line with the big choice, you get a Mintzberg Pattern. So if strategy is a decision pattern, strategy execution is enabling people to create a decision pattern. In other words:

“Strategy execution is helping people make small choices in line with a big choice.” - Jeroen Flanders

This notion requires a big shift in the way we typically think about execution. Looking at strategy execution, we should imagine a decision tree rather than an action plan. Decisions patterns are at the core of successful strategy journeys, not to-do lists.

To improve the strategy implementation quality, we should shift our energy from asking people to make action plans to help them make better decisions.

Read more…

What is strategy? And what isn't.

An essential part of strategy execution is linking your project portfolio to your strategy. This translation from strategy to actual projects implementing it is one of the most important goals of project portfolio management. This concept is easy to grasp, but where I see many organizations struggle is to actually define a strategy that is clear, easy to communicate and defined in such a way that the rest of the organization can actually execute on it.

So let's start with what strategy is not.

Mission and Vision: these are elements of strategy, but they aren't enough. They offer no guide to productive action and no explicit roadmap to the desired future. They don't include choices about what businesses to be in and not to be in. There is no focus on sustainable competitive advantage or the building blocks of value creation.

A plan: tactics and plans are also elements of strategy, but they aren't enough either. A detailed plan that specifies what the organization will do (and when) does not imply that the things it will do add up to sustainable competitive advantage. When you have read my previous article on project success you will remember that the same is true for projects.

Emergent: The world is changing so quickly, some leaders argue, that it's impossible to think about strategy in advance and that, instead, an organization should respond to new threads and opportunities when they arise. Emergent strategy has become a new buzzword at many technology companies and start-ups, which indeed face a rapidly changing marketplace. Unfortunately, such an approach places company in a reactive mode, making it easy prey for more strategic rivals. Long and midterm strategy is possible in a fast changing world and it can be a real competitive advantage.

Optimization of the status quo: Many leaders try to optimize what they are already doing in their current business. This can create efficiency and drive some value. But it isn't strategy. The optimization of current practices does not address the very real possibility that the firm could be exhausting its assets and resources by optimizing the wrong activities. Optimizing has its place in business, but it is not strategy.

“There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.”  ― Peter Drucker

Following best practices: every industry has tools and practices that become widespread and generic. Some organizations define strategy as benchmarking against competition and then doing the same set of activities but more effectively. Sameness isn't startegy. It is a recipe for medocrity.

So what is strategy?

Mike Porter states in his influential book "Competitive Strategy" that an organization creates a sustainable competitive advantage over its rivals by "deliberately choosing a different set of activities to deliver unique value". So strategy requires making explicit choices.

Lafley and Martin define strategy in their book "Playing to win: how strategy really works." as an integrated set of choices that uniquely positions the organization (which can be a company, a department, or a business unit) in its industry so as to create sustainable advantage and superior value relative to the competition.

It is natural to want to keep options open as long as possible, rather than closing off possibilities by making explicit choices. But it is only through making and acting on choices that you can win. Yes, clear, tough choices force your hand and confine you to a path. But they also free you to focus on what matters.

I really like the approach of the authors and I have used it with success in strategy definition and refining workshops. The rest of this article summarizes their approach and when this resonates with you I would recommend reading the book.

Lafley and Martin's main point is that strategy is the answer to the following five interrelated questions:

1) What is your winning aspiration? The purpose of your enterprise, its motivating aspiration. Simon Sinek calls it the "why?". Aspirations are statements about the ideal future. At a later stage, you can formulate these as OKRs that measure progress toward them. An organization must seek to win in a particular place and in a particular way. If it does not seek to win, it is wasting the time of its people and the investments of its capital providers. Think about this, and you will probably agree that this is valid for non-profit organizations as well. When I donate money I want that organization to win (in this case do as much good as possible). And the volunteers working for that organization want to win as well.

2) Where will you play? A playing field where you can achieve that aspiration. It represents the set of choices that narrow the competitive field. The questions to be asked focus on where the organization will compete - in which markets, with which customers and consumers, in which channels, in which product categories, and at which vertical stage or stages of the industry in questions. This set of questions is vital; no organization can be all things to all people and still win, so it is important to understand which where-to-play choices will best enable the comapny to win.

3) How will you win? The way you will win on the chosen playing field. To determine how to win, an organization must decide what will enable it to create unique value and sustainability, and deliver that value to customers in a way that is distinct from the organization's competition. Remember this is always tied to where you play.

4) What capabilities must be in place? The set and configuration of capabilities required to win in the chosen way. Capabilities are the map of activities and competencies that critically underpin specific where-to-play and how-to-win choices. For example for a SaaS company: software development, superb customer onboarding/support, scaling, analytics, and brand building.  The capabilities should support and reinforce one other. In isolations, even when the capability is strong, they will not generate a competitive advantage. But all together they are the pillars of growing the business.

5) What management systems are required? The systems and measures that enable the capabilities and support the choices. To be truly effective they must be purposefully designed to support the choices and capabilities. But in general you can say that the systems need to ensure that choices are communicated to the whole organization, employees are trained to deliver on choices and leverage capabilities, plans are made to invest and sustain capabilities over time, and the efficacy of the choices and progress towards aspirations are measured.

These choices and the relationship between them can be understood as a reinforcing cascade, with the choices at the top of the cascade setting the context for the choices below, and choices at the bottom influencing and refining the choices above.

Read more…

Using OKRs to define Project Success

One of the main reasons why projects fail is not defining project success. A project can only be successful if the success criteria are defined. And this ideally upfront. Unfortunately, I have seen many projects that skipped this part completely.

When starting a project, it's essential to work actively with the organization that owns the project to define success across three levels:

1) Project delivery
2) Product or service
3) Business

Project delivery success

Project delivery success is about defining the criteria by which the process of delivering the project is successful. Essentially this addresses the classic triangle "scope, time, budget". It is limited to the duration of the project and success can be measured as soon as the project is officially completed (with intermediary measures being taken of course as part of project control processes). 


Product or service success

Product or service success is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.). These criteria need to be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured immediately at the end of the project itself.


Business success

Business success is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (market share won, technology advantage), etc.


Overall project success

These levels combined will determine your overall project success. You can be successful on one level but not others. This sounds all good in theory, but in practice, it is not so easy to define the criteria for levels 2 and 3. This is one of the main reasons why so many organizations only look at level 1: scope, time and budget. They are easy to define and measure.

Personally, I think level 1 matters very little if levels 2 and 3 are not met. So in spite of the “project management triangle”, the fact is that delivering a project on time, in scope and in budget is not enough. The project must be delivered successfully – meaning that the objective(s) that motivated the project in the first place have to be reached.

This is where so-called OKRs come into the game.

What are OKRs?

OKR is an abbreviation for Objective and Key Result. The concept was invented at the Intel Corporation and is widely used amongst the biggest technology companies in the world including Google and Zynga.

OKRs are originally meant to set strategy and goals over a specified amount of time for an organization and teams. At the end of a work period, your OKRs provide a reference to evaluate how well you did in executing your objectives.

You can use the same concept for defining project success. Spending a concerted effort in identifying your project strategy and goals, and laying it out in a digestible way with OKRs can truly help your project team and stakeholders see how they are contributing to the big picture and align with other teams.

Objectives

Any project has one or more objectives. The goal of setting an objective is to write out what you hope to accomplish such that at a later time you can easily tell if you have reached, or have a clear path to reaching, that objective. Choosing the right objectives is one of the hardest things to do and requires a great deal of thinking and courage to do well.

Key Results

Assuming your Objectives are well thought through, Key Results are the secret sauce to using OKRs. Key Results are numerically-based expressions of success or progress towards an Objective. All Key Results have to be quantitative and measurable. As Marissa Mayer, a former Google’s Vice President, said:

“If it does not have a number, it is not a Key Result.”                                   

The important element here is measuring success. It’s not good enough to make broad statements about improvement (that are subjectively evaluated). We need to know how well we are succeeding. Qualitative goals tend to under-represent our capabilities because the solution tends to be the lowest common denominator.

For example, if I create a goal to “launch new training for the sales team” I might do that for one sales member. If I alternatively make a Key Result of “train 50 sales team members” and only train 10, I’ve still 10x-ed my original goal.

Don’t turn OKRs into a project task list

Do you measure effort or results? Are your OKRs focused on your objective or on the means to get there? As we mentioned before, when used correctly, OKRs define success criteria for a project. OKRs should determine whether a project achieved success. But to do that, OKRs cannot be based on activities for three main reasons:

1) We want a results-focused culture, and not one focused on tasks.

2) If you did all your tasks and nothing improved, that is not a success. Success is improving something: customers are more satisfied, sales are higher, costs have been reduced.

3) Your project is just a series of hypotheses. An idea is just a non-validated hypothesis. In the same way, we don’t know if our project will improve our results or add value to the organization. The project is just a hypothesis so you cannot attach your OKRs to a non-validated bet. See No validation? No Project! for more on this topic.

Nobody works on projects as a hobby. Behind every project is a desire to improve one or more metrics. So, instead of tracking the delivery of a project, we should measure the indicators that motivated it in the first place.

Use Value-based Key Results

There are two basic types of Key Results:

1) Activity-based Key Results: These measures the completion of tasks and activities or the delivery of project milestones or deliverables. Some examples of Activity-based Key Results are:

- Release a beta version of the product.
- Launch a new feature
- Create a new training program.
- Develop a new lead generation campaign.
- Write a solution design document

Activity-based Key Results usually start with verbs such as launch, create, develop, deliver, build, make, implement, define, release, test, prepare and plan.

2) Value-based Key Results: These measures the delivery of value to the organization or its customers. Value-based Key Results measure the outcomes of successful activities. Some examples of value-based Key Results:

- Increase Net Promoter Score from X to Y.
- Increase Repurchase Rate from X to Y.
- Maintain Customer Acquisition cost under Y.
- Reduce revenue churn (cancellation) from X% to Y%.
- Improve average weekly visits per active user from X to Y.
- Increase non-paid (organic) traffic from X to Y.
- Improve engagement (users that complete a full profile) from X to Y.

The typical structure of a Value-based Key Result is:

Increase/Reduce Metric M from X to Y                                                     

Where X is the baseline (where we begin) and Y is the target (what we want to achieve).

Using the “from X to Y” model is better than writing a change in percentages because it conveys more information. Compare the two options below:

1) Increase the number of new users by 20%.
2) Increase the number of new users from 4000 to 4800.

Option 1 can be confusing since it’s hard to tell how ambitious the target is. Are we talking about increasing the number of new users from 500 to 600 or 4000 to 4800?

Examples

When project teams start with Value-based OKRs, it is common for them to get stuck listing activities as Key Results. To convert those activities into value, think about what would be the consequences of being successful with this task. What would be the desired outcomes?

If we are successful with , we will

- Key Result #1
- Key Result #2
- Key Result #3

Example 1

If we are successful with the new campaign, we will

- Increase Net Promoter Score from 29 to 31%
- Reduce churn from 3.2 to 2.7%

Example 2

If we successfully migrate the platform, we will

- Reduce infrastructure costs from X to Y.
- Maintain availability during migration in 99,99%.
- Maintain revenue of $ X.

OKRs as a communication tool

As you might have guessed by now, effective OKRs are widely shared and meant to be understood by project teams, related teams, and stakeholders. In that regard, they can serve as a communication tool for directing teams to solve complex challenges with constraints.

As a communication tool, OKRs bring two key things to an organization:

1) Easily digestible direction such that every project member/stakeholder in the organization understands how they contribute to the mission; aka focus.

2) Expectations amongst teams and their individual members; aka accountability.

Defining measurable results becomes easier as you learn what you should be measuring and what ultimately matters for your project and business. In my work with large project teams, I find that the quality of OKRs has a good correlation with the understanding of the project. Just going through the exercise of either defining OKRs, or reworking current project plans into OKRs is a highly effective evaluation tool.

Read more…

Risk Management Is Project Management for Adults

The title of this article is a quote from Tim Lister, and is a universal principle for the success of any project in the presence of uncertainty. All software development projects are subject to risk and uncertainty because they are unique, constrained, based on assumptions, performed by people and subject to external influences. Risks can affect the outcome of projects either positively or negatively.

“If There’s No Risk On Your Next Project, Don’t Do It” 

Greater risk brings greater reward, especially in software development. A company that runs away from risk will soon find itself lagging behind its more adventurous competitors. But by ignoring the threat of negative outcomes project managers and executives can drive their organizations into the ground.

Positive Risk

Risk includes both opportunities and threats. Where negative risk implies something unwanted that has the potential to irreparably damage a project, positive risks are opportunities that can affect the project in beneficial ways. You should manage and account for known negative risks to minimize their impact, but positive risks you should manage to take full advantage of them.

There are many examples of positive risks in projects: you could deliver the project early; you could discover that the problem is easier to solve as expected; you could re-use your solution for other problems; you could acquire more customers than you accounted for; you could imagine how a delay in shipping might open up a potential window for better marketing opportunities, etc. Just be aware that positive risk can quickly turn to negative risk and vice versa.

Risk or Uncertainty? 

In project management, or more specifically in risk management, many professionals commonly use risk interchangeably with uncertainty. This is incorrect.

“Uncertainty is risk that is immeasurable.” – Frank Knight

Risk has an unknown outcome, but we know what the underlying distribution looks like. Every game in the casino has a known distribution of winning and losing. Hence you can play and manage risk. Following basic strategy for Black Jack for example. But where the hand of your new and unknown Poker neighbor is a risk, how he plays that hand is an uncertainty. Events of the past are no guarantee for the future.

You cannot manage uncertainty, but you can manage risk. What you can do is reduce the amount of uncertainty. For example by doing a proof of concept or a business case validation for your project.

Risks and Issues

Consider the following circular definition of risk: A risk is an issue that has yet to occur, and an issue is a risk that has already materialized.

Before it happens, a risk is just an abstraction. It’s something that may affect your project, but it also may not. There is a possibility that ignoring it will not come back to bite your ass. Risk management is the process of thinking out corrective actions before an issue occurs. The opposite of risk management is crisis management, trying to figure out what to do about the issue after it happens.

“The opposite of risk management is crisis management” - Tim Lister

Varieties

Risks may be encountered in an almost infinite variety of forms and intensity, it is most useful to consider two varieties:

- Incremental risks. These include risks that are not significant in themselves but that can accumulate to constitute a major risk. For example, a cost overrun in one subcontract may not in itself constitute a risk to the project budget, but if a number of subcontracts overrun due to random causes or a common cause affecting them all, then there may be a serious risk to the project budget. While individually such risks may not be serious, the problem lies in the combination of a number of them and in the lack of recognition that the cumulative effect is a significant project risk.

- Extreme risks. These include risks that are individually major threats to the success of the project, or even the company as a whole. Their likelihood is typically very low but their impact very large. Examples of such risks are dependence on critical technologies that might or might not prove to work, scale-up of bench-level technologies to full-scale operations, or dependence on single suppliers and employees. And of course aliens, always account for a space attack by aliens...

Transitions

Imagine the moment when something that used to be a risk suddenly becomes an issue. It used to be an abstraction, a mere possibility, and now it is not abstract at all. It has happened. This is the point at which the risk is said to materialize. It is the moment of risk transition.

Transition is a key concept for a project manager—it is the triggering event for whatever is planned to deal with the risk. Well, almost. The actual transition may be invisible to you (for example, your biggest client goes out of business). What you do see is a transition indicator (the client not paying your invoices for a while). For every risk you need to manage, there is some kind of transition indicator. Of course some indicators are more useful than others.

Response Strategies

Depending if a risk is positive (opportunity) or negative (thread) you have following response strategies available to you.

The reason you care about the above mentioned transition is that when the indicator fires, you intend to take some action. This is defined in your contingency plan. But much work can be doen before the transition starts. And you should. Buying a life insurance after your dead is difficult... 

Risk Management

So what is risk management? I always explain as the combined outcome of the five activties below.

1) Risk discovery: your initial risk brainstorm and subsequent triage, plus whatever mechanism you put in place to keep the process going
2) Exposure analysis: quantification of each risk in terms of its probability of materializing and its potential impact
3) Contingency planning: what you expect to do if and when the risk materializes
4) Response planning: steps that must be taken before transition in order to make the planned contingency actions possible and effective when required
5) Ongoing transition monitoring: tracking of managed risks, looking for materialization

The first of these is an overall activity, while all the others are done on a per-risk basis.

Risk management is something that most of us practice all the time—everywhere except the office. In our personal lives, we face up to such risks as sickness and early death. We mitigate by buying life and health insurance and by making arrangements for who will look out for the kids if something bad happens. We don’t pretend to be immortal or that our earning capacity can never be harmed by bad luck. Each time we take on a new responsibility—say, a mortgage—we go over all the awful things that we hope won’t happen and force ourselves to think, what if they do?

You should do the same for your software development project.

Read more…