Project Managing Conceptual Labor
Managing the lifecycle of development projects - as well as other open-ended creative endeavors — tends to be an act of wishful thinking more than "planning". How can we do better at this?
Still growingYour team is people, averaging a salary of per person. Add % for overhead and profit. You are able to schedule/sell blobs of time per year per team member, each working per week. That means that you're gross target per year is 675000. So, 3 people working 720 blobs, targeting a gross income of 675000, means billing at 937.5 $/blob. A "Big" project at your agency is about hours — 50 blobs — and takes in 46875. With people on a project, this puts the calendar time at about 4.166666666666667* weeks. This is a price!
* Caveats apply! This relationship is only so linear.
Below is a rough collection of notes that led to above, functionally unreadable.
A functional unit of project management is the “blob” (or “cell” in Taylor’s formulation). A Blob is a 4-ish hour chunk of uninterrupted time in which about 3 hours of billable work gets done. In my estimation, a career could be built on scheduling or selling 250 blobs per year at 5 to 6 blobs per week, each blob billed at a target gross rate.
Blobs must end at a stable state which is documented and accounted for, ideally with some sort of useful artifact. Blobs are expensive!
Conceptual Labor is fundamentally un-estimatable, and the really valuable work that we do tends to be conceptual labor. This means billing as-you-go and working to create a spare where the remaining work is no longer conceptual labor and can be estimated.
Writing comprehensive “behavior sheets” or specs is a good way to front-load the conceptual labor in a project, and as a plus they can be turned into test suites pretty easily. Writing these is – of course – conceptual labor and cannot be estimated.
As an aside, Taylor has found that a really robust spec takes about 1/3 of the total time of a project, which could be a neat estimating tactic.
Taylorism (different Taylor) is not a bad impulse when applied to our work, and separated from the dehumanizing goals of capital. Measuring, systematizing, and creating a library of of-the-shelf solutions helps provide a service.
Plan more than just your work in blobs! Assume 3 blobs per day, and fill with whatever; side projects, art, family, and personal time.
When pitching projects that include conceptual labor, do not pitch result X by date Y for price Z: Someone is going to get fucked on that deal. Figure out a different deal.
One of those something else is systematized, off the shelf solutions. I worked towards this deal at Fuzzco, working on e-commerce sites for small businesses. This removes as much conceptual labor from the project as possible by re-using the results from other, previously completed works of conceptual labor. This means you can solve the same hard problem many times, but still falls down on solving a radically new problem.
Another something else is to make a very different kind of deal. If working in-house, this means letting go of predictability and focusing on exploratory blobs with stable states. Follow them where they go. Don’t worry about what or when, just make sure that there is conceptual integrity, clear proprieties, and let ‘em rip.
If working client-side, this means working pay-go with docs for a desired solution, and letting go of implementation.
The important thing about this number of billable blobs per person is that it wont burn out your team. It accounts for generous PTO and sick leave, and will create more space for better work.
Notes on Process
At any given moment in a process, we have a certain partially evolved state of a structure. This state is described by the wholeness: the system of centers, and their relative nesting and degrees of life.
A. In a software project, the structure is the complete system that runs, and the humans who run and interact with the inputs and outputs. Centers are localities of coherence within this structure – behaviors, code modules, etc etc.
We pay attention as profoundly as possible to this wholeness—its global, large-scale order, both actual and latent.
A. Understanding the entire experience of your system, how its working and how it could be working.
- We try to identify the sense in which this structure is weakest as a whole, weakest in its coherence as a whole, most deeply lacking in feeling.
We look for the latent centers in the whole. These are not those centers which are robust and exist strongly already; rather, they are centers which are dimly present in a weak form, but which seem to us to contribute to or cause the current absence of life in the whole.
We then choose one of these latent centers to work on. It may be a large center, or middle-sized, or small.
We use one or more of the fifteen structure-preserving transformations, singly or in combination, to differentiate and strengthen the structure in its wholeness.
As a result of the differentiation which occurs, new centers are born. The extent of the fifteen properties which accompany creation of new centers will also take place.
In particular we shall have increased the strength of certain larger centers; we shall also have increased the strength of parallel centers; and we shall also have increased the strength of smaller centers. As a whole, the structure will now, as a result of this differentiation, be stronger and have more coherence and definition as a living structure.
We test to make sure that this is actually so, and that the presumed increase of life has actually taken place.
We also test that what we have done is the simplest differentiation possible, to accomplish this goal in respect of the center that is under development.
When complete, we go back to the beginning of the cycle, and apply the same process again.