October 2011 Archives

NHS IT project is dead, but why do large IT projects fail? Part 15

Karl Flinders | No Comments
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com , asks the question: Why do large IT projects fail? Here is the first part.

Today I am am featuring a response from a reader about the last post I placed, which was the views of  Milan Gupta,  chief architect at Barclays bank. Here it is.

Here are the other parts already published: Part 1 Brian Randell, part 2 Anthony Finkelstein, part 3 Yann L'Huillier, part 4 James Martin, part 5 Philip Virgo , part 6 Tony Collins, part 7 ILan Oshri, part 8, Robert Morgan part 9 Sam Kingston, part 10 Peter Brudenal, part 11 Mark Lewis,  part 12  John Worthy and part 13 Stuart Drew.

I will be featuring more comments from readers over time so pleaser put your thoughts in the commentrs box.

The response to part 14 from Milan Gupta at Barclays comes from a reader going by the name of Matt.

He says, "Interesting comments, but most of the really big project failures we've seen are in the public sector, where the business does not change all that fast. The problem instead is that the business is often so complicated that even the business users do not understand how it all works, especially the senior civil servants and politicians who are typically responsible for setting the overall scope, budget and timescale of the project. As the saying goes, most projects fail at the start, not at the end.

But Mr Gupta makes an excellent point about removing the layers between user and developer. Many projects - especially in these days of outsourcing/offshoring - suffer from the number of interfaces between individuals/departments/organisations that have to be negotiated every time a problem is identified or a question is asked. Add to this the tendency of suppliers to hide problems from the client, and the client's tendency to hide their ignorance of their own business requirements from these tiresomely inquisitive suppliers, and it is frankly amazing that any information ever makes it across these interfaces at all.

Agile approaches can make this situation worse, because the real requirements are only fully identified (or not) very late in the development process, so there is ample scope for mission creep, unresolved misunderstandings and nasty surprises.

Complex architectures and over-engineered designs can also add to this problem, especially in the public sector where both the client and the supplier think complexity is in itself a good thing (the client because it makes them feel special and gives them an excuse not to understand their own business, and the supplier because they can charge more for it). Some of this complexity may be inevitable, but in my experience you often end up with too many people in the process who see their roles as being mainly about generating confusion, complexity and obfuscation, rather than clarifying matters.

As for the idea of taking 90 days "from user story specification to production" in the public sector, dream on! I've spent longer than that trying to get an answer to a single question regarding specific requirements on a government project.

Anyway, after several years working as an independent contractor on government projects, I could really do with working on the kind of project Mr Gupta describes...!"

Public sector IT jobs plummeting and software suppliers are recruiting the most

Karl Flinders | 1 Comment
| More

I have just received the latest figures from Salary Services Limited (SSL) on the IT job vacancies out there.

One of the most interesting revelations was just how much recruitment the software houses/consultancies are doing. In fact George Molyneuax, who puts together the SSL research, says these companies are struggling to fill vacancies.

The latest figures revealed that in the third quarter of the year there were 44,112 permanent and 8,176 freelance IT jobs advertised by software houses/consultancies. This compares to 14,873 and 6,185 by finance firms and a staggeringly low 605 and 297 by public sector organisations.

The vacancies in the software/consultancies segment were 18% higher for permanent roles and 23.9% higher for freelance jobs than the third quarter last year.

The outlook for the public sector looks set to get worse. The National Audit Office this week said in a report that IT jobs in government are likely to be cut further.

So it looks like public sector IT staff will have to look at the private sector and more specifically the software supplies sector for opportunities. I recently did a survey asking whether IT professionals thought public sector IT workers were cut out to do a job in the private sector. I received had exactly 100 responses and 51% said public sector IT workers are not equipped to do private sector IT jobs, while 49% said they were.

How do you transfer from public sector IT to the private sector?

I asked the following questions in a blog post and had this advice from people in the IT profession:

What advice would you give to public sector IT professionals attempting to get into the private sector?

"Be prepared to start lower than your pay grade and work your way up by learning that business speaks more clearly than politics. Numeracy."

"Rethink your aspirations and attitude.  Start shouldering some responsibility and read industry magazines to at least try to stay in touch with the pace of technology."

"Go contracting."

"Be prepared for an awful lot of knockbacks based on preconceptions of what the recruitment industry and the industry itself thinks you are."

What are the main differences were between working in public sector IT and private sector IT.

"Public sector IT is much larger, and is driven by the commercial department instead of IT.  The solution focuses primarily on the numbers and the overall business benefit comes way down the list.  If the public sector were to consider the overall cost of government IT, including the ridiculous number of commercial managers through the life of the contract, then they would probably realise that it makes better sense to start pulling some of the IT work back in house.  It's an outsourcers dream when they look at UK PLC."

"I would differentiate private sector into: Public Suppliers and Private Suppliers first. Words that describe working in Public sector: individual islands, frustration, working for a department, shirking any accountability, fear of misinterpretation, bunker mentality, ordered, driven by job security, stove-piped hierarchy without leadership. Words to describe Public Suppliers: (same as Public sector!) because it can use the same techniques to maintain high prices, and long contracts to block competition.  Words to describe working for Private Suppliers: driven by success or competitive failure, focus on working as a project team, learn by being allowed to make mistakes, recognition by peers, growth is seen as positive instead of a further cost to the nation."

"The private sector is vastly more aggressive environment."

"The main difference I've noticed is the willingness to take decisions instead of fudging them and management and direction being committee-bound. Also, for the most part, I haven't noticed the same commercial pressures or the same time is money consciousness in the public sector. So, in many respects it's the attitude once again, but not of those on the front line, more the attitudes of those who are in management layers of B2 and above."

What IT skills are most in demand in the private sector?

"In the private sector you are actually being encouraged to make improvements rather than just talking about them or indeed using "oh dear" legislation to block improvements in the public sector."

"My recent experience of private sector tells me that web skills, agile and RAD, and architecture to platform systems over the long term enabling re-use and sharing."

"Architecture."

What opportunities are there for public sector IT professionals in the private sector?

"I work in the public sector.  Having come over from the private sector I can't see a lot of people that would be able to make the transition the other way.  I think that the key skill that is lacking tends to be attitude.  There are a lot of very good and very clever civil servants, but they are in the minority and I can see that they are usually destined to reach the higher levels of management."

"Unfortunately I don't there are many opportunities for public sector staff, perhaps supplier management."

"For my own part (defence) it appears to be the opportunities are limited to poacher turned gamekeeper - moving to defence suppliers as either project/engineering resources or as interims. It's pretty bleak. Yet, there are still companies where you would expect defence IT professionals to gravitate to, but for some reason the skills don't appear to be transferable."

What training would you suggest IT workers that are looking to move from the public sector to the private sector take up?"

"Courses in risk taking, assertiveness and simple finance to help understand profit as a driver for change."

"It depends on the level of staff and what role they currently do or would aspire to in the private sector.  I suppose things like agile methodology, web technologies, architecture skills, service management."

"TOGAF or ITIL, depending on job." Read more about TOGAF with this free dowload from Computer Weekly.

"Java, Agile, ITIL, Prince - the usual offenders."

Public sector IT jobs plummeting and software suppliers are recruiting the most

Karl Flinders | No Comments
| More

I have just received the latest figures from Salary Services Limited on the IT job vacancies out there.

One of the most interesting revelations was just how much recruitment the software houses/consultancies are doing. In fact George Molyneuax, who puts together the SSL research, says these companies are struggling to fill vacancies.

