Thanks, But No Thanks
When it comes down to it, the primary function of management is to allocate finite org resources to efforts that will subsequently increase revenues and/or decrease costs. By resources, I mean people and money (for salaries, materials, tools, training, etc) and time.
Since projects vary wildly in complexity/importance/size, required skill-sets, and they (should) have end points, correctly allocating resources to, and amongst, projects is a huge challenge. Both over and under allocation of resources can threaten the financial viability of the org and, thus, everyone within it. Under-allocation can lead to a stagnant product/service portfolio and over-allocation can lead to an expensive product/service portfolio. Note that either under or over allocation can produce individual project failures.
To correctly allocate resources to projects, especially the “human resources“, some things must be semi-known about them. Besides desired outcomes and required execution skills, project parameters like size and/or complexity should be estimated to some level of granularity. That’s why, for the most part, I think the #noestimates and #noprojects people are full of bullocks. Like agile coaches, they mean well and their Utopian ideas sound enticing. Thanks, but no thanks.
I think the #NoProjects people have something of an idea but went all baby/bathwater on us. Too much of a focus on projects does harm end users (and the relationship between them and their IT providers) – people use products, not projects. The product produced by a project lives after the project is over and that fact is often overlooked. That being said, a product’s lifetime is, in my experience (in-house IT), a collection of projects. Just because they’re not the most important thing doesn’t mean they’re not an important thing (unless you’re running a pure flow process where the lifetime is nothing but a continuous stream of changes and additions).
As for the #NoEstimates crowd, I think they really want to do away with estimates but can’t commit because they realize how ludicrous that is for so many contexts. As such, they either come off as trolls or confused.
I think of projects as more abstract than products. A project can end with a new product, an improvement to an existing product, a process improvement/change, an IR&D prototype, a tool procurement/installation/training, etc..
Exactly…a project is an activity around the thing, not the thing itself. If you go to a contractor to build a house, you’re ultimately interested in the house, not the building of it.