Tag: Business Intelligence

The Virtual Leader Part 1 Building Trust

Written by Elizabeth Larson on April 8, 2020. Posted in Articles. 3 Comments on The Virtual Leader Part 1 Building Trust

“Community is nothing, except what is based on trust.” – Yo-Yo Ma[i]

Since so many of us are practicing social distancing by, among other things, working from home, I thought it would be a good time to review some tips and tried-and true techniques for leading teams virtually. This article focuses on the importance of and tips for establishing trust virtually.

When we work from home, it is harder for us to establish trust. Although not impossible, it’s harder to communicate, which we’ll discuss further in Part 2. It’s harder for us to recognize and address conflict. And it’s harder for us to ensure that real work gets done without being overbearing.

What can the virtual leader do to establish trust? We establish trust virtually the same way we establish trust in any work environment, but it’s harder. So here are a few tips:

Make and meet commitments

Make commitments purposefully. It’s well known that we need to follow through with our commitments. But that means we actually need to make them. I tell people that I once had a boss who never had to meet any commitments because he never made any. Telling people what we’re going to do and when is critical for leaders wanting to establish trust. Even if we’re not sure that we can meet the commitments, we need to make them. However, this is not license for making commitments haphazardly. They have to be realistic. We lose credibility quickly when we lack the courage to make realistic commitments—when they are either too easy or too hard to meet. Our commitments should be grounded in reality rather than being overly optimistic or so loose that it will be impossible not to meet them.
We need to let everyone know when we can’t meet our commitments. Life and the unexpected happen, and when they do, we need to let people know. Immediately. Many of us have fallen into the trap of waiting too long to communicate bad news. We think that somehow if we try extra hard, we’ll be able to meet pull off a miracle. But if we wait too long to communicate bad news, we will break the trust. It’s better for us to let people know if there’s a high likelihood that the commitment can’t be met. How we communicate, though, is key. For example, telling stakeholders “we’re late–sorry about that” is weak and will automatically bust any trust we want to establish. We need to let them know why we’ve missed the commitment we made, the impacts of doing so, and then make a new commitment based on data, not emotion.

Establish routines

It’s important for the virtual leader to ensure team routines are established and followed. Routines can be established for many things, and routines that work for one team might not work for another. As virtual leaders our role is to facilitate the team and help them decide on such things as how often the team will meet, for how long, and for what reasons. Routines establish a sense of normalcy. They can provide the team with a sense of purpose and security, which in turn builds trust in the virtual leader.

Our role as the virtual leader is to facilitate the conversation about routines. The team’s role is to provide recommendations to us. But we should not accept the team’s recommendation without question. An effective leader, virtual or not, ensures that the team’s recommendations have been well thought-out and will meet the goals of the team, the project, and the organization.

Advertisement
[widget id=”custom_html-68″]

Plan and monitor results

As Lewis Carroll famously said, “If you don’t know where you’re going, any road will get you there.” If we want Wonderland-style chaos, we’ll skip the planning. We might hear team members say things like “let’s just get the work done,” or “it takes longer to plan than to do the work,” but in these uncertain and chaotic times, it’s not a great way to build trust. Planning, regardless of the methodology or set of practices used, is a proven way make the team feel purposeful. It provides them with a sense of accomplishment as planned tasks get completed. And that shared sense of accomplishment is a great way to bring the team together and build trust not only with the leader, but within the entire team.

Monitoring to ensure results are complete is equally important. Monitoring has many names. Some people call it micromanagement. It’s not. It does not involve doing the work for the team. It does not involve looking over anyone’s shoulder. It’s not “Big Brother.”

Monitoring work can take many forms. It can be done in a daily meeting where members talk about what was planned, what was accomplished, and obstacles that have occurred withing the last 24 hours. It can be a status report with much of the same information. It can involve the use of software where all team members can see the progress of work items. Scrum and other agile methods are all over this concept with daily scrums and burn-down and burn-up charts. Sure, they use different terminology, but the concept is the same—let’s figure out where we are, where we should be, and what’s getting in the way of getting there.

One important component of monitoring involves learning of obstacle/impediments right away. Our role is not to chastise team members for incomplete or late work, which is guaranteed to break trust. Rather, it’s to coordinate all necessary resources to solve the problems and remove the obstacles so that team members can move forward. This is particularly important in a virtual environment. Being geographically dispersed can make some team members feel stuck and isolated, preventing them from moving forward quickly. Knowing that the goal of the leader is be “chief roadblock remover” can be comforting to the team. As virtual leaders we need to find the time and courage to:

