How an Information Imbalance causes painful failure in software projects

To actually deliver valuable software or websites on time and on budget can seem amazingly difficult.  The horror stories of large, enterprise and public sector IT projects that have gone disastrously wrong are often in the news.   However, even more common, I suspect, are the smaller projects that have wasted time and money and resulted in failed products or (even worse) long, drawn out suffering for everyone involved.

The scrapyard of failure
You know the kind of thing I mean: where small companies or individuals have started a software

development project with shinning eyes, dreaming of the life changing impact the planned product will bring.  Then, over months, or even years, they are dragged over the expensive, incredibly painful, burning coals of a screwed up project.

I imagine a virtual scrapyard full of the twisted, broken output from this type of project and a world full of the scarred and suffering former dreamers now looking at any software development with cynical eyes.

Its a shame; because these sorts of failed projects are totally avoidable.  There are ways and means to avoid the pain so that even when a project hits some bumps everyone walks away without the scars and not adding to that virtual scrapyard of horrors.

There are loads of buzz words to label the tools we use to guide us to success; some cover the ways to increase technical success, some how to make sure the project output brings value and some to keep the people involved smiling.  If you are thinking of things like agile development, lean startup, MVP or some of the many others then you are absolutely correct.The correct mix of these approaches is the recipe for software project success.

However, there are a few underlying pitfalls that are worth pointing out, so that you can be sure to avoid them even before getting started.

One of the biggest is an “information imbalance” and the miscommunication agonies that it causes.

What is “information imbalance”?

An information imbalance is when one party has more knowledge than the other(s) involved. For example, think of the caricature sleazy car salesmen who uses the fact that he knows much more than his buyers to rip them off.

This is one of the great changes the web is bringing; sellers who rely on that kind of information imbalance are no longer winning.  But I digress.

Information imbalance in software projects?
Perhaps the best way to understand this is with an example:

A Story
Company X has a great software idea and, because they have no in house expertise, contract a low cost developer to build it.  The developer receives a description of the software and beavers away for a while. Every so often the company asks for a written or verbal update summarising progress (perhaps getting as much as some screenshot images).  Finally the developer produces a product.  Company X is shocked at how “terrible” and incomplete the software is and they start a long process of back and forth with lists of changes trying to get somewhere near the original vision.  Both sides become more and more frustrated as time and budget disappears.  Eventually the company either scraps the project or starts to invest in a new, more expensive developer.

The information imbalance
In these types of situation one or all of the following are probably true:

  • Customer understanding incomplete: The company either did not have a clear understanding of the value their software idea would bring to the customer or they did not have a way of communicating this with the developer. Or both.
  • Business realities not communicated: The developer is not aware of time, budget or other factors and so works without regard to priorities.
  • Technical skills either lacking or applied incorrectly: 100% of the technical understanding lies with the developer.  This means that Company X is placing a huge amount of faith in them.  Opening up the possibility of abuse; where the developer intentionally misleads the Company either to cover weaknesses or to extract additional budget.  More commonly, however, this results in major communications failures where both parties misunderstand each other and the project suffers through the resulting confusion.

There is so much more that could be picked out of this short story that contributes to failure.  I maintain that the underlying issue can be seen as information imbalance.

And this is just one small example, there are many other ways that this problem manifests in different projects. It can happen with internal software development departments, with web development agencies, with outsourced development and many more. Perhaps you have experienced some of these?  Can you see the information imbalance or communication barriers?

Breaking down the information imbalance in software projects
To understand information imbalance in software projects lets simplify the knowledge and skills required into two areas:

Technical Knowledge
The specialists (the myriad different disciplines of developers, coders, creatives) who create software obviously have extensive and detailed technical skills and knowledge in order to be good at what they do.  Great technical and creative skills are vital to the success of any software project.

Business and Customer Understanding
In order to be successful all business software projects need to be closely aligned to business objectives, like in the case of Hippo’s CMMS software solution for maintenance managers.  This requires a detailed understanding of who the software is for and how it is bringing value, improving lives or achieving a goal. On top of that a clear understanding of real world imperatives, such as time constraints, budgets and the inevitable political implications with multiple stakeholders.

The problem comes when one of these areas of information is missing or when they are unequally distributed across walls of communication that prevent a flow of understanding that keeps the project balanced and on track.

Balancing for success

So how do we avoid this information imbalance?  Well, that takes us back to all the buzz words that come with good project management.  For most projects I would recommend an iterative, agile approach; though there are a thousand ways to cut that pie.  And others may have different recommendations.

However, I firmly believe that the consistent theme for success in clear, structured communication.

It is important to notice that I am not saying that everyone involved should learn to code or that the technical team should be involved in every little business decision.  Rather, you need clear information flows so that the right business, customer and technical understanding is used to keep the project on track.

In larger teams perhaps it is the role of a project manager or product owner to facilitate this flow of information (and to ensure that it is understood!). On smaller teams or with individual developers it is important for those with the technical skills to be working with a very clear business and customer focus.

Good intentions are not good enough
One final thing to note as we ride into battle against the demon of information imbalance and failed software

projects is that little word “structured” above.  Every single project, ever, in the history of projects starts out with optimism and good intentions. In order to succeed you MUST build in a communication structure that keeps things on track.  This includes feedback loops and ways of dealing with changes and problems as the project on-folds.

If you are intending an iterative approach then you must stick with all of it!  You will need discipline to make the decisions that keeps your iteration timetable.

Avoid the scrapyard
To actually deliver valuable software on time and on budget can seem amazingly difficult.  The first step to avoiding the scrapyard of failure is understand the information everyone needs and to communicate: clearly and consistently.

Leave a Reply

Your email address will not be published.