False Projects

In my last post (Inconvenient Truths of Project Status Reporting) I used an expression which I think deserves highlighting and explaining:

        False Projects

False projects occur when we use the word “project” for work which is not really a project. For example:

• There is no end date to the work, it goes on and on, rightly or wrongly.
• The team is not broken up, it goes on and on, rightly or wrongly, i.e. the team is not a temporary structure.
• The output of the work is not defined in advance, or might not even be defined.

Some might think I’m playing word games here but I think its important, I think we need to be clear about our terms. Please, hear me out. (This is really important when we talk about #NoProjects and #BeyondProjects. If this is a new idea to you see my Why Projects Don’t Make Sense post.)

PRINCE 2 (the UK project management standard) offers the following definition of “a project”

“A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.”

This is the definition which is most commonly violated. PRINCE 2 helpfully offers a second definition of a project:

“A management environment that is created for the purpose of delivering one or more business products according to a specified business case.”

This seems like a pretty open ended definition, none of the terminating conditions of the first, thats part of the problem. Potentially they are very different. Under this definition a false project would be a piece of work which is called “a project” but for which there is no specified business case or defined products.

Lest I be too UK centric, the American Project Management Institute offers this definition (I have highlighted the parts which concern me most):

“More specifically, what is a project?

It’s a temporary group activity designed to produce a unique product, service or result.

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.”

As with the first PRINCE 2 definition the emphasis is on an activity that ends. In this definition the team “don’t usually work together”, there comes a point when working together becomes normal.

An awful lot of software development work just doesn’t correspond to any of these definitions but we call it a project. And a lot of work - whether we call it a project or not - is managed by a Project Manager which kind of implies someone, somewhere, thinks of it as a project.

I call such work a False Project.

The problem is: when we use the language of projects - when some people assume the work conforms to one of the above definitions, specifically when they think there is an end, or a temporary arrangement - then we create a conflict. We create confusion. We create a cognitive dissonance.

When we manage a piece of work as “a project” when it isn’t then at the very least we use the wrong language and tools. Worse still we create expectations that can’t be met. Part of the #NoProjects / #BeyondProjects logic is about fixing this conflict, closing this gap.

Personally I have a little hypothesis but I don’t know how to prove it - or disprove it. If someone has employment statistics on managers, middle managers and project managers for the last 30 years we might be able to find some supporting evidence.

My hypothesis is: starting in the 1980’s middle managers became unfashionable, many of them got laid off in mass downsizings. But that doesn’t mean all the management work went away, sure some did but some remained. I suspect the growth in projects and project management stems from this time. I suspect that much of what gets called project management is in fact good old fashioned junior or middle management dressed up so it might be added back into organizations which have previously rejected middle management or want “flat hierarchies” (and other such oxymorons).