Skip to main content

Author: Fernando Santiago

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%.

santiago 11052018aTable 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.

santiago 11052018bTable 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%.

santiago 11052018cSPI< 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:

[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:

santiago 11052018dTable 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

santiago 11052018eTable 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

santiago 11052018fFig 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)

santiago 11052018gFig 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.

santiago 11052018hFig 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

santiago 11052018iFig 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%.

santiago 11052018jFig 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)

santiago 11052018kFig 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.

santiago 11052018lFig 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.

santiago 11052018mFig 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

santiago 11052018nFig 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.

santiago 11052018oFig 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

santiago 11052018pFig 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.

santiago 11052018pFig 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.

Why are Project Managers Allergic to Schedules?

Imagine bakers that didn’t like ovens, because they are too hot, or surgeons that, when facing an open patient at the OR think “this is too hard, let’s close the patient and get him back on meds.”

Sounds absurd, but this is what many project managers do when it comes to maintaining a schedule, the central tool of our profession.

Many project managers have flocked to agile just to get away from the need to create and maintain a schedule. I am an agile practitioner and trainer myself and can tell you that it is true that agile doesn’t require a schedule, but agile is not equivalent to “cowboy management.” The discipline required to carry out an agile project is sometimes more stringent than in waterfall.

I have used Microsoft Project for twenty years now (yup, it has been around that long, and other than introducing the ribbon in 2010 that drove everyone crazy, Microsoft hasn’t done much to the tool, for which they charge over $1500/license). I have used it to manage projects and programs, even portfolios. I have been an instructor in MSP and also a trainer and coach, helping PMs to learn the tool.

{module ad 300×100 Large mobile}

I can say that, for the most part, I have tamed the beast, but from time to time it lashes at me. Microsoft Project is not an easy tool to use. It is not like Excel where all the tables are in sight. Microsoft Project is composed of many tables that you don’t see or even know exist, so any false move and you are doomed. A 10-day task jumps to 60 days, your filters don’t work, or worse.

Most project managers have no problem creating a schedule during the planning phase of the project, so they can define milestones, request resources and make commitments with stakeholders. Then they go through the moving ceremony of printing the schedule and posting the pages on a wall. Apart from impressing everybody at the office with their knowledge and sophistication, posting a schedule on the wall is completely useless.

At the start of the project, a schedule is always wrong, and you will only know how wrong it was when you finish the project. The schedule will and is expected to change every week if it is to remain relevant. The printout on the wall is nothing else but expensive and ugly wallpaper.

The main challenge with MSP or any other scheduling tool is during execution. Some project managers try to update the schedule, they do it wrong, get absurd results and finally give up. Some examples I have seen over and over are:

  • Today is July 20, and you are updating a task as complete. The task has a start date of August 03. Congratulations, you have travelled in time and completed a task in the future.
  • Today is July 20 and a task scheduled to be completed on July 17 remains at 0%. In this case, help to go back to the past to complete the task.
  • Today is July 20, and a task is scheduled to start August 17. For valid reasons, some work for that task was done last week and, to avoid the problem mentioned above, you change the start date to July 13 and report progress. In response, MSP splits the task, and now you have a dotted line followed by a bar, which you don’t know what it means. Nice.

These three examples are typical situations that are very simple to prevent, but you need to know what to do. If you don’t do it right, you are introducing technical debt to the schedule. After a few weeks, the results will not reflect where the project is in terms of milestones or percent complete, and it will get progressively more difficult to update, as you will get unexpected results you will have to fix. At the end you don’t know what to do, you are frustrated, it’s late, you want to go home, so you give up and go back to your old friend Excel, which doesn’t have a mind of its own and follows orders.

MSP is a modeling tool that can predict future state as in when milestones will be achieved and when resources will be needed. Excel simply cannot do that, and can be dangerously misleading on the real status of a project. Yet, the majority of PMs revert to Excel to different degrees, instead of sticking to the tool of our trade – the schedule. For a good PM, the schedule is the core tool. Guiding decisions for execution and management of resources, It contains all the relevant information from risks, issues, and changes.

