0845 568 5000 hello@whitecobalt.com

How to make sure software projects meet expectations

For more than 20 years now, I have been delivering software projects. On top of those I have been directly involved with, I’ve been in a position to observe dozens more.

Too often, I’ve seen these projects fail to deliver on the expectations of the client, or don’t deliver the real-world, commercial benefits they could have. Even though the software itself fulfilled its requirements, and the people involved were competent and motivated.

If you have tried to implement software in your business, you will probably have experienced this to some extent.

Since starting White Cobalt, I have focused on analysing these past projects and identifying the problems and their solutions, then incorporating that understanding into our approach. In my experience, these are the major pitfalls:

The ‘one-size-fits-all’ problem

It doesn’t.
Every business is different.

Even if your company delivers broadly the same service or product as your competitors, how you go about it behind the scenes will be different. You have different people, different strengths and a different approach. You will run your business and organise your team the way you want to.

The problem with any off-the-shelf solution is that it cannot accommodate these differences, and so it is designed to cover the lowest common denominator. The systems which promise flexibility and endless configuration options might be a step better, but they must still compromise to cater for a broad section of the market.

At best, an off-the-shelf solution will provide a series of tools to help your team, but how those tools are used (the workflow) will still be down to your staff. Updating the software becomes another admin task, another step in the workflow, instead of being the solution that reduces the work they must do.

The only solution is to build your own software, tailored to the needs of your business.

The ‘ideal world’ problem

Every job runs perfectly every time, doesn’t it?
Of course not.

Deliveries are late, people go off sick, your best customer wants something special, and you want to accommodate them. There are a hundred reasons why you might wish to make minor adjustments in your workflow for a particular job.

Unfortunately, most software is rigid; designed to take the same inputs and produce the same outputs each time, following the defined process.

The art is to allow the user the flexibility to make minor deviations from the process, in a controlled manner, without having to totally circumvent the system. So, your team can have flexibility when they need to, without totally disrupting your business’ workflow.

The ‘static requirements’ problem

A healthy business is never at a standstill; it is continuously growing, learning and evolving. And so, the requirements for your software will constantly be changing too.

But yet I still see companies treating software as a static thing; something they can define, buy, implement and then move on. Such projects are rarely finished quickly, in a small business the requirements are often out-of-date before the solution is implemented. Moreover, documenting the requirements for an entire business, in sufficient detail, at the start of the project is nigh-on impossible, and in my experience folly to try.

It is much better to approach this as a journey, not a destination. A process focused on continuous improvement of your systems, delivered as a stream of interlinked micro-projects, progressively digitising and improving your business’ operations.

The ‘disruption’ problem

You have a busy office, a pile of work in progress, existing systems full of important data, and a team set in their ways. You can’t just stop everything for the sake of putting in some new software, and you’re probably thinking you don’t have the capacity to focus on implementing such a change even if you wanted to.

And you’re right.

Trying to implement a major software change all in one go will result in a tremendous amount of stress and disruption to your business.

So, don’t. Do it gradually instead.

Truthfully, there will always be some burden on your team, but by delivering the solution progressively and in small stages, we can minimise the impact. It also gives your team time to adapt, and feed into the process, then because they helped refine the outcome; they will buy into the project.

The ‘lead time’ problem

Things tend to happen fast in small businesses. The ability to react and be nimble is one of the few advantages you have over larger companies.

But if it takes months to change your software, you lose that ability, and by the time updates are delivered, the opportunity could be lost.

Much like other problems I’ve outlined above, the solution is to embrace a process of continuous improvement. So there is already an infrastructure for the delivery of change – on both sides of the relationship. Plus, adaptability will be ‘baked into’ the architecture of the software from the start.

So, delivering change, and quickly, becomes business as usual.

We have embraced the lessons in these experiences; they are at the core of our approach. We understand that technology must align with your business needs, enable and empower your team and be flexible and adaptable to grow with your business.

If you’d like to know more about how we can help your business, we’d be delighted to talk to you.

Steve Stovold

More insights

Get in touch to discover how your business can thrive with our Digital Transformation as a Service.