Project Management Principles vs Practices

After reading “Principles” by Ray Dalio for the second time this year I was thinking about what principles do I have in the area of project management? And how are these principles different from practices?

 We are always looking for simple ways to apply good principles (patterns of advice) with meaningful practices (specific actions). This is the crux of delivering consulting advice in most situations. So what is exactly the difference between principles and practices? Here is one example.

 The Boy scout motto – “Be prepared” – is a timeless principle.

 “Buy a plunger before you need a plunger” is a practice that applies this principle in a memorable way.

Principles are good ideas or good values stated in a context-independent manner. Practices are applications of these principles stated in a context-dependent way.

Project Management Principles

When you look at project management I firmly believe in the five principles of project success as defined by Glen B. Alleman in his excellent book “Performance-Based Project Management".

These principles are best stated in the form of questions. When we have the answers to these questions, we will have insight into the activities required for the project to succeed in ways not found using the traditional process group’s checklist, knowledge areas, or canned project templates.

1) What does “done” look like?

We need to know where we are going by defining “done” at some point in the future. This may be far in the future—months or years—or closer—days or weeks from now.

2) How can we get to “done” on time and on budget and achieve acceptable outcomes?

We need a plan to get to where we are going, to reach done. This plan can be simple or complex. The fidelity of the plan depends on our tolerance for risk. The complexity of the plan has to match the complexity of the project.

3) Do we have enough of the right resources to successfully complete the project?

We have to understand what resources are needed to execute the plan. We need to know how much time and money are required to reach the destination. This can be fixed or it can be variable. If money is limited, the project may be possible if more time is available and vice versa. What technologies are needed? What information must be discovered that we don’t know now?

4) What impediments will we encounter along the way and what work is needed to remove them?

We need a means of removing, avoiding, handling or ignoring these impediments. Most important, we need to ask and answer the question, “How long are we willing to wait before we find out we are late?”

5) How can we measure our progress to plan?

We need to measure planned progress, not just progress. Progress to plan is best measured in units of physical percent complete, which provides tangible evidence, not just opinion. This evidence must be in “usable” outcomes that the buyer recognizes as the things they requested from the project.

It does not matter what practices you use to manage and deliver your project. It also does not matter what kind of a project it is. As long as it is a project, the five principles of project success are valid.

Project Management Practices

Most often there is a principle, a truth, a reason, behind the practice you use. Are you aware of the principles behind the practices you have in your project?

- Why do you create a project plan and schedule?
- Why do you do risk management?
- Why do you create a stakeholder map?
- Why do you create RAID lists?
- Why do you use OKRs to define project success?

We must know why we do something otherwise we are just copying someone else.

If you just do something because someone, or some company, you admire is doing it you are following the practice. This will create a sense of legalism in your project team – just following a good idea, or even worse, making good ideas the rules, something you and all your team must do. When we do this we have no inner conviction to help us over the hurdles, when things get hard we’ll give up.

Instead of mindlessly copying we need to consider the principles, the truths we want to build our project on, and then carefully think through the best practices for our team to learn and grow in that truth.

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.

For example, the system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, and so on.

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 example, financial value contribution (increased turnover, profit, etc.) or competitive advantage (market share won, technology advantage).

All these measures are so-called 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 to miss an opportunity or threat on the road ahead until you hit 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. Therefore the lack of these definitions on the three levels as described above is 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.

4) Engineering practices: the practices that are implemented are a good leading indicator of engineering quality.

5) Risk management: the presence or lack of risk management is a great leading indicator of the impact of negative surprises.

6) Availability of up to date RAID lists: the quality of these lists are a great indicator for awareness of trouble. Especially your issue resolution time.

7) Engagement of stakeholders and Steering Committee: When the stakeholders do not care about your project, then why should you?

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.

In a nutshell: Using metrics that measure past events is like driving while looking through the rear window. It’s easy to miss an opportunity or threat on the road ahead until you hit it.

When you need some guidance on how to define and measure project success, just download the Project Success Model by clicking on the image.

Read more…

Effective Strategy Execution in 10 Steps

After you have defined your organization's 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 De Flander 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 to successfully execute your strategy.

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 the organization understand not only what needs to be done, but why.

Transparent and clear communication creates the necessary understanding and engagement for the new/adapted strategy.

For example, 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, and other means 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 to determine if the strategy is producing results, not to control performance.

Your business strategy is a hypothesis. It’s your best estimate of the route to success … but it’s still an estimation. That’s why 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 regular strategy reviews 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.

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 your resources are added to the strategy formula. This is one of the most difficult steps in strategy execution—and it’s also where execution quite often goes wrong.

This step 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.

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 the strategy is not executed (or part of it, anyway).

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, just 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 the 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 gets 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 organizational level.

No matter how well planned your strategy is, executing that strategy effectively is vital in order to achieve results. 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.

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.

100% 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 threats 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. Relying solely on such an approach places a 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 strategy. It is a recipe for mediocrity.

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 company 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 these could be: software development, superb customer onboarding/support, scaling, analytics, and brand building.  

The capabilities should support and reinforce one another. 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.

In a nutshell: Strategy is an integrated set of choices that uniquely positions the organization in its industry so as to create sustainable advantage and superior value relative to the competition.

Read more…

Using OKRs to Define Project Success Criteria

One of the main reasons why projects fail is not defining clear project success criteria. A project can only be successful if the success is 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 criteria 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.

