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).

Inconvenient Truths of Project Status Reporting

Long time readers of this blog may recall that I subscribe to the high-brow MIT Sloan Management Review. They may also remember that I’m never quite sure it is worth the rather high subscription fee. But once in a while an article comes along which is worth a year’s subscription. The “Pitfalls of Project Status Reporting” is this year’s article.

As the title suggests the article looks at why project status reporting, specifically for IT projects, so often fails to alert companies of the problems in project work. (Clearly the authors are unfamiliar with #BeyondProjects/#NoProjects but I suspect most of the same problems can be found in the false-projects so beloved of IT organizations.)

If you want the full story you will need to buy your own copy of the article (Amazon have it for £2.50) but for the rest of you here are the highlights, the 5 points the authors called “Inconvenient Truths” plus some of the text and a couple comments from from myself. The comments are all my own but the quotes - and the headlines in bold - are from the article which is research not conjecture, something we could do we more of!

1. Executives can’t rely on project staff and other employees to accurately report project status information and to speak up when they see problems.

“[software project managers] write biased reports 60% if the time and that their bias is more than twice as likely to be optimistic.”

Basically people don’t like reporting bad news and worry that reporting it will reflect badly on themselves.

2. A variety of reasons can cause people to misreport about project status; individual personality traits, work climate and cultural norms can all play a role.

“employees who work in climates that support self-interested behaviour are more likely to misreport than employees who work in climates based on ‘rules and code’.” Why do I think of banks and bonuses when I read this?

3. An aggressive audit team can’t counter the effects of project status misreporting and withholding of information by project staff.

“Once auditors are added to the mix… a dysfunctional cycle that results in even less openness regarding status information.”

“Diminished trust in the senior executive who controlled their project was associated with an increase in misreporting.”

More reporting will make things worse, if auditors arrive then people don’t feel they are trusted and guess what? They might not show the auditors the dirty washing and might tend to paint things as good.

4. Putting a senior executive in charge of a project may increase misreporting.

“research suggests that the stronger the power of the sponsor or the project leader, the less inclined subordinates are to report accurately.”

I find this suggestion very worrying because some people in the Scrum community insist that the Product Owner must be an executive (“the real product owner”) who has real power to secure the resources and changes a make the project a success. This research suggests that having a strong, senior, Product Owner could make things worse.

5. Executives often ignore bad news if they receive it.

I am reminded of one client where my own attempts to raise a red flag have gone no-where. On my final visit to the client I spoke with the senior architect to again voice both my concerns over the work and the failure of anyone to listen. Unfortunately he had the same problem. He saw the same problems but couldn’t find anyone willing to listen.

My initial thought on all of this is that this is all the more reason to base reporting on deliverables, i.e. what has actually been delivered that is working and in use, that is rather than reporting on proxy “status” criteria, report actual progress, actual deliverables.

Xanpan official, the end of the beginning?

This blog post marks the official release of “Xanpan: Team Centric Agile Software Development”.

You can now buy:

• Xanpan electronic version from LeanPub with free updates.
• Xanpan printed version from Lulu which includes a code for free electronic copy of from LeanPub, which in turn entitles you to a free electronic updates.

A book I never set out to write. A book I’m glad I’ve written. A book which has been very different to write than my previous books.

I say this is the official release because:

• I don’t intend to revisit this manuscript for a while: although I’m already eyeing a small title change and I’ve found one small error to correct this morning.
• The printed version of the book is now available to buy.
• I need to stop fiddling with this material to move onto new material.

I’ve also updated the website for Xanpan (xanpan.org) with excerpts and such.

Until now the book was entirely a LeanPub effort, that meant I could sell the book and push out changes quite easily. But once I accepted that this was a book I decided it also needs a physical manifestation. I’ve used Lulu for several small projects in the past and they seemed a natural choice - particularly since LeanPub provide a couple of small features to make moving to Lulu easier.

But, once you start doing physical copies the cost of changes increase, you start to encounter batch processing and one time activities (e.g. reviews and ISBN numbers) and incremental change becomes slower and possibly more difficult.

Although one advantage of Lulu over LeanPub is that Lulu has a review system - and there are already several Xanpan reviews posted. (Post script: Johnny Graber has posted a review of Xanpan on his blog.)

Neither version is yet available through regular bookshops, specifically Amazon. Once you start doing that more options close down.

More importantly there are some new essays I want to include under the Xanpan umbrella, topics I think need to be discussed. While I could simply add them to this volume I want to change my focus and to do that I think it will help to have a different target in mind.

Hence I’ve started work on “Xanpan volume 2: Management Heuristics”. This also means that at some time in the future I’ll rename this volume “Xanpan volume 1: Team Centric Agile Software Development.”

So, consider the current publication as a Stable Intermediate Form. No promises on when any of Xanpan2 will be available but if you would like to follow progress sign up on LeanPub.