Coordinate resources outside the team to solve the problems
With the team figure out how to keep moving forward in a parallel path as a solution is found to the obstacle at hand.
Get experts or other team members to help get unstuck. Having other sets of eyes is important, but it’s much harder when the team doesn’t have the benefit of being together.
Let the team know what we’re doing to resolve the problem. Keeping the team informed is vital to building trust.
Provide encouragement. Take time to let team members think through problems with you. Listen to them and do not provide easy but ineffective answers.
Communicate delays and problems to key stakeholders. Tell them what the delay is and what we’re doing to remove the obstacle.

There are, of course, more ways to establish trust virtually, but these tips provide a start. In Part 2 we will delve into the complex subject of communications.

[i] PBS Newshour, March 18, 2020, https://www.pbs.org/newshour/show/yo-yo-ma-on-encouraging-songs-of-comfort-amid-global-crisis

Can the Same Person Function as a PM and BA on the Same Project or Agile Effort?

Written by Elizabeth Larson on May 8, 2019. Posted in Articles. 6 Comments on Can the Same Person Function as a PM and BA on the Same Project or Agile Effort?

Ten years ago I wrote an article entitled, Can Same Person Function as a PM and BA on the Same Project.

I wrote that there we need to distinguish whether the same person “could” (sure they could, but with sometimes questionable results) and whether they “should.” I explained that it made complete sense to have one person play both roles in certain circumstances, like when a project is known to be “small,” or on high-performance, self-directed, cross-trained teams, when an organization lacks funds for both roles, and when an organization doesn’t recognize both roles. I said it is helpful, however, to know the differences between the roles and know when each is being played.

Ten years later I still agree with what I wrote. However, there is another question that needs to be put into the mix—what about Agile? Before we answer the question of Agile, let’s a have a quick look at some basic differences between the PM and BA roles.

Generally speaking, there is an inherent difference of objectives between the two roles. Project management is more about the project and business analysis is more about the product. The project manager’s role is to meet project objectives. The BA’s role is to help organizations reach their goals by recommending value-added solutions that solve business problems. This is a subtle but important difference. Put another way, the project objectives help the organization meet its business goals and objectives. The PM focuses on the former; the BA on the latter.

I mentioned that the PM typically focuses on the project, including resolving issues about the project, managing project risks, and getting the resources working on activities and tasks. And that the BA typically focuses on the end product, like managing risks related to the product, eliciting questions about a new product, and specifying the details of the product so that it can be developed and delivered.

Although the PM may do some work related to the product and the BA may do work related to the project, there is still a need, I think, for both roles on most projects. It seems to me that because there is a different focus and different objectives, there is often a pull in opposite directions, especially when both roles report to different organizational functions. Project managers want, among many other things, to deliver the product on time and within budget. Business analysts want to ensure that customers can actually use the product once it has been implemented.

Advertisement
[widget id=”custom_html-68″]

But wait—what about Agile?

With Agile there may or may not be a BA and PM on the team. Our question, then, is can the same person focus on both the product and the delivery of that product at the same time? For the product we mean not just the product backlog, but the details of the features that comprise the backlog. By delivery focus we mean someone to protect the Agile processes and remove roadblocks so the team can move forward. Someone who can develop burndown and burnup charts to know what’s been completed and what’s left to do.

The answer of course is yes, it’s possible to have one person focus on both. While not ideal, it may be necessary when there are not enough resources to have a dedicated product owner and scrum master.

It would take someone with the skills to specify the features in enough details so they can be estimated and built, like a product owner—if, and this is a critical constraint—they are authorized to make business decisions. But someone who also focuses on the delivery of the features. This can work in small organizations and on small projects. It can even work in larger organizations when the organization needs to “make do” with less than an ideal number and types of resources. And although there are inherent risks with this approach, it can work.

Let’s look at a real example. A small organization used an outside IT resource to develop a product and a member of the management team to be the product owner. This manager not only was able to make business decisions, but also had both a BA and a development background. The features were developed “agily” and were scheduled to be delivered every few weeks. The acting product owner and developer worked through complex design issues and the features were implemented almost flawlessly. So far so good.

The difficulty was that although the PO and developer worked together superbly on the product features, there was no one looking after the delivery of those features. There was no one, in other words, to support or protect an Agile process. There were occasional Scrum meetings, but no daily meetings to review status and issues. The progress was not routinely monitored, and weeks would go by with no results delivered and no clear idea of when the next feature would be released. There were no retrospectives and not many reviews of the features with other key stakeholders. Because this was a small company and everyone was doing a million other tasks, this process more or less worked. But the lack of focus on the project proved frustrating for almost everyone involved.