For example, the system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, and so on.

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 example, financial value contribution (increased turnover, profit, etc.) or competitive advantage (market share won, technology advantage).

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 X, 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.

Closing Thoughts

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 done 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 activities 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…

Why Do Technology Projects Fail so Often and so Spectacularly? My Personal Top 10 Reasons

It was to be a great digital leap for Germany’s biggest discount grocer. Instead, after seven years and €500 million, Lidl’s new inventory management system with SAP is dead on arrival. Now everybody is asking why.

Big technology projects fail at an astonishing rate. Whether major technology implementations, postmerger integrations, or new growth strategies, these efforts consume tremendous resources over months or even years. Yet, as study after study has shown, they frequently deliver disappointing returns—by some estimates, in fact, well over half the time. These reports show that 25 percent of technology projects fail outright; that 20 to 25 percent don’t show any return on investment; and that as much as 50 percent need massive reworking by the time they’re finished.

And the toll these failed projects take is not just financial. These defeats demoralize employees who have labored diligently to complete their share of the work. Reputations are lost, and legal issues arise.

But the question is why. Why do so many technology projects fail—and fail so spectacularly? From my experience, it’s usually not technology problems that derail technology projects. I am of the opinion that most technology project failures can be attributed to poor management, while only a small percentage are due to technological problems. Reports seem to support my theory.

Below you will find the reasons for project failure that I’ve encountered most in my work as a project recovery consultant.

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. Without a clear and concise description of done, the only measures of progress are the passage of time, consumption of resources, and production of technical features. These measures of progress fail to describe what business capabilities our project needs to produce or what mission we are trying to accomplish. Capabilities drive requirements. Therefore, without first identifying the needed capabilities, we cannot deliver a successful project, and it will end up a statistic, like all the other failed projects.

2) Poorly defined (or undefined) success

Besides not having defined what done is, one of the more common problems I see with IT projects is an ill-defined goal or definition of success.

A project can only be successful if the success criteria are defined, ideally upfront. Unfortunately, I have seen many projects that skipped this part completely. When starting on 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

A company will say they want to improve customer service, for example, but no one ever bothers to say what that looks like. Shorter call times? Fewer calls? Higher customer satisfaction? How will you know when you’ve succeeded? If you don’t know, you’re doomed to fail.

Related: When is my project a success?

3) Lack of leadership and accountability

Too often, technology projects are deemed “IT” projects and relegated to the IT department, regardless of what the project actually is. But for any project to work, it needs strong leadership from the top down. If a project doesn’t have buy-in and support from C-level executives as well as specific department leaders, it’s difficult to get employees on board and hard to know who is in charge when leadership questions arise.

The moment projects are dubbed “IT projects” and left to the IT department, a lack of accountability can also develop. Executives may wrongly believe that they can’t understand what’s happening, and leave it to the tech guys to figure out. This is a mistake. If your tech team can’t adequately explain what’s happening on the project or why it’s needed, that’s a huge red flag. And if the executives aren’t driving the project and holding the team accountable, it can easily spiral out of control.

Related: How to establish an effective Steering Committee (and not a Project Governance Board)

4) No plan or timeline

How can we get to “done” (see above) on time and on budget and achieve acceptable outcomes? We need a plan to get to where we are going, to reach done. This plan can be simple or complex. The fidelity of the plan depends on our tolerance for risk. The complexity of the plan has to match the complexity of the project.

Without a clear timeline and plan with milestones, any project (but technology projects in particular) can wander off the original path and meander through many detours and dead ends. A clear plan and someone to keep track of it is vital for keeping these projects moving forward.

Also, the famous watermelon reporting (green from the outside and bright red from the inside) is far more likely to happen when there is no clear plan and measure of progress.

“Plans are useless, but planning is indispensable.” – Dwight D. Eisenhower

5) Insufficient communication

As mentioned above, someone on the tech team needs to be able to explain the project details regularly to the “non-tech” executives and other stakeholders. It’s vital for someone on the team to have strong visualization and storytelling skills in order to communicate clearly and regularly what’s happening with the project.

Related: Outsourcing technical competence? and 10 Principles of Stakeholder Engagement

6) Lack of user and performance testing, or failure to address feedback

The thing about technology projects is that ultimately, they’re made for people, not machines. A lack of real-world user testing before launch is a common problem. The software engineers, solution architects and business analysts think they know what users want, but users may have an entirely different set of needs and problems. Once user testing is conducted, the project has to prioritize addressing the feedback, or the end user won’t be happy—and ultimately won’t use the technology created for them.

On a similar note it is essential to test under expected load very early. Even the best system won’t be used, or be very ineffective, when it is just too slow.

Related: Start your project with a Walking Skeleton and It's never too early to think about performance

7) Solving the wrong problem

I’ve seen this time and time again with IT projects: companies think they’re creating something to address the problem, but it turns out they’re addressing the wrong problem. In our customer service example, if the company decides that shorter call times is the metric for improved customer service, employees become incentivized to get off the phone as quickly as possible, which may or may not actually improve customer service. Yes, call time decreases, but customers may be even less satisfied than before.

“We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.” – Russell L. Ackoff

Related: Understanding your problem is half the solution (actually the most important half)

8) Trying to adapt standard software to business processes instead of the other way around

Adjusting standard software to quirky business processes is a recipe for disaster. Going back to the Lidl SAP project, apparently one of the biggest problems was a “but this is how we always do it” mentality at Lidl. Changing the software necessitated reassessing almost every process at the company, insiders say. But Lidl’s management was not prepared to do that.

