Project Contradiction Theory

So I've been talking and thinking about contradictions for a couple of weeks now. And I've come up with an idea of how we can use the idea of contradictions to focus on successful delivery of projects.

I'm going to call this idea "Project Contradiction Theory."

It's this:

The more successful you are at identifying and managing the contradictions in your project, the more successful your project is likely to be.

And this has a corrollary:

The more contradictions go unmanaged in your project, the less likely your project is likely to be.

And it also has this corollary:

The contradictions in your project are telling you where your model of the world is wrong.

I think this is a very interesting idea and I don't think I've seen it talked about much.

What I'm going to do now is list some contradictions that regularly pop up in projects. Some ways of finding more contradictions and some ways of managing them.

Some common contradictions

Let's start simple.

The project can't be done in the time required

The project can't be done with the money available

These are just "trade-off" contradictions. The way to manage them is to make them apparent, to make it apparent that a smaller scope could be delivered for whatever is the stated specific time, or the stated specific money. This idea is discussed in the Agile literature as the "Iron Triangle."

Of course, this contradiction has it's only corollary:

The sooner and more clearly this "Iron Triangle" contradiction is understood and made clear so it can be managed, the more likely it is that whoever makes it clear will be either silenced, or kicked off the project.

How this gets managed will be different in every case. What I've find to be effective is to come up with some way of counting the work that we know needs to be delivered for a particular deadline, and then some way of tracking the progress of the team through that work.

What you're trying to do by using this kind of progress tracking is involve as many of the team as possible (and the product owner) in the estimation, tracking and prediction process. By doing this, you're "dipping their hands in blood." I know, it's a nasty phrase. But what it's capturing is that you want everybody in the team to be involved in the predicition that the project won't deliver on time.

What I've yet to do, is to figure out a way of getting through predicting when a project will end without threats, recrimination and attempts to silence the bad news. So there's another contradiction:

By doing the right thing on a project, you increase the chances of getting kicked off a project.

What makes this slightly easier is that you don't want to be on a project that hasn't tackled this contradiction. Or I don't want to be, anyway. But I'm not going to pretend that this is easy. It isn't. I'm also not going to pretend that your project has much of a chance if you don't manage this contradiction.

You want to deliver your project, but there are lots of regulations stopping you from delivering your project (and you don't know what they are)

All sorts of projects are surrounded by regulation and "Non functional requirements". Government projects, financial projects, medical projects. Often, exactly what regulation, isn't clear until the project is either in its late stages, or it is actually live.

Again, the strategy for dealing with this contradiction is already known and it's a part of the Agile approach to software development - working software. But not just demonstrated working software. Working software in the hands of the users, or working software as near the hands of the uses as is possible. In general, the nearer you get to putting your working software in the hands of reals users, using real data and paying with or playing for real money, the more chance you have of flushing out non-functional requirements and regulations that you didn't know existed. Connected to this contradiction is another one:

Many non-functional requirements don't contain all (or any) requirements

They are just a process of putting a project in purgatory. Many old-fashioned "quality" checks are also only designed for "finished" products rather than early prototypes or small scope bits of working software. The way through this might not be to meet all the requirements, it might just be to show to the people who really want the software how much addressing the non-funtional requirements is costing.

There are also a whole bunch of contradictions about wanting the project.

The client really wants the project to be delivered until there's a chance it can be delivered

There's a quote that I read once in an encylopaedia of philosophy which I can't find anywhere on the internet:

"When the absolute touches the water, it becomes a fish"

Something like this happens when working software is released. When working software is release, it becomes a reality. And reality can be great, reality can pay off much more than a dream, but reality can also be terrible. Reality can make it clear that an idea was dumb. Reality can make it clear that an idea was coherent, but just doesn't pay. Reality can make clear the fatal, expensive and embarrasing flaws in and idea.

For a long time in a project, the person who is pushing the project will be lost in the dream of the project, then as the project is developed, teh person pushing the project will often complain that the project isn't being developed fast enough and isn't being delivered when it needs to be.

That doesn't stop this same person becoming, nervous and reluctant for a project to be launched when it starts to near completion. Because when the absolute touches the water and becomes a fish, who knows? Is it a shark? Is it a minnow? Is it a bucket of stinking chum?