Finally, I want to emphasize again that we’re talking about focus, not job titles. We’re talking about someone who not only has the skills to focus on both the project and product, but the time. So even on Agile projects, can the same person be both a BA and a PM, that is, be able to focus on both the product features and the delivery of those features? Sure, but when the main focus is the product, the delivery might suffer and vice versa. On projects of any size, there is less risk when these job functions are separated.

Project Strategy the Missing Link in your Corporate Strategy

Written by Paul Oppong on May 1, 2019. Posted in Articles. 3 Comments on Project Strategy the Missing Link in your Corporate Strategy

The way that projects are managed and executed has a direct relationship to organisational success

because everything that people do in a business should be linked back to its strategy. A strategy is a plan of action that allows a long-term goal to be achieved. If you think about it, if a project fails, then this costs the organisation time and money. The organisation will not achieve its short-term goals, and this will prevent it from achieving its longer-term goals – or it will at least slow it up. When you consider this, it makes sense that projects are managed according to a strategy, and that this strategy is aligned with the corporate strategy. This means that project strategy is a very important consideration for most companies. Here we will consider the relationship between the project strategy and the corporate strategy and portfolio and program management.

How the Corporate Strategy Impacts on the Project Strategy

The project or program strategy will be informed by the corporate strategy. This allows the business to implement its overall strategy. Since strategies are usually developed at the upper echelons of the organisation, these will cascade down to lower levels, to be managed and delivered through portfolios, programs and projects. This occurs in a hierarchical and systematic manner. When It is done well, there will be cohesion, visibility and an effective means of communication. Communication is key, since without it there may be difficulties for the project team in understanding what they are doing and why. Without this, there can be project management failure.

Within a solid framework and with good communication, project strategy can be managed dynamically. But what is the project strategy? In most cases, the project strategy typically refers to all aspects of the project lifecycle. Usually, clear review points are decided on to make sure that the project is being well managed. If it is not, then optimisation can occur, as the project strategy continues to develop.

When the organisation’s senior management team devise the corporate strategy, they decide what they are going to do, and how they are going to go about it. Running projects is often a major component of how they are going to go about delivering the strategy. It is all very well having a finely-polished mission statement presented on the company website, and a thorough five-year plan documented, but without action, nothing happens. As noted earlier, the word strategy means having a plan of action. Putting aside the five-year plan and failing to take any action will usually mean that the strategy is not delivered, and long-term goals do not get met. Steps must be taken to ensure that processes are in place to deliver projects and achieve goals. This requires that a number of activities occur. First, it must be decided what projects will be likely to be needed to deliver the strategy. There will usually be various projects needed, but not sufficient resource to complete all of them at the same time. Resources are precious. The senior management team must communicate the priorities and assign resources to these.

Advertisement
[widget id=”custom_html-68″]

A clear direction must be provided by the senior management, and a business owner is assigned to ensure that the project stays on track to help the business achieve its strategy through the project strategy employed. The Project Management team will then report to this business owner. The project or program manager thus has a critical role in impacting strategy delivery and achieving organisational goals. If the PMO runs the project efficiently and effectively, with good communication throughout then there is a greater chance of the strategy being achieved, and long-term results being delivered.

Project management is usually a core process within the overall business enterprise model. Programs and projects allow the organisation to effect change in a managed and controlled way. It is worth noting that in many cases, companies consider that program management implies the management of business benefits, as well as the idea of product or brand. This distinguishes it somewhat from project management.

How Project Management Tools and Principles Help Advance Business Strategy

Project management tools and principles are important in effectively advancing business strategy. This is because they help the people working on the project to stay on track and aligned with the overall vision. As part of the project strategy, projects must be properly defined, with a clear scope and related to corporate goals and strategies. From there, Gantt charts and other project tools help track who needs to be doing what and when, so that milestones can be delivered in a timely manner. Controlling changes to the project is also important to keep it on target. If senior management requires a major change in scope at the last minute, a change control process helps because it assesses what the impact of the change will be in terms of time and cost. This can then be communicated effectively back up the hierarchy so a decision can be made regarding what is most important – delivering on time and to budget or including this change. This helps with effective strategic decision making. Portfolio management is often of fundamental importance for project and program prioritisation, as well as for resource allocation.