Unlike many of their competitors, Lidl bases its inventory management system on purchase prices. The standard SAP for Retail software uses retail prices. Lidl didn’t want to change, so the software had to be adapted. Many more accommodations had to be made, and the more changes there were to the code, the more complex and more susceptible to failure the Lidl software became.

Performance fell, and costs rose. Altering existing software is like changing a prefab house—you can put the kitchen cupboards in a different place, but when you start moving the walls, there’s no stability.

“Something I learned in ERP for dummies: Don't customize software to your process unless the process is your competitive advantage.”

9) Continuing to pursue bad ideas

In Hollywood, they say it’s easy to make a bad film from a good script but impossible to make a good film from a bad script. Though you won’t always recognize a bad idea straightaway, once you do, never assume that you’ll make it work or believe that you’ve put in too much effort to change course. The sunk cost fallacy is real.

For large or high-risk projects (what is large depends on your organization) it should be mandatory to do business case validation before you dive headfirst into executing the project. The minute you recognize that an idea won’t work, you have to pull the plug. It’s usually impossible to fix a bad idea, and you’ll only waste time, money and energy trying to put lipstick on a pig.

Related: No validation? No project!

10) No real decisions and death by committees

A project often has multiple parties interested in its outcome and groups may even have divergent goals and expectations. I once spent months working with multiple enterprise and solution architects on a new data analysis and modeling platform, only to have our carefully crafted design dismantled by the company’s various heads of department demanding changes to meet their individual needs. Our problem was that we failed to establish who really owned the project and therefore didn’t deal with potential conflicts and disappointments in advance.

Feedback and governance is an essential part of any project. But decision-by-committee rarely leads to the best outcome. Every project should start by establishing clear, workable goals and give one person the ultimate ownership and accountability for meeting them.

Related: Many decisions are no decisions (and this makes projects difficult)

Read more…

10 Benefits of Project Portfolio Management Done Right

Project Portfolio Management is a combined system of tools, methodologies, and processes to support your organization in reacting to change with the speed that is necessary for your organization to thrive. It helps you to do the right projects and to do projects right.

Project Portfolio Management (PPM) does not involve making project-by-project choices based on fixed acceptance criteria. Instead, decisions to add or subtract projects from the portfolio are based on the four goals of PPM:

1) Maximizing the value of your portfolio

2) Seeking the right balance of projects

3) Creating a strong link to your strategy

4) Doing the right number of projects

But how does this help your organization? Why does it makes sense to implement it?  Below you will find ten clearly measurable benefits that you can expect when implementing PPM in your organization. Let’s explore each of these benefits in detail.

1) More Insightful Decision-Making

The first benefit of PPM concerns its ability to drive better business decisions. To make good decisions you need good data, and that’s why visibility is so crucial, both from a strategic, top-down perspective and from a tactical, bottom-up perspective.

Anything that can be measured can be improved. However, organizations don’t always do sufficient monitoring. Few organizations actually track project and portfolio performance against benchmarks. Worse, strategic multiyear initiatives are the least likely to be tracked in a quantitative, objective manner. For smaller organizations, the absence of such a process might be understandable, but for a large organization, tracking is a must.

Not monitoring project results creates a vicious circle: If results are not tracked, then how can the portfolio management and strategic planning process have credibility? It is likely that it doesn’t, and over time, the risk is that estimates are used more as a means of making a project appear worthy of funding than as a mechanism for robust estimation of future results. Without tracking, there is no mechanism to make sure initial estimates of costs and benefits are realistic.

When you have a good handle on past project metrics, it makes it much easier to predict future factors like complexity, duration, risks, expected value, etc. And when you have a good handle on what is happening in your current project portfolio, you can find out which projects are not contributing to your strategy, hindering other more important projects, or not contributing enough value.

Reviewing the data of your project portfolio gives you project history that reflects the symbiotic relationship between money, time, people, value, and projects. Informed decision-making forces you to draw findings based on organization-wide benefits rather than personal interest, contributing to overall portfolio success.

High-value projects are those that align strategically with the organization’s long-term objectives. Effective portfolio management collects information from those project initiatives that performed well in the past and successfully delivered business value. It explores the probability of similar projects flowing in the pipeline, preparing your people to obtain the appropriate briefing and training beforehand.

Your organization is as good as the data you have. The longer you rely on outdated or irrelevant information, the more you just guess and operate in the dark. PPM gives you a reporting and monitoring strategy that will help you get the insights you need. See “How to monitor your portfolio” for more details.

2) Better Risk Management

It is important for organizations to create portfolios that reduce risks, but at the same time, it is necessary to take enough risks to move forward and stay competitive. You must target a point on the scale between playing it so safe that you never reach your full potential, and taking too much risk and losing everything.

Where this point is depends on your appetite for risk, the stage of your organization, your industry, and many other factors that you know better than I do. After you have decided on this point, your project portfolio needs to be balanced in such a way that the combined set of projects have the risk profile and upside potential you want.

PPM helps you create this balance by making the risk vs. value balance visible, transparent, and part of the decision-making process. See “How to evaluate your portfolio” for more details.

3) Optimized (NOT Maximized) Resource Utilization by Doing the Right Number of Projects

Traditional project portfolio management is all about value optimization and optimizing resource allocation. Both are designed in such a way that, in my opinion, it will result in the opposite. As we have seen time and again, running projects at hundred-percent utilization is an economic disaster. Any small amount of unplanned work will cause delays, which will become even worse because of time spent on re-planning, and value is only created when it is delivered and not when it is planned. Hence, we should focus on delivering value as quickly as possible within our given constraints.