The latest figures revealed that in the third quarter of the year there were 44,112 permanent and 8,176 freelance IT jobs advertised by software houses/consultancies. This compares to 14,873 and 6,185 by finance firms and a staggeringly low 605 and 297 by public sector organisations.

The vacancies in the software/consultancies segment were 18% higher for permanent roles and 23.9% higher for freelance jobs than the third quarter last year.

The outlook for the public sector looks set to get worse. The National Audit Office this week said in a report that IT jobs in government are likely to be cut further.

So it looks like public sector IT staff will have to look at the private sector and more specifically the software supplies sector for opportunities. I recently did a survey asking whether IT professionals thought public sector IT workers were cut out to do a job in the private sector. I received had exactly 100 responses and 51% said public sector IT workers are not equipped to do private sector IT jobs, while 49% said they were.

How do you transfer from public sector IT to the private sector?

I asked the following questions in a blog post and had this advice from people in the IT profession:

What advice would you give to public sector IT professionals attempting to get into the private sector?

"Be prepared to start lower than your pay grade and work your way up by learning that business speaks more clearly than politics. Numeracy."

"Rethink your aspirations and attitude.  Start shouldering some responsibility and read industry magazines to at least try to stay in touch with the pace of technology."

"Go contracting."

"Be prepared for an awful lot of knockbacks based on preconceptions of what the recruitment industry and the industry itself thinks you are."

What are the main differences were between working in public sector IT and private sector IT.

"Public sector IT is much larger, and is driven by the commercial department instead of IT.  The solution focuses primarily on the numbers and the overall business benefit comes way down the list.  If the public sector were to consider the overall cost of government IT, including the ridiculous number of commercial managers through the life of the contract, then they would probably realise that it makes better sense to start pulling some of the IT work back in house.  It's an outsourcers dream when they look at UK PLC."

"I would differentiate private sector into: Public Suppliers and Private Suppliers first. Words that describe working in Public sector: individual islands, frustration, working for a department, shirking any accountability, fear of misinterpretation, bunker mentality, ordered, driven by job security, stove-piped hierarchy without leadership. Words to describe Public Suppliers: (same as Public sector!) because it can use the same techniques to maintain high prices, and long contracts to block competition.  Words to describe working for Private Suppliers: driven by success or competitive failure, focus on working as a project team, learn by being allowed to make mistakes, recognition by peers, growth is seen as positive instead of a further cost to the nation."

"The private sector is vastly more aggressive environment."

"The main difference I've noticed is the willingness to take decisions instead of fudging them and management and direction being committee-bound. Also, for the most part, I haven't noticed the same commercial pressures or the same time is money consciousness in the public sector. So, in many respects it's the attitude once again, but not of those on the front line, more the attitudes of those who are in management layers of B2 and above."

What IT skills are most in demand in the private sector?

"In the private sector you are actually being encouraged to make improvements rather than just talking about them or indeed using "oh dear" legislation to block improvements in the public sector."

"My recent experience of private sector tells me that web skills, agile and RAD, and architecture to platform systems over the long term enabling re-use and sharing."

"Architecture."

What opportunities are there for public sector IT professionals in the private sector?

"I work in the public sector.  Having come over from the private sector I can't see a lot of people that would be able to make the transition the other way.  I think that the key skill that is lacking tends to be attitude.  There are a lot of very good and very clever civil servants, but they are in the minority and I can see that they are usually destined to reach the higher levels of management."

"Unfortunately I don't there are many opportunities for public sector staff, perhaps supplier management."

"For my own part (defence) it appears to be the opportunities are limited to poacher turned gamekeeper - moving to defence suppliers as either project/engineering resources or as interims. It's pretty bleak. Yet, there are still companies where you would expect defence IT professionals to gravitate to, but for some reason the skills don't appear to be transferable."

What training would you suggest IT workers that are looking to move from the public sector to the private sector take up?"

"Courses in risk taking, assertiveness and simple finance to help understand profit as a driver for change."

"It depends on the level of staff and what role they currently do or would aspire to in the private sector.  I suppose things like agile methodology, web technologies, architecture skills, service management."

"TOGAF or ITIL, depending on job." Read more about TOGAF with this free dowload from Computer Weekly.

"Java, Agile, ITIL, Prince - the usual offenders."

Why do IT Projects Succeed?

Karl Flinders | No Comments
| More

I am currently running a series on the blog looking at the reasons why big IT projects fail. I have been asking experts on this subject to contribute and I have featured their individual contributions in blog posts.

Click here to see the last one, which contains links to all 14 featured so far. There are more in the pipeline. James Martin, who used to be European CIO at Lehman Brothers, contributed part 4 of the series.

James has now contributed with an article looking at the reasons why successful IT projects succeed.

Here it is:

Why IT Projects Succeed

By James Martin

James Martin.jpg"Computer Weekly recently ran a feature on why IT projects fail so I wanted to respond with some thoughts on why IT projects succeed. There are a few signals to look out for in a new project or programme which could help predict if it is more likely to succeed or could be heading for trouble from the start.

If any of these aspects are weak or absent, they can provide an early warning sign that a project may be late, over budget, cancelled or fail to deliver its promised benefits. If action is taken when these issues arise, the chances of a project completing successfully may be dramatically increased.
Many firms have rigorous project approval and budgeting processes but sometimes this can be more about going through the motions rather than taking a meaningful look at the cost, risk and probability of delivering the anticipated business benefits.

The firms I've seen do this best managed the process like an investment pitch involving the regional CIO, business sponsor, end users, finance, subject matter experts, vendors and external advisers. The meetings were like a blend of 'The Apprentice' and 'Dragon's Den' TV shows with the IT and business team pitching for project investment while being quizzed or challenged by their peers and experts from other departments.

This helped improve the quality of business cases as people didn't want to be shot down in such a high profile forum. The same process was used to review projects in flight. If a business case or project had deteriorated since original approval, they could be cancelled and staff redeployed to more valuable work. It was a very Darwinian approach but ensured limited budget was generally focused on the most worthwhile investments.

This is not a scientific or theoretical list, it's a collection of practical observations made since the mid-1990s working in IT management roles for a number of large financial organisations.

Robust business case

Is the business case robust, clear and compelling? There either needs to be a realistic and achievable return on investment (ROI) or a "cannot avoid" situation such as a regulatory requirement or IT security issue.  There are other "must do" examples like systems capacity and performance, replacing unsupported platforms and old hardware. If the business case could not withstand questioning in Lord Sugar's Boardroom, re-think it before going any further. Claiming a hypothetical benefit like saving 5 minutes a day for 300 staff doesn't count unless the staff cost will genuinely decrease or you can show how the bottom line will be directly improved. Talking about ROI over 5 years may not make sense if a new solution has an expected useful life of 2 years. There can be a lot of hot air in business cases so it's better to vent it at the beginning rather than get called out and cancelled half way through when the organisation figures out what's going on.

Organisational appetite

People close to the sponsors of a project probably think it's a great idea, but they would because they may have come up with it and then approached the most agreeable executives for support. A wider group must review proposed projects and think about them in terms of organisational objectives and whether or not the work is properly aligned with business priorities and timing. If organisational appetite is low, the project is setting itself up for potential cancellation or de-scoping later on. For example, one organisation refused to approve the most important strategic IT project requested by a business division. What the division did not know at the time was the parent firm was about to exit that line of business and did not wish to invest a substantial sum at that time even though the business case looked excellent at face value.

Learn from regulatory projects