It is also important to realise that value management is a key aspect of project strategy. Value management works to ensure that value is being created through undertaking the project. Meanwhile, risk management is also deployed to ensure that all risks to the project strategy (and consequently the overall corporate strategy) are identified, assessed, understood and mitigated. With continuous review and change it is possible to ensure that the project strategy works to deliver the most value possible, with risks well managed.

Summary

In short, if a project is to be successful, it will be run according to a project strategy that is clearly aligned with the overall corporate strategy. These links will be communicated and understood, and the organisation will have checks and balances in place to ensure the project is managed such that it can deliver.

You’ve Got Processes With A Capital P and That Stands For Trouble!

Written by Larry Blankenship on April 30, 2019. Posted in Articles. 7 Comments on You’ve Got Processes With A Capital P and That Stands For Trouble!

In Meredith Wilson’s “The Music Man” there is a scene where Harold Hill, the conman,

attempts to alarm the people of River City about the local pool hall to get them to buy band instruments. The refrain is “You got trouble my friends, trouble with a capital T which rhymes with P and that stands for pool!”

I’m going to turn that around and tell you that you may have processes with a capital P and that rhymes with T and that stands for trouble. When processes become Processes with a capital P, it means that they have stopped being a means to an end and have become the end themselves. They have become enshrined, which is the term I’ll use in the rest of this article. This can get to the point that they impede continuous improvement because the people who do them are emotionally invested in them. This sometimes leads to resistance to change when change is badly needed.

That is not to say processes aren’t needed, only that they should act as a support to achieving desired outcomes, not become the desired outcome. Doing things in a consistent way, using a process, is the most effective way to experiment with changes and understand what worked and what didn’t, but it can become a trap, if the end result isn’t kept in mind.

The first identifier for an enshrined process is its overabundance of documentation. Typically, this involves multiple volumes of manuals, protected by a complicated and byzantine approval process. Any change requires a thorough review by several committees and multiple sign offs, by which time the requirements for the change will have become out of date, and all involved will throw up their hands and claim that the whole process is too hard but won’t do anything to fix that either.

Another sign of an enshrined process is knowledge hoarding. If you find that only one or two people have full knowledge of how things work, and they jealously guard the information, it’s probably a good candidate for an enshrined process. In this instance, there will be very little documentation to enable others to evaluate or analyze the process. SMEs will be reluctant to share or will frequently claim that things are “too complicated” to explain to someone else.

If the work has become more important than the outcomes it produces, then you have encountered an enshrined process. Look at the metrics used to measure the process success. Do they relate to business objectives, or are they measurements of execution? Number of complaints processed with a goal that goes up is a process measurement. Number of customers rating their customer service experience as a 4 or better on a 5 point scale measures a business objective of satisfied customers.

Once you’ve identified an enshrined process, what to do about it? The most critical element in this case isn’t the business, but the people in it. I want to share a couple of techniques I’ve found useful in the past: Acknowledging concerns, and involvement in the solution.

Advertisement
[widget id=”custom_html-68″]

When acknowledging concerns, the pattern I’ve learned to use is Feel-Felt-Found. I learned this during my sales career. Start by acknowledging the person’s concerns are legitimate by saying “I know how you feel, many of the people I talk to felt the same way about changing how they work.” Then reassure them with other people’s experiences. “People who’ve been through this process have found that it really made things work better. Can we give it a try?”

Involvement in the solution is the best way to build ownership in the new process and prevent people from subverting change by passively or actively resisting it. If you’ve done your job in carefully listening to the people doing the process, and gathering their input, they will feel a sense of ownership in the new process. The important thing is that they will feel that they improved the process rather than had the changes imposed on them.

Assuming you’ve managed to successfully implement a new process, how do you prevent it from becoming enshrined all over again? It’s easy to assume that the hard work is over, but if you fail to plan for changes to the contexts the process operates within, it’s possible that the next change will require you to start from the beginning rather than make another incremental change. Your first objective is to make sure that you don’t rest on your laurels.

If you’ve taken time during your process review and rework to incorporate a continuous improvement culture, then much of your work is already done, as people will already be thinking about how to review and rework the process on a regular basis. If not, take the time now to set up regular reviews and identify metrics that will allow you to validate that the process is achieving its desired objectives. Make sure that you focus on business objectives, not process objectives. If business objectives aren’t being met, adjust and try again. The most important thing is to avoid falling into the same trap of measuring the process not the outcome.

The second objective to strive for is to make change easy. Keep feedback loops in place to allow the people who provide inputs information on how to improve the quality and usability of those inputs. Make sure that any feedback provided from the people who receive the output is reviewed and acted on a regular basis. Try as much as possible to use a “black box” approach. That means that the people outside the process don’t necessarily have to know the details of how the process works, just that it produces consistent, predictable results. Keep your processes as independent as possible to minimize the impact of changes on other business areas when changes are required.

