Sue Bushell asked on "LinkedIn": What are the most common failures in strategic IT planning and how are these best avoided? What best practices in strategic planning are most effective?
My answer:
1. There are no I.T. projects - only Business Projects.
Hence changing the premise of your question:
What are the most common business process failures around I.T. solutions?
[A: Make the business run the project and take the rap if it fails.]
2. I.T. is an Industry, not a Profession.
Proof: Professions Learn: repeating Known and avoidable Errors/Mistakes isn't consequence free, as it is within I.T.
3. The complete lack of History in I.T. - both on macro and micro scales.
4. The fundamental reason IT is used: It's a "cognitive amplifier".
Computing amplifies the effort and output of people, providing results 'Cheaper, Better, Faster'.
On the micro scale, no organisation I've heard of measures this. It's quantitative and should be calculable by any half-reasonable Management Accountant.
On the macro scale, the 'Profession' doesn't have or publish benchmarks on results (i.e. from across many organisations).
5. The 'Profession' doesn't even have a taxonomy of jobs and tasks, let alone any consistent method for evaluating and reporting the competence of, and skill level of, practitioners.
6. The almost complete disconnect between research results and practice. Enough said.
7. [Added]. The general capability of the Profession in general and young I.T. practitioners has declined greatly.
Proof: The increasing number of failed projects attempting to replace 'Legacy Systems'.
E.g. The failed A$200M Federal Government ADCNET project. I worked on the original IBM mainframe system, then found myself 15 years later sitting in the same awful basement not 50 feet away, coding it's replacement. The IBM system took 30-35 man-years (in structured assembler), just the second phase of the ADCNET system had a team of 70 for 1-2 years - and was abandoned. The best description of it is the Federal Court Judgment:
GEC Marconi Systems Pty Limited v BHP Information Technology Pty Limited
Federal Court of Australia
12 February 2003 and 14 July 2003
[2003] FCA 50; [2003] FCA 688
8. [Added] Creating Software is a performance discipline.
You have to both know the theory and be able to create good software.
Who are the Great Heros of Open Source? The guys that demonstrate they can code well.
Like Music, Surgery and Architecture, software requires head and hands to do it well.
9. [Added] Design is Everything.
This is what the Bell Labs Computing Research guys understood and what Microsoft doesn't. They invented the most cloned Operating System in the world - Unix, and then went onto build Plan 9, it's replacement 20 years later - with around 20 man-years. It was created portable and scalable, running on 6 different platforms from day 1. Of course it was incredibly small and blindingly fast. Time has shown it was robust and secure as well.
Not an accident that 15 years later Microsoft spent around 25,000 man-years on 'Longhorn', and then threw it all away! (The infamous 'Longhorn Reset' on 23-Sept-2005 by Jim Allchin)
Then spent the same again to create 'Vista' afresh from the 'Windows Server 2003' codebase.
How could Microsoft not understand what was well known 15 years prior, especially as Microsoft ported Unix to Intel in 1985?
There's more, but that will do for now.
"I.T. Governance" may be part of the Solution, but standards like AS8015 are primarily aimed at allocating blame or pushing all responsibility for failure onto I.T. and abnegating from I.T. any successes.
The 'root cause' of all I.T. failures is trivial to identify, but probably exceedingly hard to fix. These days, almost no projects should fail due to technology limitations - only practitioner and management failures.
The 'root cause' is: Business Management.
Yes, there are many problems with I.T. practitioners, but think about it...
Around 1950, Commercial Computing was born.
Some projects worked, in fact succeeded brilliantly: Man went to the moon on the back of that work just 2 decades later.
And then we have the majority or 'ordinary' projects that fail to deliver, are abandoned or under-deliver...
The first time 'management' commissioned a bunch of 'Bright Young Things' to build The Very Best Computer System Ever, they would naturally believe the nerds and their self-confidence.
After that effort failed, what would the rational approach be to the next project?
Not the usual, "do whatever you want and we'll see", but "you didn't do so well last time, how about we try smaller pieces or doing it differently?"
And when lining up for the third go-round, you'd think competent business managers (the ones writing the cheques) would put the brakes on and say "you haven't shown you can deliver results, we have to manage you closely for your own sakes."
"Fool me once, shame on you. Fool me twice, shame on me."
And who's the cause on the third, fifth, hundredth or thousandth repetition?
The people who keep paying for the same 'ol, same 'ol.
My answer:
1. There are no I.T. projects - only Business Projects.
Hence changing the premise of your question:
What are the most common business process failures around I.T. solutions?
[A: Make the business run the project and take the rap if it fails.]
2. I.T. is an Industry, not a Profession.
Proof: Professions Learn: repeating Known and avoidable Errors/Mistakes isn't consequence free, as it is within I.T.
3. The complete lack of History in I.T. - both on macro and micro scales.
- Show me any large organisation that can even list all its current projects, which is a necessary starting point for:
- Formal "Lessons Learned" from projects and operations - known problems are avoided, known effective practices are used.
- Jerry Weinberg wrote definitive works on Software Quality Management and 35 years ago proved that focusing on Quality results in better code, written far faster & cheaper. And it is much more reliably and consistently produced!
- Jim Johnson of Standish Group, nearly 15 years ago started definitive research on what proportion of IT Business Projects fail and the causes of failure. This work is fundamental to advancing the Profession - but nobody else studies this field so his results can't be verified or refuted. Nor have organisations or practitioners, by-and-large, acted on this knowledge. People do argue that his results are suspect because other single-shot reports don't agree. But nothing happens to resolve this fundamental issue!
- Software ReUse is notable in how little it is practiced. Can it be possible that nearly ever problem is completely new? Not in my experience.
4. The fundamental reason IT is used: It's a "cognitive amplifier".
Computing amplifies the effort and output of people, providing results 'Cheaper, Better, Faster'.
On the micro scale, no organisation I've heard of measures this. It's quantitative and should be calculable by any half-reasonable Management Accountant.
On the macro scale, the 'Profession' doesn't have or publish benchmarks on results (i.e. from across many organisations).
5. The 'Profession' doesn't even have a taxonomy of jobs and tasks, let alone any consistent method for evaluating and reporting the competence of, and skill level of, practitioners.
- In a construction project you wouldn't specify "10 vehicles needed", you say "6 5-tonne trucks, 2 utes, a 20-tonne tip-truck and a bobcat".
- If the profession can't distinguish between the speciality, competence and skill levels of its practitioners, how can the business folk?
- If project plans don't identify the necessary the precise skills needed - implying some way to assess and rate the 'degree of difficulty' of individual tasks/components - then the right 'resources' can't be applied.
6. The almost complete disconnect between research results and practice. Enough said.
7. [Added]. The general capability of the Profession in general and young I.T. practitioners has declined greatly.
Proof: The increasing number of failed projects attempting to replace 'Legacy Systems'.
E.g. The failed A$200M Federal Government ADCNET project. I worked on the original IBM mainframe system, then found myself 15 years later sitting in the same awful basement not 50 feet away, coding it's replacement. The IBM system took 30-35 man-years (in structured assembler), just the second phase of the ADCNET system had a team of 70 for 1-2 years - and was abandoned. The best description of it is the Federal Court Judgment:
GEC Marconi Systems Pty Limited v BHP Information Technology Pty Limited
Federal Court of Australia
12 February 2003 and 14 July 2003
[2003] FCA 50; [2003] FCA 688
8. [Added] Creating Software is a performance discipline.
You have to both know the theory and be able to create good software.
Who are the Great Heros of Open Source? The guys that demonstrate they can code well.
Like Music, Surgery and Architecture, software requires head and hands to do it well.
9. [Added] Design is Everything.
This is what the Bell Labs Computing Research guys understood and what Microsoft doesn't. They invented the most cloned Operating System in the world - Unix, and then went onto build Plan 9, it's replacement 20 years later - with around 20 man-years. It was created portable and scalable, running on 6 different platforms from day 1. Of course it was incredibly small and blindingly fast. Time has shown it was robust and secure as well.
Not an accident that 15 years later Microsoft spent around 25,000 man-years on 'Longhorn', and then threw it all away! (The infamous 'Longhorn Reset' on 23-Sept-2005 by Jim Allchin)
Then spent the same again to create 'Vista' afresh from the 'Windows Server 2003' codebase.
How could Microsoft not understand what was well known 15 years prior, especially as Microsoft ported Unix to Intel in 1985?
There's more, but that will do for now.
"I.T. Governance" may be part of the Solution, but standards like AS8015 are primarily aimed at allocating blame or pushing all responsibility for failure onto I.T. and abnegating from I.T. any successes.
The 'root cause' of all I.T. failures is trivial to identify, but probably exceedingly hard to fix. These days, almost no projects should fail due to technology limitations - only practitioner and management failures.
The 'root cause' is: Business Management.
Yes, there are many problems with I.T. practitioners, but think about it...
Around 1950, Commercial Computing was born.
Some projects worked, in fact succeeded brilliantly: Man went to the moon on the back of that work just 2 decades later.
And then we have the majority or 'ordinary' projects that fail to deliver, are abandoned or under-deliver...
The first time 'management' commissioned a bunch of 'Bright Young Things' to build The Very Best Computer System Ever, they would naturally believe the nerds and their self-confidence.
After that effort failed, what would the rational approach be to the next project?
Not the usual, "do whatever you want and we'll see", but "you didn't do so well last time, how about we try smaller pieces or doing it differently?"
And when lining up for the third go-round, you'd think competent business managers (the ones writing the cheques) would put the brakes on and say "you haven't shown you can deliver results, we have to manage you closely for your own sakes."
"Fool me once, shame on you. Fool me twice, shame on me."
And who's the cause on the third, fifth, hundredth or thousandth repetition?
The people who keep paying for the same 'ol, same 'ol.
No comments:
Post a Comment