1/ I think I've finally understood why making a simple Project List, with small scopes, desired outcomes, and delivery dates, is one of the hardest things for knowledge workers to do
2/ Everyone knows we're moving rapidly toward "project-based work." This is a more fundamental shift than work becoming remote, contractual, or multi-team. Everyone knows what projects are! Right?
3/ We use the same word, but a "project" in the new economy is vastly different than a "project" in a big, traditional organization. It's like using the word "cat" for a tiger in the jungle, and also a fat house cat
4/ Trad'l orgs are like factory farms: everything is about scale. What allows a project to survive in this environment is to make it large, bloated, meticulously planned, long-running, with vague objectives that can be reinterpreted after the fact
5/ Large size helps a project attract the funding, political capital, sunk costs, and inertia necessary to survive the torturous path through the bureaucracy. The pork barrel spending (everyone adding things since they know the project can't be killed) is actually a feature
6/ But put this fattened milk cow in the jungle, and it'll get slaughtered. "Projects" in the new economy resemble lean, agile tigers. Small, adaptable, will eat anything, willing to hunt but preferring to watch for opportunities
7/ In project-based work, what allows projects to survive is to work very quickly, which requires shedding as much of the decision-making, approval, and consensus-making process as possible
8/ Remote teams of free agents wait until last possible moment to pull together around a problem, avoiding fixed overhead of having a whole staff waiting for something to work on. Perverse incentives of "makework" are eliminated, paradoxically making these quick decisions better
8/ What allows projects to survive is clear success criteria, because FAR worse for free agents than a project outright failing is dragging on for months as a half-dead zombie. This robs them of both opportunity cost AND learnings, while failing to compensate them proportionally
9/ New economy is also very uncertain, so many assume success criteria can't be written. The opposite is true - they are more important than ever, but we have to change how we write them, from prescribing means to describing ends
10/ Old-world projects try to lay out each step, because in a slowly-moving environment, executing intermediate steps successfully = completing whole project successfully. "Following the plan" was actually MORE important than project success, because you could cover your ass
11/ New economy projects describe the end state in vivid, exciting, but objective detail, focusing everyone's efforts on outcomes that are inherently valuable, whose completion is inherently meaningful (instead of meaningful according to the plan)
12/ The desired outcome shouldn't be "Deliver training manual" (the plan), but what will the manual improve, accelerate, enable, strengthen, accomplish, increase? You're not even saying those outcomes are "right," just that achieving them would inevitably yield fruitful learning
13/ Delivery dates or deadlines are even harder: putting a date on anything is suicide in large org, because you put yourself on the hook for something you can't remotely control. Easier to keep it hazy, so all missteps and changes can be translated to pushing out delivery date
14/ But probably hardest part is making projects smaller. This goes against every instinct learned in a large org (and even adopted by many ppl that have never worked in one). Because you're exposing inner workings (heh) to outside scrutiny
15/ By tightly scoping your projects, and attaching outcomes and dates, you're on the hook. Lack of progress in any one of them becomes immediately visible, and you're accountable. "Lowering the water level" exposes what isn't working, just like in Toyota production lines
16/ But just as in Toyota, you can view this as an opportunity, not a threat. Toyota considers it a bad thing if the andon cord (which signals a problem and potentially stops production) isn't pulled often enough. It signals that things are being hidden under excessive inventory
17/ Plant managers will then further reduce batch sizes & tighten operating parameters in order to surface more problems. Problems in this way are reframed as opportunities. They point the way to continuous improvement
18/ I encourage making such a Project List, and then showing everyone who will listen. It takes courage, boldness, openness to hearing feedback. But you will either gain a following as people join you in your case, or you will learn VERY quickly what isn't working
19/ A final reminder of what a GTD-style Project List looks like: a tightly scoped project that will finish within a few weeks + a desired outcome that describes an end state that can be reached many ways + a deadline or delivery date (which becomes a review date when passed)