The final objective is to keep documentation simple and readily available. At all times, the current version of the process documentation should be online and available to everyone who performs the process. Sharepoint or an online wiki are great places to keep shared documentation. While it’s important to have version control, it doesn’t hurt to make the documentation easy to change when it’s needed. Focus on pictures and short paragraphs. Avoid writing novels. Flowcharts are one of the best ways to describe processes. Keeping the documentation simple means it’s less likely to end up in a paper copy on someone’s desk, which means it’s out of date by definition.

I hope by following the suggestions in this article, you’ll be able to recognize, fix, and avoid enshrined processes in your projects. I think you’ll find the benefits of doing so are substantial.

RPI – The third musketeer in the Earned Value Framework

Written by Fernando Santiago on November 6, 2018. Posted in Articles. 5 Comments on RPI – The third musketeer in the Earned Value Framework

Good things come in “threes”: from the divine Holy Trinity to the mundane, and here the list goes on and on: the three little pigs, caballeros, stooges, amigos, sisters and, of course, the musketeers.

Three is a “sacred” number, which for many represents perfection; the stability of a tripod is an example.

Earned Value Management (EVM) started with a trilogy: PV, EV and AC. However, the relationships between three elements are two: n x (n-1)/2 = 2 (as we all recall from high school, well, maybe). The two relationships are, obviously, SPI and CPI, the two great indicators that come from EVM.

However, EVM has received strong criticism in recent years. With the advent of agile and other approaches that talk about delivering “value”, EV has been discredited, and for good reason: the term is a misnomer. Earned Value should be called Earned Scope, and this is what creates the confusion particularly in those that do not understand EVM and don’t understand what value means either but, isn’t that always the case? Ignorance fuels criticism.

In capital goods projects and programs, EVM is religion. Industries like defense, aerospace, nuclear, etc. have been using EVM for fifty years and have perfected the technique to an art. Conversely, in IT, EVM is shunned and perceived by many as overly complicated, a relic from the industrial revolution in project management. Very few organizations, outside of capital goods, use EVM, and those that do usually do it poorly. To make things worse, tools like MS Project and JIRA provide “automatic” calculation of EV at the task level which creates even more confusion in people who don’t have an understanding of EVM. Recently a friend of mine who runs one of the main PPM solutions for a major Canadian bank told me they were implementing EVM and like all the other tools, it builds from the task level, a conceptual mistake but easier for the tool. With fifty thousand projects, when they run the calculation it crashed after 18 hours.

No wonder why organizations out of capital goods shun EVM: they don’t understand it.

Despite all these shortcomings, and despite the cries from agile practitioners that EVM is a step back in the evolution of project management, this framework remains healthy and is in for the long run. This past May I presented a topic on strategy execution at the EVM conference in Fort Lauderdale, Florida, with close to 500 participants, and will present another one in November in Washington DC. Two conferences per year is not bad for EVM, not bad at all.

Today everyone is talking about managing benefits, and very few people turn to Earned Value as a framework that could be used for this purpose. There are two reasons for this: EVM has been discredited, as explained above and, second, it is about delivery performance, which happens during execution. However, Crispin Piney, the author of the book Earned Benefit Program Management, CRC Press 2017, developed a framework to extend EVM in a way that it covers not only delivery but also benefits and value. In his book Crispin mentions how by pure chance, he and I connected on LinkedIn and he found in my work a piece that was missing in his framework. We started to collaborate and we co-wrote Chapter 4 of the book. In May 2018 Crispin was the keynote speaker at the Earned Value Management Conference in Fort Lauderdale, Florida, where I also presented a topic on strategy execution.

Crispin’s book explains an approach to calculate Planned Benefits, an equivalent to Planned Value in EVM. Planned Benefits, or PB, can be compared to forecasted benefits during the execution of the project, allowing for the calculation of an indicator, Realization Performance Indicator, RPI, the third musketeer. EVM now has the trinity of indicators: SPI, CPI and RPI.

When we approach the topic of benefits, we get into the same “challenge” that generates the need for EVM: “A yearlong project is six months into execution and has spent 60% of the budget: is this project on schedule, on budget?” The answer is, of course, not enough information. Similarly, a project that has an estimate of $2.5M in benefits in the next five years, should it be done? The answer is, of course, not enough information. Until we know the amount of the investment required, we cannot say. If investment is $1.5M and happens in the first year of the project, the project gives a rate of return of 20%. This can then be compared to the company’s hurdle rate of, say, 12%.