Regulatory projects are often more successful than other types because the objectives, deadlines and consequences of failure are laid down by the regulator. This takes the "what?", "when?" and "why?" questions away from an organisation and only leaves the "how?" problem to solve. As the consequences of failing to deliver a regulatory project often have greater impact than the failure of other types, organisations tend to take more care of them. Take a look at how your firm's regulatory projects have been structured, who was involved and how they were managed. If your project is missing any of the key ingredients you've seen in a successful regulatory project, proceed with caution.

Split perception

Have you ever been in a project meeting with a group of really smart people and wondered how they collectively made some very poor decisions? It happens and it can be difficult to overcome if individuals feel they would be speaking out of turn or criticised in public for going against the grain. It's the corridor conversations afterwards that sometimes come up with the right answers, but they often don't make it back into the fabric of a project. If you sense a divergence between the formal view of a project and what people are talking about in private, it could be heading for trouble. Find out more about the issue and fix it before it develops into a full-scale split and throws the project off track.

Political football

In large organisations it is not unusual for people to have complex and diverse objectives, so making sure a project is at low risk of becoming a political football is key. You may find some people support a project because they think it's genuinely valuable and others may simply go along with it so they can show later it was a bad idea and step in with their own proposals. It pays to think about who might be interested in using a project as an example of 'what not to do' and dealing with it at an early stage. If a project has been widely communicated and all parties have had a chance to comment, this should flush out those who may not be in favour and provide an opportunity to resolve it before going further. It can be a bad sign if a project has started quietly without giving people a chance to comment. The project may be vulnerable to political disruption when it becomes visible later and those who were denied the chance to comment take steps to sink it.

Process vs progress

Project methodologies, processes, documentation and reporting are very important but must not be allowed to overshadow delivering the project itself. If an organisation has an unusually heavy emphasis on project administration, this may be in response to a recent history of unsuccessful projects. Unfortunately this can enable people to hide behind the method or overhead if a project fails.  Sophisticated methodologies, timesheets and reporting tools are unlikely to save a project if it is fundamentally flawed in other areas. A consistent approach is vital for large organisations but the most successful projects are run by skilled managers who navigate expertly through a methodology rather than blindly apply it by the book. It's the difference between a true artist and somebody painting by numbers. The focus must always be on delivering the project benefits with the methods and tools providing a means to that end, not an end in themselves.

Too big to succeed

If a project is longer than about 10 months, technically complex, delivering into a fast-moving business or spans more than one budget year, it faces higher risks and should be split into smaller, deliverable components each of which have some value as a standalone modules. With budgets running on an annual cycle, projects which span a fiscal year-end can risk losing funding in favour of higher priorities. Technical complexity can lead to unpredictable time or cost extensions and if the business opportunity has evaporated by the time the project lands, the effort may have been wasted anyway. For a large project to be successful, it needs to be structured as a flexible programme of smaller projects which provides staged benefit delivery and exit points if the organisation needs to change direction or priority along the way.

The right structure

The right structure and organisational participation is key to the success of all but the smallest projects. An IT team may be very capable of developing a solution in isolation but it is unlikely to be successful as a project overall. It may sound obvious to insist on user representation during a project but it is always worth running through the whole organisation chart and considering whether finance, audit, compliance, HR, operations, facilities and any other departments should also be represented. There is a balance to be struck between keeping project involvement tight and making sure the right people are included. Once the full scope of involvement has been established, the structure and roles must be designed carefully so everyone knows what their level of involvement will be. A successful project needs to be integrated effectively into an organisation, not tacked on like an afterthought.

Focus and dedication

Splitting key resources across several projects is often a recipe for disaster as people have a natural tendency to spend time on the things that interest them the most or are the least problematic. If key resources are split between multiple projects, a trend can emerge where certain projects are absorbing more time than they should making it difficult to manage or forecast progress. Timesheet systems are supposed to help control this but I've not yet seen one used effectively over a meaningful period of time. If a project is important, it should be important enough to warrant dedicated resources in its key roles. If it doesn't, it may say something about how important the project really is to the organisation. There are exceptions, but if a project is worth doing, the best approach is often to allocate people full-time and get it done fast rather than spin it out for months in parallel with a host of other work.

People who mean it

The people who get projects done most successfully tend to be people who believe strongly in what they're doing. They may not always be methodology or subject matter experts but they know how to get from A to B and sweep people along with them. They're not just there to follow a recipe and take the money, they're on a mission to reach a goal. A project needs people like this in its leading roles to drive it forward, steer it through challenges and motivate everyone else involved. These people can be tough for an organisation to deal with, but if you don't see any of them in a project, you may never see the end of the project either.

Conclusion

It's easy to criticise project failures with the benefit of hindsight but there are some basic steps that can be taken to improve their chances of success. The reason so many projects go astray is probably more to do with organisational culture than it is about the inherent capability of a project team, so providing the best environment for projects to thrive is essential. The right environment can help deliver even the most tortuous projects but a poor environment can cause even the simplest of endeavours to be bungled, often at great expense.

Success checklist

CHECK                                  TARGET

1  Business case                    Ensure it would survive a grilling in the Dragon's Den
2 Organisational appetite         Confirm the organisation wants it, not just the sponsors
3 Regulatory projects              Compare project setup to a successful regulatory project
4 Split perception                    Ensure formal and informal project viewpoints remain aligned
5 Political football                    Identify, manage and neutralise political footballers
6 Process vs progress             Focus on delivery, the method is only a means to an end
7 Too big to succeed               Break long or complex projects into 'valuable modules'
8 The right structure                Fully integrate the project into the organisation
9 Focus and dedication           Get the right people in the right roles, full-time if possible
10 People who mean it            Fill leading roles with people who are on a mission to deliver"

NHS IT project is dead, but why do large IT projects fail? Part 14

Karl Flinders | 1 Comment
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com , asks the question: Why do large IT projects fail? Here is the first part.

Here are the other parts already published: Part 1 Brian Randell, part 2 Anthony Finkelstein, part 3 Yann L'Huillier, part 4 James Martin, part 5 Philip Virgo , part 6 Tony Collins, part 7 ILan Oshri, part 8, Robert Morgan part 9 Sam Kingston, part 10 Peter Brudenal, part 11 Mark Lewis,  part 12  John Worthy and part 13 Stuart Drew.

Today is the view of Milan Gupta, chief architect at Barclays bank.

He says: "Large IT projects fail for the simple reason that business moves a lot faster than large projects ever can. It's a competitive world out there and to be on the cutting edge, agility is everything.

Gone are five year priority plans, today, businesses are living in the now adapting to market dynamics and eco-system changes daily. This does mean that by definition large IT projects are doomed to failure because by the time they've reached completion, the business has changed.

There are a number of things you can do to mitigate this risk by doing projects in smaller chunks - typically 90 days from user story specification to production. Some other core principles to accelerate project execution:  balanced business and technical leadership, small top-talent co-located teams, decreasing the layers of "translators" between the end customer and the developer, continuous integration, and test driven development. It is fatal to allow a development team to disappear for a year before they put their software into production."

 

Suppliers must create SME cloud packages

Karl Flinders | No Comments
| More

I always here about the fact that the SME market is bigger than the Enterprise sector and big IT suppliers always claim to be targeting the sector. Yet SMEs always seem to remain second class citizens with few of the big players willing to  invest heavily in services specifically for SMEs.

Part of the problem is the risks involved with serving SMEs. It is a very fragmented market made up of companies of a plethora of sizes, in a wide range if industry sectors, and spread across a multitude of locations.

