Voices on Project Management

by Lynda Bourne

One thing we learned from 2020 is that it's difficult to make predictions, especially about the future. (Danish physicist Niels Bohr’s words from 1971 still ring true.) Still, the world doesn’t stand still, and project managers need to keep looking ahead. That’s the whole purpose of a project controls function: to produce information that helps us make decisions about the future.

In many respects, project plans (schedules, budgets, etc.) are similar to economic forecasts. For decades, both have been used to make predictions more academically rigorous through mathematical techniques. The problem is these models are suited to the stationary physical world, where everything that happens is governed by the unchanging laws of physics—or to games of chance, in which the probability of something happening can be calculated fairly easily and accurately. They do not neatly apply to the intricacies of a dynamic project or economy.

Two leading British economists, professor John Kay of Oxford University and professor Mervyn King, a former governor of the Bank of England, recently launched a critique of the unrealistic assumptions their peers have added to conventional economics in the book, Radical Uncertainty: Decision-Making for an Unknowable Future.

Their view is that making predictive models more mathematical does not improve the accuracy of the predictions. The models assume the decision-maker and all of the other actors will follow the logic underpinning the model. But we all know the people being modeled do not behave rationally and rarely, if ever, actually work to the plan.

Kay and King call this type of modeling “small world,” as the right and wrong answers can be clearly identified. Projects (and economies) operate in a “large world” occupied by consumers, businesses and government policymakers, and characterized by what they call “radical uncertainty.” People in the large world have to make decisions based on a small part of the information actually needed about both the present and the future. Most of the time we can never really know if we made the best decision, even after the event.

Fortunately, like Alice in Wonderland facing the appearing and disappearing Cheshire cat, people are very good at coping with uncertain situations. And it’s amazing how often we get it right. Kay and King conclude: “Our knowledge of context and our ability to interpret it has been acquired over thousands of years. These capabilities are encoded in our genes, taught to us by our parents and teachers, enshrined in the social norms of our culture.” Human intelligence is effective at understanding complex problems within an imperfectly defined context, and at finding courses of action that are good enough to get us through the remains of the day and the rest of our lives. They are not necessarily the best solutions, but they’re ones that are good enough.

So where does that leave project controls? We have predictable tools such as earned value, critical path and the like built on the basis of predictable calculations. Unfortunately, these calculations are rather bad at accurately predicting actual future outcomes. But is the imprecise information useful?  

My thinking is that control tools can provide useful insights, but only if you accept there will always be a difference between the prediction and reality as the future unfolds.

How do you use project controls to chart paths forward into the unknown?

by Lynda Bourne

The world of business is moving toward storing and exchanging documentation in electronic formats—and the transition is swift. While this process has its advantages, my team and I have been working on a major report based on a data set of more than 250,000 records, and the project has highlighted some problems. Namely, as it becomes easier to preserve every iteration of a document, finding useful information becomes harder.

There are two basic types of document storage and retrieval systems with a couple of nuances:

1. Systems that rely on taglines or document characteristics for sorting and searching (e.g. document titles, taglines in emails, dates, authors, senders, receivers, etc.)
2. Systems that allow the full content of most document types to be searched (think Google)

If your organization isn’t using one or more of these systems, it soon will be!  You’ll probably find that they solve many problems typically found in paper-based systems, but they also introduce a new suite of issues. Here are some of ways in which these systems fall short—and ways to overcome these challenges:

Establishing one source of the truth. As people become more used to the system, they begin to rely on it. And if something isn’t uploaded, stored or created in the tool, it ceases to exist. You cannot rely on people remembering to do the right thing, and if someone is doing something unethical, they will try to evade the system. The solution lies in system design and automation. Discipline and processes are needed to make sure a document retrieval system contains all of the documents.

Creating one document, one record. Send an email to 10 other people in the organization and you immediately have 11 versions of the one document scattered across various email accounts. (And this is before “reply all” and email trails start to build.) Your document management system needs to be smart enough to recognize identical versions of the same document and archive the 10 copies. However, when someone changes the email (maybe by forwarding it), you have a new document, and the process gets more complex if there are attachments. Here, the solution is a system that can manage families of documents.

Finding what you need—easily. This is the biggest challenge with massive archives of documents (and was central to our work over the last few months). How do you find information?  A search based on document contents may seem like the best option, but if you Google “PMI PMP exam change,” you get 891,000 results. And it’s Google’s systems that decide which of the pages it will show you and the sort order. That means if you’re looking for something specific, you may have to dig through a sea of hyperlinks and page titles. This gets even more difficult if you want to check if something did not get documented. A null-result may mean the alleged document does not exist—or it may mean your search terms are slightly ambiguous.