When the team is involved during planning, and the schedule is kept visible to the team week after week, they not only get used to the schedule, but the tool plays the same role as the “project wall” in agile. The end result is the same – a team that moves towards self-management. It is a beautiful thing when you watch a team discussing and trying different scenarios of what to do to get the next milestone back on track. Of course, for this to happen, you need a schedule that works.

Many companies are embracing agile as the approach of choice, but there are, and there will always be projects that do not fit agile, so the schedule is alive and has many more years to live. Furthermore, you can combine approaches like using agile for one major deliverable and a traditional waterfall for other deliverables.

I was consulting with an insurance company that wanted to do agile not matter what. They had a major program that involved a front end that nobody understood and for which they couldn’t make up their minds, which was perfect for agile. The project also had to deliver all the “piping” between the new front end and the back-office applications. This part had no volatility, was predictable, and could be planned using traditional methods.

My recommendation was to start with the piping, using a traditional approach, and then do the front end using agile, using the agile principle “procrastinate, procrastinate, procrastinate”. They followed my recommendation and built the backend with no problems. In the meantime, the direction changed three times, so it paid to procrastinate. The front end was then delivered using agile. A success story that required an overall schedule to manage all these components, and a detailed schedule to manage the back end. Long live the schedule!

So what should project managers do?

  • Never push team leads or resources to update the schedule. If it is hard for a PM, imagine what they will do if left unsupervised.
  • If you have a small project, you, the PM, must be the bridge between Excel, napkins, backs of envelopes, and the schedule.
  • If you don’t have the skills to update schedule properly, get help. The built-in help will not address these topics. What you need is training and maybe coaching from your PMO or local PMI chapter.

A well-tracked schedule can and should become the core tool the PM uses to manage the project. It integrates all the relevant information (actuals, resource availability, risks, issues, assumptions, constraints, etc.) into one tool that can model the expected results and tell you the most likely dates for your milestones. For this, you also need an organizational culture that encourages transparency and early warnings that dates may not be met. Other organizations prefer the “head in the sand” approach and deal with the problem when it blows up, usually throwing more time and/or money.

The majority of project managers think that they can manage all the relevant project information with sticky notes on their foreheads. This approach, while valid and very frequent, has two problems:

  • Too many sticky notes, they won’t fit on your forehead
  • The sticky notes will fall when you start sweating

Being a good scheduler will elevate your career as a project manager, particularly when you use it as a tool for collaboration and team self-management. Maybe it will not become your favorite video game, but it shouldn’t be the monster under your bed either. A good project manager that is also good scheduler can have a brilliant future.

Is Project Management a skeleton from the Industrial Revolution?

santiago Nov11It is the beginning of November now, and as Halloween just passed, we drive by graveyards, open tombs, and skeletons, some of them funny, some not so much. In some cultures, like in Mexico, “Dia de los Muertos” is the day to honour the dead. In North America we dress up our kids in costumes and walk the streets for candy, Mexicans take food and tequila to the cemeteries and party all night. Hey, we Latinos can make a party out of anything!

Skeletons are innocuous when they remain in their coffins. The problem is when they pretend to be alive and, even worst, when we listen to them, as if it were still their time, when it is not.

Project Management has been accused of being a thing of the past, a dinosaur, a cadaver that enjoys surprising health. In 2002 a group of developers got together at a ski resort in Utah and came up with the Agile Manifesto, which was an elegant way to tell project managers to get out of the way and let developers do what they do best: build software without the interference of project management and project life cycle processes and rules.

While this is not a call to go wild and back to “cowboy development”, it should be interpreted as a wake-up call. Software developers, computer engineers, etc; are usually the bright kids out of high school, the nerds with a cap and propeller. However, the question is: what do you call a nerd twenty years after graduating from high school? The answer is “boss”.