This brings us to lean thinking. Lean is sometimes described as focusing on smaller batch (project) size, shorter queues, and faster cycle time. The focus is on delivering value quickly. In truth, lean is much more than this. The pillars are respect for people and continuous improvement resting on a foundation of manager-teachers in lean thinking. Queue management is just a tool that is far from the essence of lean thinking. But it is a very helpful tool that can have a very positive impact on your project portfolio management process.

PPM gives you a framework and guidelines to help you do this.  See “Doing the right number of projects” for more details.

4) Alignment With the Strategy of the Organization 

One of the biggest mistakes organizations make is not linking projects with strategic goals. Many organizations have a well-defined and well-scoped strategic process. This can be augmented by better and broader idea capture to provide supportive tactics, but the execution of it is the critical challenge. Indeed, as is widely recognized, weakness in execution, not a weakness in strategy, is a primary reason for organization failure. Knowing this, it is important to link the strategic theory governing the organization to the experience of project management. Without this linkage, either the project portfolio is blind to the needs of the organization or the strategic goals are empty, with no support at the execution level. It is clear that this is an area that organizations must get right for long-term success.

Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. – Sun Tzu

PPM makes this linking part of every step of the process. See “How to categorize your project backlog“ and “How to evaluate your portfolio” for more details.

5) Increased Project Delivery Success

One of the best ways to demonstrate the value of PPM is to show how it creates an environment that leads to repeatable and predictable project success. While not discounting the skills of the Portfolio Team, the essence of an effective PPM is providing a process framework and technology infrastructure that allows you to continuously meet your organization’s objectives. Repeatable success is gained by establishing best practices and proven project management methodologies and enforcing their use throughout the organization.

PPM consists of methods that factor in the scale, complexity, duration, and deliverables of a project. With an effective PPM strategy, you can leverage the processes and lessons learned from previous projects. A central repository of historical and real-time data helps you prioritize projects, preventing them from being wrecked by ‘guesstimations.’ This way you can be a proactive organization, not a reactive one.

Unsuccessful project delivery leads to project failure. Project failure can be caused by many factors such as cost overruns, schedule delays, poorly defined requirements, mismanaged resources, lack of strategy alignment, unresolved issues, or technical limitations. PPM allows organizations to ensure these risk factors are transparent and minimized within project delivery.

While it is easy to see how your projects perform in the present, what matters more is ensuring this success repeats itself in the future. Aggregating your projects gives you a consolidated view. This leads to your demands being captured in order to evaluate and prioritize your projects. Individual roles and responsibilities can be allocated to workload, which structures your workflow.

Repeatable success is achievable with a framework that sets boundaries to tightly control the project. It mandates the usage and effectiveness of technical infrastructure and establishes practices that improve governance. Repeatable success equals progress toward your organization’s objectives when the projects were aligned with those objectives in the first place. Many projects fail to deliver benefits even if they’re executed successfully.

6) Faster Project Turnaround Times

Too many organizations try to save money on projects (cost-efficiency) when the benefits of completing the project earlier far outweigh the potential cost savings. You might, for example, be able to complete a project with perfect resource management (all staff is busy) in 12 months for $1 million. Alternatively, you could hire some extra people and have them sitting around occasionally at a total cost of $1.5 million, but the project would be completed in only six months.

What's that six-month difference worth? Well, if the project is strategic in nature, it could be worth everything. It could mean being first to market with a new product or possessing a required capability for an upcoming bid that you don't even know about yet. It could mean impressing the heck out of some skeptical new client or being prepared for an external audit. There are many scenarios where the benefits outweigh the cost savings (see "Cost of delay" for more details).

On top of delivering the project faster, when you are done after six months instead of 12 months you can use the existing team for a different project, delivering even more benefits for your organization. So not only do you get your benefits for your original project sooner and/or longer, you will get those for your next project sooner as well because it starts earlier and is staffed with an experienced team.

An important goal of your project portfolio management strategy should be to have a high throughput. It’s vital to get projects delivered fast so you start reaping your benefits, and your organization is freed up for new projects to deliver additional benefits.

There are many reasons why PPM can reduce project turnaround times by an average of 10 percent. Lean governance, workflow, and standardization tend to reflect repeatable, proven processes. The defined processes aligned with PPM technology allow team members to keep the work flowing and will typically increase productivity because it answers two important questions: “What do I stop doing?” and “What do I do next?” As we all know, strategically aligned projects should always result in value for the organization. With shorter time to market, this value can be realized sooner and in many cases can give organizations a head start on their competition. See “Project portfolio throughput: Faster is better” for more details.

7) Maximized Organization Impact

You will maximize the impact of your projects for your organization when you follow the process of PPM. Since PPM is built around the four goals below, you will do the right projects—namely, the ones that push your strategy forward and deliver actual value whilst fitting your appetite for risk.

1) Maximize the value of the portfolio.
2) Seek the right balance of projects, thus achieving a balanced portfolio.
3) Create a strong link to strategy, thus the need to build strategy into the portfolio.
4) Do the right number of projects.

See “How to evaluate your portfolio” for more details.

8) Reduced Sunk Costs

For large or high-risk projects (what is large depends on your organization) it should be mandatory to do business case validation before you dive head-first into executing the project. In the Project Portfolio Funnel below you will see a phase called "Validation" after selection of a project has taken place. In this phase you typically have a business case validation and/or a technical validation in the form of a proof of concept.

