Fighting Entropy While Climbing the Project Management Mountain

Since Clausius invented the term over 150 years ago, physicists have wrestled with the concept of entropy. In simple terms, entropy is when natural forces break things down over time versus helping them evolve to a more sustainable state. For example, think about what would happen to a Ford pickup truck left in your driveway for 30 years. The paint would bubble, rust would form, the engine would seize and the truck would no longer be able to fulfill its original purpose. None of us would expect that vehicle to magically evolve into the newest model F150 with increased payload and better gas mileage.

Unfortunately, the law of entropy holds true in virtually every aspect of life including how we scope, plan, and manage projects. Long cycle times have an increasing number of external influences that contribute to the deconstruction and derailment of our best-laid plans. This is especially true in the R&D world where we attempt to do things that were never done before. By nature, R&D projects can have a vague path to completion, and a chance of failure that is not only possible, but probable. Faced with pressure to innovate and develop new markets, we tend to ignore the existence of entropy and focus on results instead of progress. This can lead to difficult discussions with leadership, disenfranchisement of key stakeholders, and a project that will never end without significant intervention.

So how do we combat entropy and ensure the success in all of our projects, including long-term projects where we can’t see the far side of the mountain? Here are tips that can help you gain better control of outcomes and more efficiently climb the long and involved path up a project management mountain.

1. Understand your starting point. As a child I dreamed of playing Major League Baseball. From the first time I picked up a whiffle ball bat, my backyard transformed into Three Rivers Stadium and I became a young Barry Bonds swinging for the fences. Today, I’m sitting in an airport lounge writing about the challenges of project management—a wild departure from my dream. The fact is, I am not Barry Bonds, my yard was not Three Rivers Stadium, and my bat was made of plastic. There was a lot of evolution that needed to happen to get me to my dream. Perhaps I should have been focusing on holding the bat correctly before winning the World Series. The same is true with projects. Understanding your starting point and the next realistic milestone is critical to driving longer-term success.

2. Set smaller targets or checkpoints.Entropy has two main contributors: time and external influences. Projects, especially in the R&D world, can run well past three years in duration. In the last three years I have worked for five different people, traveled to four countries, gained three new nieces, and lived in two houses. (I feel like the words “and a partridge in a pear tree” should come next.) For corporations those three years are 12 quarters of earnings calls and analyst expectations that the business must react to. Time brings a barrage of external forces that press in on us and add complexity to our world. While it’s important to keep an eye on the prize and the end game, breaking projects down into smaller sub-projects can get us to a new plateau and a vantage point that provides three main benefits. First, this allows us to systematically plan and execute work in our immediate line of sight. Next, smaller sub-projects with shorter durations limit the number of external influences that can act on the work. Finally, this approach can help us to better prioritize what needs to be done now. I had a client ask me this week, “How do I prioritize working on a development project that has an end date three years out?” After asking a few questions, the answer was simple, prioritize the milestones and deliverables that need to be accomplished now to be on track to meet a timeline three years out, or in project management lingo, prioritize items on the critical path.

3. Make your assumptions known early and know what can be known.Working with clients, I am frequently surprised by how many “knowns” are left to chance. I was recently helping a team build project plans for developing a new chemical polymer. As we were working on developing the project timeline, the team made an assumption that the testing cycle would take 90 days to complete because the work requirement was one chemist for 90 days. I challenged their assumption by asking, “Are you sure the testing department has capacity to devote facilities and a full-time resource to your project for the next 90 days?” The team made a call to verify and learned that there were three projects in the lab already and the likely timeline to completion was a minimum of six months out, double the original estimate.

Asking questions across silos and challenging assumptions that may not be supported by data will drive better project outcomes by making roadblocks visible. If we cannot control these roadblocks, at least we can identify the derail area and manage any effects. Having hard information also will facilitate conversations with leaders and stakeholders when expectations need to change.

These potential roadblocks are why we ask the question, “What could go wrong?” prior to project implementation. This simple question enables us to raise potential challenges and then use data and information to assess the threat and minimize the risks. I was part of a team tasked with doing a postmortem review of an ERP implementation that went horribly wrong. The changeover shut down the company’s shipping function for weeks after go-live and created issues for many months. Since I was new to the ERP world, I decided to Google “top ERP implementation failures” to give myself a reference point. If memory serves me correctly, the implementation we reviewed checked off every one of the top 10 items on the list. By planning for “known” risks, this ERP implementation could have had a much more favorable outcome.

If necessity is the mother of invention, then ambiguity is its ornery uncle. Where ambiguity exists in projects, we fill that void with assumptions on time, cost, performance, resources, expectations, and purpose. When Ferdinand De Lesseps surveyed the route of the Panama Canal before starting construction, he made the assumption that weather conditions in the region were stable. He was unaware that the treacherous rainy season would raise water levels as much as 35 feet. A disastrous assumption! France’s attempt to build the canal failed, 22,000 people died, and investors lost $287 million. Making his assumption visible early may not have stopped the project, but it could have given early insight into impending danger as the rain began to fall. Calling out assumptions early helps project managers, leaders, and stakeholders find common ground for project expectations and progress outside of the traditional time, cost, performance metrics. As you are navigating the project management mountain, many assumptions are based on where you are today. As you progress through a project, amending assumptions that have proved invalid and adding new assumptions based on what you’ve learned, is key to effective project communication and risk management.

4. Maintenance is required. Even when we have done the best possible job of defining and planning a project, during implementation things will often not go as planned. Why…because motion is one of the outside forces that creates opportunities for entropy to take over. Think back to our Ford pickup truck in the driveway. This time we don’t let it sit but instead start to drive it the day we bring it home from the lot. We researched the models, chose the amenities, and invested the money. What happens if we don’t do the routine maintenance, wash and wax it, and check the tire pressure? It has similar problems to the car that sat in the driveway. Projects need routine check ups on things like performance to plan, upcoming tasks that may require adjustments to timing or resourcing, and a host of other issues that come with driving through implementation. Daily standup meetings, formal reviews, and periodically asking critical questions about project performance are all necessary to combat implementation entropy.

There is also the special maintenance that may need to take place when we hit an implementation “pothole” like a change in client expectations and scope, a change in economic conditions that affect our budget, or some other risk factor raises its ugly head. These issues may require us to rethink where we are on the mountain and amend our course to deliver against a new set of expectations and objectives.

The longer and more complex a project, the greater the risk of entropy, especially when you have never seen the distant terrain. Understanding where you are starting, setting smaller targets, planning for the knowns, laying out your assumptions, and performing project maintenance will help eliminate the external influences that present themselves over time. You will manage the effects of entropy within your plan—instead of letting entropy manage you.