Software Development (Auckland Edition)

How to stay on budget, on time and actually get people to use the software!

Are you thinking about developing a custom piece of software? Where do you start? Will it ever finish? What will it look like when it is done?

The story we hear all the time from companies who have gone down the software development path is that it ran over budget, took six months too long and then, when it came about, it was like trying to feed a child cod liver oil to get them to embrace it!

Sadly, this story covers the majority not the minority of projects.

As a business recognises a clear problem or roadblock in their business that could be solved by a piece of custom or licensable software, they go through tried and true processes that seem to give the same result.

A poor one.

In this article, I want to:

• Dispel the myths that this is the only way to develop software.
• Suggest tips on how to mitigate these problems.
• Get your team to take on the software as if they had developed it themselves.

Some of these tips are not rocket science; others may alter your perspective (which is a good thing). You may even notice that you already know some. As a developer, I do like order so I have broken them down into smaller digestible chunks below.

Enjoy.

Start with conversations, not instructions.

‘New Software Roll Out: June 17, computers will be down for two hours’ the subject line reads. James read as he got into work on Monday.

He was first hearing about a new piece of technology that was supposed to make his life better… for the first time.

The instructions read ‘A training session will be held on June 20th to go over how to use the software’

As he read, scepticism came over him. This was the third rollout of software in the last year and the last two had been disasters. He felt that he and his colleagues were being spoken to like children in a dictatorship.

Now you may feel my words are harsh or they do not apply to you. But they do. When trying to do something helpful for a business, it is easy to forget about the people at the bottom. The ones that actually will be using the tool.

You think that a little bit of user acceptance testing here and there covers this off…. However, it does not.

Software these days is a way of life, something that makes or breaks your work life. It can make staff more productive or send them into a spiral of confusion.

Companies I have seen doing software well, know that it is important to bring staff in at the Why stage.

Explain early what you want to achieve, ask for feedback before you even write the development brief.

Getting staff involved early on means that, when the software is launched, they feel like they were part of the development and the introduction. They put their money on the table and buy in.

It does not have to be hard. It involves a few internal communication emails, a feedback survey and actually responding to them.

It involves effort.

Speaking with a software project manager they said ‘I love developing software’ but when it comes to getting people to use it, it is like pulling hen’s teeth. People are naturally averse to change. When change is thrown on them and demanded, they rebel. Getting the involvement stage wrong can lead to expensive projects being thrown away.

So what can you do differently? What are you going to commit to on your next project?

Whether you are a team of five or a hundred forget the little guy at your own peril.

Software is a journey, not an end goal.

You would have heard a similar thing about websites. How Google likes to see ‘living websites’ not static pages. It loves blog posts, new information and the journey of your website.

The same is true in software. In the early years in Auckland, developers would sit down with a client, write a 40-page brief document covering every risk, problem and pain, and then sit down for a month and start developing.

Every minor adjustment would be out of scope. You would get another invoice and the timeline would get pushed.

Software development was static.

By the time the project actually rolled out, it may have even been obsolete or in need of more work to get it useable. It was frustrating.

Currently, the idea of an agile process has really come on.

Especially for smaller companies in the sub-hundred staff sector.

Here is the way we do it. You will be able to take what you want to use in your software process.

• Start with a vision
  What is the problem you are trying to solve? What does it look like? What result does it need to give you? Where do you see it going in five years in a perfect world? Get very clear on the vision of your brief and do not be scared to dream. List every feature you can think of. I find that post-it are great for this. This is also a great time to involve your staff in the process.
• Choose a platform
  The cloud has changed how developers and companies should operate. We have never had so much integration and cloud-based starting points. Finding a platform that is malleable for your software is key. Picking one that is growing all the time and adding features is a starting point that will keep your budget down, speed up development and allow you to move quicker.
• Create broad stages
  Look at your vision and break it down into stages. Group together features that give a specific result. You are better to release a smaller stage one then be stuck waiting for the perfection of an end-to-end software solution that is never delivered. It allows you to break your costs into stages as well as to make it a much more budget conscious build that works with your cash flow.
• Get visible
  A good developer or development house should have a project management tool that allows you to track what is happening, gives feedback as it happens and works closely with you delivering the features you require. The old way used to lead to a delivered software that may not have even worked. Sometimes in practice, a software just does not work. Being involved in a feature-by-feature development means that you know what you are getting and you have helped to guide the project actively.
• Set an ongoing budget
  As your project is delivered, changes will be constant. Improvements and other things you didn’t even know to think about can only be learned while operating. If you are setup correctly, these changes can be swift and agile. We usually suggest a set monthly budget for changes. Once working, the system can constantly be refined and improved to meet your changing needs. Remember it is alive, not static.

Now I could write about this all day long. However, I do not want to bore you too much! Let’s finish off with a case study.

A client of ours came to us with a muddle of spreadsheets, forms and documents. They had been getting by for years on them in various forms. Then they realised that it was getting harder and harder the busier they got.

They were in the in-store tasting business – helping take great food and drink brands and getting them into the mouths of consumers in supermarkets (and the like).

The key users were clients (the product owners), admin (the ones keeping the machine moving) and staff (the people who did the tastings).

We sat down and did a whiteboard session on what this system could look like. The big 5-year vision, all the way down to individual features that it could have. It was a long list.

We then took it a step back and asked what would be the first step that could make a measurable difference.

They had one key spreadsheet that each client had that ran a big chunk of the business.

We mapped it out on what it would look like, what each user type would see and made the call that this was stage one of the custom software development.

We picked a piece of software that would create a flexible and scalable system and we were off.

Loading all the stages into our project management system, being clear on the key features and allowing for live feedback from our client was key.

Within six weeks the first stage was live and being tested by the team (which had been part of the development from the start). They loved it!

What a game changer even at this stage.

Were there bugs? Always.

Could things be better? No doubt.

Had new features been dreamed up? You bet.

We had a workable solution able to be tested live. For the next three months, we used the monthly budget to make improvements, refinements and additions.

Every week the system improved. It was a fun experience, which did not break the bank and was delivered on time to the expectations set at the beginning.

That is how software should be in our opinion.

I hope this has given you some insight into how to start developing your own business software. When working it will save you hours, add a tangible asset to your company and make your staff smile.

To your success.