Don’t go software first

Where do a kid’s party and a digital transformation project intersect? In that choosing the venue before picking out the theme can lead to more harm than good. 

My 5-year-old daughter recently declared she wanted a pool party for her next birthday. Putting aside the thought of screaming children running riot near 6ft of water, we agreed and put a deposit down. 

Fast forward a few weeks and she now wants her party to include lookalike actors from The Descendants and a bouncy castle. As much as I’d love to re-enact an episode of Total Wipeout, we had to remind her we’d already decided on a pool party and perhaps this wasn’t the best idea... “Oh”.

When the venue isn’t aligned with the event, there are a myriad things that can go wrong. In the case of the birthday party, we did get our deposit back. But what if that wasn’t the case? How would we go about getting insurance for a floating bouncing castle?

This (minus the water) can happen when you pick software before considering exactly what you want to do with it. Only in this scenario, cancelling the contract is unlikely to be child’s play.

Don’t jump in

Whether you’re starting from scratch, replatforming or simply looking to add to your existing platforms, it’s likely you’re inundated with options. However tempting it might be to commit to a platform, to step away from endless demos and countless chats with salespeople, it’s a risky move. 

Stop.

Ask yourself a few questions:

• What are the goals for this project? Do I actually know what I need it to do?
• What does the platform do to fulfil these goals? How do I know?
• If my requirements change, can the platform change?
• Do I have the team to run this project? Do they need upskilling?
• Have I chosen this for an easy life?
• Will a bouncy castle float in a swimming pool? 

If you are hesitating on answering any of the above, then it’s time to take stock. The worst outcome is to invest in a platform that causes more problems than it solves. 

This happened with one of our clients a few years ago. They had already decided on a CMS and had signed the contract prior to consulting with us. It was a platform we are experts in; however, they hadn’t properly matched it to their requirements.

Ultimately it meant we had to bend the system to their needs, rather than using one which fit them better to begin with. This led to more time and cost for the client – and it brings us to the question: how could they have done things differently?

What does it need to do?

Whatever challenge you are trying to overcome, you should create a formal briefing document. This should cover:

• The overview and objectives
• The scope of the project
• The challenges that may occur
• The project team
• The budget

This document does not contain the entire list of requirements. It’s a high-level description of what the project is trying to achieve.

The important step is to turn this brief into a formal list of requirements that any new platform must adhere to – at Quba we call this phase “discovery”. It is at this point that it is normally a good idea to get outside help.

We run sessions and workshops which go into great depth and fully evaluate the initial brief. It’s imperative that the correct people are involved at this stage - we always strive to get the most relevant stakeholders in these sessions. Eventually they will be the ones using the system. 

As a real-world example, very recently we ran a discovery for a company that included a warehousing element – we ensured that the people running the warehouse were interviewed so their needs were heard. Up until this point they hadn’t been considered and weren’t part of the conversation. 

These are the people on the ground that will be using the platform, so if we don’t invest the time to speak to them, it will only come back to bite us in the end.

Make a list

This effort needs to result in a document defining exactly what the platform needs to do. 

The format of the information might take different forms depending on what type of project you’re running - a backlog for Agile, a project description for Prince2, or simply a MoSCoW document. 

It’s not the format that’s key in this scenario. It’s that the right people have been asked the right questions and the requirements are all in one place.

If you think that something is missing it is perfectly fine to go back and redo parts of discovery – the cycle continues until you are content with the output. As Donald Rumsfeld once mused, there are “known unknowns”, so don’t expect to get 100% coverage. 

The project will also throw up challenges where things need to change along the way. But exposing as much as possible up front will pay dividends later.

Put them to the test

Now we have a list of what the platform should do, we can critically evaluate how our options fare against our criteria. There are a few ways to go about this, but a common technique we use is to create a matrix using the requirements and rank each platform against it. 

At a high level this will give us a score, but it is worth noting that the platform with the highest rank is not always the most appropriate. The ranking factors will need to be evaluated based on the requirements set out.

This kind of grey area is where it is useful to have a partner on hand to help, as they have done it many times before and can give an objective opinion.

See them in action

Once you have scored the platforms, and narrowed it down to two or three, make sure you see them in action. 

Vendors are well versed in demoing their software – make sure to ask to tailor it to your requirements and share the brief with them beforehand. Don’t get sucked in by deals and promises of cost reductions – evaluate it on its merits against the requirements. Money talks can come later.

You’ve got to be confident you can use the platform in the real world. A demo is a great opportunity to see how it works – we have had occasions where something looks great on paper but is then discounted because it is not what the customer is expecting.

Don’t get wet

The takeaway from all this is don’t try to put a bouncy castle in a swimming pool. Or, in other words, don’t try to shape a platform to fit your needs. 

You will need to understand your requirements before evaluating the platforms available to you, based on your insights. 

Even better, get a strategic partner involved to help you navigate these hazardous waters.