Surely with the arrival of cloud computing in the mainstream it is the opportunity for more suppliers to develop SME specific packages that can be easily accessed by SMEs. Public, private and public/private clouds will reduce the costs associated with reaching the SMEs.

In May last year I spoke to Tata Consultancy Services (TCS) about its trial of SME cloud services in its home country, India. TCS's UK head at the time A S Lakshmi said: "SMEs have the same requirements as large companies but it is difficult because they are very fragmented." I will get an update on that soon.

The reason I write this today is because I received the results of some research carried out by a hosting and could service provider Parallels. Its SMB Cloud Insights research, which you can download here, revealed a market worth £660m for SME cloud services.

It also found that 62% of SMEs plan to use cloud services.

According to the research this is what the SMEs want:

- 20% of micro SMBs (companies with 1-9 employees) currently use in-house servers, and of those 42% plan to switch from in-house to hosted servers in the next three years

- 50% of small SMBs (companies with 10-49 employees) have in-house servers, and 62%  of those are planning to switch to hosted servers in the next three years

- 28% of small SMBs and 31% of medium SMBs have e commerce capabilities, while only 15% of micro SMBs have these

- 50% of UK SMBs still design their websites in-house

- Facebook is the second leading form of web presence for SMBs with 28% actively using the website, followed by LinkedIn with 24% Only 4% of small and 11 percent of medium businesses pay for premium hosted e-mail services

- 12% of micro SMBs and 36 percent of small SMBs currently use in-house e mail servers

- While a significant portion of online application use is still free, UK SMBs plan a net increase of at least 10% in spending across several categories of online applications, including online accounting, phone conferencing and file sharing

Opinion split on whether public sector IT workers can hack it in the private sector

Karl Flinders | No Comments
| More

I blogged back in February about some research that revealed that over half (52%) of private sector companies a do not think public sector IT workers could do an effective job in the private sector.

I wrote this with the backdrop of public sector job cuts and a hope that the private sector would pick up the slack. The research was from the Financial Times and the 52% was from a sample of private sector employers.

I opened up the question to the IT industry so in a Google survey I asked: Are public sector IT workers equipped to do private sector IT jobs?

I have had exactly 100 responses and can reveal that 51% said public sector IT workers are not equipped to do private sector IT jobs, while 49% said they were. Pretty similar to the FT findings but the sample is probably mixed between public and private sector workers.

Here are some of the other questions I asked and the advice I got for public sector IT workers trying to break into the public sector.

What advice would you give to public sector IT professionals attempting to get into the private sector?

- "Be prepared to start lower than your pay grade and work your way up by learning that business speaks more clearly than politics. Numeracy."

- "Rethink your aspirations and attitude.  Start shouldering some responsibility and read industry magazines to at least try to stay in touch with the pace of technology."

- "Go contracting."

- "Be prepared for an awful lot of knockbacks based on preconceptions of what the recruitment industry and the industry itself thinks you are."

What are the main differences  between working in public sector IT and private sector IT?

- "Public sector IT is much larger, and is driven by the commercial department instead of IT.  The solution focuses primarily on the numbers and the overall business benefit comes way down the list.  If the public sector were to consider the overall cost of government IT, including the ridiculous number of commercial managers through the life of the contract, then they would probably realise that it makes better sense to start pulling some of the IT work back in house.  It's an outsourcers dream when they look at UK PLC."

- "I would differentiate private sector into: Public Suppliers and Private Suppliers first. Words that describe working in Public sector: individual islands, frustration, working for a department, shirking any accountability, fear of misinterpretation, bunker mentality, ordered, driven by job security, stove-piped hierarchy without leadership. Words to describe Public Suppliers: (same as Public sector!) because it can use the same techniques to maintain high prices, and long contracts to block competition.  Words to describe working for Private Suppliers: driven by success or competitive failure, focus on working as a project team, learn by being allowed to make mistakes, recognition by peers, growth is seen as positive instead of a further cost to the nation."

- "The private sector is vastly more aggressive environment."

- "The main difference I've noticed is the willingness to take decisions instead of fudging them and management and direction being committee-bound. Also, for the most part, I haven't noticed the same commercial pressures or the same time is money consciousness in the public sector. So, in many respects it's the attitude once again, but not of those on the front line, more the attitudes of those who are in management layers of B2 and above."

What IT skills are most in demand in the private sector?

- "In the private sector you are actually being encouraged to make improvements rather than just talking about them or indeed using "oh dear" legislation to block improvements in the public sector."

- "My recent experience of private sector tells me that web skills, agile and RAD, and architecture to platform systems over the long term enabling re-use and sharing."

- "Architecture."

What opportunities are there for public sector IT professionals in the private sector?

- "I work in the public sector.  Having come over from the private sector I can't see a lot of people that would be able to make the transition the other way.  I think that the key skill that is lacking tends to be attitude.  There are a lot of very good and very clever civil servants, but they are in the minority and I can see that they are usually destined to reach the higher levels of management."

- "Unfortunately I don't think there are many opportunities for public sector staff, perhaps supplier management."

- "For my own part (defence) it appears to be the opportunities are limited to poacher turned gamekeeper - moving to defence suppliers as either project/engineering resources or as interims. It's pretty bleak. Yet, there are still companies where you would expect defence IT professionals to gravitate to, but for some reason the skills don't appear to be transferable."
What training would you suggest IT workers that are looking to move from the public sector to the private sector take up?"

- "Courses in risk taking, assertiveness and simple finance to help understand profit as a driver for change."

- "It depends on the level of staff and what role they currently do or would aspire to in the private sector.  I suppose things like agile methodology, web technologies, architecture skills, service management."

- "TOGAF or ITIL, depending on job." Read more about TOGAF with this free dowload from Computer Weekly.

- "Java, Agile, ITIL, Prince - the usual offenders."

NHS IT project is dead, but why do large IT projects fail? Part 13

Karl Flinders | No Comments
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com , asks the question: Why do large IT projects fail? Here is the first part.

Here are the other parts already published: Part 1 Brian Randell, part 2 Anthony Finkelstein, part 3 Yann L'Huillier, part 4 James Martin, part 5 Philip Virgo , part 6 Tony Collins, part 7 ILan Oshri, part 8, Robert Morgan part 9 Sam Kingston, part 10 Peter Brudenal, part 11 Mark Lewis and part 12  John Worthy

I am looking for more comments. If you want to contribute please send you answer to the question: why do large IT projects fail? It must be under 200 words. Please send a short biog and a picture. I can't publish them all but I will consider them all. 

Part 13 today is from Stuart Drew, executive vice president at HCL Technologies Europe.

Stuart_Drew picture2.jpgBefore joining HCL, Stuart Drew was with Deloitte as senior director - financial services. He worked on the Congestion Charge project while at Deloitte. He joined Deloitte after seven years at Prudential, where he was a member of the retail board.

He says: "Every year millions of pounds are spent on high-profile IT projects, many of which involve experienced, big-name companies with access to a great pool of resources. But with this in mind, why do so many of them fail?  In my view, there are three principle reasons why major IT projects most commonly and consistently fail.
 
Firstly, I believe that large projects do not 'go' wrong - they 'start' wrong. I always tell project leaders to imagine that they are in the dock under cross-examination with the brief asking: 'When was the first time you thought this was off track?' Without exception, they always admit that the source of the problem was to be found long before they admitted it 'went wrong'. Contributing factors to this can be a fear of failure, a lack of deep enquiry on a regular basis, and a lack of rigour around change control.
 