Project teams get these bright kids who, after college or university and years of experience, are even smarter. And what we do is treat them like complete idiots. We, project managers, need to tell them exactly what to do, otherwise they will not be able to figure it out on their own. After ten years of agile practices and even PMI jumping on the bandwagon to cash in with a certification (PMI: agile was never about project management to start with), it is now widely accepted that business analysts, developers, testers, are not idiots after all. All we need to do is tell them what the goal is, and when it needs to get done, and they will find the best way to do it. Like in my favourite line in Jurassic Park: “nature will find its way”.

However, many project managers, and even methodologies, still cling to the past. And this is not about agile VS waterfall; it is about management VS leadership, it is about telling people what to do VS facilitating the conditions for the team to excel; it is about taking the driver seat or the back seat, and let the team drive.

Going back to the theme of this article, it is interesting to draw a parallel with the industrial revolution, which was triggered by the great invention of the eighteen century, the Steam Engine by James Watt, a Scottish instrument maker who created an innovation that changed the world. For centuries, industrial facilities had depended on the flow of water from a river to draw power using a wheel connected to a number of axles through a complicated arrangement of pulleys and gears that were in movement all the time. Each workstation only had to hang a leather belt from the overhead axle and they were connected to the source of power. This model had many problems: first, it was all or nothing for the whole plant; second, and most important, it depended on the flow of water: no water, no power, and in North America and Europe, water during winter time tends to freeze, so mills had to stop until the spring, when the problem was to control the excess flow from the meltdown. With Watt’s invention, none of these problems existed. All they had to do was store sufficient water, and here is where the “mill pond” comes from, so water could be drawn and boiled into steam. Although not perfect, it was a better solution. Not the best job for those shoveling coal day in day out, and fires were frequent, but it worked. So mills all over the world installed steam engines, which powered the same mechanism of axels and pulleys they had before, and the industrial revolution came to be, kids were exploited, Dickens wrote his books, fortunes were made, and people got used to cheap goods they could take home. Life was “good”.

In the nineteenth century, another Brit, Michael Faraday, an Englishman this time, invented the electric motor. It was cleaner, safer, and more dependable than the steam engine. So factories all over the world quickly adopted the new technology, replacing the obsolete steam engine with a huge electric motor. Nothing changed, it was just cleaner and safer, but the way of doing things was still the same.

It took seventy years, or three generations, for industry to realize that the advantage of the innovation they had adopted was the ability to install small electric motors at each work station, so they could be turned on and off at will, and speed controlled to suit the task at hand. Seventy years to realize the potential of technology, of the innovation they had already adopted. Do you think it is silly? Keep reading.

The history of project management is surprisingly similar. As a discipline, project management emerged after the Second World War in the aerospace and defence and engineering and construction sectors. During the fifties, sixties and seventies, mainframes became affordable for both the private and public sector. Project management software came to be in early versions of products like Open Plan, Artemis and Primavera, which are still around in some form. There were no PC’s at the time, no networks, no tablets or cell phones; only a mainframe in a protected environment, with raised floor and a group of chosen ones who could tame the beast, taking punched cards in and coming out with white and green reports. That is the world I got to know when I started my career as a project manager in the oil industry and then in the engineering consulting sector, in the late eighties.

