If you are like me and need to search the Internet for information on a person (perhaps a prospect, or someone you’re about to meet for the first time), you may have found the problems of using Google – too many incorrect entries and/or insufficient views of blogs and social networking sites.
You may wish to try a couple of new sites that have been recommended to me (thanks to Dan for forwarding on the links):
Try typing your own name into www.pipl.com and not only does it search for textual entries, it can also come up with photos extracted from web sites and social networking sites (for me it comes up with not only my own photo from this blog, but also a number of photos of other unfortunates with the same name....). Now try other contacts and/or prospects – sometimes the search provides nothing, but in many cases I find that some of the entries are for valid items not found by a conventional Google-type search.
Then try typing your own name, a company name, brand name or topic into www.addictomatic.com and it performs a search of the web for the latest news, blog posts, videos and images. I’ve been impressed with the up-to-date output from this search engine – yes, it comes up with a number of irrelevant hits, but frequently finds some relevant hits that are not found easily in a Google-type search.
Thursday 26 February 2009
Wednesday 25 February 2009
Open Source – who poached whose policy?
Only a couple of weeks after the Tories announced a policy to support Open Source, yesterday the Government published a new policy on Open Source software “that will ensure maximum value for money for taxpayers”.
Unlike the Tories though, the Government has put some meat on the bones of its press release and published 10 actions that “will actively help make sure the best possible, best value for money software solutions are put forward for tenders, be they Open Source or propriety products”. However, as with the Tory announcement, I believe the Government policy is fatally flawed.
Fortunately, those 10 policies/actions recognise the need to make procurement decisions “on the basis on the best value for money solution to the business requirement, taking account of total lifetime cost of ownership of the solution”. However, the policies/actions propose to help tip the balance towards Open Source through the introduction of two proposed safeguards that are, in my mind, unworkable in practice:
Firstly, where Government becomes locked into proprietary software it will, where possible “take exit, rebid and rebuild costs into account in procurement decisions and will require those proposing proprietary software to specify how exit would be achieved”. Whilst proprietary software suppliers can no doubt describe the exit route, it is impractical for either the supplier or the purchaser to try to estimate rebid and rebuild costs with any degree of accuracy– and who would be responsible for such costs if they were subsequently (say, 5 years down the line) proven to be wrong?
However, and rather worryingly, it does introduce the opportunity for customers who have already decided on their preferred solution to justify its purchase over, say a solution with a lower overall cost of ownership, by coming up with an over-stated exit, rebid and rebuild cost.
Secondly, “the Government will look to secure full rights to bespoke software code or customisations of commercial off the shelf products it procures, so as to enable straightforward re-use elsewhere in the public sector.” This is fine for bespoke software that can work in isolation, but is virtually unworkable for bespoke code and customisations that rely on products where the IPR is not owned by Government.
Also, this approach could potentially increase maintenance costs for Government. Within my company, Radius our normal approach for making most customer-funded bespoke modifications to our own products was to retain the IPR, but roll the modification into the standard product and make it available to all other users (Public Sector or not). This way the modification was taken forward in new releases, and maintained, under the standard maintenance agreement, at no additional charge.
If the IPR is retained by Government, then the code cannot be rolled into the standard product (i.e. to be made available to others outside the Public Sector), and presumably the Government will be happy to pay for its maintenance and inclusion in all future releases of the standard software....
I’m also bemused by the statement – “The Government will use open standards in its procurement specifications and require solutions to comply with open standards. The Government will support the development of open standards and specifications.” I can’t think how many times I’ve seen this statement over the past 25 years, be it for mainframe, Unix , e-government or general interoperability – great in theory, but never been implemented effectively in practice.
I won’t repeat the arguments contained in my post Conservative’s move to Open Source – a major mistake?, other than restating that the trick is to learn to live with the proprietary software suppliers (accepting that the UK Government software market is a significant, but still very small percentage of their overall business) rather than build ways to avoid them.
Unlike the Tories though, the Government has put some meat on the bones of its press release and published 10 actions that “will actively help make sure the best possible, best value for money software solutions are put forward for tenders, be they Open Source or propriety products”. However, as with the Tory announcement, I believe the Government policy is fatally flawed.
Fortunately, those 10 policies/actions recognise the need to make procurement decisions “on the basis on the best value for money solution to the business requirement, taking account of total lifetime cost of ownership of the solution”. However, the policies/actions propose to help tip the balance towards Open Source through the introduction of two proposed safeguards that are, in my mind, unworkable in practice:
Firstly, where Government becomes locked into proprietary software it will, where possible “take exit, rebid and rebuild costs into account in procurement decisions and will require those proposing proprietary software to specify how exit would be achieved”. Whilst proprietary software suppliers can no doubt describe the exit route, it is impractical for either the supplier or the purchaser to try to estimate rebid and rebuild costs with any degree of accuracy– and who would be responsible for such costs if they were subsequently (say, 5 years down the line) proven to be wrong?
However, and rather worryingly, it does introduce the opportunity for customers who have already decided on their preferred solution to justify its purchase over, say a solution with a lower overall cost of ownership, by coming up with an over-stated exit, rebid and rebuild cost.
Secondly, “the Government will look to secure full rights to bespoke software code or customisations of commercial off the shelf products it procures, so as to enable straightforward re-use elsewhere in the public sector.” This is fine for bespoke software that can work in isolation, but is virtually unworkable for bespoke code and customisations that rely on products where the IPR is not owned by Government.
Also, this approach could potentially increase maintenance costs for Government. Within my company, Radius our normal approach for making most customer-funded bespoke modifications to our own products was to retain the IPR, but roll the modification into the standard product and make it available to all other users (Public Sector or not). This way the modification was taken forward in new releases, and maintained, under the standard maintenance agreement, at no additional charge.
If the IPR is retained by Government, then the code cannot be rolled into the standard product (i.e. to be made available to others outside the Public Sector), and presumably the Government will be happy to pay for its maintenance and inclusion in all future releases of the standard software....
I’m also bemused by the statement – “The Government will use open standards in its procurement specifications and require solutions to comply with open standards. The Government will support the development of open standards and specifications.” I can’t think how many times I’ve seen this statement over the past 25 years, be it for mainframe, Unix , e-government or general interoperability – great in theory, but never been implemented effectively in practice.
I won’t repeat the arguments contained in my post Conservative’s move to Open Source – a major mistake?, other than restating that the trick is to learn to live with the proprietary software suppliers (accepting that the UK Government software market is a significant, but still very small percentage of their overall business) rather than build ways to avoid them.
Tuesday 24 February 2009
AGM week for IDOX and Gladstone
This week sees two AGMs for software suppliers to the Public Sector – IDOX (Thursday) and Gladstone (Friday) – when we will hopefully be updated on their prospects and fortunes to date.
Both have seen their share prices drift downwards over the past few months – but for different reasons.
Gladstone saw off its unwanted bidder, Constellation, in December and has since seen its share prices drift from just under the bidder’s offer of 25p towards the 18p level it was at before the bid was announced. Gladstone is also trying to repel a request from Constellation to have a post on Gladstone’s Board. Gladstone desperately needs good news – recent attempts to generate good news from announcements of the new software updates and the first very small user of its new Orbit package have been judged too weak by investors – let’s hope that the AGM will include some positive, hopefully quantified, news about new business wins.
IDOX has similarly suffered from a lack of good news, with only a weak announcement of a “me too” strategic partnership with Kirona since the announcement of its results over two months ago. Shareholders seem to be fretting about IDOX’s ability to maintain profit levels during the current recession, and rumours abound of further rationalisation of IDOX’s business units. Hopefully the AGM statement will include updates on the continuing absorption of IDOX’s Plantech and CAPS acquisitions, again including some quantification of the cost savings achieved.
I remain a (small) shareholder in both businesses – I believe that, as dominant leaders in their chosen markets, properly managed, they will have the strength to not only survive the current downturn in spending in the markets, but thrive in years to come. As I’ve noted before, I believe that both are likely to lose their independence at some time - but unless they trip up over the coming few months, I think it will be at least another year before any reasonable offers are forthcoming......
Both have seen their share prices drift downwards over the past few months – but for different reasons.
Gladstone saw off its unwanted bidder, Constellation, in December and has since seen its share prices drift from just under the bidder’s offer of 25p towards the 18p level it was at before the bid was announced. Gladstone is also trying to repel a request from Constellation to have a post on Gladstone’s Board. Gladstone desperately needs good news – recent attempts to generate good news from announcements of the new software updates and the first very small user of its new Orbit package have been judged too weak by investors – let’s hope that the AGM will include some positive, hopefully quantified, news about new business wins.
IDOX has similarly suffered from a lack of good news, with only a weak announcement of a “me too” strategic partnership with Kirona since the announcement of its results over two months ago. Shareholders seem to be fretting about IDOX’s ability to maintain profit levels during the current recession, and rumours abound of further rationalisation of IDOX’s business units. Hopefully the AGM statement will include updates on the continuing absorption of IDOX’s Plantech and CAPS acquisitions, again including some quantification of the cost savings achieved.
I remain a (small) shareholder in both businesses – I believe that, as dominant leaders in their chosen markets, properly managed, they will have the strength to not only survive the current downturn in spending in the markets, but thrive in years to come. As I’ve noted before, I believe that both are likely to lose their independence at some time - but unless they trip up over the coming few months, I think it will be at least another year before any reasonable offers are forthcoming......
Monday 23 February 2009
Capita/IBS – Competition Commission progress
The Competition has continued with its investigation into Capita’s completed acquisition of IBS, and has apparently completed its initial collection of information, including meeting with a number of third parties. The CC has also published copies of some of the documents submitted and summaries of some of the hearings held with interested parties (unfortunately, but understandably, the published copies of these documents have had confidential and commercially sensitive information deleted). I also note that, whilst the CC has published summaries of its hearing with Civica, it has not done so, to date, for its hearings with Northgate.
In summary, it is hard to find any organisation other than Capita that doesn’t believe that Capita’s acquisition of IBS will reduce competition for Revenues & Benefits (R&B) systems. Likewise, I think all parties seem to agree that the same does not apply to the Social Housing (SH) market where, even after Capita’s acquisition of IBS there remains a significant number of other suppliers around to ensure an adequate level of competition. Quoting from Doug Forbes' (Barony) response – “there should be a minimum of 3 vendors to maintain adequate competition in this important [R&B] market ..... the only solution seems to be — let Capita have the Housing System and auction the R&B to anyone but Capita and Northgate.”
As noted in my posts last year (see Capita/IBS – OFT’s final text - what next?), based on the criteria used by the Competition Commission, it is likely to have little choice but to conclude that the acquisition has resulted in a reduction in competition for R&B systems. But if you read the documents and summaries carefully, you can see some agreement that the market for new R&B back office systems is now very small – the numbers of open tenders in 2003 and 2004 was round 50 per annum, dropping to 14 in 2005 and 12 in 2006.
With English LA reorganisation we are seeing a continual reduction in overall market size – with 2009 reorganisation expected to see the market reduce by 33 systems, and 2010 likely to be around another 22 systems. There is also a general acceptance that the IBS back office system is more suited to small to medium sized authorities, and therefore is unlikely to be seriously in the running for the new unitary council contracts (although I’m sure IBS would disagree with this). As before the merger, Northgate and Capita are really the only two serious contenders in this market for R&B back office systems for larger authorities. If one views district councils as the target market for IBS’s R&B systems, then, over 2009 and 2010 there will be a c 24% reduction in the size of IBS’s market – potentially a major problem for the IBS R&B business both now and in the future.
With such a small number of potential new business wins per annum, it will be increasingly difficult for any supplier to justify extensive speculative development of new functionality or support for new technology. Indeed, it is highly likely that smaller suppliers like IBS would have had to cut back significantly to retain profitability, and may even had to follow other R&B suppliers into just a “support & maintenance” operation for their R&B software.
Certainly, based on the figures quoted, there is virtually no chance of a new supplier entering the market – the upfront cost and risk is immense – the likely revenue totally insufficient to justify the development expenditure – the time to market too great – and then there is always the chance that, just as the development completes, Central Government introduces local income tax, abolishes Council Tax, and/or introduces a centralised system to manage consolidated benefits and remove the need for LA Housing Benefit systems. (Let alone local authorities’ own aversion to taking new, untried systems – most LA’s wish to see three live reference sites before even short-listing a supplier).
Let me repeat that I believe the likely cost of development and testing of a new suite of back office R&B applications from scratch to be near £10M. I would agree with Capita’s assertion that existing financial systems suppliers have some of the necessary functionality and technology already, but that this would only lower the initial development costs by 10% or less. I would also agree with the comments of several parties that LA’s are unlikely to band together to fund or part-fund the development costs for a new entrant.
So where to from now?
The Competition Commission has published new directions for Capita to increase the formal separation of IBS and its management as a totally independent subsidiary of Capita so as to “preserve the possibility of restoring effective competition in the markets affected by the merger through the separation from Capita of a viable, saleable, competitive IBS business”. So clearly the CC is considering a complete separation of the whole IBS business, (i.e. including Social Housing), even though I would have thought that the SH business could have been retained by Capita (perhaps the SH and R&B systems/staff are more inter-twined than implied by the published texts).
In isolation, I still think this would be wrong. Perhaps Central Government could act in a more joined-up way, with the DWP coming up with a clear strategy (and funding?) for R&B software suppliers to enable increased investment (by both existing suppliers and new entrants) – although I fear this is unlikely, and most probably impossible. Unfortunately, the DWP’s funding of LA’s to purchase R&B systems over the past few years has not resulted in what the DWP would have wished for. Going forward, if it wants more than two real competitors, there must be more money put on the table – but hopefully in a way that delivers what Central Government wants.
Without it, even if the CC forces Capita to divest IBS, I suspect that there is a strong chance that there will still only be two main suppliers – Northgate and Capita – with a strong possibility that existing IBS customers will not have the security, nor negotiating power, that they would have had with IBS as part of Capita.
If the Competition Commission were to let Capita continue to own IBS, it has a great opportunity to put in place protection for the interests of existing & future IBS users, and possibly even some safeguards for other Capita R&B customers. Unfortunately, Central Government is not joined up, and I fear that the CC will have no choice but to act against its own restricted remit, and will be unable to provide the initiatives that this market really requires.
In summary, it is hard to find any organisation other than Capita that doesn’t believe that Capita’s acquisition of IBS will reduce competition for Revenues & Benefits (R&B) systems. Likewise, I think all parties seem to agree that the same does not apply to the Social Housing (SH) market where, even after Capita’s acquisition of IBS there remains a significant number of other suppliers around to ensure an adequate level of competition. Quoting from Doug Forbes' (Barony) response – “there should be a minimum of 3 vendors to maintain adequate competition in this important [R&B] market ..... the only solution seems to be — let Capita have the Housing System and auction the R&B to anyone but Capita and Northgate.”
As noted in my posts last year (see Capita/IBS – OFT’s final text - what next?), based on the criteria used by the Competition Commission, it is likely to have little choice but to conclude that the acquisition has resulted in a reduction in competition for R&B systems. But if you read the documents and summaries carefully, you can see some agreement that the market for new R&B back office systems is now very small – the numbers of open tenders in 2003 and 2004 was round 50 per annum, dropping to 14 in 2005 and 12 in 2006.
With English LA reorganisation we are seeing a continual reduction in overall market size – with 2009 reorganisation expected to see the market reduce by 33 systems, and 2010 likely to be around another 22 systems. There is also a general acceptance that the IBS back office system is more suited to small to medium sized authorities, and therefore is unlikely to be seriously in the running for the new unitary council contracts (although I’m sure IBS would disagree with this). As before the merger, Northgate and Capita are really the only two serious contenders in this market for R&B back office systems for larger authorities. If one views district councils as the target market for IBS’s R&B systems, then, over 2009 and 2010 there will be a c 24% reduction in the size of IBS’s market – potentially a major problem for the IBS R&B business both now and in the future.
With such a small number of potential new business wins per annum, it will be increasingly difficult for any supplier to justify extensive speculative development of new functionality or support for new technology. Indeed, it is highly likely that smaller suppliers like IBS would have had to cut back significantly to retain profitability, and may even had to follow other R&B suppliers into just a “support & maintenance” operation for their R&B software.
Certainly, based on the figures quoted, there is virtually no chance of a new supplier entering the market – the upfront cost and risk is immense – the likely revenue totally insufficient to justify the development expenditure – the time to market too great – and then there is always the chance that, just as the development completes, Central Government introduces local income tax, abolishes Council Tax, and/or introduces a centralised system to manage consolidated benefits and remove the need for LA Housing Benefit systems. (Let alone local authorities’ own aversion to taking new, untried systems – most LA’s wish to see three live reference sites before even short-listing a supplier).
Let me repeat that I believe the likely cost of development and testing of a new suite of back office R&B applications from scratch to be near £10M. I would agree with Capita’s assertion that existing financial systems suppliers have some of the necessary functionality and technology already, but that this would only lower the initial development costs by 10% or less. I would also agree with the comments of several parties that LA’s are unlikely to band together to fund or part-fund the development costs for a new entrant.
So where to from now?
The Competition Commission has published new directions for Capita to increase the formal separation of IBS and its management as a totally independent subsidiary of Capita so as to “preserve the possibility of restoring effective competition in the markets affected by the merger through the separation from Capita of a viable, saleable, competitive IBS business”. So clearly the CC is considering a complete separation of the whole IBS business, (i.e. including Social Housing), even though I would have thought that the SH business could have been retained by Capita (perhaps the SH and R&B systems/staff are more inter-twined than implied by the published texts).
In isolation, I still think this would be wrong. Perhaps Central Government could act in a more joined-up way, with the DWP coming up with a clear strategy (and funding?) for R&B software suppliers to enable increased investment (by both existing suppliers and new entrants) – although I fear this is unlikely, and most probably impossible. Unfortunately, the DWP’s funding of LA’s to purchase R&B systems over the past few years has not resulted in what the DWP would have wished for. Going forward, if it wants more than two real competitors, there must be more money put on the table – but hopefully in a way that delivers what Central Government wants.
Without it, even if the CC forces Capita to divest IBS, I suspect that there is a strong chance that there will still only be two main suppliers – Northgate and Capita – with a strong possibility that existing IBS customers will not have the security, nor negotiating power, that they would have had with IBS as part of Capita.
If the Competition Commission were to let Capita continue to own IBS, it has a great opportunity to put in place protection for the interests of existing & future IBS users, and possibly even some safeguards for other Capita R&B customers. Unfortunately, Central Government is not joined up, and I fear that the CC will have no choice but to act against its own restricted remit, and will be unable to provide the initiatives that this market really requires.
Wednesday 18 February 2009
Requirements vs. specifications – an analogy
To illustrate my earlier post, and continuing the theme of teaching grandmothers to suck eggs, consider this analogy between buying a car and an application software package.
Joe goes into a number of car showrooms – he explains to the salesmen that he’s looking for a car for his family of four. He wants a fast car, one that’s reasonably economical, and he has a budget of £15,000. After viewing some of the cars, he takes a test drive in one which he likes – it accelerates fast and reaches 70 mph quickly, has two doors and four good seats, the salesman says it returns 30 mpg, and it only costs £14,000 with a manual gearbox. He asks about accessories, adds in a roof box and a towing bracket, and leaves the showroom with a quotation and a copy of the brochure for the car. On his way home he sees that several of his neighbours have purchased the same model of car, but doesn't speak to any of them about their cars.
After a quick discussion with his wife Joe decides to buy the car, it is duly delivered and after a couple of weeks he returns to the showroom complaining that with the roof box in place he’s not getting 30 mpg, and when he tows the caravan, he’s not getting the acceleration nor the speed that he expected. Even worse, his two 6ft teenagers can’t get into the back seats easily, and his wife can’t drive it because she can only drive automatics.
The garage quickly falls back on its contract of supply – which is against the specification included in the brochure supplied with the quotation – and which specifies the conditions for the quoted fuel consumption and performance, and included measurements of the rear seat sizes and doors. The fault lies with Joe - a purchaser who failed to involve all the users (his wife and children), failed to define fully his requirements (his family and the caravan), and failed to check the specifications contained in the brochure before he ordered the car. He also failed to recognise that if you use a product in a non-standard way or change the specification (e.g. adding a roof box, or towing a caravan), it can dramatically change the expectations of how the product will perform.
The car salesman does however, point out to Joe that there is a 4-door version of the car, with a bigger engine and automatic gearbox, that would tow the caravan easily – and an estate version that would remove the need for the roof box. However, it costs £20,000 and is not so economical to run.
So Joe decides to live with his new car........
Joe goes into a number of car showrooms – he explains to the salesmen that he’s looking for a car for his family of four. He wants a fast car, one that’s reasonably economical, and he has a budget of £15,000. After viewing some of the cars, he takes a test drive in one which he likes – it accelerates fast and reaches 70 mph quickly, has two doors and four good seats, the salesman says it returns 30 mpg, and it only costs £14,000 with a manual gearbox. He asks about accessories, adds in a roof box and a towing bracket, and leaves the showroom with a quotation and a copy of the brochure for the car. On his way home he sees that several of his neighbours have purchased the same model of car, but doesn't speak to any of them about their cars.
After a quick discussion with his wife Joe decides to buy the car, it is duly delivered and after a couple of weeks he returns to the showroom complaining that with the roof box in place he’s not getting 30 mpg, and when he tows the caravan, he’s not getting the acceleration nor the speed that he expected. Even worse, his two 6ft teenagers can’t get into the back seats easily, and his wife can’t drive it because she can only drive automatics.
The garage quickly falls back on its contract of supply – which is against the specification included in the brochure supplied with the quotation – and which specifies the conditions for the quoted fuel consumption and performance, and included measurements of the rear seat sizes and doors. The fault lies with Joe - a purchaser who failed to involve all the users (his wife and children), failed to define fully his requirements (his family and the caravan), and failed to check the specifications contained in the brochure before he ordered the car. He also failed to recognise that if you use a product in a non-standard way or change the specification (e.g. adding a roof box, or towing a caravan), it can dramatically change the expectations of how the product will perform.
The car salesman does however, point out to Joe that there is a 4-door version of the car, with a bigger engine and automatic gearbox, that would tow the caravan easily – and an estate version that would remove the need for the roof box. However, it costs £20,000 and is not so economical to run.
So Joe decides to live with his new car........
Tuesday 17 February 2009
Requirements vs. specifications
This may be a post to teach grandmothers to suck eggs, but the question has been asked – why do I go on so much about the importance of separate requirements and specifications stages – surely they are the same?
This is, unfortunately, a common problem with IT projects these days – I would say that the vast majority of the problem projects I’m asked to deal with have had core problems in this area – and mostly for suppliers/developers who have contracted against incomplete and/or inaccurate requirements, without a specifications stage for the customer to sign off before development/implementation starts. When analysing such projects, when I ask for the “specifications” I am invariably given the “requirements” – without either the customer or the supplier having realised that the specifications have never been produced.
As my ex-managers and sales staff will testify, this is one area that, as MD of a software house, I drummed into my staff – the difference between requirements and specifications, and the importance of a customer agreeing not just the requirements (i.e. what he wants the system to do) but also the specification (how the system will fulfil his requirements) – and how difficult it is to estimate accurately any development work until a specification has been agreed.
Yes – it is possible, with good in-house IT department and development teams, to short-circuit some of these phases – but not in customer/external supplier, fixed price contracts – the risks can be just too great.
Contracts involving existing software application packages should be a lot easier, but in some cases, despite the supplier’s statement of compliance against the customer’s requirements being accurate, the supplied solution turns out not to be what the customer really wanted – why? – it comes back to the difference between requirements and specifications.
With modern application packages, most common requirements can be met, but in most cases the supplier’s Tender/proposal doesn’t spell out how each requirement will be met – e.g. the customer may expect (want) a single screen format and transaction to meet a specific requirement, yet the supplier’s solution is to use two or more screens and transactions – if the customer hasn’t spelt out the his needs in detail, there can be problems.
More importantly, some customers do not recognise their own responsibilities in the pre-contract stage of buying an existing application package – namely that of satisfying themselves (and their end-users) that the intended solution operates the way they want their requirements met. At the end of the day, most application software packages are purchased on the basis of a statement of compliance (typically against requirements) and then a specification of the software package – which, typically, has been the subject of demonstration and reference visits – and if these latter stages have been skimped, or the wrong staff drafted in, the customer can fail in his part of the procurement.
Buying or supplying systems against requirements can be highly risky – for both customer and supplier. For application products, they can be procured safely without a separate specification stage, provided both parties work together to agree that the proposed solution will meet the customer’s requirements. For bespoke developments (including large changes to existing packages), I always recommend that final fixed price contracts are not let until a firm specification has been agreed between the parties – possibly using the phased fixed price approach I’ve discussed in previous posts.
P.S. I provide consultancy to both customers and suppliers on both the pre-contractual stages of procurement of new systems/services, and the resolution of problems in projects after contracts have been let. Visit my web site at www.systemsolveconsultancy.co.uk for further details, or contact me at phil@systemsolveconsultancy.co.uk .
This is, unfortunately, a common problem with IT projects these days – I would say that the vast majority of the problem projects I’m asked to deal with have had core problems in this area – and mostly for suppliers/developers who have contracted against incomplete and/or inaccurate requirements, without a specifications stage for the customer to sign off before development/implementation starts. When analysing such projects, when I ask for the “specifications” I am invariably given the “requirements” – without either the customer or the supplier having realised that the specifications have never been produced.
As my ex-managers and sales staff will testify, this is one area that, as MD of a software house, I drummed into my staff – the difference between requirements and specifications, and the importance of a customer agreeing not just the requirements (i.e. what he wants the system to do) but also the specification (how the system will fulfil his requirements) – and how difficult it is to estimate accurately any development work until a specification has been agreed.
Yes – it is possible, with good in-house IT department and development teams, to short-circuit some of these phases – but not in customer/external supplier, fixed price contracts – the risks can be just too great.
Contracts involving existing software application packages should be a lot easier, but in some cases, despite the supplier’s statement of compliance against the customer’s requirements being accurate, the supplied solution turns out not to be what the customer really wanted – why? – it comes back to the difference between requirements and specifications.
With modern application packages, most common requirements can be met, but in most cases the supplier’s Tender/proposal doesn’t spell out how each requirement will be met – e.g. the customer may expect (want) a single screen format and transaction to meet a specific requirement, yet the supplier’s solution is to use two or more screens and transactions – if the customer hasn’t spelt out the his needs in detail, there can be problems.
More importantly, some customers do not recognise their own responsibilities in the pre-contract stage of buying an existing application package – namely that of satisfying themselves (and their end-users) that the intended solution operates the way they want their requirements met. At the end of the day, most application software packages are purchased on the basis of a statement of compliance (typically against requirements) and then a specification of the software package – which, typically, has been the subject of demonstration and reference visits – and if these latter stages have been skimped, or the wrong staff drafted in, the customer can fail in his part of the procurement.
Buying or supplying systems against requirements can be highly risky – for both customer and supplier. For application products, they can be procured safely without a separate specification stage, provided both parties work together to agree that the proposed solution will meet the customer’s requirements. For bespoke developments (including large changes to existing packages), I always recommend that final fixed price contracts are not let until a firm specification has been agreed between the parties – possibly using the phased fixed price approach I’ve discussed in previous posts.
P.S. I provide consultancy to both customers and suppliers on both the pre-contractual stages of procurement of new systems/services, and the resolution of problems in projects after contracts have been let. Visit my web site at www.systemsolveconsultancy.co.uk for further details, or contact me at phil@systemsolveconsultancy.co.uk .
Monday 16 February 2009
Gladstone/Constellation battle rumbles on
Failed bidder Constellation Software Inc continues its battle to win a place on its target, Gladstone’s Board, and after a technical hiccup, has succeeded in getting an EGM to be held on 16 March to vote on its proposal for Constellation’s CEO, Mark Leonard, to be appointed to as a Director of Gladstone.
Gladstone has two main arguments against this, firstly that Constellation is a competitor (for both its main membership systems and fledgling education products), and secondly that it might enable Constellation to obtain information that would enable it to buy Gladstone “on the cheap”. In both cases, Gladstone argues that having a Constellation representative on the Board would endanger the interests of all other Shareholders.
Constellation has yet to respond to make its case for a Board position, but it will no doubt focus on the existing Board’s failure to exploit its dominant market position more fully, and its relatively poor returns to shareholders.
Unfortunately, I do not see this stalemate resolving itself. From the (very few) discussions I’ve had with Gladstone shareholders, it seems that – as with their failed takeover bid – Constellation will not get the shareholder backing necessary to get a place on the Gladstone Board. Meanwhile, Gladstone’s management will have to expend some considerable time and money in repelling this request, an unwanted diversion from running the main business......
Gladstone has two main arguments against this, firstly that Constellation is a competitor (for both its main membership systems and fledgling education products), and secondly that it might enable Constellation to obtain information that would enable it to buy Gladstone “on the cheap”. In both cases, Gladstone argues that having a Constellation representative on the Board would endanger the interests of all other Shareholders.
Constellation has yet to respond to make its case for a Board position, but it will no doubt focus on the existing Board’s failure to exploit its dominant market position more fully, and its relatively poor returns to shareholders.
Unfortunately, I do not see this stalemate resolving itself. From the (very few) discussions I’ve had with Gladstone shareholders, it seems that – as with their failed takeover bid – Constellation will not get the shareholder backing necessary to get a place on the Gladstone Board. Meanwhile, Gladstone’s management will have to expend some considerable time and money in repelling this request, an unwanted diversion from running the main business......
Too much haste – not enough speed
Following my post on how to manage large projects, I’ve been reminded by one of my ex-managers of an example on the importance of the requirements stage – I’ll keep the names confidential to protect the.....
A few years ago, Radius was the leading supplier of applications in this specific area for local authorities – on the back of this we were invited to bid for a Central Government project to supply similar functionality. The competitive procurement was being managed by a major consultancy, but would be very quick – all suppliers were to be given just 7 working days to respond to the tender.
When the tender arrived, the requirements were obviously both incomplete and, in some places, plain wrong (some of the requirements even breached accounting rules). We knew that, as a small company with very little experience of working with Central Government, we were unlikely to win the business; so we decided (perhaps incorrectly) to take the high-risk approach of re-writing the requirements to include those areas that were obviously wrong or missing, and add options for some additional elements that users would normally need.
Our solution existed, could be piloted almost immediately, and could be put live in the few months required by the aggressive timetable - we bid a low price, but we admitted that the system would have to be re-engineered after a few years to meet vast transaction levels predicted in year 5 (something that we built into our project plan and costing). Our bid was rejected, primarily on its inability to meet the year 5 transaction levels. We never did find out officially who won the bid – the system didn’t go live as required a few months later – or even a few years later.....
Many months after the bid I spoke to one of the other bidders – again a supplier who had a working solution – they had also been ruled out (reputedly on price). He believed that the contract had been let to a major services organisation to develop from scratch against the original (flawed) statement of requirements, and that with extensions caused by changes in requirements identified after the contract had been signed, the Government had already paid out more than their original fixed price bid.
I’ve never been able to confirm whether that is true or not – certainly the system as initially specified never saw the light of day, and a stop-gap, partial solution was put in place several years later – a solution that has apparently never achieved the forecast transaction rates for year 2, let alone the suggested year 5 volumes....
Did the contractor pocket a 7-figure sum for his work on this failed project? And what happened to the Central Government sponsor (the project took over two years, so no doubt he had moved on before the project was marked as having failed)? The consultancy that managed the procurement is still a major services supplier to Central Government.
Whatever happened, it highlights the problems of rushing the all-important requirements stage – too much haste – not enough speed.....
A few years ago, Radius was the leading supplier of applications in this specific area for local authorities – on the back of this we were invited to bid for a Central Government project to supply similar functionality. The competitive procurement was being managed by a major consultancy, but would be very quick – all suppliers were to be given just 7 working days to respond to the tender.
When the tender arrived, the requirements were obviously both incomplete and, in some places, plain wrong (some of the requirements even breached accounting rules). We knew that, as a small company with very little experience of working with Central Government, we were unlikely to win the business; so we decided (perhaps incorrectly) to take the high-risk approach of re-writing the requirements to include those areas that were obviously wrong or missing, and add options for some additional elements that users would normally need.
Our solution existed, could be piloted almost immediately, and could be put live in the few months required by the aggressive timetable - we bid a low price, but we admitted that the system would have to be re-engineered after a few years to meet vast transaction levels predicted in year 5 (something that we built into our project plan and costing). Our bid was rejected, primarily on its inability to meet the year 5 transaction levels. We never did find out officially who won the bid – the system didn’t go live as required a few months later – or even a few years later.....
Many months after the bid I spoke to one of the other bidders – again a supplier who had a working solution – they had also been ruled out (reputedly on price). He believed that the contract had been let to a major services organisation to develop from scratch against the original (flawed) statement of requirements, and that with extensions caused by changes in requirements identified after the contract had been signed, the Government had already paid out more than their original fixed price bid.
I’ve never been able to confirm whether that is true or not – certainly the system as initially specified never saw the light of day, and a stop-gap, partial solution was put in place several years later – a solution that has apparently never achieved the forecast transaction rates for year 2, let alone the suggested year 5 volumes....
Did the contractor pocket a 7-figure sum for his work on this failed project? And what happened to the Central Government sponsor (the project took over two years, so no doubt he had moved on before the project was marked as having failed)? The consultancy that managed the procurement is still a major services supplier to Central Government.
Whatever happened, it highlights the problems of rushing the all-important requirements stage – too much haste – not enough speed.....
Wednesday 11 February 2009
Projects over 2 years....
Another comment I’ve received on last month’s posts, relates to how would I handle IT projects that couldn’t possibly be completed in a two year period?
Yet again we’re back “eating an elephant” – breaking the project down into smaller, more manageable bites. But perhaps more importantly, it’s also down to ensuring that the requirements for the project have been accurately and completely defined – prior to a specification stage that includes detailed walk-throughs with real-life end users. This is the most important phase of an IT project – yet is typically rushed or overlooked, and frequently completed without adequate reference to the managers and end-users that will be using the system.
I’m a great believer in “phased fixed price” contracts for dealing with large projects that require the development of customised software – splitting out each phase into separate contracts where the current phase is on a fairly firm basis (ideally fixed price against an agreed definition), with budgeted prices for the next phases (typically based on some broad brush assumptions of what will come out of the each phase). Such an approach allows for the requirements collection phase to be contracted separately and carried out by potential eventual developer (if you want to know how to do this in a way that allows for subsequent changes in contractor, please contact me).
When dealing with my managers and team leaders, in the early stages of such projects, I’ve encouraged them to “define the box” – not necessarily what’s in the box, but where the edges are – so that we can know when the project “slips out of the box”. Sitting down with a customer to discuss those box outlines during the requirement stages then proves to be very enlightening – normally for the customer who starts to realise both those areas that he’d forgotten about, and the sort of size/scope of his project.
I also like to see throw-away prototypes, different screen layouts and sample reports as early as possible in the specification stage (but don’t try to turn the prototype into something used in production – every time I’ve seen this tried it’s failed). I remain a firm believer in documentation for all requirements and specifications – particularly for large projects.
“Rapid development” approaches can be adopted for individual “boxes”, but only on the basis of a clear, documented definition of the “box outline”, and full recognition by the customer of the implications of such a development route – but personally, I would try to stay away from such an approach in large projects, unless they are being completed by your own in-house development team (and even then, I’d look for a track record of success on smaller projects before employing this approach on large projects).
Contracting for the technical infrastructure can be handled in parallel, or more likely with large projects, after the detailed specifications for the major “box” elements have been signed off. Hopefully the needs of the training and roll-out stage will have been identified in the requirements collection and subsequent phases, to ensure that topics such as software installation and upgrades can be as automated as possible, and the need for end user training minimised.
There are many potential downsides to this approach but, handled properly, this way can add a level of certainty to projects that is sadly lacking for many current, large projects. Yes – as requirements grow, or specifications change, costs and timescales can increase – but then informed decisions can be made about subsequent phases, expectations set better, and there is a much better chance that the whole project will see the light of day as a success.
P.S. For some of the laws on project management for large projects, including the “90% complete syndrome”, O’Malley’s corollary to Murphy’s Law, and many others, please visit my website.
Yet again we’re back “eating an elephant” – breaking the project down into smaller, more manageable bites. But perhaps more importantly, it’s also down to ensuring that the requirements for the project have been accurately and completely defined – prior to a specification stage that includes detailed walk-throughs with real-life end users. This is the most important phase of an IT project – yet is typically rushed or overlooked, and frequently completed without adequate reference to the managers and end-users that will be using the system.
I’m a great believer in “phased fixed price” contracts for dealing with large projects that require the development of customised software – splitting out each phase into separate contracts where the current phase is on a fairly firm basis (ideally fixed price against an agreed definition), with budgeted prices for the next phases (typically based on some broad brush assumptions of what will come out of the each phase). Such an approach allows for the requirements collection phase to be contracted separately and carried out by potential eventual developer (if you want to know how to do this in a way that allows for subsequent changes in contractor, please contact me).
When dealing with my managers and team leaders, in the early stages of such projects, I’ve encouraged them to “define the box” – not necessarily what’s in the box, but where the edges are – so that we can know when the project “slips out of the box”. Sitting down with a customer to discuss those box outlines during the requirement stages then proves to be very enlightening – normally for the customer who starts to realise both those areas that he’d forgotten about, and the sort of size/scope of his project.
I also like to see throw-away prototypes, different screen layouts and sample reports as early as possible in the specification stage (but don’t try to turn the prototype into something used in production – every time I’ve seen this tried it’s failed). I remain a firm believer in documentation for all requirements and specifications – particularly for large projects.
“Rapid development” approaches can be adopted for individual “boxes”, but only on the basis of a clear, documented definition of the “box outline”, and full recognition by the customer of the implications of such a development route – but personally, I would try to stay away from such an approach in large projects, unless they are being completed by your own in-house development team (and even then, I’d look for a track record of success on smaller projects before employing this approach on large projects).
Contracting for the technical infrastructure can be handled in parallel, or more likely with large projects, after the detailed specifications for the major “box” elements have been signed off. Hopefully the needs of the training and roll-out stage will have been identified in the requirements collection and subsequent phases, to ensure that topics such as software installation and upgrades can be as automated as possible, and the need for end user training minimised.
There are many potential downsides to this approach but, handled properly, this way can add a level of certainty to projects that is sadly lacking for many current, large projects. Yes – as requirements grow, or specifications change, costs and timescales can increase – but then informed decisions can be made about subsequent phases, expectations set better, and there is a much better chance that the whole project will see the light of day as a success.
P.S. For some of the laws on project management for large projects, including the “90% complete syndrome”, O’Malley’s corollary to Murphy’s Law, and many others, please visit my website.
Tuesday 10 February 2009
In support of generalist CRM and ERP systems?
The immediate response to my post in support of best of breed software packages was an even mix of support for my view, and defence of generalist CRM and ERP systems.
Leaving aside the supportive comments, the comments defending the CRM/ERP systems tended to focus on the role of the consultants or System Integrator - that win the contract to implement a solution around the chosen CRM/ERP software – and their level of specialisation in the needs of the customer.
In this area there are good and bad suppliers (and good suppliers who sometimes don’t get it right). I could give examples of supposed “specialist” ERP/CRM service suppliers who win business on the back of their extensive experience in a sector, and then ship in a horde of highly-priced consultants with no previous experience of the sector – who then go back to first principles in trying to tailor and implement the system. I can also give examples of specialist ERP/CRM suppliers who have an excellent understanding of typical user requirements, supply consultants with real experience of their customer’s operations, and look to implement the chosen system as quickly and cheaply as possible – rather than find reasons for supplying even more consultancy days.
For potential customers – having decided on implementing a generalist CRM/ERP system - how to decide on which service supplier?
As I’ve posted before, it is essential to follow up on reference sites – and not just those nominated by the services supplier – get a list of all their customers and get to meet some of those who have not been nominated. Try to get to see their Post Implementation Report – how did the implementation succeed against the original business plan, budget and timescale – and is the system truly delivering benefits? Get to meet end users and their managers – is the system doing what they want – or have they had to change the way they work to match the system (and has that business process change helped or hindered their organisation?).
And don’t be afraid to draft in specialist applications to overcome shortfalls in particular areas – for instance, it’s amazing how many local authorities using ERP applications have found it easier, quicker and cheaper to buy specialist best-of-breed applications to work alongside their ERP system. Yes, the ERP supplier will try to fight against it, but many authorities have seen that the supplier’s arguments are unfounded – and several systems integrators now use those specialist applications in the tenders to help them win the overall business.
Above all else, ensure that your supply contract has a clear definition of what is being delivered – it’s amazing how many contracts I’ve seen that have taken months to negotiate, but still lack basic definitions of deliverables – indeed, whilst there may be “expectations” in the minds of senior managers and officers, many contracts still refer just to delivery of the software package against a standard specification, and a number of “warm bodies” at certain per diem rates.....
Leaving aside the supportive comments, the comments defending the CRM/ERP systems tended to focus on the role of the consultants or System Integrator - that win the contract to implement a solution around the chosen CRM/ERP software – and their level of specialisation in the needs of the customer.
In this area there are good and bad suppliers (and good suppliers who sometimes don’t get it right). I could give examples of supposed “specialist” ERP/CRM service suppliers who win business on the back of their extensive experience in a sector, and then ship in a horde of highly-priced consultants with no previous experience of the sector – who then go back to first principles in trying to tailor and implement the system. I can also give examples of specialist ERP/CRM suppliers who have an excellent understanding of typical user requirements, supply consultants with real experience of their customer’s operations, and look to implement the chosen system as quickly and cheaply as possible – rather than find reasons for supplying even more consultancy days.
For potential customers – having decided on implementing a generalist CRM/ERP system - how to decide on which service supplier?
As I’ve posted before, it is essential to follow up on reference sites – and not just those nominated by the services supplier – get a list of all their customers and get to meet some of those who have not been nominated. Try to get to see their Post Implementation Report – how did the implementation succeed against the original business plan, budget and timescale – and is the system truly delivering benefits? Get to meet end users and their managers – is the system doing what they want – or have they had to change the way they work to match the system (and has that business process change helped or hindered their organisation?).
And don’t be afraid to draft in specialist applications to overcome shortfalls in particular areas – for instance, it’s amazing how many local authorities using ERP applications have found it easier, quicker and cheaper to buy specialist best-of-breed applications to work alongside their ERP system. Yes, the ERP supplier will try to fight against it, but many authorities have seen that the supplier’s arguments are unfounded – and several systems integrators now use those specialist applications in the tenders to help them win the overall business.
Above all else, ensure that your supply contract has a clear definition of what is being delivered – it’s amazing how many contracts I’ve seen that have taken months to negotiate, but still lack basic definitions of deliverables – indeed, whilst there may be “expectations” in the minds of senior managers and officers, many contracts still refer just to delivery of the software package against a standard specification, and a number of “warm bodies” at certain per diem rates.....
Monday 9 February 2009
In support of best of breed software packages
My post on the NHS NPfIT also appears to have re-ignited a discussion on the benefits of buying a number of best-of-breed systems rather than one “umbrella” application from a single supplier (e.g. buying best-of-breed sales order processing, accounting, e-procurement, debt management, and similar applications, or buying just one supposedly all-embracing ERP system).
As you may have guessed, I’m a supporter of the best-of-breed approach – looking at an analogy, if you were seriously ill and needed treatment, I’m sure that we’d all want to see a doctor/consultant who specialised in treating our illness, not just any general doctor – and the same can be said for software applications – we would like to use a specialist supplier.
As with illnesses (we would deal with a cold and a serious illness differently), a lot depends on what applications are most important for our business/organisation – which applications can help best to increase sales, avoid cost or improve service? These are the applications where best-of-breed solutions should be adopted first. For many fast growing businesses, this means that they are happy taking a generalist view of, say, their finance function, whilst really focussing on benefits from implementation of best-of-breed CRM, marketing and sales applications geared towards their particular market. Meanwhile, established companies may wish to focus more on specialist applications to address costs and/or assist manufacturing or service delivery.
Yes, there are potential drawbacks of having to deal with a larger number of suppliers (rather than just a single, say, ERP supplier), and dealing with disputes between suppliers over whose problem a fault is, but these can be mitigated if the supply/support contracts are negotiated properly. I’d argue that you’re more likely to get better support from a smaller, best-of-breed supplier, who has a reputation to retain in his chosen (possibly, only) market, rather than a global supplier whose focus may not be in your chosen market.
Unfortunately, there can be too many of the wrong reasons for buying software solutions. The type of phrase “you can’t get fired for buying IBM” lives on in markets such as ERP and CRM – particularly when there can be a gravy train of seemingly never-ending services work for consultancies employed to shoe-horn a badly fitting generalist application into a business/organisation for which the application was never designed.
In the Public Sector I continue to be amazed at the number of authorities that have paid vast sums of money for full-blown CRM systems that are now used as just advanced call-handling/routing systems; or ERP systems where, after changing the organisation’s business practices so that they matched the way the ERP system worked, the promises of “one data warehouse for all financial information” is nowhere near realisation, even though the project is years late and way over budget.
All the big successes though, seem to be the best-of-breed applications, developed, implemented and supported by companies that really know their chosen market and requirements.
I’m a firm believer in solving the “how do you eat an elephant” riddle by taking “one bite at a time”. As regular readers will know, I’m not in favour of projects which take longer than a couple of years to complete – changing requirements and staff over any longer period than 2 years will elongate the project, put it over-budget and put at risk the planned benefits from the implementation. An incremental approach using best-of-breed applications will almost always be cheaper and faster than an attempt at a big-bang approach, and have the added benefit of actually doing what end user and management want, delivering real business benefits.
Hence my views on How NHS NPfIT should have been procured. Small is not only beautiful, it’s also practical, cheaper and faster – and is more likely to succeed......
As you may have guessed, I’m a supporter of the best-of-breed approach – looking at an analogy, if you were seriously ill and needed treatment, I’m sure that we’d all want to see a doctor/consultant who specialised in treating our illness, not just any general doctor – and the same can be said for software applications – we would like to use a specialist supplier.
As with illnesses (we would deal with a cold and a serious illness differently), a lot depends on what applications are most important for our business/organisation – which applications can help best to increase sales, avoid cost or improve service? These are the applications where best-of-breed solutions should be adopted first. For many fast growing businesses, this means that they are happy taking a generalist view of, say, their finance function, whilst really focussing on benefits from implementation of best-of-breed CRM, marketing and sales applications geared towards their particular market. Meanwhile, established companies may wish to focus more on specialist applications to address costs and/or assist manufacturing or service delivery.
Yes, there are potential drawbacks of having to deal with a larger number of suppliers (rather than just a single, say, ERP supplier), and dealing with disputes between suppliers over whose problem a fault is, but these can be mitigated if the supply/support contracts are negotiated properly. I’d argue that you’re more likely to get better support from a smaller, best-of-breed supplier, who has a reputation to retain in his chosen (possibly, only) market, rather than a global supplier whose focus may not be in your chosen market.
Unfortunately, there can be too many of the wrong reasons for buying software solutions. The type of phrase “you can’t get fired for buying IBM” lives on in markets such as ERP and CRM – particularly when there can be a gravy train of seemingly never-ending services work for consultancies employed to shoe-horn a badly fitting generalist application into a business/organisation for which the application was never designed.
In the Public Sector I continue to be amazed at the number of authorities that have paid vast sums of money for full-blown CRM systems that are now used as just advanced call-handling/routing systems; or ERP systems where, after changing the organisation’s business practices so that they matched the way the ERP system worked, the promises of “one data warehouse for all financial information” is nowhere near realisation, even though the project is years late and way over budget.
All the big successes though, seem to be the best-of-breed applications, developed, implemented and supported by companies that really know their chosen market and requirements.
I’m a firm believer in solving the “how do you eat an elephant” riddle by taking “one bite at a time”. As regular readers will know, I’m not in favour of projects which take longer than a couple of years to complete – changing requirements and staff over any longer period than 2 years will elongate the project, put it over-budget and put at risk the planned benefits from the implementation. An incremental approach using best-of-breed applications will almost always be cheaper and faster than an attempt at a big-bang approach, and have the added benefit of actually doing what end user and management want, delivering real business benefits.
Hence my views on How NHS NPfIT should have been procured. Small is not only beautiful, it’s also practical, cheaper and faster – and is more likely to succeed......
Tuesday 3 February 2009
e-procurement marketplaces - and one to watch
Following on from Monday’s post on pure play e-procurement suppliers, I was asked about e-procurement marketplaces, how they fit into the e-procurement market and how well are they performing.
The dot.com boom saw the rise of a plethora of e-procurement marketplaces - too many – and it was inevitable that there would be a severe rationalisation. I believe that now there are only two marketplaces/suppliers that will survive long term....
E-Governm
ent Solutions (EGS) did well to partner with IDeA to create the IDeA Marketplace, and see off most of the other public sector marketplace suppliers in England & Wales. They seem to have continued to grow on the back of developing partnerships with both customers and suppliers, although I’ve always thought that their partnership with OGCBuying.Solutions would give them more problems than benefits. However, EGS appear to have managed to get that all important critical mass – processing over £1bn of transactions each year – and developing specialist marketplaces for specific markets - that should see it survive long-term – provided it keeps meeting it customers’ and suppliers’ needs.
eProcurement Scotl@nd (ePS) appears to have achieved the same in Scotland –
but only on the back of a massive investment by the Scottish Executive. The PR coming out of ePS is strong – “The eProcurement Scotl@nd service is one of the most comprehensive and successful Public Sector eGovernment initiatives in the world” – and take-up by both suppliers and organisations appears to have been good. But I keep hearing doubts raised by senior Officers in some customer sites that ePS is not delivering the benefits that they want to see – partially on purchase prices, but particularly in the area of back office processing.
I continue to believe that the way for any marketplace to succeed is to partner effectively with all parties involved. EGS has done this, and in particular has partnered with Financial Management System (FMS) suppliers rather than try to compete with them. ePS, meanwhile, seems not to have partnered so well with FMS suppliers, but seeks to replace their procurement systems – i.e. rather than be a true hub-like marketplace, it is seeking to extend its footprint too far into the customers’ sites – meaning that their customers cannot achieve the full back office integration.
My personal opinion is that ePS needs to adopt a more open approach to partnerships if it is to survive. Also, I would doubt that ePS could survive long-term if The Scottish Executive removed its very active support. Meanwhile, EGS has a business model that should let it survive, indeed thrive, long term.....
One to watch – is Due North, a subsidiary of AIM-listed Access Intelligence –
which supplies e-sourcing systems on a hosted basis to a small number of local authorities, emergency services and other Public Sector organisations. Although a very small business that had no clear focus to date, Access intelligence has just had a cash injection by Elderstreet Investments, appointed Michael Jackson (former Chairman of Sage) as Executive Chairman, announced the divestment of most of its acquisitions of the past few years, and a focus on SaaS.
I always regarded Due North as a strong supplier on the few occasions we met them in tenders – their solution is liked by its end users, is seemingly quick to implement, and providing it on a SaaS basis is the right way forward. I doubt that they will develop their “portals” into serious competitors for IDeA Marketplace (nor ePS), but will aim to stay in their e-sourcing niche and no doubt aim to work with the established marketplaces. And if they have access to additional funds, perhaps they may seek out an acquisition or two to help them build on what is currently a very small base. They may be a minnow at the moment, and have quite an uphill struggle ahead of them – but I suspect that they may have the ideas and the funds to become a significant player.
The dot.com boom saw the rise of a plethora of e-procurement marketplaces - too many – and it was inevitable that there would be a severe rationalisation. I believe that now there are only two marketplaces/suppliers that will survive long term....
E-Governm
ent Solutions (EGS) did well to partner with IDeA to create the IDeA Marketplace, and see off most of the other public sector marketplace suppliers in England & Wales. They seem to have continued to grow on the back of developing partnerships with both customers and suppliers, although I’ve always thought that their partnership with OGCBuying.Solutions would give them more problems than benefits. However, EGS appear to have managed to get that all important critical mass – processing over £1bn of transactions each year – and developing specialist marketplaces for specific markets - that should see it survive long-term – provided it keeps meeting it customers’ and suppliers’ needs.eProcurement Scotl@nd (ePS) appears to have achieved the same in Scotland –
but only on the back of a massive investment by the Scottish Executive. The PR coming out of ePS is strong – “The eProcurement Scotl@nd service is one of the most comprehensive and successful Public Sector eGovernment initiatives in the world” – and take-up by both suppliers and organisations appears to have been good. But I keep hearing doubts raised by senior Officers in some customer sites that ePS is not delivering the benefits that they want to see – partially on purchase prices, but particularly in the area of back office processing.I continue to believe that the way for any marketplace to succeed is to partner effectively with all parties involved. EGS has done this, and in particular has partnered with Financial Management System (FMS) suppliers rather than try to compete with them. ePS, meanwhile, seems not to have partnered so well with FMS suppliers, but seeks to replace their procurement systems – i.e. rather than be a true hub-like marketplace, it is seeking to extend its footprint too far into the customers’ sites – meaning that their customers cannot achieve the full back office integration.
My personal opinion is that ePS needs to adopt a more open approach to partnerships if it is to survive. Also, I would doubt that ePS could survive long-term if The Scottish Executive removed its very active support. Meanwhile, EGS has a business model that should let it survive, indeed thrive, long term.....
One to watch – is Due North, a subsidiary of AIM-listed Access Intelligence –
which supplies e-sourcing systems on a hosted basis to a small number of local authorities, emergency services and other Public Sector organisations. Although a very small business that had no clear focus to date, Access intelligence has just had a cash injection by Elderstreet Investments, appointed Michael Jackson (former Chairman of Sage) as Executive Chairman, announced the divestment of most of its acquisitions of the past few years, and a focus on SaaS.I always regarded Due North as a strong supplier on the few occasions we met them in tenders – their solution is liked by its end users, is seemingly quick to implement, and providing it on a SaaS basis is the right way forward. I doubt that they will develop their “portals” into serious competitors for IDeA Marketplace (nor ePS), but will aim to stay in their e-sourcing niche and no doubt aim to work with the established marketplaces. And if they have access to additional funds, perhaps they may seek out an acquisition or two to help them build on what is currently a very small base. They may be a minnow at the moment, and have quite an uphill struggle ahead of them – but I suspect that they may have the ideas and the funds to become a significant player.
Monday 2 February 2009
Update on e-procurement suppliers
Following on from my post on e-procurement – supplier take-up is still the problem I’ve been asked what has happened to the pure-play e-procurement suppliers to the UK Public Sector that I commented on last year in my post After Anite and IBS – where’s the next big acquisition?
From what I’ve seen, the situation for those companies, Proactis and @UK, in the UK Public sector has deteriorated over the past year. I can but repeat my assessment of last year “My own belief is that pure-play e-procurement companies are unlikely to survive long term – no matter how good their products, in the longer term most customers will look to buy procurement systems along with their financial and/or other systems.”
This seems to have been borne out by the Public Sector procurements of new systems over the past year - limited in number, they have typically resulted in the purchase of a financial management information system with its own e-procurement or spend control functionality. Without firm partnerships with those FMIS suppliers, I fear for both suppliers in that market.
Proactis
Since its float on AIM back in 2006, Proactis has seen its share price decline 90% from a peak of 109p down to it current 10.5p, valuing the company at just £3.2M, under half of last year’s reported revenue of £6.6M (when the company reported a £0.5M loss after large one-off costs for restructuring following (in)digestion of its acquisitions).
With its move into other markets, and international coverage, Proactis will, I believe, survive and, once we move into a more positive financial environment, should thrive as companies look to replace outdated back office systems. Whilst they do sell directly, they have focussed on building their network of accredited resellers, and have diversified their offerings away from just pure e-procurement and spend control. Although loss-making, they are cash generative and do not, apparently, have to go to their bank to refinance any loans.
However, as a company that came to the market with great expectations, Proactis has suffered from poor investor confidence through the unexpected profits warning last year, and it market cap now sits at a level equal to just its recurring revenue, and its shares on a large bid/offer split of 8/13p. Apparently now unloved on AIM, where will Proactis go?
As I noted last year, I believe that there is a strong chance that Proactis will be acquired by a bigger player (see my post from last year for the names of some potential candidates). Proactis should give a trading update when they announce their interim results around the mid- to end- March – it will be interesting to see how they’ve survived the current credit crunch.....
ATUK
It will be even more interesting to see how (if?) @UK is surviving. By my calculation, unless it’s seen a big improvement, its continuing cash burn will mean that this runs out of cash sometime later this year. It appears to have done well to win an OGC buying solutions framework for data manipulation and spend analysis last year, but is only one of 8 successful bidders, and it’s difficult to see how much revenue will flow @UK’s way.
As I noted in my post from last year, I don’t think @UK’s business model will fly – it’s been constantly loss-making since its formation, losing £2.37M in the last full year, and reporting a £0.67M loss at last interims, on revenue declining by 7% to £1.08M, and burning £0.6M in the six month period.
With only c £1.2M cash in the bank at 30 June 2008, @UK needs to do something pretty drastic to survive long-term. I’m not sure that any of the major players will be interested in buying a company with such minimal revenue and large annual losses – the only possible purchaser might be a company running a marketplace that could integrate the @UK business at minimal extra cost.
Perhaps @UK will back out of its e-procurement market (or try to sell it?) and concentrate on just its company formations business, which would appear to be profitable. Last year saw the ousting of both CEO (the very competent and experienced Grant Oliver) and Chairman (Bernard Fisher), and the forcing through of an ability to raise £500k by a highly-dilutive share placement (not open to all shareholders) that will triple the shares in circulation and value the company at just £840k.
Rumours are also circulating that attempts to purchase the company formations arm have been rebuffed; and that now the business appears to be back in the hands of the original founders, it will de-list and split into two separate companies – the e-procurement bit (to be sold off or closed?) and the company formations bit.
Even with an additional £500k, the current rate of cash burn sees the company run out of cash around the year-end - so I’m sure that 2009 will be a crunch year for @UK – it will be interesting to see how it all pans out.....
From what I’ve seen, the situation for those companies, Proactis and @UK, in the UK Public sector has deteriorated over the past year. I can but repeat my assessment of last year “My own belief is that pure-play e-procurement companies are unlikely to survive long term – no matter how good their products, in the longer term most customers will look to buy procurement systems along with their financial and/or other systems.”
This seems to have been borne out by the Public Sector procurements of new systems over the past year - limited in number, they have typically resulted in the purchase of a financial management information system with its own e-procurement or spend control functionality. Without firm partnerships with those FMIS suppliers, I fear for both suppliers in that market.
Proactis
Since its float on AIM back in 2006, Proactis has seen its share price decline 90% from a peak of 109p down to it current 10.5p, valuing the company at just £3.2M, under half of last year’s reported revenue of £6.6M (when the company reported a £0.5M loss after large one-off costs for restructuring following (in)digestion of its acquisitions).
With its move into other markets, and international coverage, Proactis will, I believe, survive and, once we move into a more positive financial environment, should thrive as companies look to replace outdated back office systems. Whilst they do sell directly, they have focussed on building their network of accredited resellers, and have diversified their offerings away from just pure e-procurement and spend control. Although loss-making, they are cash generative and do not, apparently, have to go to their bank to refinance any loans.
However, as a company that came to the market with great expectations, Proactis has suffered from poor investor confidence through the unexpected profits warning last year, and it market cap now sits at a level equal to just its recurring revenue, and its shares on a large bid/offer split of 8/13p. Apparently now unloved on AIM, where will Proactis go?
As I noted last year, I believe that there is a strong chance that Proactis will be acquired by a bigger player (see my post from last year for the names of some potential candidates). Proactis should give a trading update when they announce their interim results around the mid- to end- March – it will be interesting to see how they’ve survived the current credit crunch.....
ATUK
It will be even more interesting to see how (if?) @UK is surviving. By my calculation, unless it’s seen a big improvement, its continuing cash burn will mean that this runs out of cash sometime later this year. It appears to have done well to win an OGC buying solutions framework for data manipulation and spend analysis last year, but is only one of 8 successful bidders, and it’s difficult to see how much revenue will flow @UK’s way.
As I noted in my post from last year, I don’t think @UK’s business model will fly – it’s been constantly loss-making since its formation, losing £2.37M in the last full year, and reporting a £0.67M loss at last interims, on revenue declining by 7% to £1.08M, and burning £0.6M in the six month period.
With only c £1.2M cash in the bank at 30 June 2008, @UK needs to do something pretty drastic to survive long-term. I’m not sure that any of the major players will be interested in buying a company with such minimal revenue and large annual losses – the only possible purchaser might be a company running a marketplace that could integrate the @UK business at minimal extra cost.
Perhaps @UK will back out of its e-procurement market (or try to sell it?) and concentrate on just its company formations business, which would appear to be profitable. Last year saw the ousting of both CEO (the very competent and experienced Grant Oliver) and Chairman (Bernard Fisher), and the forcing through of an ability to raise £500k by a highly-dilutive share placement (not open to all shareholders) that will triple the shares in circulation and value the company at just £840k.
Rumours are also circulating that attempts to purchase the company formations arm have been rebuffed; and that now the business appears to be back in the hands of the original founders, it will de-list and split into two separate companies – the e-procurement bit (to be sold off or closed?) and the company formations bit.
Even with an additional £500k, the current rate of cash burn sees the company run out of cash around the year-end - so I’m sure that 2009 will be a crunch year for @UK – it will be interesting to see how it all pans out.....
Subscribe to:
Posts (Atom)