The second issue is one of ineffective governance. Much lip service is paid to project governance, yet there are still too many people who do not understand what it is and how it should work. Shared accountabilities are dangerous, stakeholders are not all identified and handshakes between component contributors are too frequently unclear and undocumented.
 
Finally, failure to keep the end goal in mind can play a significant role. Project creep is too common and must be resisted at all costs, notwithstanding project ambitions also change. Overall, it's important that the single (it must be one) project manager must remain brutal in the rigour of their execution, and must always keep top of mind the ultimate objective."
 

Case studies will drive the rapid adoption of the cloud

Karl Flinders | No Comments
| More

I blogged earlier this week about just how much the cloud computing debate has moved on.
A year ago everybody was talking about the cloud. But there was not much context to what they were saying. Everybody had a cloud strategy or was devising one.

But this year when I think about the case study type articles I write and the conversations I have with businesses and IT suppliers I can see things have really moved on.

I gave a couple of examples in the blog post. These were Everything Everywhere setting itself the target of having 40% of its internal systems in the cloud within three years and International Personal Finance, which has embarked on a 12-month project to move its IT infrastructure into a private cloud which will cut costs by millions of pounds and make its planned expansion easier.

These case studies are coming thick and fast. And they are about companies in all sectors.

Yesterday I wrote two interesting case studies about businesses harnessing the cloud. There was energy firm Haven Power utilising the Amazon Web Services (AWS) cloud and the Royal Liverpool and Broadgreen University Hospital NHS Trust moving its data into a private cloud.

Case studies demonstrate the power of the cloud as well as its diverse role. They are really interesting because businesses are finding how the cloud offers so much more than the reason they decide to move to it in the first place. For example Haven Power wanted a disaster recovery option, but ended up with an extra IT infrastructure for development and testing as well.

They are a great way to help businesses understand what the cloud can do for them, rather than just talking a supplier's word for it. It also helps them see how other companies are actually doing cloud migrations.

And there are lots more.

This year looks set to be a major landmark for cloud computing as it moves from a "must have" to a "have and must get more out of it."

The government's Strategic Implementation Plan (SIP) for IT, which puts cloud computing at the heart of its £1.4bn cost saving programme for IT, says round 50% of all new IT spend will be made through cloud computing by 2015

Outsourcing will never be the same.

NHS IT project is dead, but why do large IT projects fail? Part 12

Karl Flinders | No Comments
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com soon, asks the question: Why do large IT projects fail?

 Here are the other parts already published: Part 1 Brian Randell, Part 2 Anthony Finkelstein, part 3 Yann L'Huillier, part 4 James Martin, part 5 Philip Virgo , part 6 Tony Collins, part 7 ILan Oshri, part 8, Robert Morgan, part 9 Sam Kingston, part 10 Peter Brudenal and part 11 Mark Lewis.

I am looking for more comments. If you want to contribute please send you answer to the question: why do large IT projects fail? It must be under 200 words. Please send a short biog and a picture. I can't publish them all but I will consider them all. 

Today is part 12 from John Worthy.

worthy_john.jpgJohn Worthy is a lawyer at Field Fisher Waterhouse. He has over 25 years' experience advising major corporates, banks and government agencies on their strategic IT and outsourcing transactions in the UK, Europe and worldwide. 

He says: "History is littered with IT projects running over time, over budget and under delivering. As a lawyer, I see many fail because some of the main foundations of the project contract are missing.

Sometimes the parties do not adequately specify the technical and performance requirements in the contract. So it is difficult for both supplier and customer to know what the system should deliver. Other times, the contractual processes for managing change are missing (or, worse, ignored).

Even then, projects can go astray where the agreement does not contain suitable project management structures. Without these, the parties may have to rely on good fortune, rather than proper disciplines.

If there is a serious problem in implementation, and the contract does not set out appropriate practical solutions, there is a risk of a downward spiral, where supplier and customer have to renegotiate the way forward from scratch.

Last, but certainly not least, the contract may be left in a drawer, instead of being used as a manual to run the project effectively.

While a carefully crafted agreement will not guarantee success, getting the right contract foundations will always help to achieve a positive result."

Cloud computing no longer just buzz but seismic shake to outsourcing

Karl Flinders | No Comments
| More

I have been asked by the National Outsourcing Association to speak at an event next month. At the event I will be talking about what trends I am seeing in the outsourcing sector.

I sat down the other day to put some thoughts together and after a few minutes it really hit me just how big this year has been for cloud computing in the IT outsourcing sector.

A year ago everybody was talking about the cloud. But there was not much context to what they were saying. Everybody had a cloud strategy or was devising one.

But this year when I think about the case study type articles I write and the conversations I have with businesses and IT suppliers I can see things have really moved on.

Recent examples include Everything Everywhere setting itself, and its supplier T-Systems, the target of having 40% of its internal systems in the cloud within three years. Read my interview with the CIO here.

Then there are companies such as International Personal Finance, which has embarked on a 12-month project to move its IT infrastructure into a private cloud which will cut costs by millions of pounds and make its planned expansion easier. Read my case study here.

This year could see clouds used by businesses get a whole lot thicker. More cumulonimbus than cirrus as companies put more and more IT into clouds.
From recent discussions with CIOs, IT directors and the like, it does appear that businesses are now ready to move deeper into the cloud.

At a recent meeting with a big supplier I was given the prediction that 60% of the average enterprise will have 60% of its applications in the cloud.

Last month I sat down with the global IT head at one of the UK's biggest banks. This was a meeting in advance of a raft of announcements set to come from the bank.

The bank is about to begin a process of wrapping a private cloud around all of its systems, both internal and those that face customers.

It was described to me as creating a cloud that customers and workers just point a device at to get to what they want. Obviously this is a big bank with lots of in-house IT expertise. But it will not be doing it itself but rather using an ecosystem of suppliers.

This brings me on to the new role of the IT outsourcing service provider. Forget systems integration it is now cloud integration.

Outsourced and insourced applications are of the same quality and there is no difference between onshore and offshore

Karl Flinders | No Comments
| More

I wrote an article today about research from Cast Software.

Using automated analysis tools the company's second annual Appmarq study measured the structural quality of 686 IT applications from 145 companies from across sectors.

It looked at about 320 million lines of code in development environments including Cobolt, Java, J2EE and .Net.

I spoke to Bill Curtis who is chief scientist at Cast Software. He is also the co-author of the software development Capability Maturity Model (CMM).

He told me a couple of interesting findings in relation to outsourcing.

He said the survey revealed that there was no difference in quality between applications that have been developed in-house and those where development was outsourced.

He also said there was no difference in quality between applications developed onshore and those developed offshore.

What do you think?

NHS IT project is dead, but why do large IT projects fail? Part 11

Karl Flinders | No Comments
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com soon, asks the question: Why do large IT projects fail?

I started with the comments made by Brian Randell. Randell is a professor of at the School of Computing Science at Newcastle University.

Then part 2 came from Anthony Finkelstein,  professor of software systems engineering at University College London (UCL) and dean of UCL Engineering.

Part 3, was from Yann L'Huillier, group CIO at financial services giant Compagnie Financiere Tradition..

Part 4 was from James Martin, the former IT COO Europe at investment bank Lehman Brothers.

Part 5 came from Philip Virgo , who is secretary general at the Information Society Alliance. He has nearly 40 years' experience of IT projects.

Part 6 was from investigative journalist Tony Collins.