Because of the central concept dictated by the mainframe, the model worked as follows:

  • A command and control approach to program and project management, with project managers cracking the whip every five minutes or so, pushing teams of hundreds of engineers and draftsmen creating blueprints and other documents. It was the industrial revolution all over again, just cleaner.
  • Engineering projects, as predictable as they are, can be defined in advance in an excruciating level of detail, so the mainframe was fed with schedules that had thousands of tasks. Updates were fed to the mainframe and we got back reports with the state of the project. Considering how primitive the technology was, we did pretty sophisticated project management. Today I have to smile when students and project managers tell me that Earned Value is complicated. We did it back then with punched cards, pencil and paper. We had no PC’s, no Excel, just paper and pencil, and a brain.
  • While this was happening in the aerospace and defence and engineering consulting, IT was just getting started with project management. As software companies and IT departments in banks and insurance companies (some were called IBM Department, believe it or not), the need for project management became obvious. As projects got bigger, more complex and difficult to manage, IT turned to the “pros”, the hard core engineering PM’s, to help with project management. Engineering Consulting firms saw the business opportunity and spun off firms to sell this know-how to industry. I happen to work in one of those firms, and project management was our product to sell.
  • In the eighties and nineties, many PMs decided to jump ship and got hired by IT departments and software companies. I was one of them, and we did what we knew best: we replicated the model that worked so well in engineering consulting, and it failed miserably. First of all, engineers are easy to manage: us engineers tend to be structured, predictable, we follow process and rules. A command and control model works well with engineers. On the exact opposite, software engineers, architects, developers, are a different breed: they are artists, they are creative, they are constantly coming up with new things. Some of them can be “prima donnas”. A command and control model doesn’t work well with these people, but we tried anyway, and we failed. In the early nineties, the Standish Group surprised the world with the “Chaos Report”, a research project based on thousands of IT projects all over the world, and it was not pretty: only one out of three projects in IT was completed within a reasonable time and cost variance and meeting scope. The vast majority of IT projects were outright failures, with average overruns of 200% and up, severely behind schedule and over budget.
  • Continuing down memory lane, in the eighties and early nineties we got a number of innovations that had great potential to improve project management in IT: the PC, the network and, you guessed it, Microsoft Project.
  • So what did we do with these new capabilities? We made exactly the same mistake that was made in the eighteen century with the electric motor: we replaced the mainframe with a PC on steroids, or so it seemed at the time, installed MS Project, and ran the show exactly the same way as before, only cheaper. We put schedules with thousands of lines through MS Project, and it choked and crashed (twenty years have passed and still does…). We printed the schedules, some even printed PERT diagrams and used them as fancy wall paper to impress the bosses with the sophistication of the project management profession. These schedules and PERT diagrams stayed on the walls for months and years, and who would even think about updating them; that would be too much work. We were material not for a Dilbert strip, but for a complete book.
  • As we geared towards Y2K (for the younger generation, we thought that computers would stop working when clocks would go from 99 to 00, Terminator would come and destroy the world as we know it; at the end, nothing happened, but there was plenty of work for all of us for a few years). Shops were busy again, the dot com era was booming and IT was the place to be. The problem, and there is always a problem, is that projects were less predictable every day, as we moved from mainframe to client-server to web, things were just impossible to predict in advance. This is when and why agile emerges, and it teaches project management a lesson or two.

For those who have braved the history lesson and made it to this point, the good news is that IT is finally starting to get its act together. Today the reports from the Standish Group show improvement, while there is still a lot to be done, results are not as bad as before. It took us twenty years, at least not seventy years like two centuries ago, to realize the potential of having a scheduling tool available throughout the organization, and information flowing across projects, programs and portfolios. PPM tools now provide the functionality to support smaller teams, even agile teams, each one accountable for a deliverable or work package, with its own schedule and, most important, self-managed, with a project manager that is no longer a dictator but a facilitator. This is not exclusive to agile, and it is applicable to even pure waterfall projects.

The key idea is to relinquish the need to have centralized command and control, and delegate to teams, empower the leaders and their teams, give them a date they have to make, explain to them how their piece fits in the overall project or program, and why the date is important, and they will deliver.

Remember: you have the brightest kids in your teams. Don’t treat them as idiots. If you can’t handle the change, you are still on time to pick up a skeleton costume for Halloween or, even better, “Dia de Muertos” in Mexico. And don’t forget the tequila: you are going to need it.

