JoinSign In
About Us

Peter Bowen asks: In today’s environment with revenues under pressure from OTT’s, competitors and the regulator, does any CSP have the time and resources to squander on the excessively long projects of the past? 


File:Rain, Steam and Speed – The Great Western Railway.jpg

Rain, Steam and Speed - The Great Western Railway
Turner, 1844




Many people still talk about systems implementation projects of more than 12 months, with little regard to the fact that whilst resources are being ploughed into the new solutions, investment in the current infrastructure all but stops. This leaves a CSP exposed, as it is not able to respond to competitor initiatives.  It also leads to frustration and can spawn the introduction of shadow IT applications to bridge the gap, or the implementation team eventually being forced to deliver early resulting in issues such as incorrect bills. 


Let’s start with some facts:  only 16% of projects are deemed successful in that they are on time, on budget and meet expectations: the larger the project the smaller the success rate.  Putting to one side those projects that were doomed to 'fail' from the outset, as budgets were set before anyone knew what the solution would be, there are a number of common issues we come across as to why project run over time.  But rather than reel out the stats from various studies by the British Computer Society, Gartner, Standish and the Oxford University, I thought I'd take a leaf out of Snowdon Burgess's book - Telesperience’s inside man - and talk about the characters that cause failure (see How Internal Politics destroys Innovation, Change and Success).


Top of the pile for me is the Guru.  The Guru comes in two flavours: the first being an individual on a greenfield site to whom everyone is happy to delegate the task of relating their requirements to a vendor and/or developers.  This individual does not have the capacity to assimilate the totality of what is needed, so what gets delivered is not what is wanted and costly change requests follow.


The second type of Guru is resident in the organisation and is seen as the 'go to' person for anything related to a core system.  When the time comes to replace the system, the co-operation of the Guru is seen as essential.  The trouble is the Guru has no desire to see his or her empire dismantled, and so starts a programme of disinformation, or is not available to answer questions - thus restricting the flow of information.  He or she usually only offers up insights after something has been done, which means it will need to be redone after the revelation. 


I have come across Gurus in several industries and have seen numerous attempts at replacing core systems fail because of their actions/inactions. 


In one instance, a Guru was being paid more than the CIO as he held the company to ransom and had seen off two attempts to replace his system. 


Organisations need to guard against 'guru-ising' anyone, and if possible avoid the problems associated with this dependency.  If they already have gurus, they need to figure out how to work around them. 


Another character I often encounter, is the Stenographer.  The Stenographer is an analyst (I use the term loosely) who is charged with capturing information to produce a requirements specification and happily trots off  with a blank piece of paper (and blank mind) and asks “so what do you want”. 


The result is that what is delivered is what was asked for, but is not what is needed.  I happen to think that the hardest job on any project is defining in detail what's needed and that the analyst must do research before sitting down with business users.  Note: poorly-defined requirements are the single biggest contributor to project failure.


Our next character is the Project Manager (PM). Now whilst the hardest job is defining the detailed requirements, the hardest task is that of a PM.  Even great PMs fail if the conditions for success have been removed.  For instance, the PM cannot chose his/her team or does not have the ability to remove those who are not performing.  Lack of management backing undermines the PM’s position, as does management making project-impacting decisions without involving the PM. 


However, before you start feeling sorry for the PM remember that for every good one there is at least one poor one.  The irony is, of course, that the truly bad PMs always move on before the projects they have set on a collision course spectacularly fail, and some poor soul is left to pick up the pieces or take the blame.


Ok, so apart from terminating a Guru, replacing a Stenographer and empowering and backing the PM, what else can be done to ensure success and reduce time-to-delivery? 


In a word 'Milestones' - hard tangible deliverables, of which there must be at least one each week.  If there is an activity that takes more than two weeks it should be broken down into weekly deliverables and any slippage assessed to determine if the issue can be fixed by the PM or if help is needed.


Approach is also important.  The PM can have a great plan and total backing from management, but if the way in which the assignment is structured is wrong, then the project will fail.  The PM must explain the approach up-front and it must make sense.


On a final note, who should lead a project?  It has long been the case that system implementation projects are run by IT project managers but given that business has the most to lose, should it not lead projects with support and help from IT project management?


Looking forward to hearing your thoughts on this.

Peter Bowen

Powered By
Copyright Babworth Ltd. and © 2012 Telesperience - All Rights Reserved

Babworth Ltd is registered in England and Wales - 6620167

35 Firs Avenue, London, N11 3NE