Part 7 featured professor ILan Oshri, associate fellow at Warwick Business School and associate professor at the Rotterdam School of Management. 

In part 8, I featured comments from Robert Morgan, director at sourcing broker Burnt Oak Partners.

Part 9 were the comments of Sam Kingston, head at IT service provider T-Systems.

In part 10, I presented the views of Lawrence Grahan lawyer Peter Brudenal.

I am looking for more comments. If you want to contribute please send you answer to the question: why do large IT projects fail? It must be under 200 words. Please send a short biog and a picture. I can't publish them all but I will consider them all. 

Today, part 11,  is another lawyer. This time Mark Lewis at Berwin Leighton Paisner.

Thumbnail image for mark lewis.jpgMark is head of the outsourcing practice at BLP. He has specialised in IT and outsourcing for over 26 years and represents customers and providers, so understands both sides in any deal.

He says: "Customers, even big companies, lack internal resources to specify technical and operational requirements fully or at all.  Increasingly they are unwilling to engage consultants. So they start IT projects with little or no actual specification of what their business users need.

They hope the requirements will become clearer with time and that the supplier will help them specify, document and deliver them. (Not going to happen, of course.) Customer then signs up supplier to master services agreement with projects being called off piecemeal.

With no holistic project scope and changes in corporate strategy and business need, project scope changes and creeps and costs escalate. Timetables may be met (there are often penalties for missing them), but deliverables and services do not always meet the customer's needs.  With no clear or incomplete specifications, it is hard to pin blame on the supplier.

So customer has to go back to the drawing board, usually with the same supplier: more time and cost.  In the rare cases where a customer can pin blame on the supplier (because it can point to a clear contract specification or term that the supplier has failed to meet) we get to hear of the dispute." 

 

How many Blackberry users will shift to Apple?

Karl Flinders | No Comments
| More

Could a combination of factors soon see the number of Blackberry users plummet?

The problems suffered by Blackberry users this week could be another opening for its competitors. Blackberry users suffered problems using their data servers for three days this week. The problem started in the EMEA region but then spread to South America and the US.

In the past a problem like this might not have done that much damage to Blackberry given its position as the must have business mobile device. But this is not the case anymore.

I did a story in May last year about Standard Chartered bank's decision to dump the Blackberry as its chosen mobile phone for staff and rather move them onto the iPhone.

The bank says the iPhone is a way to develop in-house mobile applications, cut costs and enhance employee satisfaction. It has 75,000 employees. Part of the reason for doing this was to give employees the opportunity to use the devices they were used to when working.

This is becoming an increasing trend as companies adopt Buy Your Own Computer strategies. This allows workers to decide the computer devices they want to use at work. We all know how much people love Apple iPhones and iPads, so this could put Blackberry under even more pressure. I was with the CIO of another bank the other day and he had an iPhone and an iPad and he talked about Apple's increasing importance in business.

This will become a common occurance because the new generation of employees are very technology savvy and want to use the same technology in the office and at home. People born between 1982 and 2000, known as generation Y now a significant portion of the workforce and businesses need to have the right kind of technology in place to satisfy them.

Another major shift is the increasing maturity of the cloud. This is creating a situation where consumers point their mobile phones at a cloud whenever they want a service. Businesses will emulate this with private clouds that employees will link to using their device of choice. Employees and customers will probably be using the same devices.

Although Standard Chartered is going to develop its own applications for the iPhone there are already business applications available. I did an article back in 2009 about some of the business apps on the iPhone. I thought now might be the time to link to that article. Here is the article: Top twelve enterprising iPhone apps for business.

Here is a more recent article about business apps on the iPhone.

NHS IT project is dead, but why do large IT projects fail? Part 10

Karl Flinders | No Comments
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com soon, asks the question: Why do large IT projects fail?

I started with the comments made by Brian Randell. Randell is a professor of at the School of Computing Science at Newcastle University.

Then part 2 came from Anthony Finkelstein,  professor of software systems engineering at University College London (UCL) and dean of UCL Engineering.

Part 3, was from Yann L'Huillier, group CIO at financial services giant Compagnie Financiere Tradition..

Part 4 was from James Martin, the former IT COO Europe at investment bank Lehman Brothers.

Part 5 came from Philip Virgo , who is secretary general at the Information Society Alliance. He has nearly 40 years' experience of IT projects.

Part 6 was from investigative journalist Tony Collins.

Part 7 featured professor ILan Oshri, associate fellow at Warwick Business School and associate professor at the Rotterdam School of Management. 

In part 8, I featured comments from Robert Morgan, director at sourcing broker Burnt Oak Partners.

Part 9 were the comments of Sam Kingston, head at IT service provider T-Systems.

I am looking for more comments. If you want to contribute please send you answer to the question: why do large IT projects fail? It must be under 200 words. Please send a short biog and a picture. I can't publish them all but I will consider them all. 

Today, in part 10, I present the view of  Lawrence Graham lawyer Peter Brudenal.

Peter Brudenal is a specialist in technology and outsourcing law at . He has over 15 years' experience in advising companies on technology procurement, the outsourcing of services, contract disputes and software development. Recent work includes, advising the UK Home Office on a £250m outsourcing of IT work for the design, development and integration of a biometrics system for iris recognition.

"Although there is no single reason why the failure rate of IT projects is so high, I believe there are a couple of key factors that are often found in the aftermath of a project failure.  Firstly, the need for customers and suppliers to work together on a complex IT project is too often discussed and "agreed" prior to the contract being signed, but then forgotten about when the contract is drafted and in the practical administration of the project.  Customers often believe that the inclusion in the contract of a detailed list of specifications and requirements should be sufficient for the supplier to then go away and produce a "fit for purpose" system.  However, it will only be through constant dialogue, and often refinement of those contractual requirements in line with the customer's business objectives, that a successful outcome is likely to be achieved. This is too often not reflected in the contract.
 
Secondly, and I believe this is partly as a result of the high failure rate in IT projects, many customers have become very risk averse. As a result we are getting longer and longer contracts dealing with every possible eventuality.  This however, often has the effect of stifling the parties' ability to work together to solve problems, or change direction where necessary, and builds an adversarial layer into the relationship.  Instead, what we need are shorter, more flexible, results-oriented contracts that set out more accurately the collaborative manner in which most parties to a complex IT project want to work. "

NHS IT project is dead, but why do large IT projects fail? Part 9

Karl Flinders | No Comments
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com soon, asks the question: Why do large IT projects fail?

I started with the comments made by Brian Randell. Randell is a professor of at the School of Computing Science at Newcastle University.

Then part 2 came from Anthony Finkelstein,  professor of software systems engineering at University College London (UCL) and dean of UCL Engineering.

Part 3, was from Yann L'Huillier, group CIO at financial services giant Compagnie Financiere Tradition..

Part 4 was from James Martin, the former IT COO Europe at investment bank Lehman Brothers.

Part 5 came from Philip Virgo , who is secretary general at the Information Society Alliance. He has nearly 40 years' experience of IT projects.

Part 6 was from investigative journalist Tony Collins.

Part 7 featured professor ILan Oshri, associate fellow at Warwick Business School and associate professor at the Rotterdam School of Management. 

In part 8, I featured comments from Robert Morgan, director at sourcing broker Burnt Oak Partners.

I am looking for more comments. If you want to contribute please send you answer to the question: why do large IT projects fail? It must be under 200 words. Please send a short biog and a picture. I can't publish them all but I will consider them all. 

Here in part 9 we have the comments of Sam Kingston.Sam Kingston T-Systems.JPG