PPM is about doing the right projects. In order to help with this I typically use an adapted version of the lean product validation from Jon Lay and Zsolt Kocsmárszky (https://leanvalidation.hanno.co/) as an obligatory step in the process.

We will distinguish between four different kinds of validations. Depending on the project that you want to validate the business case for, you do only one, two, three, or all four of them. When your project is about launching a new product or service I would advise you to do all four validations before executing the project. The results of these validations form your business case validation. Or the opposite, of course; they can also show you that you should not do this project.

A. Validate the problem: Is this a problem worth solving? If users don’t think this is a major problem, your solution won’t be appealing.

B. Validate the market: Some users might agree that this is a problem worth solving. But are there enough of them to make up a market for your product or service?

C. Validate the product/service/solution: The problem might exist, but does your product/service/solution actually solve it?

D. Validate the willingness to pay: There might be market demand and a great product or service. But will people actually be willing to reach into their wallets and pay for it?

As you can see, these validations focus on the introduction of a new product or service for your clients. But you can easily reframe them for all of your projects. Your market can be your employees instead of customers. For example, when you think about implementing a new CRM, but only a very small but vocal number of users see the benefit of it, and are actually quite happy with what they currently have, your market is too small. Or how about the willingness to pay for the accounting department for a new solution that triples the yearly operational costs? See “No validation? No project!” for more details.

9) Transparency

Project Portfolio Management relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. When transparency is complete, these decisions have a sound basis. When artifacts are incompletely transparent, these decisions can be flawed, value may diminish, and risk may increase. See “How to monitor your portfolio” for more details.

10) More and Better Ideas

Although there is clearly no shortage of ideas within organizations, most organizations unfortunately seldom capture these ideas, except in the few cases where a handful of employees are sufficiently entrepreneurial to drive their own ideas through to implementation. This can happen in spite of the organization, rather than because of it.

Organizations are effective at focusing employees on their daily tasks, roles, and responsibilities. However, they are far less effective at capturing the other output of that process: the ideas and observations that result from it. It is important to remember that these ideas can be more valuable than an employee’s routine work. Putting in an effective process for capturing ideas provides an opportunity for organizations to leverage a resource they already have, already pay for, but fail to capture the full benefit of—namely, employee creativity.

To assume that the best ideas will somehow rise to the top, without formal means to capture them in the first place, is too optimistic.

Providing a simplified, streamlined process for idea submission can increase project proposals and result in a better portfolio of projects. Simplification is not about reducing the quality of ideas, but about reducing the bureaucracy associated with producing them. Simplification is not easy, as it involves defining what is really needed before further due diligence is conducted on the project. It also means making the submission process easy to follow and locate, and driving awareness of it. PPM defines exactly such a process. See “Demand management” for more details.

Read more…

How to Establish an Effective Steering Committee (And Not a Project Governance Board)

Without exception, every large project I was involved with over the past 15 years had a Steering Committee (SC).

Broadly speaking a SC is a group of high-level stakeholders who provide strategic direction for a project, provide governance, and supports the Project Manager. Ideally, SCs increase the chances for project success by closely aligning project goals to organizational goals. However, this is unfortunately not always guaranteed.

Many SC’s I have worked with were very effective and added tremendous value to the project, some of them were the reason that a project got into trouble, some of them never noticed that a project was in trouble until it was too late, and the large majority of them were somewhere in between. Note that my experience is biased because I primarily work with troubled projects for a living.

In this article I will provide my perspective on the definition of a SC, what it should aim to accomplish, who should be part of it, and present my lessons learned in the form of 16 tips on how you can establish a SC that adds value to your project and your organization.

So what exactly is a SC?

The "steering committee" of a project can be described as a "governing device" used to organize key project stakeholders and empower them to "steer" a project (or group of projects) to successful outcomes. So what is ‘steering’? Steering is not managing. Managing seeks to get the job done, but steering determines what the job is.

The SC members help guide the business. The project team and the Project Manager do not. They can direct, control and manage the required changes in the business, the team can only define, plan and support them. If the business isn’t prepared for the project (and the team has done their part) then the steering committee has failed.

Few SC members realize this but their function is to serve as a resource for the project team, and in particular the Project Manager. They need to be searching for what has to be done to ensure the success of your project, determine what challenges exist, and reveal what other business or external events need to be taken into account and managed. You don’t just want them to turn up once a month to have a few questions and engage in meaningless discussion.

Most SC’s believe their role is to ‘control the project’. The recent use of the title ‘Project Control Boards’ for SC’s emphasizes this lack of understanding as to the SC’s role. Undoubtedly there is an element of ‘project control’, and yes, there is an element of board-like governance (are you complying with the necessary standards and policies?), but these are minor aspects of their role.

Where the steering committee adds value is by clearing obstacles from the pathway to success for the project. This requires taking action. Many SC’s don’t realize this is their critical function, and often they are not prepared to adopt it, until enlightened (and, often, pushed).

What Is the Job of Your SC?

As pointed out above of the SC’s general job description is "to steer a project to successful conclusion through deliberation, decision making, support and action".

This doesn't necessarily mean that every SC’s specific job description is automatically the same. Quite the opposite, specifics can vary greatly based on the following key factors:

Scope: Will the SC have jurisdiction over a single project or a group of projects (program or project portfolio)? This article will address only project SC’s, but much of it is applicable to portfolio and/or program committee’s as well. I have written extensively about project portfolio management in other articles.