Table 1 – Example of a project IRR

However, when risk is considered, the situation could change:

If delivery risk is high (i.e. new technology, multiple and conflicting stakeholders, unclear requirements, etc.) the amount of investment and the duration of the project is likely to increase.
If benefit risk is high (dependent on industry/market forces, time to market critical, etc.) the amount of benefits and the time to realize could also change.

In a high delivery and high benefit risk scenario, the situation looks bleak: an IRR of only 2%, way below the hurdle rate of 12% and not enough to justify this project.

Table 2 – Example considering risk

Based on this, we can say that it is value what matters, and not benefits alone. “Realization Value” (RV) can be defined as Benefits minus Investment and adjusted to risk and the time value of money. It is this definition of value that should be used when defining a portfolio management performance framework.

Going back to our example, people who would highlight the impact of risk would be called fear mongers, so the sponsor would likely throw a pep rally where s/he asks the commitment from the team to deliver as planned, so the $1.5M is allocated and the $2.5M is forecast; let the games begin.

As the project progresses, EVM would allow us to track schedule and cost performance, so we can produce reports with SPI and CPI (schedule and cost performance indicators) that clearly show how bad a decision we made approving the project.

The concept of Earned Benefit (EB) is a natural extension to Earned Value Management. EB is tied to components, deliverables that have the potential to generate benefits. Planned Benefit is based on the plan to deliver the components, measured in Business Case benefit dollars. This is analogous to Planned

Value (or BCWS for those old enough to remember), which is the scope planned to be delivered at a given time, measured in Budget dollars.

Before we tackle the numbers, let’s explore some differences between EV and EB:

They are units of scope measured in dollars, but different dollars: PV in budget dollars, PB in benefit dollars from the business case
Earned Value recognizes scope as it gets completed, while Earned Benefit recognizes benefit both as a potential benefit as the component projects progress, and as accruing benefit once components complete and are ready to generate benefit.

The calculation of EVM indicators is well known; well, it should be. Anyway, let’s assume that we all understand what SPI and CPI mean and, most importantly, how to interpret these metrics:

Indicator = 1 means right on target. Basically, it means that the actual execution is on track
Indicator above 1 is good: either ahead of schedule or under budget
Indicator below 1 is bad, either behind schedule or over budget

The terms good and bad have to be taken with a grain of salt. There is another reason why my Catholic upbringing conjures images of sin and guilt when words like good or bad are used. In reality, a kiss is just a kiss, like in Casablanca, and a plan is just a plan, and the only thing that we knew for sure, when we started the project, is that the plan was wrong, and that we would finally get it right when we finished the project. So, we are comparing reality to a plan that is wrong, so tolerance for variation against that plan is needed.

A very graphic way to illustrate tolerance is the “bull’s eye” chart, presented in Fig. 1. This chart is based on the tolerances defined by the organization for schedule and cost performance. Some points to consider:

The organization can choose to define these tolerances at different levels: corporate, business unit, etc. and/or consider other factors like type of project, approach to delivery, etc.
Tolerances are not symmetrical. In the example, SPI for a project behind schedule remains green down to 0.9 or 10% of variance while on the positive side, a project ahead of schedule remains green up to 1.4 or 40%.

SPI< 1Behind schedule SPI= 1 SPI> 1 Ahead of schedule

Fig 1: Bull’s Eye Chart

The obvious question that jumps off this chart is how does a project that is ahead of go yellow, and even red? What these colours mean is that this project requires management attention, as one or more of the following could have happened:

The estimate was too conservative, “sand bagged”
Coordination with other projects in a program or a portfolio for deliverables or transition of resources could be disrupted

The same logic applies to cost performance, as funds and resources tied to a project could have been allocated to other projects or invested in the market.

At this point the question is: is there an indicator for benefit, let’s call it RPI, which could work in a similar way as SPI and CPI?

There are two answers to this: the calculation of RPI is covered in Piney’s Earned Benefit Program Management book. For Piney, RPI is based on the ratio of contribution and allocation, terms associated to the model used to calculate benefits for a program or for a portfolio. Allocation is defined as the investment to date in the component projects; Contribution is the potential benefit “earned” from the current progress on the same projects. The full details of the calculation of this Earned Benefit are out of the scope of the current article.

The second option, which I call “poor man’s RPI” is a simple ratio of Planned Benefits to Forecasted Benefits, which works as follows:

Advertisement
[widget id=”custom_html-68″]