Developing systems that balance providing information that you need against burying you under masses of content requires the wisdom of Solomon. Artificial intelligence can help if the search is routine, but for an important ad hoc search you are probably on your own. One way to help focus searches is by structuring the information, using folders or codes. The problems are minimizing misplaced information and persuading everyone to use the system. Again, system design is central to developing processes that work.

The concept of a paperless project has been around for a while now and electronic document management systems are becoming increasingly common. The challenge that remains is scaling this concept up to the enterprise level and developing tools that can quickly provide you with the information you need from a pool of several million documents. 

What do you do to store documents and facilitate the ease of information access?

by Lynda Bourne

Projects mean reports! Many project teams are required to produce weekly and monthly reports for their client as part of a contract, or because of an internal set of reporting requirements. This process comes with challenges:

1. The information is out of date—project reports largely focus on what has happened.
2. Most reporting regimes use a one-size-fits-all structure. This is better than freeform reporting, but it means while all of the information may be needed by someone, there’s a lot of redundant information for almost everyone else.
3. They are time-consuming and expensive to produce.
4. The information is groomed and edited to suit the narrative the report writer would like to tell. You don’t need to be dishonest to change the impression a report creates; you simply need to understand how language works. 
5. The people who really need the information are usually too busy to read it.

That raises a big question: Do we need traditional reports? Developments in business intelligence, artificial intelligence and system integrations offer a far more useful solution—putting real-time information in front of the people who really need to know now.

Most of the information on virtually every project (even traditional construction projects) is recorded in various software tools. With a little bit of organization, the data can be brought into a business intelligence (BI) system in real time. The result: a dashboard showing what’s occurring in real time, usually with a drill-down capability to see what has changed and why.

The problem with BI is usually too much information and added noise created by different elements within the tool being updated, edited and corrected at different times. This generates false differences for short periods of time. This is where artificial intelligence (AI) comes in to play two useful roles:

1. Within the BI system to filter out the noise: For example, if Bill’s timesheet has been entered but his work for the day has not been updated, wait until the end of Bill’s shift before flagging low productivity—his work update may be entered in the next 5 minutes. (Real time is good, but needs managing/synchronizing.) 
2. Outside of the system to learn what’s important to whom: No one can spend all day looking at the dashboard. AI can be trained to send targeted alerts when something relevant to a manager changes enough to warrant their attention. An email or an SMS is sent with a link embedded to the relevant part of the dashboard.

Do reports still have a role? My answer is yes, but it’s a different role. Reports are needed to explain something or to show the results of an investigation or inquiry. For example, a team (or individual) may be tasked to report on the preferred subcontractor to engage for a particular role on a project. The report provides leadership with the information and options needed to make a decision. In fact, this would be a far better use of the time currently spent by PMO and project staff preparing and distributing weekly and monthly reports.

I want to hear your thoughts: Do traditional reports still have a place among project teams?

By Lynda Bourne

In my last post, The Real Estimating Challenge Isn’t Calculating the Cost, I suggested that calculating a project cost estimate is the easy bit. Having the estimate accepted by either a client or your management—or both—and then delivering your project on budget is far more difficult. In this post, I want to look at the challenge of delivering on budget.

Knowing what a project is likely to cost is important from every perspective: personal, professional and organizational. But developing a realistic and achievable cost estimate has two components: first you develop the baseline estimate, then you need to develop a realistic contingency. Most people do step one; very few even think of step two.

The baseline estimate should be realistic, and there are many valid approaches to creating one. But what comes next?

If you simply stop at the net cost estimate based on expected resource usage and known cost rates, your project will inevitably overrun its budget. There are no allowances for risks, which will inevitably arise during the course of the work. No project is ever risk-free.

Risks are uncertainties that matter. From a cost perspective this includes both variability in estimates and performance, and uncertain events that may or may not occur.

Managing Variability

Variability is inevitable. The work might be completed quicker or slower than planned, people might change and cost more or less per hour, etc. The only certainty is that the actual cost outcome will vary from the estimate.

The key question is: by how much? Use past performance as a guide to size this part of the contingency appropriately.

Managing Uncertain Events

This type of uncertainty is the realm of the risk register and its list of identifiable uncertainties, overlaid by other risk events that were not foreseen. These are the known unknowns and unknown unknowns of risk management.

This type of risk can be mitigated or reduced by good practice, but neither of the unknowns can be eliminated entirely. Residual risks always remain. The important question is: How do you compensate for the remaining risks in your business case or cost estimate?

One approach is to pad the estimate and hide the costs within the overall price. The problem with this approach was identified by Eliyahu Goldratt in Critical Chain (1997). He stated that when the contingencies are hidden, they tend to get absorbed by the work and are generally larger than needed. This is not a good way of working. For example, in developing software every test may fail, but only some will identify bugs that need fixing. Padding every test with some allowance for failures hides the money, and it is likely to get used anyway to cover all sorts of other events. 

