Taylor Vs Deming and Software Development - Part 2
Del.icio.us
Digg this
It is clear that over the past 50 years Deming’s ideas have become the dominant management doctrine among the western industrialised nations and have often been lauded for the transformation of Japanese car manufacturing in the 1970’s. Adoption of these ideas by Toyota and other Japanese car manufacturers generated such stunning productivity that it firmly entrenched these companies as the dominant players in the modern, global car manufacturing market.
Heart land of Deming & Taylor – The production line.
Despite this transformation in manufacturing, Deming’s doctrines have not had the same impact on the civil engineering, construction and to some extent the IT industries. The reason for this can be traced back to Deming & Taylor’s focus on improving production line efficiency. In contrast civil engineering and construction derive their revenue almost exclusively from the sale of unique project ventures which are rarely repeated. A key difference.
Similarly, IT Project Managers are also largely responsible for the set-up and management of one off enterprises, to deliver a single custom-made product which satisfies the requirements of a specific business case. To achieve this result, a Project Manager is responsible for the design of a “Bottom-up" project plan & the assembly of the necessary resource to deliver such a project in accordance with the designated time, quality, cost and scope coordinates. Furthermore, the one-off nature of IT projects means that a strong element of upfront product design is required.
In my view, one of the biggest reasons for large IT Project Failures is the lack of collective responsibility by line managers (who are largely the sponsors behind most IT projects) for a project or programme delivering the software equivalent of a Skyscraper rather than a Dog Kennel.
This lack of recognition can generate clashes between project and line management philosophies severely impacting the likelihood of project success.
All too often line manager sponsors see standard project management practices as totally alien and culturally unacceptable at the point where the project interfaces with the line function. These thoughts frequently cause the project to be run along modern line management principles. Sponsors often believe that values, team work, positive thinking, and motivational activities, can, if applied correctly, overcome all issues and problems and make rapid high quality delivery a reality. The engineering detail in the form of product designs /plans are left in the hands of the newly empowered and motivated project teams often working towards designated delivery dates. Vital processes such as risk /issue management become one off shopping lists, and things like change control, detailed project plans, quality control and targeted delivery based on bottom-up planning become sidelined activities.
To get a more detailed idea of this important and often overlooked reason for frequent IT project /programme failure I suggest that you take a look at one of my favourite blogs Carpafactum and pick up an inexpensive copy of Race through the Forest – a Project Management Fable by Timothy Johnson.
The Dot.com era spurned numerous companies unable to deliver technically feasible, cost effective ecommerce solutions because their projects were run in accordance with line management principles i.e Boo.com. The merchant bankers and former line managers from retail backgrounds believed that motivation and the employment of clever young people was all that was needed to make the magic work.
How wrong they were and how little things have changed today!
One memorable example of this kind of project /programme failure occurred in the London Insurance Market a few years ago when a huge programme setup to deliver an electronic insurance trading system failed spectacularly. The sponsor spent most of his time taking staff on days out to discuss and agree organisational values and sort staff into “pods” (small teams) without project plans, resource plans or any kind of change control or quality management. The sponsor naïvely believed that teamwork, positive waves (no talk of reality), trust, values, long hours focused on fuzzy task breakdowns and ever changing requirements would overcome everything.
It was no surprise to find that after two years these youthful and motivated project teams failed to overcome the towering and ever growing levels of complexity, technical infeasibility and wasted effort i.e “Thrashing” (tasks and activities completed only after discovering that they were no longer necessary due to unclear and ever changing requirements). In the end, and only after running millions over budget, the backers cut the money and shut the programme down.
However, a strange and surprising aspect of this story was that the programme had been attempted twice before, failing each time for similar reasons !
I don’t want all of this to sound like I am anti Deming where IT projects are concerned, because it is clear that happy and motivated staff who feel empowered, are very important factors in making IT projects a success. However, as IT projects start to increase in size and scope, their complexity tends to increase exponentially along with the level of potential software bugs. Without taking a more engineering and scientific based approach to the running of such projects, one usually finds that exceptional productivity gains will not alone guarantee success – Please read the book CRASH for many case studies covering this and other reasons for IT Project Failures.
If this realisation was not enough, we now know that Deming inspired thinking is being injected back into the way we run IT projects from a different direction. Yes, I am referring to Agile development methods and associated mind set /culture. Setting to one side the Agile approved list of iterative development methods for discussion in a separate post, it is clear that the Agile mind set is based around the Agile manifesto (please see my post Agile Fees Feeding Frenzy). My views on this manifesto are like my views on socialism. “Nice idea but doomed to failure” because it makes incorrect judgments about human nature (please read my post Agile fails to get to grips with human nature) and the narrow self interested behaviours of corporations, consultants and individuals alike.
Agile /Scrum and associated development methods win where motivation /energy empowerment are more important determinates of success, and when IT project complexity and size are low (new media projects). In larger scale projects where the complexity dramatically escalates, Agile approaches offer no alternative to solid proven project management and software engineering principles.
The moral of all this is to never get lured into running large IT projects in the first place. They are investments strictly not for “wives or widows”.
This message is corroborated by Bill Joy one of the biggest names in the US IT industry. In 1990 at the Churchill Club in Silicon Valley Bill Joy a tousle-haired programming genius and Silicon Valley legend known sometimes as “the other Bill”, predicted that Microsoft would ride high for several years and then everything would change. Joy was disgusted by computer code complexity and was convinced that something small and simple would generate the next great change in the computer industry. He stated that the next great breakthrough would not come from smart people working at Microsoft or Sun but a few unknowns working in a small company. These amazing predictions came true in the form of Google and Netscape.
Therefore, it has always been clear to me that the key to successful Project Management is not so much Taylor vs Deming, but having the talent to inject enough of Deming’s ideas into your project /programme to make sure you have a motivated /dynamic project team, whilst at the same time (relative to size), containing these freedoms within boundaries dictated by solid /proven engineering and project management principles.
Self assembling project teams (Scrum) and redirecting valuable Technical Architects into team management (Scrum Masters), is not going to be the recipe which brings the world consistent and repeatable IT project success.
Click here to see Part 1
This entry has been viewed 3307 times.
READER COMMENTS:
Next entry: If all else Fails - Threaten the Project Manager
Previous entry: Taylor Vs Deming and Software Development - Part 1
<< Back to Home
.
Kevin - thanks for the reference to Race - you are very right in your observations between quality management and project management principles.
Posted by Timothy Johnson on Fri 29th September 2006 at 12:26 AM | #