Planning and running large, ambiguous projects present many opportunities to lose time. After all, how can we be efficient when we don’t necessarily know the solutions and/or we don’t necessarily know the path to the solutions? It’s easy to assume that the ambiguity and complexity of many projects makes it improbable, if not impossible, for us to plan and run projects efficiently, but the world of science suggests this doesn’t have to be the case.
Scientists use a specific, repeatable process dating back to the early 1000s for tackling such challenges that lends itself quite well to the business environment. In science, it is called the scientific method. And, for the most part, scientists have applied this method to tackle more ambiguous and complex problems than we face in business.
One of the early examples of the scientific method in action sheds light on both the simplicity and power of the method. In the early 1600s, Galileo set out to determine how objects accelerate under the influence of gravity. To begin his exploration, he could have gone any one of a million different directions, but instead, he set out to disprove an existing theory formed by his predecessor, Aristotle, that objects of different weights will accelerate at different rates.
From there, he came up with a scenario that would have to be true if his hypothesis – weight (or more properly, mass) doesn’t affect the rate of acceleration – was right: two balls of different weights would take the same amount of time to descend a ramp. Galileo, then took, what may seem like the obvious next step, and he collected data to determine if this scenario was actually true. He tracked how long it took balls of different weights to roll down an inclined ramp. It turns out he was correct: they both descended in the same amount of time.
Galileo’s simple process enabled him to debunk the prevailing wisdom of the day and create groundbreaking theories in the field of physics. He essentially followed 3 steps that we too can apply to our projects:
Start with a falsifiable hypothesis:
A hypothesis is what we expect the answer to be. It creates a fulcrum that everything else is weighed upon. If work isn’t directly linked to proving or disproving the hypothesis, then it shouldn’t happen. Developing a hypothesis can be challenging when a lot of uncertainty exists, but generally we find it challenging because we haven’t spent adequate time considering the potential outcomes of a project.
In science, hypotheses must be falsifiable, meaning the hypotheses can be proven wrong. In the business context, this means that our hypotheses must represent a real choice with real alternatives. Leading business thinker, Roger Martin, explains it this way: “Strategy is about making specific choices to win in the marketplace. It requires making explicit choices to do some things and not others.” A clear, falsifiable hypothesis lays the groundwork for the rest of the project.
Determine what would have to be true for the hypothesis to be right (i.e., the assertions):
The next step is to run through the thought experiment of what would have to be true in order for the hypothesis to be true. This process enables us to determine the assertions that the hypothesis rests on. It’s important to avoid skimping on assertions so that you fully understand the factors that will determine if your hypothesis is right.
Once you have your list of assertions, it’s time to weigh the significance of each. You can do this by asking three questions:
- How important is each assertion to proving my hypothesis?
- What burden of proof does each assertion require?
- In what ways are my assertions dependent on each other?
Answering these three questions will enable you to determine where to focus your work and where to start.
Identify the data needed to test the assertions:
Now that you have a hypothesis and assertions, it’s time to turn to the place most people start projects: what data, information, or analyses must be done to prove the assertions. The hard work done up to this point should make this a fairly easy process unlike the typical process of deciding what work should be done, which can feel more like throwing darts blindfolded than a scientific process.
Here, again, it’s important to avoid letting your curiosities get the better of you. Identify only the minimum amount of data, information, and analyses required to prove your assertions. Keep in mind that if an assertion is low in importance or burden of proof, you should be able to spend less time on this step. Think of the simplicity and minimalism of Galileo’s data collection effort, and yet, the disproportionately large outcomes.
Ambiguity and complexity don’t need to drive our project management toward inefficiency. By starting with a falsifiable hypothesis, determining what would have to be true for the hypothesis to be right, and only then, identifying the data needed to test the assertions, we can plan and run the most complex business projects productively.