The better approach is to price each test on the assumption that the test will pass, and then create a contingency for bug fixes. This allows the cost of rectification to be seen, monitored and controlled independent of the costs associated with testing. If the number of bugs is too high, this becomes obvious and allows management to consider ways to improve processes.

Managing Contingencies

Calculating the amount of money needed to adequately cover the risk exposure of the project is complex. It requires expertise. But once this has been done, the values calculated should be divided into two distinct parts:

1. The project contingency, held within the project budget to compensate for variability and other known unknowns that will occur to a greater or lesser extent. The project manager should be responsible for looking after the expenditure of this money but is expected to report to senior management on each use.
2. The management reserve, held outside of the project budget for use by senior management to offset the effects of unknown unknowns.

These are not slush funds. They are calculated and held for explicit events that may occur and the use of the funds is constrained, controlled and reported on throughout the life of the project.

Summary

Developing a sensible level of contingency and reserve is a complex process and beyond the scope of this article. The message is simple, though: If you do not include contingencies, you will overrun your project budget!

The bigger challenge is to convince management to accept the need for a properly evaluated contingency in every project. Achieving this requires the solutions outlined in my last post, linked to a concerted program of support from both the organization’s PMO and its portfolio management team.

The challenge is not insurmountable. Large parts of the U.S. government under the auspices of the Government Accountability Office are mandating this approach, and the U.K. treasury has its Green Book. Your challenge is to inspire similar attitudes within your organization’s senior leadership team.

How does your project team develop realistic contingency plans?

By Lynda Bourne

Calculating a project cost estimate is the easy bit. Having the estimate accepted by either a client or your management—or both—and then delivering your project on budget is far more difficult.

The technical processes involved in developing a realistic and achievable estimate are well-defined in standards and guides such as the Practice Standard for Project Estimating - Second Edition. But, after the development of this cost baseline, every project faces two challenges: The first is dealing with the uncertainty associated with every estimate and developing an adequate (but not excessive) contingency to cover the known uncertainties. The second is having the estimate accepted to allow the project to proceed.

There are three interlinked issues that can lead to non-acceptance of the estimate:

1. Unrealistic expectations about what the cost should be on the part of the person paying, which is usually linked to a lack of trust in the person presenting the estimate.
2. Unwillingness on the part of the person paying to accept the fact that every estimate contains a degree of uncertainty and placing undue emphasis on a “guaranteed” price without any form of contingency.
3. A lack of confidence, skill and/or communication ability on the part of the person/team delivering the estimate.

Over many years, I have found any idiot can produce a winning bid or cut costs in a business case to get the project accepted, and then lose money doing the work. The work of Bent Flyvbjerg, professor of major programme management at Oxford University's Saïd Business School, would suggest that this is almost traditional in the accepted costs for megaprojects. But, under-pricing work to get the project started is hardly ethical, and likely to be career-limiting in the long run.

I’ve also noticed smart clients understand that an unrealistically low bid will cost them dearly in the long term due to diminished quality, excessive claims and/or the cost of dealing with a failed project. Unfortunately, smart clients are in the minority. But if it were your money and project at stake, would you want a client who puts the short-term expediency of a cheap price ahead of achieving value? Starting an under-priced project and attempting to cut costs to meet budget constraints almost always drives down quality and drives up costs over time.

There’s a well-known business quote, often attributed to John Ruskin: "There is hardly anything in the world that someone cannot make a little worse and sell a little cheaper, and the people who consider price alone are that person's lawful prey. It's unwise to pay too much, but it's worse to pay too little. When you pay too much, you lose a little money—that is all. When you pay too little, you sometimes lose everything, because the thing you bought was incapable of doing the thing it was bought to do.”

The antidote to these challenges is having the skills needed to develop a sound estimate that has a reasonable prospect of allowing the project to be delivered on budget, having the confidence to stand by the estimate and to justify the costs, and, most important of all, having the communication and stakeholder engagement skills needed to sell the estimate to either your client or your manager. 

The factors underpinning your engagement and communication capabilities include:

• Your credibility. The people you are communicating with need to know you are competent, honest and reliable. Their perceptions are vital.
• Your stakeholder assessment skills. Determine who is really important in the decision-making processes and what their real objectives and interests are. This understanding is vital in helping you develop a proposal that can be accepted.
• Your ability to communicate complex information. There is usually a lot more to a project proposal or business case than just the cost. Decision makers need to understand the benefits of the proposal and feel confident you can look after their interests. You must be able to communicate this plan effectively to different audiences.

Each of these elements work together to help you get good project proposals accepted. They also help you help your managers abandon projects that do not add value. If the project does not stack up at the proper price, it should not be funded.

How do you go about selling your good project proposals?