At the time of approval of a project during the initial stages, a business case is a given and it is safe to assume that it provides the calculation of Net Present Value, which is based on the series of cash flows described earlier in this article at a given discount rate set by the organization. NPV is a financial quantity, not a rate or an indicator, so it can be used to compare future values to a baseline.
At subsequent gates, depending on governance, or following a time cycle (e.g., quarterly), projects are required to review their business cases. This includes both investment (cost) and benefits. This raises the following concerns:
- If NPV is used to calculate RPI, it is including the impact of changes in cost so, in a way, it is double counting costs. While this is true, EVM has the same situation with schedule and cost, as a project that takes longer will likely cost more money, likely the burn rate, for a longer period.
- As RPI represents benefits, we should not measure value, only benefits.
Because of these considerations, the simple solution is to discount only the benefits, the positive flows, and not the investments, or negative flows, as seen on Table 3 below:

Table 3 – Discounted Benefits

As much as someone may have thought that sunglasses should have been included with this article to look at the bull’s eye chart, it does provide in a very simple and graphic way the state of a project or a portfolio, or the comparison of portfolios, etc. The problem is that the two axi of this matrix are already taken with SPI and CPI, and now we need to insert RPI. To solve the problem, we will consider an element of EVM called a conservative estimate of the budget = Budget / (SPI x CPI), as displayed in Table 4

Table 4 – Conservative Estimate

Now that we can call this indicator DPI, to represent delivery performance and RPI for benefits, we can use the bull’s eye chart as in Figure 2

Fig 2: Bull’s eye chart – Delivery VS Benefit

When the portfolio has dozens or hundreds of projects, a bubble chart looks more like a bubble bath. An alternative is to display three sets of information, one at a time, with a Business Intelligence tool like Power BI, or using an application that has this functionality, like ValueViewer from P3M Solutions:

Number of projects
Investment
Internal Rate of Return (IRR)

Fig 3 – Number of Projects in Bull’s Eye Chart

As shown in Fig 3, out of 35 projects, only 1 is under budget and ahead of schedule but 20 are “green”, 12 are yellow and 2 are red, from which 1 is unrealistically ahead of schedule and under budget.

The same chart can be used to display investment, as shown in Fig 4, as well as Internal Rate of Return (IRR) or NPV. This information allows executives to assess “where they are putting their chips” which, analogous to the decisions made at a casino, it is based on expected return, investment and risk. Unfortunately, in this case, the table is not all green, like at the casino, but this is reality.

Fig 4 – Total investment in bull’s eye chart

A simple case study will help to illustrate all these concepts:

An online retailer is developing a web application to let customers know when products that are related to the things they are buying are on sale. As an example, if you are buying paint, brushes and frog tape, it may be nice to find out that rollers are on sale. Customers can either shop online or through a call centre. The project has identified three major deliverables:

Web app for customer shopping on-line
Call centre application to provide the customer service rep with the products on sale as the customer places the order
Engine that manages the relationships between products: (i.e. paint, solvent, brushes, rollers, tape, ladder, etc.) and presents the information to the other two components

Looking at these deliverables we can identify the web app and the call centre application as business capabilities that will allow the business to do something it couldn’t do before and generate incremental revenue (benefits). The engine is a technical capability, or enabler, that contributes to the business capabilities but doesn’t generate business value by itself. When all these capabilities are implemented, they will contribute to business outcomes, revenue increased in this case. We can capture all these relationships in a Results Chain Diagram, presented in Fig 5

Fig 5 – Results Chain Diagram for the case study

The company has estimated that incremental sales due to these capabilities will be $3M/year for on-line sales app and $2M/year for the customer service application.

The results chain (RCh) also captures the contribution each element has on the forward nodes of the chain. In the example, the contribution of the engine to the business capabilities is different, as it reflects how dependent on the engine the outcome is, and in the case of the web app it is more dependent, as there is no human interaction. Fig 6 presents these contributions in a percentage basis. When there is only one contribution it is 100%.

Fig 6 – Contributions in the example

The next step is to estimate benefits. The sponsor of this program has calculated the expected increase on line items per order, the Key Performance Indicator (KPIs), from the current 3 to 5, and that this will generate $400k/year. For the call centre KPI, the expected increase is from 4 to 6, with incremental revenue of $500k/year. These benefits are then propagated:

Forward, left to right, to the financial outcome of revenue increased
Backwards, to capabilities and initiatives, based on the relative contributions (percentages)

Fig 7 – Propagation of inflows/benefits