Authority: Will the SC serve as the ultimate authority on the project, or will the SC function to advise the ultimate decision making authority (i.e. the project executive or sponsor)?

Difficulty: What is the degree of project difficulty? When the project is of a higher degree of complexity, visibility, sensitivity, cost and risk, the job difficulty increases in direct proportion, which ultimately places greater burden on the SC members and exposing SC operations to increased scrutiny. Job difficulty goes a long way in determining how a given SC will be organized, who will be appointed, and how it will operate in order to reach the expected results.

Deliverables: What will the SC produce? After all, that's the reason for forming a SC - to produce all the results (analysis, decisions, directives and opinions) needed to support and "steer" a successful project.

These are the factors that will drive job specifics. No steering committee can be expected to function properly without a clear description of job requirements. That's why defining the job is the first and most important action for SC success.

Who is in Your SC?

With the right people in the room, your SC can almost guarantee project success. But how do you have selected the right people? Picking experienced leaders and subject matter experts is beneficial, but it is not always good enough.

Most often, the project sponsor, senior management, key stakeholders and high-level permanent representatives of clients and suppliers are members of a SC. Within the project governance structure, the members of the SC are now strategically positioned to effectively promote the goals of their respective organizations.

This sounds good in theory, but SC members are usually chosen by the areas they represent in a checklist type style. It may sound counterintuitive, but having balanced representation can be problematic. Members come to the table only with perspectives that are influenced by their vested interests. For example, during a restructuring exercise, the SC can disintegrate into winners and losers; those who got their way and those who did not. In the end, the ultimate loser is the organization.

You can tackle this challenge by involving non-biased members. Identify members who do not have vested interested in particular outcomes of the project itself. This could be a finance person for a technology project or a product manager in an HR project. A neutral member will not get lost in the details and will not push for their own agenda. They can contribute by challenging the biases of others, and helping ensure balanced participation and achieving results.

Some projects are so controversial and political that the SC cannot function objectively. Bringing in professional facilitators adds a critical dimension of neutrality and a focus on achieving objectives.

In my opinion SC’s benefit from a mix of executive leadership and practitioners. This creates a balance of hands-on experience and people who are agents of change. You need people in the SC who are in the position to bring about organizational change.

Having such a mix will often result in members having not equal levels of power within their own organizations. While some are mid-level managers, others may be top executives, which results in an imbalance in decision-making abilities. I will address this later in the article when discussing the rules of engagement.

Having the optimal membership of the SC is critical to project success. Potential members should:

> Have a known vested interest in making the project and the SC a success.

> Be willing to participate as a SC member and agree to the SC’s job and expectations.

> Have the authority to make decisions on behalf of the organization they represent.

> Be willing and able to work with the other SC members.

> Be able to perform the work in a timely fashion.

> Have a clear line of authority over the project team.

Importantly, the Project Manager is NOT a member of the SC but is essentially “contracted” by the SC to ensure project success as agreed. The Project Manager takes part in the SC meeting, but they should not participate in decision-making; the Project Manager’s role is to update members on the project’s progress, areas of concern, current issues, and options for addressing these issues.

What is the Optimal Size of the SC?

Ideally a SC is made up of four to seven people, but it can be larger in order to obtain buy-in from all concerned areas of the organization.

A small group, comprised of senior people, can make strategic decisions, give strategic advice, and also give the project influence among the intended users. However, a small group may not represent the necessary breadth of experiences and perspectives needed to ensure success. Moreover, busy senior executives and experts may not be able to give enough time and thought for the tasks at hand.

A larger group, (say up to ten), is manageable when the meetings are very organized and structured. A large group can obviously include a greater range of members, thus tapping in to a wider range of experience. However, a larger group can sometimes lose its effectiveness because of its sheer size. Meetings are even more difficult to schedule.

Establishing the Rules of Engagement

Try putting a number of people in a room, call them the SC, vaguely define their job and leave them on their own to figure out what it all means and how to get the job done. They might produce results for a while, but sooner or later, problems will appear. Perhaps not everyone heard the same message. Perhaps people will struggle to gain control. Perhaps changing circumstances will throw everyone a curve ball. These are the types of risks that diminish productivity and can complicate results.

For some, believe it or not, a SC is treated like a stage. Power plays are made behind the scenes. Deals are cut before meetings are held. You can almost see the strings being pulled in the meetings. Suddenly, SC meetings begin to get cancelled, and members become disengaged. Solutions lack vital information and perspectives. The puppets don’t enjoy having their strings pulled and simply walk away from the SC.

This can be avoided when the job (see above) is presented as a roadmap in the form of a documented "SC Charter". The Charter specifies how the SC will be organized and how it will operate, all from a procedural and process point of view. This is a great approach to improve productivity, save time, minimize conflict and set expectations. I recommend that SC members agree at a minimum on the four following things:

> How decisions are made

> How participation will be managed

> What happens when there is disagreement / conflict

> What happens between SC meetings

Normally, the members of a SC are selected because they occupy positions in an organization that the ability and authority to make strategic decisions is a given. However, it must also be recognized that regardless of the make-up of the SC, or the position of its members in an organization, it is in most cases not intended to be a “voting democracy”.

As discussed in the job of your SC it makes a huge difference what authority your SC has in how the rules of engagement are invoked. In theory it would be optimal to have the decision making authority with the SC according to a pre-defined decision making process. In reality a SC often exists as a group of individuals who should share a common purpose but whose opinions and agendas may not always be completely aligned.

