This post is concerned with the phenomenon of Search Engine Optimisation, commonly known as SEO. This is a subject on which I anticipate making a few more posts, so I thought it would be a good idea to start out with a non-technical trip through its meaning, history, practice and, importantly, the way in which it is sold as a service. We can start with an innocent ideal, 'ideal world' view of the topic before we have to incorporate the corrupting influence of the various companies out there selling 'snake oil'.
When search engines were first devised, their purpose was to catalogue all the information on the Internet, in order to help people locate information when they didn't know where to look for it. For the mutual benefit of the search engine, the person posting the information and the person looking for it, the idea of 'meta data' was incorporated into the web pages. This meta data consisted of a description of the page's contents as well as some 'key words' which summarised the pages content. This content enabled the search engine to better understand what the page was about, the searcher to have a better chance of finding what they were looking for and the publisher of having his content found: everybody benefitted.
However, as the web became more commercialised this altruistic element disappeared. Even before the days when the dedicated SEO companies appeared, unscrupulous web designers would aim to outwit the search engines by, for example, repeating the same word again and again in the keywords. The search engines - or, rather, the people building them - got wise to this trick and began to penalise this activity. Since then search engines have had to become far more clever about evaluating a site's content, actually examining the site in detail, rather than simply trusting the meta data. Some people will even tell you that search engines ignore meta data but this isn't true; the description is often used on the search results page and there are many people out there - who know more detail about this subject than I do - who will tell you that keywords are still taken into account, at least by some search engines.
It was as consequence of this that the phrase "content is king" became popular when discussing search engines and it is absolutely, undeniably true that if your site has plenty of relevant content then you have done 80% of the work. The other 20% is in making sure that search engines can find their way around the site in order to process and index this content and this is why elements such as site maps - which simply tell search engines where to find all the pages on your site - are so important.
It is this process of making a website accessible and easily digestible for search engines that I would describe as 'true' search engine optimisation: the site is optimised for search engines. This True SEO also ensures that every aspect of your site is fully indexed and available, via the search engine, to anyone who is looking for it. This means that all your specialisms and unique selling points are made available to your potential clients and customers.
So what's the difference between this True SEO and the snake oil version, which is promoted by these companies that profess to specialise in SEO? Well, the first thing is to look at what these companies offer. One of the first and worst signs is when they "guarantee" to get your site in the top ten on, typically, Google. It stands to reason that this cannot be guaranteed - what if eleven competing businesses hire these services - so read the small print and marvel at the number of ambiguities and get out clauses. The next thing to watch is that they offer to get your site in the top ten for a number of key phrases, perhaps two or three. So, let's say you are selling sports shoes, they might guarantee to have you in the top ten for "athletics shoes", "running shoes" and "sports shoes". If you are reckless enough to sign up, the first thing they will want to do is to remodel your site and its content to reflect these phrases. This gives search engines a skewed view of your site and takes the emphasis away from the finer detail.
A phrase that is coming into use at the moment is 'long tail' SEO and this is the antithesis of the snake oil SEO. Long tail SEO is related to the fact that a significant proportion of, for example, a retailer's sales will not be in his best sellers. (One example of this that I've read about states that less than half of Amazon's sales come from their top 140 thousand products.) This highlights the mistake of emphasising a few key products: long tail SEO is about making sure that all your products (or services) are clearly visible to search engines so they can be indexed and made available to people searching for them.
It's clear, I'm sure, from this posting that I take a dim view of these companies. Quite apart from their dubious ethics, they make our life at Meantime harder. We carry out True SEO and the results from that can sometimes take months to become apparent plus we never guarantee results. Unfortunately, these other companies lead our clients to expect the undeliverable. However, we know that a well constructed site with good content will work well with the search engines and that our clients's will appear - often in the top ten - when people search for their goods and services.
Tuesday, 9 June 2009
Thursday, 21 May 2009
UAT: what is it for and who benefits from it?
When I was first working in IT in the late eighties, I remember one site where there was a cultural revolution taking place: they were going to start asking the users (or “the business”) what they wanted from IT systems.
Implied in this, of course, is a suggestion that the business took what they were given and that the IT department dictated who could have what. The truth, though, is a bit more subtle than that. Often the business wouldn’t have a clear idea what IT systems could do for them: they had no idea of what was possible and, of the applications that could be delivered, which ones constituted a ‘big ask’ and which ones were straightforward.
Over the last twenty years, the user base in blue chip companies has become increasingly familiar with business systems and it is more common now to see the business working hand in glove with the IT department. Consequently, a way of working has arisen, which includes gathering and documenting the users’ requirements before development starts, and, once development is complete, it is now accepted (and good) practice to give the users a chance to review the new work before it is put into their ‘live’ production environment, where it will be used with their real business data. This practice is called User Acceptance Testing or UAT.
For a completely new system the UAT environment will consist of an environment which is as close as possible to the proposed new live system, so that users can learn to use the new applications. For a change or upgrade to an existing system, the UAT environment should consist of a copy of the existing live system with the new work applied to it. This enables the users to see what has changed and what has stayed the same and also to see how the new processes cope with their existing data.
A word about data: this should, as far as is possible, be a copy of the live data. However, since a company won’t, for example, want its clients and customers receiving email from a test environment, it is necessary to ‘sanitise’ the data to some degree. Similarly, live credit card details should not be moved to UAT nor should the credentials for interacting with the live database or third party systems (such as payment gateways).
UAT provides three main benefits:
Firstly, it enables the users to reconcile what has been delivered against what was in their original requirements. It’s not unusual for there to be a form of ‘Chinese whispers’ as a requirement moves between the users, the business and systems analysts and the developers. The onus, of course, is firmly on the IT people to understand and keep sight of the original requirement and, if that is lost along the way, then the business have every right to refuse to sign off the release when they identify the omission in UAT.
Secondly, it provides an opportunity for ‘scenario based’ testing. A decent IT department will carry out thorough system testing against the functional specification (which is derived from the Business Requirements Document) but it is quite possible for this testing to be carried out properly and to sign the release off as fit for UAT yet for an error to be missed. This is best explained by example: a couple of years ago, we built an e-commerce system and one of the requirements specified that once items were sold, then the quantity should be subtracted from stock. We delivered this requirement, including automatic email notification when stock levels fell below a user defined trigger point. However, it was during UAT that the client pointed out that in order to minimise their costs, they held as little stock as possible, often ordering the required items in only after a customer had ordered them. Consequently, we had to amend the system to allow for negative stock values.
This brings me nicely to the last of these main benefits: less live fixes. If, in the example above, we had not had a user acceptance test, the client's business would have ground to a halt as many items would have not been available to order (as there were zero items in stock). The resolution to this problem was simple enough and took about half a day to apply. That half a day didn’t seem much when the client could be off testing other aspects of the system in UAT but it would have been a very different story if their business had lost half a day’s sales whilst we made the change.
So, who does benefit? As the points above illustrate, I believe the answer is everyone. The users have a huge amount of reassurance that their requirements have been met, without the stress of seeing the work for the first time in a live environment. Where issues do arise, they know they are low impact, affecting only test data and not the live business operation. From IT’s point of view, the department ends up with happier, better serviced users and, crucially, a minimum of high-pressure, risk laden live fixes with the business (understandably) demanding regular updates.
At Meantime, we are often working with users who don’t have blue chip experience but there is no reason why we shouldn’t use our experience and bring the good practice of UAT to our projects. The concept is easy to understand both in terms of execution and benefit, and our clients quickly grasp it. Ultimately, this simple step in the project life-cycle takes away a whole load of the stress and aggravation that is associated with IT delivery.
Sunday, 3 May 2009
Case Study: Entrust Social Care
To make any case study worthwhile, it needs to highlight one or more salient points about the service that it is intended to illuminate. I'm starting with this particular case study because it demonstrates three important characteristics of well built bespoke software:
1. It has a clear cost benefit.
2. It improves the way in which the client's business is run.
3. It provides management information about the processes that it manages.
The client in this case is Entrust Social Care, whose website can be found at www.entrustsocialcare.co.uk. The Company provides temporary Social Workers (Locums) to the Public Sector across the UK, who in turn approach Entrust to satisfy their staffing requirements. One of the most important parts of Entrust's business is making sure that the locums are paid promptly after submitting their timesheets.
The locums are paid for the hours they work (sometimes working for different clients in the same week), for their expenses and they are also awarded bonuses. In addition to this, they might opt to take time off in lieu. Each week, the MD at Entrust, Ian Brindley, would process the timesheets submitted by the locums, using Excel to calculate the payments and track the time worked against bonus goals. It was a time consuming process and it was what Ian spent the Thursday and Friday of each week doing. It was boring work, yet vitally important, which is a poor combination. Furthermore, Ian didn't feel able to delegate the work out to his staff.
Ian and I had worked together at JPMorganChase in 2000, and he approached me to ask whether Meantime could do anything to help ease his situation. He explained that his business was developing well and that he was generally very happy: the only fly in the ointment was this weekly business with the timesheets. We spent some time talking to Ian about his business, the specific issue and about possible solutions.
This done we then designed a database that would store the details of both Ian's clients and the locums who were working through him. Over this we laid an administration system that would enable Ian to add and maintain this data. We then repeated this process, adding the relationships between the locums and the Social Work Teams in which they were placed.
The next step was to provide Ian with an easy to use interface where he could select a locum, choose a location where they were working and then enter the hours worked, expenses et cetera for a given week. Finally, we provided the function to produce a report of all the payments required for each locum.
As a consequence of this work, using the same inputs and providing the same outputs, we reduced the timesheet processing from two days to two hours (which is how long it took to type in the data). Additionally, we were able to provide valuable data from the system, simply because the relevant part of Ian's operational data was being processed by it. At the press of button Ian could access powerful business information regarding the number of contracts he had in place, the number of clients and locums he had on his books, plus vital financial information.
So, to summarise, let's look at those three points again:
1. The system has a clear cost benefit. Timesheet processing was taking up every Thursday and Friday, i.e. 40% of Ian's working time. Whilst I'm not privy to what Ian pays himself, I know that the cost of the software was less than two-fifths of his salary and, furthermore, it was a one-off cost.
2. The system improves the way in which the client's business is run. Once the system was in place, Ian suddenly had an extra two working days available in his week, something that would be hugely attractive to any Managing Director. This gave him more time to grow his business plus the confidence that he could manage the additional workload.
3. The system provides management information about the processes that it manages. Without even consulting Ian, common sense would have enabled us to provide useful reports to Ian. In addition to those mentioned above, we were in a position to answer questions like Who are my best clients? How much have I paid out to locums this quarter? Which care clients appear to be using more or less of my services over time?
All businesses are different and that is why they need bespoke software for their IT solutions. For those solutions to be effective, the businesses need to pick suppliers who are demonstrably strong when it comes to business analysis: there is a lot of work to be done before the first coding keystroke takes place. The Entrust project is a great example of how, by listening to the client and working with him, we were able to provide a solution that exactly matched his requirement.
1. It has a clear cost benefit.
2. It improves the way in which the client's business is run.
3. It provides management information about the processes that it manages.
The client in this case is Entrust Social Care, whose website can be found at www.entrustsocialcare.co.uk. The Company provides temporary Social Workers (Locums) to the Public Sector across the UK, who in turn approach Entrust to satisfy their staffing requirements. One of the most important parts of Entrust's business is making sure that the locums are paid promptly after submitting their timesheets.
The locums are paid for the hours they work (sometimes working for different clients in the same week), for their expenses and they are also awarded bonuses. In addition to this, they might opt to take time off in lieu. Each week, the MD at Entrust, Ian Brindley, would process the timesheets submitted by the locums, using Excel to calculate the payments and track the time worked against bonus goals. It was a time consuming process and it was what Ian spent the Thursday and Friday of each week doing. It was boring work, yet vitally important, which is a poor combination. Furthermore, Ian didn't feel able to delegate the work out to his staff.
Ian and I had worked together at JPMorganChase in 2000, and he approached me to ask whether Meantime could do anything to help ease his situation. He explained that his business was developing well and that he was generally very happy: the only fly in the ointment was this weekly business with the timesheets. We spent some time talking to Ian about his business, the specific issue and about possible solutions.
This done we then designed a database that would store the details of both Ian's clients and the locums who were working through him. Over this we laid an administration system that would enable Ian to add and maintain this data. We then repeated this process, adding the relationships between the locums and the Social Work Teams in which they were placed.
The next step was to provide Ian with an easy to use interface where he could select a locum, choose a location where they were working and then enter the hours worked, expenses et cetera for a given week. Finally, we provided the function to produce a report of all the payments required for each locum.
As a consequence of this work, using the same inputs and providing the same outputs, we reduced the timesheet processing from two days to two hours (which is how long it took to type in the data). Additionally, we were able to provide valuable data from the system, simply because the relevant part of Ian's operational data was being processed by it. At the press of button Ian could access powerful business information regarding the number of contracts he had in place, the number of clients and locums he had on his books, plus vital financial information.
So, to summarise, let's look at those three points again:
1. The system has a clear cost benefit. Timesheet processing was taking up every Thursday and Friday, i.e. 40% of Ian's working time. Whilst I'm not privy to what Ian pays himself, I know that the cost of the software was less than two-fifths of his salary and, furthermore, it was a one-off cost.
2. The system improves the way in which the client's business is run. Once the system was in place, Ian suddenly had an extra two working days available in his week, something that would be hugely attractive to any Managing Director. This gave him more time to grow his business plus the confidence that he could manage the additional workload.
3. The system provides management information about the processes that it manages. Without even consulting Ian, common sense would have enabled us to provide useful reports to Ian. In addition to those mentioned above, we were in a position to answer questions like Who are my best clients? How much have I paid out to locums this quarter? Which care clients appear to be using more or less of my services over time?
All businesses are different and that is why they need bespoke software for their IT solutions. For those solutions to be effective, the businesses need to pick suppliers who are demonstrably strong when it comes to business analysis: there is a lot of work to be done before the first coding keystroke takes place. The Entrust project is a great example of how, by listening to the client and working with him, we were able to provide a solution that exactly matched his requirement.
Saturday, 25 April 2009
Why bespoke software? (And how to tell if you need it.)
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.
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.
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)