A proven tip to prevent small project failures

Data, technology and innovation projects fail all the time.

Large scale programs have project management teams and processes to help.

If you do not have those resources, well meaning assumptions, inexperience or lack of either domain or technical knowledge, can easily derail a project.

If you’re either commissioning or delivering a small scale tech project, here is a proven tip that will ensure everyone sees the project as a success.

 

Failed projects.

Failure in small technical projects can be either technical or at the human level.

Sadly the latter is much common and more damaging.

Whether they are external or internal projects, previously great relationships can end up destroyed by a failed project.

All subsequent contact (if there is any) fuelled by suspicion, mistrust and claims of incompetence.

People become scarred. They become hardened. They become determined never to let it happen again.

I’ve even heard one guy say it “almost ended [his] life.”

Truly, I hope he was exaggerating.

The point: Failed projects are a BIG deal for people.

 

So, how can this be avoided?

Firstly, it is my belief that no-one sets out to work on a failed project.

People have the best of intentions and want success.

However, what is “obvious” to one side, is not always to the other.

It is this misunderstanding we aim to tackle.

 

What is a successful project anyway?

Well, the people commissioning the project want their problem solved.

The people delivering the project want to create a great solution.

Simple.

Except it’s not.

Look again.

The people commissioning the project and those delivering the project don’t have the same goals.

Whilst they are certainly complimentary, well meaning and with the best of intentions, they are not the same.

It is subtle but critical.

You see whilst the commissioning people see the “real” problem as solving their immediate issue, the delivery people see the “real” problem as the technical challenge.

This cartoon (called the General Problem) sums it up nicely.

The person you can see is commissioning the “project.”

They want to enjoy their food more than they currently are.

They decide salt will help so commission the project.

They ask the delivery team for the salt.

The delivery team hear’s the request, probably nods and says “OK”, then goes into action.

The commissioning person is left in the dark as to what’s going on.

The delivery team are solving a complex technical problem.

It is taking time.

The commissioning person becomes frustrated.

There is confusion.

A confrontation.

The project fails.

The issue here is that NEITHER side are taking charge to clarify the project requirements.

Both assume that is the others responsibly.

In practise, I’ve seen people get very militant about this.

It is a shame as a it can easily be avoided.

 

What is really going on?

So the project actually fails in the second picture – the one where nothing is going on.

This is where no one is talking.

By the time we get to the third picture it is too late.

It might be interesting to explain what I believe both sides are thinking here, especially on the delivery side for those who class themselves as “non-techies.”

The commissioning people are really confused. What is so difficult about passing the salt? Especially for such a delivery expert?

The delivery side see the challenge slightly differently. They’ve been here before. Of course they know how to pass the salt quickly. However, they’re likely thinking two other things:

1- They feel that as soon as commissioning person gets the salt and tries it, they will change their mind. “Oh, can you now pass me the pepper?” The delivery team want to be prepared for that. They realise the commissioning person doesn’t really know what they want. They’re just trying salt. For delivery people there is nothing worse than asking them to do the same thing twice. Therefore they’re trying produce a more generalised solution as it makes their life easier to cope with changes, even though that’s not what they’ve specifically been asked for.

2- They feel that simply passing the salt is too trivial (maybe to warrant their fee?) They’re afraid they might get “found out” if another delivery expert comes along later and looks at what they’ve done. They fear a ruined reputation and of having their core principals and values questioned. No-one likes to be conned or accused of being an imposter. As professionals they therefore need to be able to look themselves in the mirror and know they did the best job possible.

I’m not sure if that sounds far fetched? I don’t believe it is.

The point is the delivery guys are focused on the technical implications. The commissioning people on what the project enables.

Neither daring to question.

Both assuming (the best actually.)

 

Whats the solution?

The underlying issue here is obviously about clearly communicated requirements.

My tip comes in the form of a simple question:

“If we built/did/produced this, is that success for you?”

Using this question forces communication at the right level for both sides.

Implicit is that there is a clarification of understanding through action.

It is not a nod. Yes I understand.

It is proof of understanding and clarification of requirements through active demonstration and discussion.

It is actually what everyone needs but seldom properly ask for until it is too late, especially on smaller projects.

By asking this constantly and right from the very initial meetings, it is good for all.

The delivery team are forced to communicate something tangible, representative and appropriate. Even if it doesn’t “work” yet.

The commissioning team are forced to decide and give specific feedback. Even if they’d not thought about things quite like that before.

This helps set expectations, build trust and cement what success looks like.

 

Not my job?

Personally I’d say the onus falls on the delivery side to lead this.

However.

If they’re not doing it, those commissioning the project must take charge.

This is the failure in the cartoon.

Do not assume the delivery guys are producing the right thing.

If the delivery guys are not asking this question, then get them too.

There is clear benefit for both sides:

The delivery guys won’t invest a Herculean effort pulling something together that the commissioning team will dismiss. They get clear, cemented requirements and clear measures of project success.

The commissioning guys get a chance to clarify and refine the solutions proposed by the delivery team early. They get to see tangible work-in-progress, understand delivery team thinking and decide direction.

Success for all.

 

It does take trust.

To do this most effectively takes trust and acceptance of each others goals.

Those responsible for delivery will get it “wrong.”

Those commissioning will change their mind.

That’s the point.

You’re not looking to change fundamental truths.

You’re proactively tackling them together.

Just like the best high-performing teams, you’re building your relationships, finding solutions and working together through the compromises.

This question will consistently unearth misunderstandings and poor assumptions.

It will enable you to correct early and correct often.

It’s crazy simple but it really does work.

Ask this question regularly and everyone benefits.

Now and on all future projects.