Finally, we add the investment needed by each initiative (in blue under the symbol) and propagate it forward (from left to right). From this diagram, shown in Fig 8, we can conclude:

The overall return of this program is positive, with a total investment of $780 that is recovered in the first year, with at least four more years of inflows.
Each one of the nodes has a positive return.

Fig 8 – Propagation of outflows/investments

Fig 8 captures the baselined plan described in the business case. The Results Chain diagram (RCh) captures all the relationships and the contributions and allocations in a static way. In this diagram we can see that return on investment (ratio of benefits to investment) is overall positive, and also positive at every node except for the initiative Develop CS App, where investment is slightly higher than the benefit.

The time component is not represented in this diagram, as it belongs to another venerable PPM tool, the portfolio roadmap, captured in Fig 9. This is where dependencies and constraints for execution are captured and managed. The RCh captures relationships for realization of benefits, not dependencies for execution.

Fig 9 – Portfolio Roadmap

What a plan! Now, let’s execute

At the end of the first calendar quarter, March X

Engine started late, in March, still “hoping to deliver on time” (haven’t we heard this before).
SPI is 0.46 as it shows 1 month of progress against two months. CPI is 0.8.
Management decides not to revise forecasted benefits yet, so RPI = 1 for both business outcomes

Fig 10 – Example Q1 200X

At the end of Q2 the situation is as follows:

Customer Service App did not start in June as planned
Engine has recovered to SPI = 0.88 through overtime and contract resources, CPI is at 0.86.
Management decides to adjust down the forecast to no benefits in the first year, RPI down to 0.94 for call-centre app, as benefits for the first half of the year have been removed. Benefits for the online app also went down to 0.90.

Fig 11 – Example Q2 200X

At the end of Q3 the situation is as follows:

On-line sales app did not start in September as planned, due to project resources temporarily assigned to support the Call Centre App.
Call Centre App also hit some new issues; the project is behind schedule with an SPI = 0.77 and CPI of 0.83.
Engine has not been able to recover and still around 0.80 SPI. Management has decided to approve an extension to the end of June 20X1.
Benefits forecast has been adjusted, as projects will not be able to realize benefits until the engine is in place. The engine is what is called an “essential contributor”; this means that whether the on-line sales or the call centre app are delivered in Feb 20×1, benefits will not be realized until later. The adjustment of the forecast is based on the following considerations:
- Call centre app does require training and a ramp up time as there is human intervention. No benefits will be realized until Q3 20X2, for a total of $150 in the year. RPI goes down to 0.71.
- On-line sales do not require human intervention and the customer should be able to pick up this functionality very quickly. Benefits start to ramp up in Q2 (half of the $100k per quarter and $100 in Q3 and Q4, or a total of $250 in 20X1. This is closer to the original estimate of $300k, RPI goes up to 0.97

Fig 11 – Example Q3 200X

You get the picture; no? Let’s try the Bull’s Eye Chart, which shows the three projects in this program

On-line sales have not started, so it remains at 1-1
Call centre app is in the lower left corner, with DPI of 0.68 and RPI of 0.71
The engine delivery is behind, at DPI = 0.68. In terms of benefits, the engine delivers a technical capability, and enabler, that contributes to the benefits of the other two projects but doesn’t have benefits on itself, which is why we represented it at RPI = 1. Alternatively, the engine could have the RPI of the overall benefits of the “program”, but the calculation of this is beyond the scope of this article.

Fig 12 – Example Bull’s Eye Chart

As seen in the example, Earned Benefit and RPI provide that metric that was not available before. Since RPI is based on planned and forecasted benefits, it can be measured at any time during delivery, as it will reflect both the impact of changes in the schedule, and adjustment based on changes in external conditions (i.e. state of the economy, or competitor entering the market, etc.).

SPI, CPI can be presented in grids against delivery risk, as RPI can be presented against benefit risk. Grids can also be built for each one of the three indicators against project stage (i.e. on-hold, planning, executing, etc.). What this means is that the three indicators that come from an expanded EVM system can be used as the foundation to put together indicators that relate to stage, risk, etc. This provides a very solid foundation for a framework destined to optimize the investment, as it covers both delivery (SPI and CPI), benefits, risk (delivery and benefit) and incorporates the time value of money. This is, by definition, a framework that focuses on optimizing return on investment from projects.

The three musketeers are complete: RPI comes to complement two venerable performance metrics that have been used for fifty years to measure delivery. The adoption of Earned Benefit and RPI are a natural progression to EVM and will likely become part of this comprehensive framework.

We have our trinity.