Therefore, it makes sense to give the final decision power to the SC chair when there is disagreement. It is of course than essential that the chair of the SC should be an individual with the actual authority and empowerment to make such decisions as may be necessary in the best interests of the organization and the project.

The chairing of the SC is most often done by the Project Sponsor who should have been selected for those very qualities. In my experience, from time-to-time the Sponsor as chair of the SC will be required to make decisions that run counter to the view of some (or even all) of the other SC members.

16 Tips for a Highly Effective Steering Committee

Tip #1 Your SC should focus on collaboration, cooperation and communication.

At the end of the day, SC members are just individuals who are appointed to do a difficult (and often thankless) job. The job is made much easier if the surrounding work environment is consistently positive, where every voice is heard, opinions are respected, information is shared, and common sense prevails. This occurs when SC (and project) leadership acts to promote member collaboration, cooperation and communication. Create trust.

Tip #2 You should plan your SC meetings ahead and decide upfront how you handle decision making between meetings.

Simply scheduling a SC meeting can be a problem, as each representative has his or her priorities and a busy agenda. If the Project Manager needs input before going ahead with some important change, he or she may not be able to get it in time if a SC meeting is required and it can’t be scheduled immediately. Even with the best intentions, the SC might slow the project down to a halt, due to slow decision-making or excessive analysis. For this reason, it makes sense to already plan the meetings a long time ahead. This is where the monthly SC meetings comes from. But this is not really helpful. Imagine having an issue a week after your last SC meeting. You have to wait for three weeks for the next meeting, and then in that meeting no decision is made because some or all members want additional information/analysis. And suddenly you are waiting for up to 8 weeks from issue to decision. Hence you have to discuss how you handle these situations.

Tip #3 Your SC time should not be used by looking at a status report.

The precious time available during the monthly SC meetings is often occupied by the Project Manager presenting a progress report. This is utterly useless, since this can be done far more efficiently through email without the demand on time (and the associated cost and non-productiveness) of senior managers and the Project Manager. Address SC members’ need for regular, timely information, with a monthly report that is a little more than just a snapshot of the previous month’s performance against known targets. Besides this snapshot you should add changes in the RAID lists and a forecast of “highlights” anticipated in the month to come (proposed completions, benefits delivery, transitions to operations, handovers to customers etc.). Provide this information by email and only discuss it during SC meetings when somebody has a question.

Tip #4 Show instead of tell.

A demo of what the project has been building, or an example of what is not working is so much more powerful than just words. Use this strategy as often as possible. It promotes a better understanding and awareness for the project and its issues. What I have done at different companies with great results is to have one regular SC and then a SC in the form of a “Sprint Review” where the project team is showing the SC members what they have done and the SC members can ask the whole team questions rather than just the project manager. These meetings are very helpful for both sides.

Tip #5 Be honest and transparent.

It is a shame this should be even a tip, but more times than I would like to remember I have worked with project teams that want to keep issues and challenges away from the SC because they think it would make them look incompetent or endanger the career of the Project Manager. We all have seen the watermelon reporting tactic. Green from the outside and bright red from the inside. This way of handling organizational challenges causes so much troubles for everybody involved. Don’t create drama about small things, but indicate issues when they arise not when it is too late to react. Tell them as it is.

Tip #6 Make decisions, real decisions.

A decision has NOT been made until people know:

> The name of the person accountable for carrying it out;

> The deadline;

> The names of the people who will be affected by the decision must be made aware of the consequences, understand the issue, and approve it—or at least not be strongly opposed to it; and

> The names of the people who have to be informed of the decision, even if they are not directly affected by it.

Tip #7 Your SC should not manage the project.

The more significant a project is to an organization, the more vital it is that the SC actively supports the Project Manager, but paradoxically, it is this role which is most often misunderstood or simply overlooked in many organizations. Too often, because of the importance of a project, the SC seeks a degree of control which should reside in the hands of the Project Manager with the result that “micro-management” occurs, often manifested through the “monthly meeting”. SC’s should steer, not manage.

Tip #8 Your Project Sponsor and Project Manager need to be able to work with each other.

It is critical to ensure a good working relationship between the Project Manager and Sponsor – some conflict or difference of opinion is healthy but if the two roles are constantly at odds, the project will suffer. Before finalizing decisions on either role, the current working relationship between the two should be evaluated to increase the likelihood of success.

Tip #9 Your SC should organize the necessary resources.

SC members should help a project by providing active support to ensure that resources are made available as required, especially in a “matrix” organization where key people reside within functions and are only “loaned” to projects. SC members in charge of such functions should use their position and influence to help the Project Manager overcome the many obstacles that the matrix approach creates, e.g. where a conflict arises between project and functional priorities, it is usually the function that prevails. It is also not uncommon for resources to be withdrawn or reallocated at short (or no) notice.

I am the opinion that when a project is of major strategic importance to the organization, key people should be withdrawn from the functions and dedicated to the project for the duration required. Such a proposal often meets with considerable resistance which SC members should seek to overcome if the project is deemed to be of greater significance than the function affected – at least in the short term but perhaps even in the longer term.

Tip #10 Your SC should establish how project success will be defined and measured.

