The Elephant in the room – all that time wasted trying to manage software

You know how it is.

Email. Software installations. Licences. Printers. Bloody printers. Always on the blink.

Trying to manage IT infrastructure is a massive drain.

On your time. On your sanity.

What if you could just focus on bringing value to your business?

Not wasting time sorting out trivia.

Luckily, things are getting better.

Software licences are much simpler than they used to be. Especially with the rise of cloud-based hosted software, where all access is governed by usernames and passwords.

And the fact that so much software is browser-based, or installed through an app store helps too.

But it can’t solve everything.

Look into Remote Desktop systems (both Microsoft and Apple have them) so you don’t need to hop around from desk to desk when setting things up.

And outsource it.

That way you never have to deal with another bloody malfunctioning printer again. Surely that’s worth the money!

I’ll write up exactly how to choose the right provider very soon.


Got a question about how software can help your business? Drop us a line

Why are IT projects unsuccessful?

You’re out there, hustling for your business, day after day. Putting in the hours.

You come up with a way of streamlining things.

A computer system that will:

  • Reduce time spent on mundane tasks.
  • Lower your costs.
  • Increase your revenue.

Sounds amazing.

And then you think back to the headlines.

“Yet another costly IT project failure”.

“Ballooning Costs pull the plug on flag-ship computer system”

It always seems to be the same story.

All that time and energy put into IT which could be better spent elsewhere.

But why?

What is the problem with IT?

Complexity

It’s almost impossible to comprehend how complex today’s computers and operating systems are.

The Apollo Guidance System, which controlled the missions to the moon in the 1960s and 70s, is able to perform 41 instructions per second, using less than 13000 transistors.

An iPhone 6’s central processor has 1.6 billion transistors and can perform over 3 billion instructions per second.

Think about that for a second.

The device in your pocket is billions of times more powerful than the computer that literally defined the term “rocket science”.

Now think about how complex it must be to harness that power without shooting yourself in the foot.

Communications

Because of that, when we want something building, we need to define exactly what it is we want. In some ways, NASA had it easy. The laws of physics were well understood, the physical properties of the materials they used were well understood. So in a given set of circumstances, the computer should do this. In this other set of circumstances, the computer should do that.

Compare that to your average piece of business software. The customer has sent in six angry emails in quick succession. What should the computer do? The driver has been stuck in traffic for twenty minutes so the delivery might be late. What should the computer do? Is there a set answer to these questions?

So we need tightly defined specifications – in situation A I would like the system to do X, in situation B I would like the system to do Y. And so on.

But specifications like that are very hard to write.

Partly because it’s really hard to deal with every possible scenario. NASA can afford to spend millions on designing their software. Most small businesses can not.

And also because software is intangible.

If you’re building a chair, you probably have a pretty good idea in your mind of what it’s going to end up like, even before you begin. Because you’ve sat in a thousand chairs.

But if you’re building an IT project, unique to your business, what does the end result look like? And, even if you know, how do you communicate that vision to the IT department or software development team?

So what’s the solution?

The first thing we need to do is reduce the complexity.

Focus in on what’s important.

Every time you come up with a feature, think “will it make us money? will it reduce our costs?”. If the answer to both of those is “no” then it goes on the back-burner. We’ll think about it later.

Then, take the necessary features and define them. Precisely.

What happens when things go according to plan? What’s the most likely way things will go wrong? What’s the second most likely way things will go wrong? Is there another path to achieve the same goal? Is there another path to achieve the same goal with less complexity? Why is there more than one path to the same goal? Can we eliminate one and make things simpler?

And then build your feature quickly and ship it.

Because software is intangible, it only really makes sense when you see it in front of you.

So get the bare minimum built as quickly as possible and get it out there. In front of the employees who will be using it. In front of your most trusted customers to get their feedback.

Because once it’s in front of people, they’ll see the flaws that you missed and, just as importantly, the better future, the possibilities that the project opens up.

And it will change direction. Inevitably.

So don’t invest too much beforehand – concentrate on one feature, plan it out in detail, then build it and ship it.

Once the dust has settled from that, decide on your next feature, plan it out in detail, build it and ship it.

Reduce the complexity. Focus on revenue. Get feedback as early as possible. And your IT project will be a success.


Get free advice and tips on using IT to reduce your costs and increase your revenue – sign up here

The story behind EchoDek’s 7 day software

The trouble with getting a software project built is that they’re always late and they always go over budget.

Wouldn’t it be great if you could be sure that what you were getting was what you asked for and it was going to be delivered on time?

After 20 years working as a commercial software developer, I hit a rough point with an existing client whose project I had been working on for three years. We both knew why the system wasn’t working as it should (3rd parties involved with blame all round) and I wanted them to rewrite the whole thing; they were scared about the cost and potential for overruns, given the amount that they had already sunk into the project.

So I said “let me take Feature X and I’ll rebuild it in a week”. They agreed – because a week’s worth of work is practically no risk for them. I stripped the feature down to its pure essentials and by the next Monday they had something they could take to their customers and start selling. They immediately bought a second week to add some niceties and finishing touches to the administration side of things.

Since then I’ve followed the same pattern on other work that’s come my way – find out which part of the project will actually make money and concentrate on specifying, building and shipping that; no frills, no niceties, just the essential feature to get the job done.

It’s better for me and the developers, as we get to work on well-specified projects with a fixed scope but more importantly it’s low risk for the customer; they know what they are getting, what it’s going to cost and when it’s going to be delivered.

And so I thought I’d launch it as a standalone service.

Presenting 7-day Software from EchoDek https://clientrobot.com/.
On-spec, on-budget and on-time.


Get free advice and tips on using IT to reduce your costs and increase your revenue – sign up here

You know your problem? You do too much…

I’ve been a professional software developer for twenty years now.

There’s been one idea I’ve been reading about for about fifteen of those years, but it’s only in the last couple that it’s really come home to me how important it is.

And it’s really, really simple.

How can you make it smaller?

The feature that the client is asking for … what can you take away?

Does it look like a complex piece of work? Well, which pieces can we leave out?

Does it reduce the client’s costs? No? Then get rid.

Does it earn the client more money? No? Then drop it.

An example: we had an issue where we found a loophole in a piece of software – the customer could pay for a piece of work, use it, then cancel the work and they would be refunded their cost – even though they had already made use of it.

The client proposed a series of changes; notifications during use, tracking what the customer was doing, logs of exact times and usage levels.

I said “how about … we don’t let them cancel their own projects?”

The desired end result was to make sure that they didn’t get refunded for work they should have paid for.

The root cause was that if they cancelled the work we had no log of what they had actually used.

Instead of treating the symptom, we dealt with the cause. And suddenly, two weeks of work was reduced to less than an hour. A deadline that we were going to miss became easily achievable.

So, whenever a client proposes something, just think “what’s the problem here? And what’s the simplest solution to it?”

And how can I make it smaller?


Get free advice and tips on using IT to reduce your costs and increase your revenue – sign up here