Lorem ipsum dolor sit amet, consectetur adipiscing elit lobortis arcu enim urna adipiscing praesent velit viverra sit semper lorem eu cursus vel hendrerit elementum morbi curabitur etiam nibh justo, lorem aliquet donec sed sit mi dignissim at ante massa mattis.
Vitae congue eu consequat ac felis placerat vestibulum lectus mauris ultrices cursus sit amet dictum sit amet justo donec enim diam porttitor lacus luctus accumsan tortor posuere praesent tristique magna sit amet purus gravida quis blandit turpis.
At risus viverra adipiscing at in tellus integer feugiat nisl pretium fusce id velit ut tortor sagittis orci a scelerisque purus semper eget at lectus urna duis convallis. porta nibh venenatis cras sed felis eget neque laoreet suspendisse interdum consectetur libero id faucibus nisl donec pretium vulputate sapien nec sagittis aliquam nunc lobortis mattis aliquam faucibus purus in.
Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque. Velit euismod in pellentesque massa placerat volutpat lacus laoreet non curabitur gravida odio aenean sed adipiscing diam donec adipiscing tristique risus. amet est placerat.
“Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque velit euismod in pellentesque massa placerat.”
Eget lorem dolor sed viverra ipsum nunc aliquet bibendum felis donec et odio pellentesque diam volutpat commodo sed egestas aliquam sem fringilla ut morbi tincidunt augue interdum velit euismod eu tincidunt tortor aliquam nulla facilisi aenean sed adipiscing diam donec adipiscing ut lectus arcu bibendum at varius vel pharetra nibh venenatis cras sed felis eget.
This is Part 2 of a series on the top problems with Project Management Tools. See Part 1: Old Tools, New Rules to catch up.
In Part 1 we talked about how the tools we use for Project Management today are deeply rooted in their decades-old past. Today we’re going to shift from the tools to how they have created a mindset stuck in the ideas of ‘management’ and ‘control’.
Project Management as a concept arguably started the first time a bunch of humans tried to accomplish some goal together. There’s some pretty good evidence that the Ancient Egyptians used early forms of program management to build the Great Pyramid of Khufu sometime around 2560 BC. For about 4,000 years it was the largest man-made object on Earth, built from more than two million limestone blocks weighing an average of 2.5 tons without the use of pulleys or iron tools.
Construction management firm Daniel, Mann, Johnson, & Mendenhall (DMJM) worked closely with Mark Lehner, an Egyptologist with the Harvard Semitic Museum, to perform a forensic analysis of the construction project (Program/Construction Management in 2550 b.c.: Building the Great Pyramid at Giza). Their conclusion: “the total labor expended is 36.7 million days, or approximately 131,200 man-years. Thus the average labor force over the 10-year duration of the project is therefore 13,200 men.” Imagine all the tools and techniques they used to manage that workforce and ensure a timely completion. How many of these same tools and techniques are you still using today to manage radically different types of projects on radically shorter timelines?
The rigid, hierarchical nature of those 13,200 workers led, some 4,500 or so years later, to the original org charts of the US railroad companies. Drafted for the New York and Erie Railroad company in 1855, this is one of the first know org charts (at left). The chart mapped responsibility to the actual structure of their various rail lines to ensure on time trains across the whole system. As Caitlin Rosenthal writes:
If any one data point was mismanaged it could bring dire results: “One delayed train, for example, could disrupt the progress of many others. And the stakes were high: with engines pulling cars in both directions along a single set of rails, schedule changes risked the deadly crashes that plagued 19th-century railroads.
Those rigid, inflexible management structures — both for people and for projects—were a requirement in a data-poor era in which very little analysis could happen in real-time. There’s a nostalgic tinge to thinking of the efforts and companies that required those approaches, from running railroads to mobilizing troops for WWI, which led to the birth of the Gantt chart as we know it. That probably feels very little like the type of organization you work for today, and yet many of the same rigid tools and technologies are probably part of your everyday.
In our New York Times bestseller The Decoded Company (Chapter Five: Engineered Ecosystems), we talked about how the traditional, hierarchical, command-and-control structure originated in military contexts but are being rejected in today’s armies. We included this quote from David S. Alberts’ 2007 article for the International C2 Journal, entitled Agility, Focus, and Convergence: The Future of Command and Control:
Command and Control is an approach that, while it was once very effective in achieving its ends, is no longer the only possible or even the best approach that is available. Command and Control is a solution to a problem that has changed. The situations for which Command and Control is best adapted have been transformed by the realities of the Information Age. Thus, the assumptions upon which Command and Control were based are no longer valid.
Instead, the proposed alternative focuses on autonomous teams that have the ability to make decisions quickly, based on their own unique contexts. As we concluded in Decoded:
If Command and Control is no longer right for the modern military, then it is no longer right for the modern corporation. This is an era of incrementalism, of constant small course corrections informed by dynamic evidence gathered in real time, not of grand master plans dictated down by generals behind the lines. Success depends on a rapid response to reality, not on an abstract blueprint. Thanks to data, we can readjust whenever we get relevant information, and the more information we get the better we become at navigating the landscape while maintaining alignment with our strategic objectives.
Let’s compare this with the approach to high-velocity decision makingoutlined in Jeff Bezos’ 2017 annual letter to Amazon shareholders. Jeff’s commitment to leading Amazon as a “Day 1” company, which he’s been doing since they were founded (he even works in a building called Day 1 just to reinforce the message). For Jeff, despite Amazon’s massive success, they’re still on Day 1. He was recently asked “What does Day 2 look like?”, which triggered his annual letter — they never want to become a Day 2 company. As he says:
“Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1.”
So, how do you avoid the kind of paralyzing, slow decisions that cause Day 2? He gives three suggestions:
First, never use a one-size-fits-all decision-making process. Many decisions are reversible, two-way doors. Those decisions can use a light-weight process. For those, so what if you’re wrong?
Second, most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.
Third, use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes.
We have a slightly different version of the third point, which we call “safe to try”. Most organizations inoculate themselves against change in the same way that your body unleashes white blood cells on an infection. Everyone in the org attacks the proposed change with thousands of reasons it won’t work until it’s eventually bloodied into submission and vanishes. That approach rests on a default of no, rather than a default of yes. “Safe to try” is different in that opposition has to present a valid reason why something isn’t safe to try—and that’s their only possible objection. Not feeling comfortable, not wanting to upset people, and a litany of other nots are all not valid objections.
The tools you use to manage your projects today probably give you very little ability to imagine high-velocity decision making or evolving from Command and Control. They’re designed from a different time in which those were fundamental truths of the universe —much like gravity —and are very difficult to escape.
It’s time to give up the illusion of control baked so deeply in yesterday’s mindset and tools and adopt the role of Conductor, orchestrating projects to awesome conclusions. We need to recognize that the types of projects we’re managing are (for most of us) not massive construction projects or complex railroads but rather rapidly changing, agile, team efforts that often span silos, geographies, and timelines.