Sam is UK head at IT service provider T-Systems. He was previously head of EDS UK' commercial and was CIO at East Midlands Electricity when that industry was deregulated. This meant major changes to billing systems.

"The reasons why certain outsourcing deals can fail is that in a first generation outsourcing the supplier will have gone in with an optimistic price to win the deal and also the client will not of engaged their core business as to the impact that the deal is likely to have on the core business activities, e.g. business process change driven by application changes or infrastructure changes such as new end user workplace devices or unified communications solutions. There will also be the distraction of achieving penalty milestones instead of focusing on delivery of the programme as a whole.

In a second generation outsourcing deals the client is usually more alert to the possible impact of renewing the outsourcing deal and so greater effort and detail is put into defining for example the transition & transformation project elements. The transition & transformation will be technically more challenging as most of the "low hanging fruit" transformation benefits will have been completed in the first generation contract.  Thus possible causes of failure and delay can be related to: budget constraints; and the fact that the technology is bleeding edge and so getting hold of the correctly skilled resources available will be a challenge.

In subsequent outsourcing deals then the supplier and client will probably concluded that the best approach is to have a transparent and jointly managed programme with an agreed risk/reward scheme to incentivise both sides in the delivery of the programme.  Another prerequisite of success is that full business sponsorship will be in place and all key risks identify with a joint mitigation plan in place before the two parties sign the contract.  Failure of the projects would then be down to the more traditional reasons for project failure such as not managing the triple constraint of Schedule, Quality & Cost and poor stakeholder management."

NHS IT project is dead, but why do large IT projects fail? Part 8

Karl Flinders | 1 Comment
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com soon, asks the question: Why do large IT projects fail?

I started with the comments made by Brian Randell. Randell is a professor of at the School of Computing Science at Newcastle University.

Then part two came from Anthony Finkelstein,  professor of software systems engineering at University College London (UCL) and dean of UCL Engineering.

Part three, was from Yann L'Huillier, group CIO at financial services giant Compagnie Financiere Tradition..

Part 4 was from James Martin, the former IT COO Europe at investment bank Lehman Brothers.

Part 5 came from Philip Virgo , who is secretary general at the Information Society Alliance. He has nearly 40 years' experience of IT projects.

Part 6 was from investigative journalist Tony Collins.

Part 7 featured professor ILan Oshri, associate fellow at Warwick Business School and associate professor at the Rotterdam School of Management. 

I am looking for more comments. If you want to contribute please send you answer to thequestion: why do large IT projects fail? It must be under 200 words. Please send a short biog and a picture. I can't publish them all but I will consider them all. 

Today in part 8, I feature comments from Robert Morgan, director at sourcing broker Burnt Oak Partners. In the past he has applied his IT outsourcing expertise to a project to the virtualise DEFRA. He has repositioned major IT outsourcing deals at large organisations including Rolls Royce, Bombardier Transportation and DWP. He co-founded sourcing advisory Morgan Chambers and sold it to Equaterra, which was later acquired by KPMG.

He says: "Large IT projects fail broadly in three stages of the normal lifecycle:

Preparedness - A solid understanding and detailed business case of what, why and how the project will be undertaken is critical. All contributing or benefitting parties must have had their say, their role and responsibilities and agreed the commitment needed for success. Full overt executive sponsorship must be visible in all communications, budget and senior management effort - not just for the project kick-off but for every envisaged stage. Design, documentation, governance and reporting must be robust and fit for purpose too.

Execution - expect the unexpected and have multiple ways to handle change. Business must have the ability to understand "complex change" beyond technology, decide on the quality of facts, and act swiftly with clear understanding of likely impacts to budgets, timeframes, functionality and measures of success. SLA's must be tightly relevant to the business. Governance is no substitute for poor project management, however it can and should drive and escalate executive decision to reign in failing projects early.

Reviews - All large projects need pre-planned and crisis escalated reviews for executive decisions. They must constantly check that measures remain simple, relevant and challenging. That staff attrition is not affecting the projects ability to deliver and reinforce executive sponsorship."

 

 

 

There is more than meets the eye in BP multi-sourcing strategy?

Karl Flinders | No Comments
| More

I recently wrote about BP's multi-sourcing strategy which has seen it reduce the number of IT service suppliers it works with from about 3,000 to seven.

The article described, in the words of the oil giant's global CIO Dana Deasy, how the company managed it. Deasy was talking at the Gartner Outsourcing summit in London last month.

The case study is of interest to us all, not only because it reduced the number of suppliers so substantially, but because BP saved about $200m of its annual IT budget.

The article described some of the techniques used to keep the suppliers on their toes. During the talk however Deasy did not explain some of the finer detail. This is not a criticism because he was there to explain how he manages his smaller multi-sourcing environment.

But I will give a bit more detail. Computer Weekly was contacted by a small supplier after we wrote the article. The supplier said it has supplied BP for years and still does. What has changed said the source is that thousands of suppliers now work through another supplier. A combination of Computacenter in the UK and Compuware in the US manage thousands of sub-contractors, said the source.

So in actual fact BP still has thousands of suppliers but only manages seven strategically.  Even the Computacenter and Compuware part of the deal was not mentioned.

It seems a sensible route to take. The small supplier did however say that smaller players are being squeezed very hard on price under the model.

I did speak to a source close to one of BP's seven strategic suppliers. He told me the model used splits suppliers into three groups. There are: the seven strategic partners, who actually manage some other suppliers; then there is the Computacenter/Compuware tactical partner; and then there are lots of sub-contractors.

Nothing wrong with the model but I thought I should give more detail as I didn't do it earlier. This is one of the challenges writing stories from a conference when you can't expand with the person presenting.

Are Western IT services providers letting the Indians in for a second time? Or is it just IBM and Accenture?

Karl Flinders | No Comments
| More

I wrote a news story recently following a report from Deutsche Bank sent to me by a reader.

The report was the result of interviews carried out with four of Europe's top ten banks. The research was carried out by the German bank and management consultancy group Value Leadership Group.

It said that the big banks want to increase the proportion of work done offshore but incumbent suppliers most notably Accenture and IBM are not playing ball. IBM and Accenture have huge workforces in India but the banks are saying that they are moving more of the work onshore. This is adding cost for the customer.

"Most banks we polled complained that despite the service agreements, during the last financial year [multinational] firms like Accenture and IBM saw resource issues offshore and used a greater proportion of their onsite headcount while executing application development projects," said the report.

These service providers seem to be playing a risky game and the research revealed that the big Indian suppliers such as TCS and HCL are taking business from some incumbents.

For example HCL and TCS recently won sizable deals with Deutsche Bank itself. The HCL deal, which is for five years, will transform the support of Deutsche Bank's core applications with a service that will meet ITIL and LEAN global standards. Although no value was announced for the deal a source told me it is £300m. Then TCS won a deal with Deutsche Bank to transform IT support in its investment arm.

If this is right it would seem shocking that the Western multi-national suppliers would risk losing deals with big banks. It seems some suppliers haven't learnt from their mistakes of the past.

I met up with one of the pioneers of Indian IT services last year.  Ashok Soota was the executive chairman of tier-two Indian service provider MindTree when I spoke to him last year. He is better known for being the president of Wipro in the 80s and to late 90s. When Soota was at the top of IT India some of the senior executives of the big Indian players today were out in the field.

He said the reason the Indian suppliers became such big players in the IT outsourcing sector was because they took their eyes off the ball.

I think it is interesting to republish what he said back then given the trend revealed by Deutsche bank and Value Leadership Group.

