Project Narrative Arc -- Is there a "middle"?

See Paul Glen's opinion piece on Projects and the Ungrounded Middle.

There's a subtle issue here that bothers me. It's the phony narrative arc imposed on a project.

Glen says that "managers talk about beginnings and endings". This is a -- potentially -- phony narrative arc we're told to wrap around a project. Some projects are small, clear and have more-or-less definite beginnings.

Glen also says that "The beginnings are abstract and ambiguous". This is a more useful reality. The project's official "beginning" is unrelated to the conversations and decisions in which it actually began.

Details Details

The biggest issue with the imposed narrative arc is that it is a distortion of the real beginning of the project. See "Aristotle's Poetics and Project Management" The official beginning, the kick-off meeting, and the official project charter may not match the real situation as understood by accounting (in paying for the project) or the users (in having expectations) or the product owner (in prioritizing the sprints).

It's risky trying to impose a definite start and charter on a project. It's likely to be wrong; at the very least it can be misleading.

The details matter, and imposing a phony narrative arc can elide or obscure the details.

Better Practice

Background and context leading up to a project are very, very important and shouldn't be elided. While every little detail in the entire lead-up to a project isn't helpful, what is interesting is changing the concept of inception of a project.

From the first conversations, we should stop looking at all projects as discrete, unified things with a Beginning, Middle and End. Some projects may be discrete, but many software development projects will have a large backlog, numerous deliverables, constant upgrades, improvements and "maintenance" and will be a career move more than a project.

We have to realize that the very first, preliminary conversations about software involve a prioritized backlog of feature requests.

Later, when we try to impose our standard narrative framework, and have a kick-off meeting, we already understand the project as a series of sprints to build some things. The "deliverables" are ranked from most valuable to least valuable.

Don't Create a Middle

Honesty about the lack of a clear start allows us -- from the very beginning -- more latitude to rethink and re-prioritize. There is no separate moment when clarity sets in. It was always clear that the end-state was "enough" software, not "all of these features and nothing but these features". We avoid the ungrounded middle, and it's emotional low-point.

We avoid the ungrounded middle because we don't impose a phony narrative arc on the enterprise. We can be much more clear that we're involved in a sequence of sprints. We can pace ourselves for the long haul.