Don`t forget to leave your comments below.

So You Think You Can Dance?

Waterfalls can produce lots of energy too?

High energy teams are not exclusive to agile. One of the principles of agile approaches that has a strong contribution is time boxing, as everything in agile has a fixed duration: the number of weeks for the iteration/sprints, the duration of the daily scrums, planning, retrospectives, etc. Time-boxing establishes cadence and, after two or three iterations, the team learns how much output they can produce. In addition, having short term goals keeps the teams at a constant high pace and productivity.

Many project managers today see the traditional waterfall approach as a dinosaur, a dysfunctional approach that should be avoided. This is simply not true, as waterfall is not only a valid approach but the only option for certain types of projects that don’t fit agile. The implementation of COTS (commercial off the shelf software) relies heavily on scheduling, as training sessions need to defined, rooms booked, etc. There is no way out: you need a schedule, and a detailed one. This just can’t be done using agile.

Using waterfall is not equivalent to a low-energy team. There are no “sticky notes”, colourful project walls and you don’t feel proud to be a pig (yes, in agile being a pig is a good thing) and you can call non-team members chickens. While not as colourful, a waterfall project can be high energy and lots of fun.

Cadence is one of the strategies that turns a waterfall project into a high energy team, and is defined at two levels:

  • A weekly cycle for execution: in essence, this is similar to a weekly sprint, without the rigour of planning and retrospective that agile has. The weekly cycle starts with the gathering of information on actuals at the end of the week, usually Friday afternoon or Monday morning. The PM updates the schedule with these actuals and assesses the situation of the project: is the next milestone (always the next milestone) still on track? Then the PM meets with the team with the schedule visible to everyone, so the team can visualize the situation, come up with ideas to bring the milestone back on track if needed. Adjustments to the schedule are done “live” by the PM in front of the team so, at the end of the meeting, everyone leaves with a clear idea of what needs to be done this week to stay on track. After the meeting the PM makes final adjustment to the schedule and generates the weekly status report, which becomes a by-product and not the main purpose of the weekly cycle.o
  • Milestones that keep the team at the right level of effort, not too distant that allows for slacking for a week or two after a milestone is achieved, similar to what happens in college after mid-terms. Milestones should not be too close either, because if the team achieves a milestone every few weeks, they become meaningless, losing the power to motivate as visible and common goals. Research done a few years back by the PMO Executive Council identified 40 drivers of excellence in project management, and the number one driver was “Obsession with the achievement of milestones”. As a side note, “Following Project Management Practices” was the last on the list, still important, but not as much as other drivers. There is no “rule of thumb” to define the number of milestones or the interval between milestones, but there are some “old dog tricks” to plan milestones:

    • Make your milestones aggressive but achievable, and always protect the milestone with a buffer or contingency.
    • Spread the effort in a way that the early milestones are easier to achieve, because the project is still ramping up, resources are not all on board, etc. The middle section of the milestones should be very demanding for the team, as this is the time to make progress and plow through work. The final section of the milestones should be easier to achieve, as the final stretches of every project always discover new things and, there is less room to maneuver as you approach the final milestone. In particular, the first milestone needs to have a high degree on confidence. Why, because it will become the prophecy for the team on whether they can achieve the milestones or not. As Seneca, the Greek philosopher said “Whether they think they can or cannot, they are right”.

Cadence is a fundamental principle of project management which, as discussed earlier, comes “built in” in agile approaches. When using waterfall, cadence will be a result of planning, for milestone definition, and a project management plan for execution. So you decide: tango or cha-cha?

Don’t forget to leave your comments below.

Is your corporate strategy a “Wishion”?

Santiago Oct31 01“Wishion” is not a typo. Most companies have Mission and Vision statements that are sound and well written. Sadly, when it comes to strategy, what they have is a “Wish-ion”: a document that defines what the company wishes to achieve, but not how it will get there. Almost every strategy document has the word growth in it; expense reduction and productivity improvement are also favourites. These are clearly goals that do not define a strategy on their own. To qualify as a strategy it should define what the company will do, or not do, or do differently, in order to achieve different results. Furthermore, it should define strong reasons why they think the strategy will work for them. If it doesn’t it is just a “Wish-ion”.  You can put it in acrylic, it is harmless anyway; nothing will come out of it.

The term “Wishion” was coined almost twenty years ago when I was doing my MBA at Schulich in Toronto: a student mispronounced the word vision, and said “wishion”, and I found it really funny as I thought of the possibilities of this new term to define poor strategy.

It is surprising that after almost thirty years of building a body of knowledge in strategy management, with armies of MBA’s learning these principles and many of them working for consulting firms, so many companies get this wrong. When nine out of ten companies fail to implement strategy, a good part of the problem is that there is no real strategy to implement.
Formulation of strategy is just the first step in the process, so nobody should expect to have a list of projects or initiatives listed on the strategy document. This should be the result of the process of translating the strategy into actionable elements: programs and projects. But the strategy needs to have enough substance in order to be translated into actionable elements.

Let’s look at a simple example; Joe is the owner of a cafeteria that sells pretty good coffee for $1/cup. Joe is losing customers who prefer to spend $4 at a fancy option two blocks away. Joe is not giving up and decides to transform his business into a fancy coffee shop and use the “fair trade” banner to convince customers to pay him $4 for a cup too. For this he will capitalize on his personal contacts from years of volunteer experience building schools in Kenya and Guatemala, coincidentally countries that produce great coffee. Joe’s idea is that a percentage of the revenue will go to actual projects the shop will fund, with progress visible to customers. This way they will feel good, instead of feeling robbed. In addition, he will replace the traditional muffins and pastries he sells with exotic options that are lower in calories and offer some novelty. Joe expects customers to spend more time at the store too, so he will provide amenities like Wi-Fi and plugs for laptop users at every table and small booths for on-the-go meetings. Finally, he will also grind and sell coffee in bulk. With all these changes, he expects the customers not only to return, but also to stay longer at the store and spend more in every visit.

While simple, the example offers a well defined strategy that can be easily translated into three clear business outcomes: “average customer visits increased”, “average time at the store increased” and “average spend per visit increased”. Those are the key non-financial results that will be significantly different than today and, if achieved, will generate a difference in the financial results of the business.

Well defined business outcomes are a solid foundation to tackle the next set of key questions:

  • Why are the current levels of the business outcome where they are?
  • What do we need to do that we haven’t done before to get the outcome we expect?
  • What do we have to continue doing, but do differently?
  • What are they things we should do that we cannot do today?
  • What are the things we should stop doing?

The answers to most of the questions above are capabilities, either business or technical, that require initiatives to deliver them. And this is how your strategy translates into a portfolio of programs and projects. Instead of the traditional approach of coming up with lists of projects and assess their potential return and alignment to the strategy, this process translates the strategy into programs and projects, so alignment is no longer an issue and return is assessed based on their relative contribution to the overall results. This is top-down portfolio management.

In our example, Joe has already answered many of the questions above, but there are clearly other things Joe needs to do: he needs to learn how to buy coffee in bulk and import it, and then he needs to find suppliers and negotiate contracts, etc. All these are business capabilities Joe doesn’t have today.  Joe also needs to select and buy equipment to make good espresso, and also install the Wi-fi and plugs. These are technical capabilities.

If there were other Joes in the same situation, their strategy document would probably read like this: “The central strategic trust is to increase revenue by regaining the preference of the patrons. We will achieve this as a result of superior customer service and differentiated products which, when combined, will create a unique experience for the customer and regain the position of the coffee shop of choice for the patrons in the area”. If the strategy at your company sounds like this, you may have a Wishion.

Don’t forget to leave comments below.

  • 1
  • 2