Project management
With special attention to speculative and innovative projects
March 23, 2021 — September 25, 2024
Making projects happen via a combination of institutional affordances and teamwork. I am especially interested in innovative/research/invention, which by design have a different structure than something more reasonably routine and repeatable, such as building a house.
1 Estimating
The Planning Fallacy, project overruns, amelioration strategies, and pathologies of queueing theory
Erik Bernhardsson, Why software projects take longer than you think has a neat statistical essay with some basic statistics which nonetheless produce some non-intuitive results for time management. Segue into queueing theory.
David R. MacIver, How to think about task estimation
Ben Brostoff, in Strategies for Long Projects, proposes that a certain kind of “irrational” optimism is the rational attitude to doing big things.
The Planning Fallacy: Predicting Times and Costs
Hofstader’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s law
There are some handy keywords to find citations for here: This Is Why Your Projects Always Take Longer Than You Expect.
2 Empirically informed
This field is full of MBAs citing anecdata. How much empirical statistically meaningful study is there of efficient organisations actually? I am sure there is some research here, behind the protective chaff of Business school glossy reports.
3 Operations research style
Breaking Logjams in Knowledge Work:
To get operations out of constant overload and firefighting, Broad’s genomics platform switched to a pull system. The key to understanding the difference between push and pull is to recognise that WIP inventory is a double-edged sword. Though it is intended to help mitigate variability in speed and productivity between steps in a process, it also hides information that supervisors and operators could use to manage and do the work more effectively. In a push system with lots of WIP, an operator can focus on her individual task with little regard for what is happening around her. But a pull system forces a broader awareness. It sets clear limits (both upper and lower) on WIP accumulation. When an individual or team hits one of those limits, that’s a sign of an underlying problem. Managers can trade off short-term productivity and long-run learning by adjusting the WIP limits. Tighter limits allow them to identify and fix problems in the system; a wider span leads to fewer hiccups and more short-run throughput.
4 Skunk works style
There is a whole literature of managing innovative/disruptive projects. Scott Locklin, with his signature blend of under-sourced passive-aggressive assertions and insightful contrarian perspective, mentions a particularly interesting era of innovative engineering and project management: the mid-C20 development of a guided missile as a skunk-work intrapreneurial project, headed by some character called Bill McLean. The tale is worth reading. See The Sidewinder Story / The Evolution of the AIM-9 Missile, Westrum (2013) and Lenfle (2014). Alternative angle: What an interesting way of temporarily avoiding a moral maze.
Interesting quote:
How to squelch genius according to Bill McLean:
- Coordinate work carefully to avoid duplication: Everything new can be made to look like something we have done before, or are now doing.
- Keep the check reins tight; define mission clearly; follow regulations: Nothing very new will ever get a chance to be inserted.
- Concentrate on planning and scheduling, and insist on meeting time scales: New, interesting ideas may not work and always need extra time.
- Ensure full output by rigorous adherence to scheduled workday: Don’t be late. The creative man sometimes remembers his new ideas, but delay in working on them helps to dissipate them.
- Insist that all plans go through at least three review levels before starting work. Review weeds out and filters innovation. More levels will do it faster, but three is adequate, particularly if they are protected from exposure to the enthusiasm of innovator. Insist on only written proposals.
- Optimise each component to ensure that each, separately, be as near perfect as possible: This leads to a wealth of “sacred” specifications which will be supported in the mind of the creative man by the early “believe teacher” training. He will the reject any pressure to depart from his specifications.
- Centralize as many functions as possible: This creates more review levels and cuts down on direct contact between people.
- Strive to avoid mistakes: This increases the filter action of reviews.
Coda Hale, Work is work:
Prioritise the development of force multipliers.
If an organisation is largely working on the same types of problems it was in previous years, it’s cause for concern.
Ben Reinhardt, Why does DARPA work?
Gallons of ink have been spilled describing how DARPA works1, but in a nutshell here is how DARPA works. Around 100 program managers (PMs) with ~5 year appointments create and run programs to pursue high-level visions like “actualize the idea of man-computer symbiosis.” In these programs they fund researchers at universities and both big and small companies to do research projects of different sizes. Collectively, groups working on projects are called performers. Top-level authority lies with a Director who ultimately reports to the Secretary of Defense. DARPA has an incredibly powerful model for innovation in defence research, and I believe an abstract ‘ARPA Model’ could yield similar results in other domains. In this piece I’ll explain in detail why DARPA works. I’ll use that description to feel out and describe to the best of my ability a platonic ARPA Model.
5 Solo
See time management.
6 Overruns
Related: Development hell.
Bert Hubert argues How Many Hours for Multithreading the Server?
WHY is someone asking you for such detailed estimates? Do they really care if it takes you 1 hour to do the ACLs and 120 hours to do the multi-threaded architecture or the other way around? Often the person asking you for estimates doesn’t even know what these things are!
No, a major reason why they are asking this stuff is to give you lots of rope to hang yourself with. For them, it is a big covering of asses exercise. Because if you go faster than you scheduled, it is your issue (‘this guy has been overbilling us!’). If you go slower, it is DEFINITELY your issue. If part of the project was easier, but another part was harder, it is still your problem (‘he missed the deadline for the layout demo but he mumbled something about the ACLs being ready!’).
Another major reason is that by having YOU be very detailed, it saves THEM from having to make any tough choices. You …
And this is where you turn the tables on the people with the spreadsheets.
Force THEM to commit to specific times and deliverables! If there are unanswered questions on the project (operating system? virtualised or not? database to use?), block on that. “I can’t plan unless I know what the work is!”. List ALL the things you need to know.
If they can’t answer that on the spot (and a project manager typically won’t be able to), ask them for an exact date when they CAN provide the answers.
To, appropriately enough, be continued later.
7 The simplest thing
8 Prioritisation
9 Tools
10 Incoming
- Tossed Salads And Scrumbled Egg This is some deep project management lore
- Samir Unni, Molecular Missionaries
- Spencer Greenberg, The Question Looping Process: how to build great products by asking the right questions