As I’ve mentioned previously, the most obvious reason to develop bespoke software is that you have a requirement that isn’t fulfilled by any package that is available. However, there are a couple of subtle refinements to this argument.
Firstly, there may well be software that is available to you but either it doesn’t work in quite the way you want it to or perhaps it is too complex. Last year we took on a client who was paying £14,000 per annum for a package that handled their e-commerce and stock management. They had decided to put a budget of £28,000 towards a bespoke solution on the basis that they would be saving money after two years. When we saw the feature rich package we made it clear that we could not duplicate all the functionality we were seeing for the budget available but the client quickly put us straight: they only wanted about a third of the functionality but they wanted it to work in a way that made sense to them and the way they worked.
And this brings me on to the second refinement. Typically, in any location, there will be many companies operating in the same sector and some of these will be more successful than others. This may be down to crude distinctions such as cost but over time the biggest differentiator will be down to the way in which each company operates and interfaces with its clients/customers and suppliers. For some elements of that business – payroll, for example – the software that is used will make no difference to a third party’s experience with the company. However, the software that is part of the process is a different matter entirely.
Over the next few days I will put up three posts that detail case studies that I believe illuminate the point that I am making here. However, here are a few indicators that will show if you could benefit from bespoke software.
1. You find you are entering the same data in multiple locations. Many mature companies with quite sophisticated processes find themselves using multiple spreadsheets or a number of software packages. This means the same data needs to be entered in multiple locations and if that data should change, then someone needs to know all the places that it needs updating.
2. Your processes are very ‘paper driven’. It repeatedly surprises me just how far companies can get with almost completely paper-based systems. These can work well until a piece of paper is mislaid or, worse, there is an incident such as a fire, which completely destroys the system. Goods and property can be insured but data is irreplaceable if it is not kept safe and backed up. All our software is web-based and all our clients’ data is backed up every day.
3. Your processes rely on your staff knowing them. That might sound obvious – of course your staff need to know what they’re doing - but there is not only a training overhead involved here, it also means your staff are less flexible and less able to cover for one another. A good IT system should reflect the way your business works and so your processes should be implicit in your software. A package will dictate that process and impose it on your business.
4. You want to share data with your clients. But not all your data, of course. Web-based bespoke software enables your clients to log on to your website and see their data: orders, statements et cetera. This cuts down on calls to your staff.
Ultimately, well-written bespoke software should provide huge benefits and give a great boost to your company. Your day to day business should run like clockwork, with happier clients and customers, less stressed and more flexible staff, who will be free to concentrate on their jobs and not administration. What’s more, having all this operational data in once place provides enormous opportunities for extracting highly valuable management information about the way your company is running.
Saturday 25 April 2009
Monday 13 April 2009
So, what's the point?
I started a limited company - Meantime IT - in 1991. Initially, it was simply a vehicle for my freelance work with a number of blue chip companies and I was the sole employee. However, in the mid-nineties my brother, Warren, and I became interested in the emerging Internet platform and started developing websites. However, we were both frustrated by the limitations of the medium and continued with our day jobs while working on those sites in our spare time.
As the web became more viable as a platform, we planned to make web development our full time occupation but then Warren went to work for Goldman Sachs and I went on to work for the Royal Bank of Scotland, managing the testing of the first 'thin client' version of their Internet Banking software. In 2004 I finally took the plunge and Meantime IT has been running as a software house, working exclusively on the web since then.
However, there is a major difference between working as a limited company to facilitate freelance IT and running an SME out in the real world: as a freelancer there are plenty of agencies out there, taking requirements from their blue chip clients and matching them up with the CVs they take in from contractors. For an SME, especially in today's economic climate, things are a little different. It's one challenge to put together a company that can successfully deliver working IT systems but we also need to tell people about it. Hence, this blog was suggested as part of our marketing strategy and, after my initial reservations, it occurred to me that this would also be a good place to lay out the conclusions of some of our discussions at Meantime.
So, that's the point of the blog but maybe this inaugural posting would be a good place to also ask what's the point of IT? It is a big question but, for further postings to make sense, I think it's one that needs to be asked up front. To be clear, I want to break IT into two categories. (Like many black and white statements, it won't bear close scrutiny but in such a complex world as IT, I'm going to need to take a few shortcuts.)
Firstly, there are packages. I'm using this term to define any software that is built by a company and then released to a target audience. I'm not suggesting there won't have been market research or that the software won't be configurable. Examples of this would include Microsoft Word, Apple's iTunes, Intuit's Quickbooks and Twitter.
Secondly, there is bespoke software, which is what we build at Meantime. This is software that is built for a client to their specification (and the variability in those specifications will be the topic of a future posting). It is really this second category that earns IT a bad name. People may grumble about new releases of package software - Vista is a good example of this - but, by and large, they will work as the authoring company intended. The failing projects that make the news - e.g. apparently anything that is built for the National Health Service - all involve bespoke solutions.
So, if the package solutions work, what is the point of bespoke software? Package solutions do indeed work perfectly when you have a generic requirement and everyone is happy with the same solution. iTunes and Microsoft Word are both good examples of this, as evidenced by the fact that both have made it across a partisan divide: iTunes onto the PC and Word onto the Mac. Even in the world of business, we see package solutions that work but already there is more variation as people buy solutions that are geared up to their size of business and their sector.
The key here is that if you use a package solution for a particular process then you will be carrying out that process in the same way as everyone else who uses that package. This is fine for, say, your payroll but what about those processes that help distinguish your company from the competition? Or what if you have a requirement that is quite specific and, therefore, the target market is too small to warrant a package, so no one has built one?
The key point here is that there is a strong market for bespoke software: people do want and need it. The problem is that so often what is delivered is often very flawed. Common problems include:
We have seen four decades of development of IT systems yet these problems have never been resolved. There are many books, seminars and theories all circulated which purport to solve the issues and yet matters never seem to improve. I believe that the underlying contributing problems are simple to understand and over the last five years, Meantime has successfully delivered projects that match our clients' requirements, on time and on budget. That is not to say that we haven't had challenging projects, too, and those occasions have only served to demonstrate that the processes to which we usually adhere are absolutely essential.
There is no secret ingredient, no single process that we have up our sleeves. The methods, processes and procedures we utilise require work that many companies and, crucially, developers do not wish to adopt. I will be outlining all of them in future posts, highlighting the perils of ignoring them with examples from industry and, no doubt, the day's papers.
As the web became more viable as a platform, we planned to make web development our full time occupation but then Warren went to work for Goldman Sachs and I went on to work for the Royal Bank of Scotland, managing the testing of the first 'thin client' version of their Internet Banking software. In 2004 I finally took the plunge and Meantime IT has been running as a software house, working exclusively on the web since then.
However, there is a major difference between working as a limited company to facilitate freelance IT and running an SME out in the real world: as a freelancer there are plenty of agencies out there, taking requirements from their blue chip clients and matching them up with the CVs they take in from contractors. For an SME, especially in today's economic climate, things are a little different. It's one challenge to put together a company that can successfully deliver working IT systems but we also need to tell people about it. Hence, this blog was suggested as part of our marketing strategy and, after my initial reservations, it occurred to me that this would also be a good place to lay out the conclusions of some of our discussions at Meantime.
So, that's the point of the blog but maybe this inaugural posting would be a good place to also ask what's the point of IT? It is a big question but, for further postings to make sense, I think it's one that needs to be asked up front. To be clear, I want to break IT into two categories. (Like many black and white statements, it won't bear close scrutiny but in such a complex world as IT, I'm going to need to take a few shortcuts.)
Firstly, there are packages. I'm using this term to define any software that is built by a company and then released to a target audience. I'm not suggesting there won't have been market research or that the software won't be configurable. Examples of this would include Microsoft Word, Apple's iTunes, Intuit's Quickbooks and Twitter.
Secondly, there is bespoke software, which is what we build at Meantime. This is software that is built for a client to their specification (and the variability in those specifications will be the topic of a future posting). It is really this second category that earns IT a bad name. People may grumble about new releases of package software - Vista is a good example of this - but, by and large, they will work as the authoring company intended. The failing projects that make the news - e.g. apparently anything that is built for the National Health Service - all involve bespoke solutions.
So, if the package solutions work, what is the point of bespoke software? Package solutions do indeed work perfectly when you have a generic requirement and everyone is happy with the same solution. iTunes and Microsoft Word are both good examples of this, as evidenced by the fact that both have made it across a partisan divide: iTunes onto the PC and Word onto the Mac. Even in the world of business, we see package solutions that work but already there is more variation as people buy solutions that are geared up to their size of business and their sector.
The key here is that if you use a package solution for a particular process then you will be carrying out that process in the same way as everyone else who uses that package. This is fine for, say, your payroll but what about those processes that help distinguish your company from the competition? Or what if you have a requirement that is quite specific and, therefore, the target market is too small to warrant a package, so no one has built one?
The key point here is that there is a strong market for bespoke software: people do want and need it. The problem is that so often what is delivered is often very flawed. Common problems include:
- The software that is built does not satisfy the initial requirement
- The costs often exceed the allocated budget
- What is delivered arrives late and is out of sync with the business
We have seen four decades of development of IT systems yet these problems have never been resolved. There are many books, seminars and theories all circulated which purport to solve the issues and yet matters never seem to improve. I believe that the underlying contributing problems are simple to understand and over the last five years, Meantime has successfully delivered projects that match our clients' requirements, on time and on budget. That is not to say that we haven't had challenging projects, too, and those occasions have only served to demonstrate that the processes to which we usually adhere are absolutely essential.
There is no secret ingredient, no single process that we have up our sleeves. The methods, processes and procedures we utilise require work that many companies and, crucially, developers do not wish to adopt. I will be outlining all of them in future posts, highlighting the perils of ignoring them with examples from industry and, no doubt, the day's papers.
Subscribe to:
Posts (Atom)