Executive Summary
Bridgestone are suing IBM for $600 million following a catastrophic systems implementation failure that did huge damage to the business, unable to process orders, stock piling up, losing customers, … the business information systems nightmare of every CEO.
This article examines the REAL reasons these things happen and how to prevent them by analysing the key elements of the Bridgestone – IBM situation and explaining how to prevent them occurring in your project.
Issues discussed include the viability of old software, valid governance for projects of this nature, the need for a tough and robust procurement approach and resulting contract, the Business Process myth and why the Business Process approach is dangerous, the need for a rigorous “engineering” approach, the critical need for a Business Simulation Laboratory, the benefits of tough certificates and the non-negotiable need to provide a roll-back capability in the event of disaster.
It is concluded that both parties made mistakes, that the mistakes are common place and, in reality, part of the established order and that there is a need for a radically different approach – this approach is outlined in the article.
Introduction
Bridgestone sues IBM for $600 million after suffering massive damages – tires stacked in the parking lot, hiring a third party warehouse to store stock, unable to fulfil orders, lost customers – THE business information systems nightmare of any CEO.
http://www.businessinsider.com/bridgestone-sues-ibm-for-600m-2013-11
|
The system cost over $75 million and went live in January, 2012. It immediately experienced "system-wide failures" for three months, Bridgestone alleges:
"Tires which should have been delivered to fill customer orders … piled up in distribution centres, smaller warehouses, and trailers parked in parking lots. Ultimately, [Bridgestone] was forced to lease an enormous amount [of] public warehouse space at great expense."
The complaint also says:
“IBM’s defective system lost or deleted scheduled customer orders, would not process orders, duplicated, or partially processed orders and, for those limited orders that were processed, did not complete critical corresponding business applications.”
But IBM says the problems were caused by Bridgestone. The company failed to do its part so that IBM could build the system on time and on budget. IBM sent this statement to the Tennessean:
|
Google “Bridgestone sues IBM for $600 million” in quotes so you get an exact match – 4,560 results!
This is big news.
It MIGHT be THE event that redefines the business information systems in the way that dramatic construction engineering failures a century earlier redefined the construction industry .
Why do these things happen?
Fact is that failure is rife – see my “Failure Catalogue”, failure that involves mainstream firms like Bridgestone, BMW, The BBC, etc as clients and IBM, Deloitte, EDS, etc as service providers.
In fact the indications are that the failures are getting bigger, more frequent and more damaging.
There is NO real indication that anyone has an answer to THE CRITICAL QUESTION “how do we prevent our organization getting hit by such a catastrophic event?”
This article seeks to answer that question from a very different point of view – a point of view that I term “the engineering approach”.
Before you ask what an engineer has to do with an industry that is the preserve of accountants and MBA graduates I ask you to note that ALL significant engineering structures are designed using computer based systems that are far more complex than business information systems and which are required to operate at exceptionally high levels of reliability. Engineering MORE than accounting drove the creation of high performance computers over the last fifty years.
Failure is rife
Fundamentally, failure has been rife for decades but the big implementers and the NOT so big implementers continue to focus on getting better and better at what they are doing seemingly oblivious to the principle that “if you do what you have always done you will get what you have always got”.
A DIFFERENT approach
This article seeks to present a DRASTICALLY different, and I contend, BETTER way of looking at this sort of situation directed at enabling you, as an executive of a company faced with the prospect of replacing your systems, or sitting with a project that is failing or a system that is under performing, to take DIFFERENT decisions to your counterparts in Bridgestone, BMW, The BBC, etc.
I have been investigating failures and sub-optimal outcomes of business information system projects since 1989, speaking about the reasons they happen since 1992 and learned a large amount to the point where I am now in a position to actively publish what I have learned after undergoing an intense and lengthy process of discovery, inquiry, analysis, practical application and refinement.
Following are the points that stand out for me about the Bridgestone situation:
1. COBOL – NOT a valid reason
The project commenced with a fundamentally unsound supposedly technical motivation, existing systems were written in COBOL, COBOL was “obsolete” and therefore needed to be replaced.
Note that this is a technology driven decision.
Reality is that in the real world there is still a huge amount of Cobol in operation and there is NO technical reason to replace it, except a CIO who is NOT prepared to invest in people and standards to maintain the software.
COBOL is obsolete is NEVER a valid reason to change software.
“We have a vision for a far more advanced solution tightly optimized with the way we want the business to run in the future” (NOT Business Process Re-Engineering) – IS a valid business case IF it comes from the business AND provided the old systems are properly maintained until the new system is fully operational and stable.
For more discussion on why OLD systems ARE viable and also relating to COBOL please see the article “Old Software IS Viable”, there is a piece on COBOL lower down the page.
Note that the existing systems at Bridgestone were working fine, they worked so well that Bridgestone had tens of millions of dollars to pour into their massive new systems project and still remained in business.
The balance of this article is based on the assumption that you DO have a sound business case for moving to new technology and want to do this with minimum risk and maximum value add.
My point here is simply that Bridgestone DID have a choice to move but apparently the executive were misled. In the same way in a properly managed environment it should NEVER occur that the business has to go-live no matter what, as happened with Bridgestone.
2. Governance – the BIGGEST single cause of failure
OK, so Bridgestone decided for good or bad reasons to change.
They went with SAP because SAP is supposedly THE leading brand although a look at my Failure Catalogue has SAP occurring rather frequently.
They went with IBM because IBM is a household name and surely to be trusted – although a look at my Failure Catalogue has IBM also occurring rather frequently.
Two supposedly good reasons for the executive of Bridgestone to believe they were making a good decision – SAP and IBM!
So, what went wrong?
Well, Bridgestone had some governance problems – they are alleged to have replaced their Chief Information Officer no less than SIX TIMES in two years during the project!
Inspecting the “Bridgestone USA Executive Bios” page we find that there is NO Chief Information Officer on the Executive team.
After some digging on Google I was unable to establish who the CIO reported to but it seems clear that the Chief Information Officer was NOT really a “Chief”.
Yes, it IS so that in about 70% of cases the Chief Information Officer reports into a member of the executive team, most frequently the Chief Financial Officer – because somehow businesses mistakenly believe the CFO is better qualified to manage the systems that run the company than anyone else.
One of the reasons there is so much failure and so many sub-optimal outcomes is exactly because the CFO has NO formal training that in ANY way equips them to manage technology.
IF you are NOT prepared to have the IT Manager – a person who reports to a C level executive who reports to the Chief Executive is NOT a Chief Information Officer, they are an IT Manager and calling them a CIO does NOT make them an executive. Sitting them at the top table with a reporting line directly to the CEO and operating on a FULL peer basis with the rest of the executive team is what determines if a manager is a CIO.
So, it seems probable that Bridgestone changed its IT Manager six times during the two year project NOT their CIO.
Thus IBM have some basis to allege lack of leadership on several fronts.
Most importantly, the so-called OTC (Order to Cash) project involved almost the entire spread of the business. The custodian of this integrated view of the business and the ONLY person with the muscle to make decisions stick across multiple operating components of the business is the CEO.
Since the CEO does NOT have the knowledge or the time to manage a project of this size and complexity they need an advisor and Project Leader – someone to direct the project. This needs to be a person who has done this before, a gray beard so to speak, someone at least over 50 years of age who specializes in managing this type of project on behalf of the client. The IT Manager simply does NOT have the clout and, in all likelihood does NOT have the experience to manage something like this.
Remember that when you put in place a massive new integrated system it touches just about every part of the business, it touches just about every person in the business and, by definition, it RIPS THE GUTS out of the business and replaces them with something that is supposedly better. The Bridgestone debacle provides graphic evidence of what happens when you rip the guts out of the business in a badly planned and badly managed project – you cannot ship product, you lose customers, you lose millions of dollars!
IF you get the picture of what can go wrong you will recognize that for ANY organization embarking on a project of this nature pretty much the FIRST thing you do is go out and find a REALLY senior, REALLY experienced expert who has done this a number of times before and knows what works and what does NOT work. Make sure that they have rapport with the CEO, make sure that they demonstrate intuitive understanding of YOUR business and then bind them contractually for the duration and give them an open door to the CEO as an Interim Executive.
On the face of all the evidence Bridgestone did NOT do this – probably because no one told them it was necessary – probably because almost no one does it that way which is a major reason why so many projects fail or come in seriously short of expectations.
That said there was obviously something TOXICALLY WRONG with the way Bridgestone were managing their IT Manager -- remember, since he or she was NOT on the Executive Team they were NOT really CIO – that alone could be enough reason for all the resignations. Bridgestone embarked on a massively complex and very large project and, seemingly put a lot of responsibility on this person they called CIO and then did NOT give that person the muscle and support needed to do the job. OR did something else that made the position totally untenable.
A recipe for failure!
So, does that let IBM off the hook?
NOT from where I sit.
Given that there clearly WAS a problem, it is a key element of IBM’s defence, then IBM should have done something about it.
Something like raising a “red flag” on the project and advising the CEO that in the absence of a robust and sustainable solution to the CIO problem they would have to cease work and withdraw their team until a suitable person was put in place. But that would have been bad for planned revenue so I am guessing that typical IT person temerity (people who are good with computers are generally NOT good with people, particularly when faced with conflict) coupled to quarterly revenue target driven greed got in the way of IBM’s integrity!
That is a major problem with the business information systems industry, for the most part it is driven by people who are in the game for the money and NOT for the passion of exceptional solutions delivered to high quality standards that meet or exceed client expectations and come in on time and on budget. The folk who are turned on by good solutions generally do NOT make it to the top. So, if your fundamental commercial driver is NOT aligned with a quality outcome you will make technically BAD mistakes. It seems that IBM did this.
After all, it seems they were working with an IT person who was punching below IBM’s weight and Bridgestone, according to their pleadings, was counting on IBM to provide the wisdom and maturity necessary to deliver the required outcome. Problem is that in this case IBM were, seemingly both the main player AND the referee, because there was NO in-house referee of any substance, they changed on average every four months and you CANNOT learn about the business or the project in four months let alone manage a major player like IBM.
Not to mention deal with whatever ugly governance toxicity caused all your predecessors to leave!
So, YES Bridgestone were at fault and NO that does NOT exonerate IBM – they should have intervened one way or another to stabilize the situation. Perhaps they were cutting costs and deploying light weights on their side too? Bridgestone allege they were.
The lesson for your organization
a. Make the CEO responsible – see my material on Executive Custody for guidance;
b. Appoint a highly experienced expert to run the project on behalf of the client and have that person report VERY closely to the CEO in an Interim Executive capacity with a VERY tough mandate to act on behalf of the CEO and a strong contract for the duration of the project – see my article on “The Art of Project Leadership” for some suggestions;
c. and … see the sections that follow.
3. Procurement – securing a robust, tough and enforceable contract
From the fact that Bridgestone are litigating against IBM one has to conclude that the contract was shaky. In fact, if one reads the full pleading document it is apparent that whatever contract existed did NOT have teeth.
One of the reasons that the construction industry consistently produces high quality deliverables is that the construction industry makes use of well-established tough contracts that provide all the basis necessary for legal action against the contractor in the event of failure or sub-optimal outcomes. So litigation is seldom required.
Signing the contractors contract, as it appears that Bridgestone did, after all everyone does it, is the first step in a journey to a sub-optimal outcome. Having that contract signed by an IT Manager dressed up to look like a CIO is a recipe for disaster.
Before you can sign a tough contract you must follow a tough procurement process. From the documents it appears that IBM were appointed on a “sort of negotiated basis”, they were already there, they drew up the requirements specification and then negotiated to execute it so, in a sense, they were again judge and jury.
For procurement to lay a foundation for a successful project:
a. It is vital that the CEO has first appointed their tough interim executive Project Leader / Project Director, someone with a large amount of procurement experience;
b. It is also vital that the procurement takes place against a tough and comprehensive procurement pack;c. with at least three to five bidders;
d. with a tough multi-stage adjudication procedure;
e. resulting in a tough contract.
See the discussion of the requirements for such a procurement approach on my website.
Such a contract must lock the contractor into a fixed price for a clearly defined business outcome.
It must contractually bind provably competent contractor personnel individually to the project for the duration.
It must provide for detailed discovery BEFORE the price is finalized and the contract is signed so that there is NO room for “change of scope”.
There must be a comprehensive and highly detailed project plan and “Bill of Services” such that there is NO ambiguity about what the contractor quoted to do and how much they quoted for each component so that in the event that there really IS a legitimate basis for a variation order this can be managed effectively.
Please read the material on my website for more information.
4. The Business Process Myth – irrelevant, distracting and DANGEROUS
Next issue.
The project name “Order to Cash” speaks volumes.
This was clearly a “Business Process” orientated project.
How do I know that?
Firstly the whole industry does it that way.
Secondly “Order to Cash” is a classic example of the nonsensical gobbledegook that Business Process proponents use to describe things.
“Order to Cash” is a substitute for -- order processing, works orders, warehousing, logistics, invoicing, credit control, …, or whatever Bridgestone exactly DID commission.
Wikipedia states “Business process management (BPM) is a management discipline that focuses on improving corporate performance by managing and optimising a company's business processes”.
The problem with “Business Process” is that most of the time it is NOT a “process” – a process is a sequential step wise flow of activities. Most of business is NOT that way, yes there IS a progression from receiving an order to delivering the goods and receiving payment. However, on a moment by moment basis it does NOT proceed in a sequential stepwise manner.
There are some people taking orders, some people making product, some people warehousing product, some people picking product, some people despatching product, some people generating invoices, some people following up overdue accounts and some people doing bank reconciliations, etc.
Each of these groups or individuals does their piece of work repetitively and reactively as phone calls and emails come in or people arrive at trade counters, as works orders come through in response to sales orders, as picking orders come through in response to sales orders, as trucks to particular destinations are filled or despatch deadlines are reached, as …, as ..., as…
Stuff happens and well trained staff keep things running.
Are there elements of process in places?
Yes, sometimes.
But the “order to cash process”?
What nonsense!
Then, to compound things expensive highly educated consultants come in and sit with client personnel and instead of listening, taking lots of notes and asking questions directed at gaining understanding – remember that the initial part of an engagement is, at least in theory, about the consultants learning how the business operates. Remember that the staff KNOW how it works.
Instead the majority of consultants and certainly the GREAT majority of business process consultants almost immediately dive into drawing “Business Process Maps”, “Flow Charts”, etc.
In fact, the deception is so great that many of them insist on getting client personnel to learn how to draw these meaningless diagrams. So, instead of client personnel quickly and succinctly explaining how the business works they are forced at best to digest and make sense of diagrams that make no sense and, at worst, they are forced to learn a techniques and do work that is entirely VALUELESS to them or their employer. And then the consultants have the gall to CHARGE for this!
And, IF the consultant actually does the drawing themselves, they are so busy with their brown paper or their flip chart or their white board or their Visio or their proprietary software that they are only listening with half an ear and MISS half of what they are told. Sometimes the miss is so severe that it only surfaces when the consultant presents a variation order because they were “NOT told about this” at which the personnel they imposed their arcane method on are either no longer there or are so intimidated that they do not argue.
Take a look at a typical business process map or flow chart of some component of an organization that you sort of understand.
What do you find?
There is MASSIVE real business complexity that is NOT reflected anywhere on the diagram because each block on the diagram needs anything from half an A4 page to MANY pages of text to fully describe it. Yet the diagram has taken hours or days to prepare and forms the basis of the project documentation and all the work that follows.
And, because everybody does it and NOBODY really OWNS what is happening the people in the client organization who are ORDERED to sign this meaningless childish scribble do so for fear of seeming stupid! Note that “sign-off” is one of those meaningless IT activities.
IF you want the signature to mean anything it MUST be associated with a TOUGH certificate which takes the form of “I the undersigned John Citizen do hereby certify that this process map fully and accurately represents my business function at a level of detail such that I am ENTIRELY satisfied that IBM (or other consultant) FULLY understand my function such that they will be able to design and implement systems that will work in my area”.
Try putting that in front of your average business representative and see if they sign it.
Going beyond that, there is a LIMIT to how much detail is accurately required about this thing they call the “as is”.
After all, we are ACTUALLY supposedly creating a NEW and better end state – that is the ONLY way we can justify the huge expenditure.
Yes, consultants DO need to understand the basics of the business and they DO need to know who is going to work with the system but, beyond that, how much detail is REALLY required?
Interestingly, NOT a lot.
The client personnel live all their lives in the “as is” so, provided the consultants CONSULT which most of the time they do NOT, mostly they storm along on their own mission and arrogantly DICTATE the solution they have decided that the client needs, the knowledge of the “as is” is always at hand.
The absurdity of the level of detail that many business information systems consultants insist on acquiring about the “as is” and getting paid for is highlighted by the following metaphor.
We are putting in a new road with a high level bridge over the gorge because the rough and winding track down one side of the gorge and up the other is slow and inefficient, so we survey the old road in minute detail even though it will simply be a tourist route once the new highway is commissioned!
There is a different and BETTER way and is discussed in some detail in my paper “The Power of an Executive with a Blank Sheet of Paper”.
Bring in a very experienced, very mature, executive level Strategic Solution Architect and starting with the Chief Executive have them DESCRIBE their vision of the future. How they want the business to run when the new system is up and running.
Take off the blinkers of “as is” and focus on a practical and viable future state. The business people know the present and its constraints and inefficiencies, facilitate them to take a view of an improved future state facilitated by someone who has the depth of experience and maturity to curb the vision when it runs away because people DO get carried away at times. BUT focus on a high value future state and then go away and figure out how to get there.
This is NO different to the architect for a major new prestige office building sitting down with the CEO of the client company to understand their vision for the office of the future and going away to come back a few days later with sketches of concept designs.
If the architect forced the client to learn how to draw and make their own drawings the client would throw them out immediately. Yet clients fall for this with Business Systems Consultants all the time.
The concept of a blank sheet of paper, informed by a pragmatic commercial view of what exists, which can ONLY be delivered by the top team initially, is THE way to go.
See also my article “Business Process -- Irrelevant, Distracting and Dangerous” for further discussion.
Using Business Process Mapping techniques to describe the desired future state of the business is so far off the mark that it hardly warrants comment. Look at the arch bridge above – do you think that the engineers who designed that bridge studied expected traffic flow over the bridge to design it? NO of course they did not!
The things that matter are the software functionality on a module by module basis correlated business function by business function coupled with the configuration of the system and particularly the validation data and master classification lists, see my article “The Alternative to Business Process – the RIGHT Approach” for a discussion of the correct approach.
Fundamentally, what is required is:
- Discovery of the strategic essence of the business – why it exists and HOW it thrives;
- High level functional definition of the components of the business;
- Definition of the key functional elements from a strategic essence perspective;
- Relate this to typical software modules available in the market place;
- High level specification of system requirements on a module by module basis;
- Tough procurement as discussed above;
- Determine what capabilities are to be delivered with standard software, what requires customization and what requires custom development;
- Detailed development of a comprehensive suite of representative configuration and master data -- determined by strategic essence;
- Specify and build software as required;
- Precision configure;
- Test, refine, test, finalize, accept;
- Laboratory program as discussed below including management prescribe workflow (aka process);
- Deploy and commission;
- Operate.
There is much on my website relating to this approach.
It is probable that IF Bridgestone had followed this approach there would have been MUCH less custom development.
This approach focuses attention in terms of deliverables on the two things that ALWAYS remain at the end of the project, the software and the configuration. The Business Simulation Laboratory, described below, provides the mechanism to integrate this into the business and ensure that people are fully trained – the third component that remains. The procurement approach should ensure that a rigorous project method that enforces the above points is followed.
5. Absence of engineering rigor – sloppy projects and sloppy solutions
It is clearly apparent from the Bridgestone pleadings that IBM ran a sloppy project. I do NOT say IBM AND Bridgestone, I say IBM – they CLAIM to be the experts.
Bridgestone in their pleadings make it clear that they appointed IBM as trusted advisors, as experts, as a leading brand in the field with a high level of confidence and trust that IBM would do right by them.
IBM failed outright and even allowed Bridgestone to go live despite acknowledging there were problems. There is a point at which a responsible consultant stands firm and REFUSES to allow the client to go live or, at the very least requires the CEO to sign a TOUGH indemnity clause.
A HUGE problem with the business information systems industry is that it is dominated by people who are NOT engineers and who do NOT understand that failure occurs UNLESS prevented and do NOT have a focus on preventing failure.
It is fundamentally so that success is the necessary consequence of a well-conceived project NOT failing!
Every successful engineering system and structure is successful for ONE ultimate reason, because it does NOT fail!
You can be positive and use positive language and have road shows until you are exhausted but you will NOT make a bridge stand up that has a defective design element or loading conditions massively in excess of the design.
The bridge in Minneapolis depicted in the photograph failed because of a series of operating management oversights that resulted in an extreme overload condition in the centre of the bridge, a small component failed and the bridge collapsed. The event was so extreme that it was published globally on TV and radio within minutes of the failure.
If bridges failed the way business information systems projects fail NO ONE would ever cross a bridge, in fact there would be NO bridges to cross. In fact, if the entire engineered environment operated to the extreme standards of sloppiness that characterizes the business information systems arena we would be living in grass huts – at least they would not kill us when they collapsed!
My point?
I am advocating a level of rigour, precision, accountability, etc that is far beyond ANYTHING that occurs in the business information systems industry, see my article on “The Engineering Approach to Business Information Systems Defined” for a discussion of the characteristics of this thing that I refer to as “The Engineering Approach” – it is a culture, a way of thinking, a way of doing that is unique to people who have made it their life long goal to create things of lasting value from nothing, these people are engineers and they know that without intense rigour and discipline bridges do NOT stand up!
So, you need a Project Leader who understands these principles and you need to find a contractor who understands them as well. And then you need to apply them rigorously and conscientiously.
6. Lack of formal Business Simulation Laboratory testing
Another very obvious element of the Bridgestone complaint and IBM’s response is that there WERE known problems BEFORE going live!
Bridgestone respond by saying that the failures that occurred did NOT correlate with the concerns purportedly raised by IBM.
So the situation degenerates to an admission by BOTH sides at some level that there WAS a decision taken to go live knowing that at some level there were problems.
BUT IT PROJECTS ARE LIKE THAT YOU SAY?
Why?
There is NO reason for them to be.
They are a field of engineering endeavour like any other, failure is inevitable UNTIL you eliminate every possible cause of failure from the solution.
In the case of software where admittedly the solution IS complex and abstract – see my article on “The Critical Human Foundation” on the real world human complexities that have a HUGE impact on projects of this nature it is necessary to be particularly disciplined and thorough.
The problems are compounded by the lack of formal engineering training and rigour, as discussed in the previous section but that is NOT my point here.
When an engineer is designing something that requires design elements that are different and unknown they resort to the Engineering Laboratory, a place where the REAL WORLD is simulated. It looks nothing like the real world but the structures and test equipment behave like the real world.
The photograph shows an engineering laboratory in which a miniature steel frame bridge built by second year engineering students using accurately scaled miniature steel structural sections is being tested to destruction using a “Gravity Load Simulator”, the three triangle heavy frame in the centre right of the picture which allows a large vertical load to be applied to the miniature bridge in such a manner that the bridge will fail in a manner that accurately models the way a full scale bridge to the same design would fail if overloaded.
Engineers are schooled with this type of exposure to failure and how to prevent it. The bulk of the undergraduate university curriculum for engineers relates to preventing failure and the construction of large buildings and other engineering structures is ALWAYS coupled to engineering laboratories that constantly test representative samples of material to destruction in order to provide required quality control.
A Business Simulation Laboratory LOOKS different, it is a room with tables and computers and a data projector or two but the principle of its design and application is the same. The most experienced personnel of the client organization systematically work with small quantities of carefully selected representative data to do everything possible to cause the system to fail.
The dictum is “break it until you cannot break it any more”.
ONLY once this state has been achieved can the software then be fully configured and again tested, the workflow (that is process) dictated by management and configured, the reports, models (data warehouse), alerts, etc defined, built and tested and training material developed. The training material should preferably be interactive.
Once ALL of the above has taken place and the system / systems have been manifestly proven to be ROBUST and reliable and ALL components are working THEN and ONLY then are ALL staff brought into the laboratory environment to be trained in SIMULATED live operations.
Rigorous application of this approach and a tough stand that management at every level and particularly the CEO WILL NOT authorize commissioning until the laboratory delivers a clean bill of health is critical to preventing the sort of catastrophe that Bridgestone suffered.
Should IBM have done this?
Categorically yes!
Were they negligent that they did not?
Well, YES BUT, there are very few people in the industry who know to do this let alone know HOW to do this.
That said, IF, as they claim, IBM told Bridgestone at some level that there WERE problems and they should NOT commission and Bridgestone overruled them then it is my contention that Bridgestone may have a different case but their present case is shaky.
On the other hand if, as Bridgestone claim, IBM grossly understated the problems and led them to believe that there might be a few issues but nothing serious whereas the entire solution was allegedly riddled with problems then it would seem that Bridgestone have a strong case. The challenge for the judge is going to lie in establishing where the truth lies relative to those two poles.
And the ANSWER is that NEITHER position is actually defendable. Either there were issues in which case the system should NOT have been commissioned or there were NO issues in which case the system should NOT have fallen over the way it did.
Those arguing in IBM’s defense will argue that the solution was too large and too complex to test thoroughly to which I respond that in ALL fields of engineering endeavour engineers find ways to ensure that failure does NOT occur and point to the International Space Station as an extreme example. Accordingly, I hold that with effective engineering management of a formal Business Simulation Laboratory the Bridgestone systems would NOT have been commissioned when they were.
Ultimately it comes down to whether IBM were more negligent than the industry norm and that is a difficult question!
As a whole the evidence indicates that the industry IS habitually negligent and does NOT know a better way!
As far as I am concerned there is NO alternative to the Business Simulation Laboratory and a rigorous and robust testing program managed by a tough no nonsense senior person who will brook NO arguments for compromise.
7. NO certification
There is an extension to the previous point, something that, on its own might have greatly reduced the risk of going live prematurely and that is a robust and tough “Readiness to Commission Certificate” or “Go-Live Certificate”.
Once ALL staff are trained in the Laboratory, THEN the entire project team are required to progressively sign a certificate of the following form – starting with the most junior team member:
|
Certificate of Readiness to Commission
We the undersigned:
Client Team Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementer Team Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
In our capacities as Team Leader of the Client Laboratory Test Team and Implementer Team Leader respectively of the teams comprising ourselves together with the following team members:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .sign . . . . . . . . . . .
…
Have completed Comprehensive Laboratory Testing of the full configuration
We hereby confirm that:
1. In issuing this certificate we are aware that premature issue of this certificate could lead to serious business damage, inconvenience and unbudgeted costs;
2. The team has invested sufficient time to thoroughly and comprehensively review and test the configuration;
3. The configuration has been substantively stable in the Laboratory with ongoing testing activity for not less than thirty business days;
4. We are fully satisfied that all required functionality is working correctly;
5. We are fully satisfied that all reports, models and dashboards are accurate and functional;
6. All training material has been prepared and tested;
7. All personnel have been thoroughly trained and tested and are skilled at a level that they can rapidly and accurately adjust to running the new system;
8. That we have assessed all possible risks in-depth and are satisfied that all measures necessary to mitigate these risks are in place with appropriate accountabilities and ownership.
We accordingly advise that it is our considered opinion that it is safe to commission the system and we advise that it is our considered opinion that . . . . . (Name of Implementation Company) has fully complied with their contractual obligations in delivering the required solution in the Laboratory and that the retention applicable to this stage of the project can be released and that the software can now safely be commissioned.
Sign
The certificate must then be signed by the Project Leader, the Implementer Executive Sponsor and finally the CEO of the client company BEFORE the system is commissioned
|
Similar certificates should be required at different stages of the project.
The value of such a certificate is that it forces people to think.
Conventional IT “sign-off” concentrates on getting a signature on a piece of paper – I have seen project managers rushing round getting people to “please sign” because it is the target date for sign-off and since the goal is to get signatures it is relatively easy to do.
Turn it around, and put a tough certificate on the table that has clear contractual significance and “sign-off” suddenly becomes orders of magnitude more difficult.
Business Information Systems and IT Generally is primarily about people, see my article on “The Human Foundation” to better understand this point.
Thus the psychology of how one manages people on these projects is of paramount importance. The psychology of a tough certificate with wording that clearly holds the people signing accountable cannot be under estimated – it forces people to think very carefully before putting their signatures on such a document.
And THAT is EXACTLY what you want.
You do NOT want people agreeing to the system being commissioned because of ANY pressure, you want them to ONLY agree because it is SAFE to proceed.
And you want each one of them to clearly understand that they WILL be held accountable.
So signing of the certificate might involve getting all relevant team members in a room with the CEO at the head of the table with the CEO looking each person in the eye, questioning them and ENSURING their commitment to their signature BEFORE they sign. Make it DIFFICULT TO SIGN and easy NOT to sign.
8. NO roll-back plan
Beyond that note that Bridgestone did NOT have a roll-back position. They were apparently unable to roll back to the old systems. That is an act of gross negligence that needs to be laid equally at the door of IBM and the CIO / IT Manager.
Frequently there is NO roll-back position because someone cannot figure out how to do it – that is negligence, find someone who CAN figure out how to do it and do it.
This should be NON-NEGOTIABLE!
Conclusion
From the documentation there are other factors.
Consideration of my factors relating to “The REAL Issues in Business Information Systems” – the factors causing failure and the Critical Factors for Success (the subject of my book – available on the website together with the course of the same name) will give you many more pointers to what went wrong and how YOU can avoid a similar catastrophic outcome for your organization.
Remember that “if you do what you have always done you will get what you have always got”, in this case, if you do what the IT and Business Information Systems / ERP industry has been doing for the last twenty years you will get what they have been delivering for the last twenty years – expensive projects that run over time and over budget and deliver sub-standard outcomes or outright failure.
I suggest for your consideration that there IS a better way that will deliver MUCH better outcomes, see my article on “What does a HIGH VALUE Business Information System Solution look like” for more ideas.
This outcome is outcome in which every aspect of the business runs smoothly, efficiently and effectively. The systems “flow” with the business and most activities take LESS time than they did previously.
Most importantly executives and managers have a wealth of strategic, operational and tactical management available literally at the touch of a button. Information that is of the highest quality and entirely reliable.
Executives and managers have time to be more creative and the business is able to sustain greater production, sales, etc with existing headcount or headcount has reduced by natural attrition over a year or two.
The business is booming, it is growing faster than it did before, new customers, new products, new services.
All of this traceable back to the new systems that have been expertly configured to EXACTLY model the real world in which the business operates such that the systems are easy to use and FLOW with the business.
This is what IBM should have delivered to IBM and failed!
Please browse my website for more information, the home page, http://www.james-a-robertson-and-associates.com will give you a good overview of what I am advocating and help you to navigate the entire site.
The Table of Contents lists all the webpages on the site, there is a lot of deep content that is NOT immediately visible.
The Article Catalogue lists well over 150 articles on diverse topics.
The Article Keyword Cloud provides alphabetic keywords linking to many of the articles
The Conference page lists around 90 conference presentations, nearly all different with around 40 of the presentations live on the site for you to view and download -- email me if there is a presentation you would like that is not on the site.
Pulse Measurement
I offer a concise diagnostic “Pulse Measurement” light touch, high impact investigation that in the space of a day to ten days for most organizations, depending on size and problem complexity, will deliver you a concise written report that will accurately diagnose what is wrong with your current systems OR your project OR your IT Department and prescribe meaningful and actionable treatment for the conditions I identify.
I look forward to being of assistance to you.
Dr James A Robertson PrEng