A project can only be successful if the criteria for quantifying success are clearly defined. And this should ideally occur upfront. Unfortunately, I have seen many projects that skipped this part completely. When starting on a project, it's essential to work actively with the SC 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, and quality?" It is limited to the duration of the project and success can be measured when the project is officially completed (with intermediary measures being taken of course as part of project control processes). Besides the typical project delivery KPIs you can also look at KPIs like overtime, project member satisfaction, stakeholder satisfaction, lessons learned (improved project delivery capabilities), etc.?

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 must be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured 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 (5% market share won, technology advantage), and etc.?

Tip #11 Your SC should take responsibility for business success.

When it comes to accountabilities for success, they are different for each level:

1) Project delivery success: PM (and project team).
2) Product or service success: Product/Service Owner.
3) Business success: Project Sponsor.

But when it comes to responsibility, I am the opinion the SC is responsible for business success. They run the business, the team and the Project Manager does not. They can direct, control and manage the required changes in the business, the team can only define, plan and support them. If the business isn’t prepared for the project (and the team has done their part) then the SC has failed.

Your SC should monitor business and strategic issues and provide advice to the project team on issues that may present a risk to the project or have impact on the project rationale or success.

After the project has delivered the SC should continue to monitor if the expected benefits are actually realized. A lessons learned session on each of the three levels should be organized and summarized so that the rest of the organization can learn from both past successes and failures.

Tip #12 Your SC should be a strong advocate for the project.

Your SC members should actively and overtly support the project and act as an advocate for its outcomes. If even your SC is not supporting the project, how can you expect the organization will?

Tip #13 Your SC has a very active role in maintaining your RAID lists.

A great tool to proactively manage your project are the so-called RAID lists. RAID is an acronym for Risks, Assumptions, Issues, and Decisions. Some use the "D" for dependencies instead of decisions, and some use the "A" for actions instead of assumptions. I personally track dependencies on my assumption list (because that is what dependencies are) and I have no need for a separate action list because I track actions in a separate column of each of the other lists. Your SC has a very active role on maintaining these. The members will have meaningful input on the Risks and Assumptions of the project. The same for mitigations. They will need to be aware of the Issues and every decision that cannot be made by the project team typically will be made by the SC. So instead of spending precious SC time on status reports (see above), use this opportunity to actively engage with the RAID lists.

Tip #14 Your SC should provide some governance.

Besides the steering there is also the governance role of the SC. Typically this means:

> Approve the business case, project approach and project management methodology;

> Establish delegation authorities and limits for the project management, with regard to cost, time,
resource, quality and scope;

> Define the acceptable risk profile and risk thresholds for the project, based on the company’s risk management strategy and review project risks;

> Oversee stakeholder management and change management programs;

> Oversee the project quality assurance program;

> Review and approve or reject project plans;

> Resolve matters of project cost, time, risk, resource, quality and scope escalated to the Committee;

> Monitor project progress against approved business case, project plans and delegations; and

> Approve project closure.

Tip #15 Your SC should be aware of the Dominator Effect.

SC’s need leadership, and leaders often have strong personalities. When strong personalities begin to dominate SC agendas, projects can be put at risk. The problem with the dominator effect is twofold:

> The steering committee’s direction becomes more biased  towards the dominators personal preferences.

> Valuable input and perspectives from other members rarely make it to the table.

As the dominator takes over the SC participation from other other members will decline. What’s the point in attending meetings if you’re not heard? In this case, the SC remains in name only. The co-lead model has proven effective to balance perspective and help prevent the dominator effect. Ideally, your co-leads will bring very different perspectives and leadership styles to the table to balance things out. In some instances, even a tri-lead model can be effective for large and complex initiatives.

Tip #16 Your SC should not be afraid to request project reviews.

In regular intervals on multiyear projects, reviews can serve a wide range of stakeholders and fulfill a variety of roles. It’s therefore not surprising that organizations undertake several different types of review on their most important projects. From my perspective, there are five distinct types of review. Each with its own focus and outcome.

1) Project Review: Can occur at any point through the project. It assesses progress against the original schedule, budget, and deliverables. It looks at the effectiveness of the team, project management, engineering practices, and other related processes. It typically delivers some sort of assessment of the likelihood of project success and identifies areas of concern and corrective actions.

2) Gate Review: Occurs at the end of a project phase or at some other defined point in the project’s lifecycle. It typically represents a decision point, using the outputs from an evaluation to decide whether continued investment in the project is justified.

3) Project Audit: An objective evaluation by a group outside the project team. A project audit is about being compliant and about the now. An audit aims to demonstrate the extent to which your project conforms to the required organizational and project standards. So, if your organization uses PRINCE2 or their own project management methodology, an audit will examine how closely you follow the processes. An audit can take place during or after the project.

4) Project Retrospective: Occurs as the project closes down. It assesses the overall success of the project and identifies what did or didn’t work during its execution, generating lessons learned for the future. Also known as Postmortem or Post-project Review.

5) Benefits Realization Review: Occurs after the organization has had some chance to use the outputs from the project. It evaluates the extent to which the benefits identified in the original business case have been achieved.

Closing Thoughts

Carefully constructing a functioning and effective SC is critical for project success. Don’t gamble unnecessarily on the success of your project. Strategically structure your SC to have the right leadership model based on the personalities around the table. Build objectivity into your membership and take the time to ensure everyone is in the same boat before the committee sets sails and starts steering.

In a nutshell: A steering committee adds value by clearing obstacles from the pathway to success for the project. This requires taking action.

When you need some guidance on how to define and measure project success, just download the Project Success Model by clicking on the image.

Read more…