Project management

With special attention to speculative and innovative projects

March 23, 2021 — August 28, 2022

faster pussycat
game theory
incentive mechanisms

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.

Figure 1: My experience of project management: when the client asks you to row them somewhere and you fail to manage scope creep

1 Estimating

Figure 2: ErrantScience: are one of the few charts that are entirely made from wishful thinking

The Planning Fallacy, project over-runs, and 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 meaningfully 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 recognize 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.

Figure 3

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:

  1. Coordinate work carefully to avoid duplication: Everything new can be made to look like something we have done before, or are now doing.
  2. Keep the check reins tight; define mission clearly; follow regulations: Nothing very new will ever get a chance to be inserted.
  3. Concentrate on planning and scheduling, and insist on meeting time scales: New, interesting ideas may not work and always need extra time.
  4. 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.
  5. 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.
  6. Optimize 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.
  7. Centralize as many functions as possible: This creates more review levels and cuts down on direct contact between people.
  8. Strive to avoid mistakes: This increases the filter action of reviews.

Coda Hale, Work is work:

Prioritize the development of force multipliers.

If an organization 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 defense 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 aregues 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? virtualized 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

Is hard.

Figure 4

8 Prioritization

9 Tools

10 Incoming

11 References

Buehler, Griffin, and Ross. 1994. “Exploring the ‘Planning Fallacy’: Why People Underestimate Their Task Completion Times.” Journal of Personality and Social Psychology.
Conant. 2003. Tuxedo Park : A Wall Street Tycoon and the Secret Palace of Science That Changed the Course of World War II.
Gertner. 2013. The Idea Factory: Bell Labs and the Great Age of American Innovation.
Hiltzik. 2000. Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age.
Klug, and Bagrow. 2016. Understanding the Group Dynamics and Success of Teams.” Royal Society Open Science.
Lenfle. 2014. Toward a Genealogy of Project Management: Sidewinder and the Management of Exploratory Projects.” International Journal of Project Management.
Sornette, Maillart, and Ghezzi. 2014. How Much Is the Whole Really More Than the Sum of Its Parts? 1 ⊞ 1 = 2.5: Superlinear Productivity in Collective Group Actions.” PLoS ONE.
Vázquez, Oliveira, Dezsö, et al. 2006. Modeling Bursts and Heavy Tails in Human Dynamics.” Physical Review E.
Westrum. 2013. Sidewinder: Creative Missile Development at China Lake.