"The suppliers in the West only started to feel threatened by us in 2000."

"Before 1994 Western IT companies were not really noticing us because we were mainframe maintenance."

"Then client/server came and they thought we could not do it. But we were."

"Then Y2K came along (millennium bug) and they thought we would go away afterwards. But Y2K gave Indian companies entry into big global companies."

"Then they did not think internet work could be done offshore, because of the need for a quick turnaround. But distance can be an advantage because you can work around the clock."

"The internet reduced transaction costs. Before this big players had dedicated pipelines. Now it became possible for a mid sized company to communicate with a mid sized company."

"It was 2004 by the time the big Western suppliers became anxious."

So what did they do? Well obviously they all moved to India.

So could the mistakes be being repeated? I mean banks are pretty important customers so you don't want to be losing too much business.

It might start with low cost services around application management and IT support but if the banks and Indian suppliers bolster their relationships there will probably be much more on offer.

NHS IT project is dead, but why do large IT projects fail? Part 7

Karl Flinders | No Comments
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com soon, asks the question: Why do large IT projects fail?

I started with the comments made by Brian Randell. Randell is a professor of at the School of Computing Science at Newcastle University.

Then part two came from Anthony Finkelstein. He is professor of software systems engineering at University College London (UCL) and dean of UCL Engineering.

Part three, was from Yann L'Huillier, group CIO at financial services giant Compagnie Financiere Tradition, who has also headed up IT at several of the world's stock exchanges.

Part 4 was from James Martin, the former IT COO Europe at investment bank Lehman Brothers.

Part 5 from Philip Virgo , who is secretary general at the Information Society Alliance. He has nearly 40 years' experience of IT projects.

Part 6 was from investigative journalist Tony Collins, who has revealed the problems in many an IT project, gives us his opinion on why large IT projects fail.

Today in part 7 it is Professor Ilan Oshri, who is an expert on outsourcing.

Ilan Oshri is associate fellow at Warwick Business School and associate professor at the Rotterdam School of Management.

 

ILAN OSHRI.jpgHe has authored books including:  Offshoring Strategies: Evolving Captive Center Models (2011, MIT Press);  Outsourcing Global Services (2008); Knowledge Processes in Globally Distributed Contexts (2008); Standards-Battles in Open Source Software (2008); and co-authored The Handbook of Global Outsourcing and Offshoring (2009).

He says:

"From my research I learned that failure happens in major IT outsourcing simply because both client and vendor are keen to get down to business instead of doing their homework properly. Put simply, client firms need to carefully examine and address some very basic questions prior to engaging in the actual project. Some of the questions we expect client firms to ask are: why to outsource? What's the alternative? What is the value in outsourcing and how value delivered through outsourcing improves the firm's short and long term strategic objectives? Client firms should also realise whether they have developed sourcing management capabilities to manage vendors according to some of the expectations discussed above.  While the expectation is to benefit from the value in outsourcing, our research shows that many client firms still focus on service level agreements and on daily operations. The end result is that many client firms fail to connect service delivery standards with the firm's strategic objectives. But even when such a connection between the operational and strategic objectives exists, value defined in the early stages of the outsourcing project will change over time. In other words, value is a dynamic concept that requires both clients and vendors to figure out ways to define and redefine as time goes by. Success in outsourcing is more likely to be achieved when client firms set up their expectations what can be achieved through outsourcing, communicate these expectations to their vendor and work with their vendor to define and redefine value delivered over time."

 

Tories and Fujitsu CEO spared embarrassing protest

Karl Flinders | No Comments
| More

Fujitsu's UK CEO was spared blushes yesterday as Fujitsu members of union Unite suspended a planned protest at the Tory party conference in Manchester, where he addressed a fringe meeting, and the small matter of a strike of Fujitsu workers in Manchester.

Unite members planned the strike and protest after Fujitsu allegedly breached agreements and victimised union representatives.

It seems Fujitsu agreed to come to the negotiating table in the eleventh hour and Fujitsu's UK CEO, Duncan Tait, was spared blushes. The same cannot be said for Theresa May, who had a catastrophic day.

Kevin O'Gallagher, Unite national officer, said: "Our members do not take strike action lightly. The agreement reached is good news for both our members and for Fujitsu. 

"Further talks are planned with the company. We hope this will produce an improved offer, which we will put to our members."
 

Don't let the face of your company become the backside

Karl Flinders | 1 Comment
| More

Callcentres are about the first thing we think of when it comes to outsourcing. Probably because callcentres are often the face, or even the backside, of the companies we deal with.
It is one of the most mature forms of BPO.

Even when customers complained about service levels reducing when banks put their callcentres in India companies continued to use outsourced callcentres.

It is important that any company using a call centre, supplied by a service provider, implements the same levels of security and monitoring as it would with an in-house operation.

Security lapses can do great harm. Remember when the personal details of UK citizens were being sold on the streets of Mumbai?

Despite this problems are still occurring. I wrote a story today about a scam carried out by four callcentre workers in at a TUI Travel operation in Newcastle.

The scam saw the four processing customer refunds. Using a system that they had privileged access to the workers put their own bank detail into the system so they were paid the refund rather than the customer that was entitled to it. See the full story here.

The worst part of it is the fact that TUI Travel knew nothing about this until the callcentre closed and an audit was carried out.

NHS IT project is dead, but why do large IT projects fail? Part 6

Karl Flinders | No Comments
| More

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com soon, asks the question: Why do large IT projects fail?

I started with the comments made by Brian Randell. Randell is a professor of at the School of Computing Science at Newcastle University.

Then part two came from Anthony Finkelstein. He is professor of software systems engineering at University College London (UCL) and dean of UCL Engineering.

Part three, was from Yann L'Huillier, group CIO at financial services giant Compagnie Financiere Tradition, who has also headed up IT at several of the world's stock exchanges.

Part 4 was from James Martin, the former IT COO Europe at investment bank Lehman Brothers.

Part 5 from Philip Virgo , who is secretary general at the Information Society Alliance. He has nearly 40 years' experience of IT projects.

Today in Part 6 investigative journalist Tony Collins, who has revealed the problems in many an IT project, gives us his opinion on why large IT projects fail.

Tony Collins is an investigative journalist who has specialist on large IT projects.  He is co-author of Crash, a book on IT disasters, and co-founder of Campaign4Change which seeks reforms in the public sector. He spent 21 years at Computer Weekly.

He says: "Every project is different but these are some general lessons.

1 - Projects with realistic budgets and timetables tend not to be approved.
2 - The more desperate the situation the more optimistic the progress report.
3 - End-users are likely to reject any system that gives them what they asked for. Better for the project managers to understand what users do rather than what they say they do.
4 - CEOs who know a great deal about computer projects are dangerous. The over-confident CEO may try to do too much, too soon and with too little - and possibly remove potential savings from business budgets before the savings are actually made. He gets few warnings because he is surrounded by those who'll agree with him.
6 - Keep it small and simple. If it has to be big, split it into components that are each useful in themselves.
7 - A failing project has benefits that are always spoken of in the future tense.
8 - In the public sector the unnecessary secrecy over the progress or otherwise of major projects such as Universal Credit continues. It's a pity because it increases the chances of failure. "

 

Have you entered our awards yet?

About this Archive

This page is an archive of entries from October 2011 listed from newest to oldest.

September 2011 is the previous archive.

November 2011 is the next archive.

Find recent content on the main index or look in the archives to find all content.

 

-- Advertisement --