The Rush for Quality but Buyer Beware!

In the last twenty years there has been a big push for improvements in quality that can be gained from certification under schemes such as ISO 9001. Nowhere is this more apparent than in the IT industry. I have become involved in this myself and I am a proud owner of a Quality Assurance Internal Auditor’s certificate. There are tens of thousands of companies who are ISO certified. What are the benefits? Some companies have made genuine improvements to their product or service delivery by going through the certification procedure. Many companies have obtained a marketing competitive edge by advertising that they are ISO certified. ISO certification has become big business. During my research for this blog I discovered a multitude of businesses which are advertising services to companies wishing to join the club. I found very few website contributors explaining from an objective point of view what quality management systems and ISO 9001 are all about; only Wikipedia had much to say on the subject.

Quality management has two main components: Quality Assurance which is all about the processes and procedures that need to be in place to guarantee quality and Quality Control which is all about testing a product or service against a pre-determined standard.

So what is quality? It can be described in many ways but my preferred description is “fitness for purpose”. Over the course of my thirty year career, in the IT profession, I have seen the importance of producing high quality software. The software must match the intended business purpose and it must be produced in the most cost effective way. To repair broken software is four times as expensive as producing a top quality product in the first place. Even if you produce top quality software, you are in deep trouble if it does not meet its intended business purpose.

Throughout history companies and suppliers of goods and services have seen the need for quality management even if it has been on an informal basis without official recognition by outside bodies. Companies such as Mercedes Benz, Rolls Royce and Bentley have established an absolute reputation for high quality by attention to detail and total quality management, and all without the need for outside auditors. They set the standards for quality in the automotive industry and it was difficult for their competitors to emulate them.

But what about the IT profession for which I have worked for so long. When IT was in its infancy there was a lot of resistance to change and the IT industry had to deliver software to exceptional standards to prove that it could make improvements to business processes and productivity. Failure was simply not an option. Regrettably much of the IT industry lost its way after the 1970’s and 1980’s and the industry became bloated and inefficient. Project cost and time overruns became more common as did the complete failure to deliver. In the early 1990’s confidence in the IT industry was beginning to wane. What better way to improve quality management systems and the competitive edge than by gaining ISO certification? You could prove that you were as good as any one else. Once the bandwagon started it accelerated. But, has the quality of IT delivery improved since the introduction is the ISO 9001 scheme? My view is that in general it has not. There has to be a total and continuous commitment to quality and too many companies are just paying lip service after becoming certified. So the old adage of “caveat emptor” must still prevail; so let the buyer beware.

In the course of my career I have taken time off to study wine. There are many lessons to be learnt from how the wine industry applied its quality control systems. In Europe the wine industry has been governed by quality standards since the middle of the 20^th century. In 1935 the French government imposed new wine laws as part of the Appellation d'Origine Contrôlée system. This system was used to assure the quality of vine growing and the means of wine production. A similar system has been introduced throughout the European Union and it has had varying results. Suppliers clamour to get into the top quality appellation to improve their sales. In France and other countries the system was subject to much abuse. In bad years when the harvest was cold and wet and the grapes did not ripen properly there was a temptation to add sugar to the fermenting must to increase the levels of alcohol . This practice of “Chaptalisation” is illegal in most wine regions. In times of a bad harvest there was also a temptation for producers in Northern France to import, illegally, riper grapes from the south or even Italy to improve the taste or “quality” of the wine. Many consumers could not tell that their red Burgundy was in fact adulterated with wine from the south of France. At one time the whole French system was in danger of completely losing its reputation. In the 1980’s there was a scandal involving Austrian wines when some unscrupulous producers added industrial based glycerol to the wine to improve the sweetness and the feel of the wine in the mouth. This scandal nearly broke the back of the Austrian wine export industry. Governments were forced to act to improve standards and independent testing. It is only in the last ten years or so, however, that the French authorities have actually tasted the wines as a measure of quality control. Whilst the more stringent measures have lead to a general improvement in quality, it is the force of the market that is really pushing up the level of quality in Europe. Wines from the new World where there are no government imposed standards are making big inroads into the traditional export markets of France, Italy and Spain. This is happening at the lower end of the market, but some American and Australian wines at the high end are now beginning to compete on equal terms with the top wines of Europe. Despite what it says on the label and whether the wine production is subject to quality controls or not, you are best advised to taste the wine for yourself before you buy a case. There is still a lot of bad wine on the market which is fit only to be poured down the drain. Once again let the buyer beware; a lot of poor quality wine which is not worth the money has been certified by the authorities.

A similar situation prevails in the market place for other products and services. A clean bill of health, as certified by an approved ISO 90001 auditor, does not guarantee that that the customer will get what he expects: that is top quality. The certification programme only ensures that a supplier adheres to procedures to deliver a pre-specified product or service. The auditors do not test the final product or service against a market standard. I repeat there is no guarantee that the customer will receive top quality.

From a marketing point of view being approved by a body such as the International Standards Organisation can be very important. Most customers see this is as being a guarantee of a superior product or service. It is a good selling point. However, many suppliers are only paying lip service to quality assurance. The customer must make his own efforts to ensure that the supplier is genuine and not just relying upon a certificate. Often it is better to have the courage to trust your own judgement about who can deliver the right level of quality for your business.

What is the customer to do? The IT industry in many respects is a special case. It is delivering products which have no physical being. It also delivers service. It is difficult for the customer to pre-judge the quality of the final outcome. You can taste a bottle of wine to decide if it suits your needs before you buy a case. You can test drive a car. When you buy software you can perform a proof of concept exercise to give yourself some assurance that the software will meet your basic needs but this can be long winded and expensive process. Once you have bought the software you will probably have to modify it and the software supplier will need to provide design, programming and implementation services. If your supplier is ISO 9001 certified, it does not mean that you will be guaranteed top quality performance. When you commit to a new IT project it is often difficult to back out or it is perceived to be too expensive to replace a supplier who does not come up to expectations. But, if you make the wrong decision and employ people who are not up to standard you face a bottomless pit to throw your money in. It is so important that you apply common sense and hard headed decision making when selecting a provider. Do not allow the fear factor to enter into the equation and satisfy yourself that you have selected the best supplier just because of an ISO certificate. You do this at your own peril. You must be fearless and trust your own judgement. As part of the due diligence process you must assure yourself that the supplier genuinely wants to serve the common purpose of both you as the customer, and the IT industry in general. You should also interview the staff who will be deployed on the project to ensure that they are capable of doing a good job and know how to adhere to the highest industry standards. Above all, seek out the independent opinion of other customers. A supplier who does not have ISO certification may fit the bill better than one who has, so have the courage to select wisely. IT projects are too expensive to be allowed to fail because of a lack of due diligence on the part of the customer. To rely, solely, an ISO certificate is simply not good enough.

When I need new tyres for my car or it needs to be serviced I go to my local garage just down the road which provides a high quality of maintenance at a favourable price. I checked them out with my friends before I used them and on the first few occasions when I visited I verified their work. I trust them to do a good job but they are not ISO certified. They are professionals and their customers know it. Why pass on the extra cost, of becoming certified, to the customer when you do not need to?

I always use my local garage. However, when I am on the road and get a puncture I go to KwikFit as I know they will do a good job but they can proudly display their ISO certificate on the foyer wall too.

Incident Management

Most medium sized and large companies deploy "Incident Management" systems to record errors and failures in the daily operations of their IT systems. In fact the recording of errors and deficiencies has become almost routine. Incident management has become an accepted part of information technology or information services. There is now big money to be made in providing organisations with incident management software and services. This is a big waste of money and resources because a large number of incidents should not be occurring in the first place. Incidents should be reduced to enable simple "pen and paper" administration. An incident should be a very rare exception not a regular occurrence.

I do not expect many people to agree with me, but if you have so many errors and deficiencies that you have to deploy specialised software and services, to administer them, then something is seriously wrong. There has been a failure in some or all of the following: the original definition of the business requirement, the analysis and design of the system, the design of the man machine interface, training ,education and testing. In other words you have a big quality control problem. You might also need to need at your quality assurance.

I recently read some incident management procedures which included twelve categories of errors. This is almost farcical.

Incident management systems do nothing , of course, to fix the basic problems . They do, however, divert the attention of management from resolving the real failures. Organisations become buried underneath the statistics relating to problems which should not exist in the first place. This is all a symptom of gross inefficiency.

The original promise of Data Processing or Information Technology was to improve business administration: to improve the work flow and reduce errors to a minimum or eliminate them altogether. We could then free up human resources for decision making and creative activities. This should have been achievable if we had used our brains to critically examine work processes and the methods by which we analyse , design , program and test IT solutions.

Correcting something that has gone wrong is much more expensive that doing the right thing in the first place. In other words prevention is better than cure. It is time for all organisations to do something about it.

Humanity in Management

This week the Commission on Improving Dignity in Care for Older people made a report that made recommendations to improve the care of old people in hospitals and the British National Health Service. Even though the commission was given a rather pompous name it raised some strong points. One of the most important of which is that older people are not treated with the respect, compassion and dignity that they deserve. Despite all the controls, management procedures and checklists extant in modern organisations something has gone wrong.

I posit that amongst all the controls and checklists we have forgotten our humanity and people are being treated like the computers that control our lives. A computer could not care less how you converse with it or treat it for that matter. It is just a machine that should be serving the will of the humans that created them. It is a tool which can make an organisation run very effectively if used properly. But when the machine is misused to create unnecessary bureaucracy it can clog up the "oxygen system" of the administration to create mindless systems which serve little or no purpose.

This is not just happening in the National Health Service and the caring professions it is happening everywhere. It is as if the system is being run by people who as so burdened by bureaucracy they have forgotten their humanity. It is time to re-educate ourselves and set an example to the very young in our schools of the importance of putting people first and the machine second.

We need to solve these problems not just by imposing further rules about how we talk to one another but how we act towards one another. Let the human beings be treated as sentient beings and the computers be treated as just machines and not the masters which are there to control us. Information Technology could then free all of us up to lead healthier and more constructive lives.

Paying lip service to improvements by trying to control the language we use will not really help. I would quite happily swap being called an "old boy" for a first class health service that met my needs. Action first followed by the niceties of politeness. You are what you do not what you say.

Checklists, Procedures and Drudgery again

Young people do not come into the IT industry with the intention of following checklists and procedures which make their life a drudgery. There is obviously a need for standards when analysing, designing and implementing computer systems. For some reason, however, the IT industry is being coming more and more bureaucratic and is concerned more about controlling the people than the work. This is leading to a "long hours" and "do everything at the last minute" culture, which is stifling creativity, critical thinking, productivity and problem solving efficacy. No wonder our young systems designers and programmers are bored, disaffected, tired and overworked when a crisis crops up. And, unfortunately, the crises are now occurring too often.

Why can we not encourage a working environment where young people are allowed and encouraged to think for themselves within the parameters and limits of proven standards of working? If everyone one understands the engineering principles behind good IT practice they will then be able to act more responsibly. We as managers would then be able to delegate authority and responsibility to project team members to allow them to control their own work within the confines of a good project plan and in full co-operation with their fellow workers. Every one will then be part of a well organised team which knows what to do without being restricted and hidebound by too many unnecessary rules, check lists and processes. This will then be the route back to high quality delivery, high productivity and a healthier working environment for all. We might start enjoying ourselves at work again.

Check Lists, Procedures and Drudgery

I have spent a considerable amount of my career designing procedures for best methods of operation. Before computers were widely used it was important that clerical or manual methods of operation operated at optimal cost effectiveness. When computerisation was in its infancy we often conducted studies to compare the cost of the manual operations against computerisation. We delayed automation if it was more expensive to computerise an operation . This is not the case today but it might be educational to make such comparisons; even now.

I am surprised that we have not made further advances in removing paper from our computer procedures which still rely upon manual operations to a greater or lesser extent. The technology is certainly good enough, now, to completely automate many procedures. For instance, whilst it is possible to settle a credit card account by arranging a variable direct debit to clear the whole outstanding amount, it is not so easy for the customer when they want to settle a lesser amount. I am surprised that a decision based system has not been developed to allow the customer complete flexibility on an automated basis.

Manual operations still need to be used in spite of it being feasible to completely automate some business operations. And it looks as if this will be the case for the foreseeable future. The man machine interface, therefore, needs to made as efficient as possible by the use of effective procedures. But tight procedures quite often cannot cope with the out of the ordinary situation and militate against flexibility.

All organisations now have such tight procedures and checklists, which are used to control the man machine interface, that they deny flexibility to the human operators. This is apparent when you 'phone a call centre. As long as you are calling about a routine request the operator, at the other end of the 'phone, is able to cope adequately. If, however, you are making a call about a matter which falls outside of the rules or checklists, that govern the behaviour of the human being, the procedure often falls down. Often the call centre clerk then is unable to answer a request or enquiry as they do not know what to do. Even a supervisor might not be able to deal with events which fall outside of the system rules. It is, as if the human beings themselves have become "robots" who cannot cope outside of the check lists and pre-ordained processes. Systems designers and back office managers should take this into account when organising the work. The staff should not be treated as if they are automatons, and they should be allowed and encouraged to think for themselves so that they can become problems solvers. At little bit of creativity should be allowed to creep back into the system for the sake of both the customers and the workers.

Automated systems give us the opportunity to take the drudgery out of repetitive work and free us all up to do something more creative than just push buttons.

Further to the Feasibility Study

I was involved in two very interesting feasibility studies for a major American International Bank many many years ago.

For the first, the Bank was faced with applying Composite Rate Tax or Withholding Tax to the accounts of retail customers. I was the IT representative for the feasibility study and we also used some hard headed business managers. We calculated the cost of providing an automated solution and implementing it. We also calculated the cost of implementing a manual solution. We also considered the disruption to other projects. During the study the question was asked, what was the Bank doing in the business of retail banking? We quickly concluded that the best solution was to close the accounts of the few retail customers that the Bank had. It was simply the cheaper option and made sense from a business point of view. The customers were encouraged to open retail accounts with a British correspondent bank. The cost of the feasibility study was minimal and we were able to concentrate on the business and IT aspects of implementing our Global International Banking system.

For the second, the business was interested in automating the re-investment of funds which appeared on the Bank's books as a result of the errors of other Banks. This was a large sum of money even on a daily basis and there was profit to be made from re-investing money which was in error whilst the back office traced the rightful owner of the funds. I performed a feasibility study to decide whether it would be economic to completely automate a solution but at the time there were technical difficulties which made complete automation too costly. I recommended that we shelved the the solution pending future technical improvements. Two years later I was at a meeting where the issue was raised again and an IT colleague produced my report : it was now technically possible to go ahead with the proposals. The business made some calculations that it was also economic to proceed so we went ahead.

These two examples show how a good feasibility study can be used to good effect to produce cost effective and beneficial results.

The Feasibility Study

It is very difficult to complete a very good feasibility study. You are confronted, quite often, with inadequate business information to assess the value of a proposed new system or modification.

The feasibility study is all about evaluating the the proposed business benefits against the cost of their delivery. A new system should be able to deliver an adequate return on investment. The study should also examine the technical aspects of a proposed new system as it may not be possible to deliver the promised business benefits from an operational, throughput or timing point of view.

It is relatively easy to marshal and gather all the facts regarding the cost of implementing a new system or modification and it also easy to be tempted to ignore or reduce the cost of an item if it does not support the financial case. This temptation should be resisted strongly as no organisation is done a favour if the cost of a change outweighs the financial benefit.

The real difficulty comes in calculating the financial benefits as you are often operating in a vacuum. It is extremely difficult to even calculate productivity savings let alone the reduction of staff costs. It is more difficult to assess the financial benefit of improved customer service or a potential increase in market share or intangible benefits such as improved competitiveness.

Many management experts still apply the Pareto principle or the 80 20 rule when gathering management information: that is 20 percent of your time is used to obtain 80 percent of the information needed to make your decision. Therefore, it may not be cost beneficial or even possible, in a reasonable amount of time, to get to the 100 per cent certainty that you have gathered all the facts to make an objective decision.

Business managers, therefore, are acting more often than not upon sound judgement, instinct and intuition as much as the evidence gathered from facts. When assessing the business case experience, common sense and hard headed thinking are needed. Unfortunately most of this cannot be learnt from a text book or a prescribed list of procedures. You have to have the courage to trust your own judgement and operate fearlessly.

The decision makers must include business managers and clear thinkers who are able to critically examine all financial and operational proposals and tangible or intangible benefits. The decision makers must weed out understated costs and overstated benefits. They should also consider the implications of cost and time over runs.

Doing feasibility studies to recommend the most beneficial approach have been the most interesting and most difficult tasks that I have attempted in my career.

The Common Purpose

President Obama has been talking about motivating America by getting everyone to work for a common purpose. This is not a new concept; my colleagues and I have been talking about this for years with particular emphasis to the IT industry. A little while ago I was talking to a good friend and colleague about some of the projects that we had worked upon recently, when out of the blue he said that all of the projects that he had been managing recently had been closed down because the software house he had been working for had failed to deliver their side of the bargain. There was one honourable exception where the customer, itself, had gone out of business. Why had this happened? I know that my colleague is an exceptionally talented project manager and programme director and has the drive and nous to succeed.
Many people from top to bottom in our industry do not understand the concept of a common purpose where customers and purchasers work together to meet mutually beneficial goals. These goals should be to implement information systems which meet objectively defined business purposes which improve customer service, productivity and profitability. When all the stakeholders within an IT industry work to this code of practice and set aside pure self interest there will be benefits which will accrue for the whole of our society which will become more productive and rich. If stakeholders only concern themselves with self interest then IT implementation failures will become more apparent and the whole of industry will be the worse for it. A change of attitude is needed from everyone employed in the industry to ensure that issue of common purpose is addressed effectively.

The purpose of this blog

The purpose of this blog is to encourage the use of simple techniques, common sense and straight talking to run projects. It more about the human aspects of running a project and the leadership

required to be successful. It is not about public relations and motivational speech; it is all about doing enjoyable work and achieving your goal.

Talk and promises slip off the tongue easily but delivering on your promises is sometimes very difficult and it often requires strength of character and strong leadership to achieve the right result.

No-one can lead their working life without being confronted by failure but as long as you learn from it there is no reason why you cannot be a good project manager. This blog is designed to encourage you to apply common sense, leadership and simple techniques to overcome managerial problems.

Let me get one thing of my chest: I cannot stand euphemisms. One of the most egregious euphemisms is to call a problem a challenge. I hear this all the time: on news reports and breakfast programmes or coming out of the mouths of politicians and business leaders. "Challenge" is seen to be a positive word and "problem" is seen to be negative; so heaven forbid if you appear to be negative. This attitude is nonsense and if you do not recognise that you have a problem then you will not be able to solve it. The challenge is to solve the problem which will not go away unless you take some action rather than mouthing trite euphemisms.

This blog is not about how to use processes to get your project done. Hundreds of books have been written about how to run a project and you can always go on a course. No one realises, more than me, the importance of applying standards and the correct process to get something done. In the past I have written standards about how to do work and I have designed hundreds of processes about how to do business operations but all of them have been short and to the point. There is, however, no book or process which can tell you how to have the courage, common sense and integrity to be a leader as you have to learn this yourself by experience.

I have just finishing reading "Carrying the Fire" by Michael Collins who was the command module pilot of Apollo 11. One the greatest successful projects ever attempted was achieved with minimal computing power on both the spaceship and on the ground. Nowhere in the book does Michael Collins mention Prince methodology or ISO 9001 quality certification and they still got to the moon. I wonder why? Perhaps being methodical and quality conscious was a way of life rather than a prescriptive text. The pilots had plenty of operating procedures to be mindful of just to get themselves off the ground without the extra burden of quite often unnecessary administration and bureaucracy. While we are talking about astronauts, how would mission control have responded if James Lovell, the Apollo 13 commander, had said "hey Houston we've had a challenge here" rather than "hey Houston we've had a problem here", when the oxygen tanks in the service module blew up? I suggest that they might not have made it back safely. Common sense and straight talking got them back home. All communication with the pilots was directed through one man, another astronaut, there was no room for a conference call facility - simple human communication techniques were deployed to control mankind's most ambitious and complex programme and all of its projects.

I am not a Luddite and I am an enthusiastic advocate of the efficient and effective application of information technology. Efficient and effective are the key words, for if technology is not applied with common sense and hard headed thinking the results are often administrative chaos and the failure to meet objectives.

Project Managers need to be something more than a job description. They are leaders, they need to operate for a common purpose and for the common good. They need to be excellent communicators who can orchestrate and organise all the elements of a project or programme to meet the business purpose and objectives. They need to act with integrity and not be self serving and above all they need to act with a sense of duty and responsibility to their profession. This is what this blog is all about.

Business Purpose of a Project

This is one of the most important factors influencing the success or failure of a project. How can you a plan and run a project successfully if you do not know what you are setting out to achieve? Business and finance managers must be actively involved in defining the business purpose of a new project or systems implementation. Before any new project is undertaken there must be a clear idea of the benefits of the intended outcome such as:

Improved customer service

Streamlined business operations

Improved competitiveness

New product or service offerings

Improved productivity

Reduced unit costs

Improved profitability.

In the private sector the profitability factor is almost paramount as no project should be initiated if it is going to lose money. There must be a tangible return on investment and all parties involved in the project must bear this in mind.

In the public sector or non-profit making organisations there is obviously less emphasis on making making money. However, is there not a moral imperative to either save money or to get the best value out of an investment?

I suspect that in both the public and private sector too many people do not focus keenly on value for money and eliminating waste; this is not an area which should just be left to the domain of financial and management accountants.

The business purpose of the project is translated into the objectives of the plan and the project budget. Before a project is initiated it should be the subject of a feasibility study. The practicality of implementing the business objectives is critically examined from an operational and cost versus benefit point of view. I have been involved in a number of feasibility studies during my career. During one feasibility study we quickly decided not to proceed with project because the technology could not meet the business purpose. But this decision was reversed several years later when improved computing power became available. In another feasibility study we decided to drop a banking service because the cost versus benefit of computerising it was not worthwhile. In those feasibility studies both the business and IT management were heavily involved in the decision making.

Once it has been decided that a project is feasible from a technical and money point of view the decision must be made whether to proceed or not and when. Once again business and IT management must play a key role to show how the project fits in with the other activities of the organisation. Possible business disruption should be taken into account before deciding to go ahead. Once the decision to implement has been made, the business purpose of the project should be clearly published by the senior management together with the tangible benefits of delivering the system. The senior management must also demonstrate their continuous commitment to the implementation of the project.

I learnt a long time ago that it is best to design a system backwards thus if , for example, you are simply designing a report to produce some management information it is best to agree and define what the output must contain and look like first. From this definition the processes to produce that output can be constructed and then the input requirements defined. Of course, a system specification is read from front to back but you will fail if you do not concentrate on the output or outcome required.

The same applies to the business purpose, it is the starting point of the project and all project activities must be planned and executed to achieve the business purpose. If the business purpose is irrational or ill-defined no project can correct the situation no matter how well it is run so there will be failure.

Budding project managers will do well to ensure themselves that the project they are being asked to run has a rational and well defined purpose and that all parties to the project are committed to its success otherwise ultimate failure looms. And before you think that I might be talking rubbish: what did the the application of "Gaussian Copula" risk calculations, using highly sophisticated automated programs, do to the finance industry and our western economy? Well, it nearly led to global financial meltdown. The business managers in the finance industries affected did not truly understand the business purpose of their programs and the likely effect on the financial viability of their businesses. Try this book "Fool's Gold" by Gillian Tett.

There are hundreds of examples of lesser failure. If you can foresee a failure it might be best to avoid it despite the monetary attractions. Look for projects which have a tangible business purpose which is clearly defined and communicated and establish the feasibility of the project before making a commitment. This will get you up and running on the difficult path to success.

Senior Management Commitment

Senior Management Commitment is one of the most important pre-requisites to get an IT programme or project to start working effectively and efficiently from the start. It must continue all the way through the project. This commitment must be published to all the stakeholders associated with the programme or project - from business directors and users to project team members. It is particularly important that business directors champion the project and that it is made clear throughout the business organisation that the directors support all of the project's objectives.Senior management must be confident that there will be a positive outcome from a successful implementation. The Business and IT directors must be able to demonstrate to all stakeholders that there will be a fair return on investment and that there will be customer service, productivity and business efficiency improvements realised from a successful conclusion. Senior managers usually form a steering committee to monitor the progress of the project against the plan and budget. The steering committee also convenes to approve any change to the objectives, business purpose or budget of the project.

Programme and Project Management Blues

I have worked in the IT industry since 1979 and Information Technology has taken me all over the world to work on programmes and projects. I have seen huge changes to both the computing hardware and software industries and how projects are run and managed.

I started working in IT for an insurance company in 1979 and taught myself to program computers in PL/1 using an IBM course and the assistance of the senior programmers. In those days we had an IBM 370 mainframe computer and the core storage available was 512 kb -yes 512 kilobytes. Most of the data of the insurance company was held on tapes but the 370 also used removable disks which functioned very similar. There was big excitement when the Data Processing Department bought some fixed disks which eliminated the need for computer operators to load and unload tapes and disks as dictated by the the computer programs and Job Control Language.

I could never quite get the hang of Job Control Language (JCL) with its arcane text of "dlbls" and "tlbls" but they referenced the disk and tape libraries which held the data of the company. When you wrote a computer program you used a coding sheet (on real paper) this sheet was then passed to the punch room where the punch room ladies, it was always women, converted your code into punched cards. The punched cards had eighty columns and the holes represented the order of the text. When the program was read under the control of the JCL, which you also had to write yourself on a punched card, the holes on the column were converted by the card reader into machine language. The program was run by the computer operators who used huge flowcharts to control the sequence of tape and disk loading and running of the jobs.

You had to be very careful not to make mistakes as you could easily delete the contents of a disk or tape by using faulty JCL which meant that the operators had to restore from back up. This was a lengthy task and the one time a programmer , not me, made a serious mistake the back ups had not been made in the correct sequence and this caused chaos.

"Punch girls" and Computer Operators no longer exist but you were advised to keep very good relations with them as they could help you correct and cover up errors. There was no room for arrogant behaviour especially with the "punch girls" as some women can be very cruel with sexual innuendo. It was an object lesson in how to improve efficiency by maintaining good relationships with your colleagues.

In those days computer resources were expensive and at a premium, so computer programs needed to be well structured and operate at maximum efficiency. 512 kbs is not much space to run a program by today's standards and even virtual storage was in short supply, you really had to think hard not just about the logic of your program but also the efficiency of how it would run. This was software engineering in the truest sense of the word. Even so , we managed to run a very large company with minimal IT resources and we were able to produce more reports on green "flow line" paper per day than could be read by all the staff in one year - think about it.

Computer resources were so expensive and there was such a shortage of "off the shelf" software that before a manual process was automated a cost benefit analysis was made to compare the cost of an efficient manual system versus automation. If automation could not be shown to be cost effective then it was delayed. In my early working career I was often part of teams which determined the efficiency of manual operations versus automation. Quite often a manual operation could be improved so much that it was uneconomic to automate it. I suspect that this could still be the case today but of course many people would think that you are mad to even raise or suggest this idea even to the chagrin of the organisation. I still believe that we should be open minded and apply common sense to all forms of business operation; sometime a simple written diary or address book is more effective than a "PDA".

In 1979 there were few resources to help you administer a project. Reports were written by hand and given to the typing pool. Once again you really had to think before you put pen to paper. You had to structure your report correctly and get your point across as clearly and with as few words as possible. Not all the typists were able to correct your spelling or grammar errors. If you sent a report back for correction more than a couple of times the typists, who were mostly women, got annoyed and you did not take liberties with them. It was also important to maintain good relationships and get the best typists working for you as they were able to save you time and effort by correcting spelling or grammar errors which may have crept in to a rushed report. The same applied to business letters and important internal memos. There was no email so internal written communication was made on "NCR" duplicate pads in handwriting and placed in the internal mail. Once again you had to think about what you were going to write and pay attention to spelling and grammar to avoid intense embarrassment. Flowcharts and tables were constructed manually and you really had to think how they would be included in a type written document. Word processors and design software really changed the world but we had to wait until the late eighties and nineties before their use became widespread. In 1979 not everyone had a telephone on their desk.

In the early eighties I went to work for Bank of America to implement their new tailor made systems in their European and Latin American branches. This was the most productive time of my working life and in five years I did more effective and productive work than in the subsequent twenty. I implemented more systems than I could count mostly on time and on budget. They were implemented despite some political difficulties and in one case where the business requirements were not defined properly. Our team was on the road most of the time so I suppose that we were at work for 24 hours a day but no-one asked us to work excessive hours and we only worked at weekends when we made actual or dummy conversions. During the day we tried to get everything completed in a reasonable time but we always took a lunch hour at a restaurant and we never ate lunch at our desks. The administration tools at our disposal were limited: we had a form of internal email and word processing software. Writing long reports was semi-automated we often gave long reports to a word processing section, mostly women again, who then sent them back to us via email for correction using a word processor at our desks. Diagrams and tables etc were added to reports manually or scanned. There were no portable 'phones, spreadsheets, conference calls or voice mail or blackberries. For many days we were out of contact with our boss who trusted us to do the job. We sent back a weekly report and only really 'phoned the boss when when there were political difficulties stopping us from working or there were serious problems. We won extraordinary performance awards and we were all given a years salary as a bonus for getting the job done on time and on-budget. The new systems greatly improved the administration of the Bank and reduced costs and helped them to win new business during a difficult period when there was a sovereign debt crisis. From a debt point of view nothing has changed and the same financial difficulties are being repeated - but who ever learns from history?

During the nineties and the early twentieth century I have seen a decline in the way projects are meeting their objectives, both from the point of view of the achievement of the business purpose and meeting deadlines and the budget. Fifteen years ago I jointly ran a project at a large bank which implemented a system and its changes in four international branches within nine months. The project was completed on time and within budget with only fourteen staff. In 2012 it would almost be impossible to achieve the same thing despite modern administration aids and programming techniques. Not all projects suffer but there have been some spectacular failures in both the private sector and the public sector. This trend of failure must be reversed. Why is there this failure? Well lets take a look at what happened in Bank of America.

The management were fully committed to the project and this was made clear to all parties concerned that the new system would be implemented worldwide in spite of any objections or political difficulties. It was a policy driven bank. The business purpose was fully defined and clear. The implementation teams knew what they were doing and authority and responsibility were delegated to them. The implementation teams were trusted to get on with the job. We applied a commonsense approach to the business of getting the job done. Communication was difficult because we only had 'phones (land line only) and internal email whilst away from the office. Because communication was difficult and we could not easily contact the bosses when something went wrong we had to plan carefully and think what we were doing. Likewise the bosses could not easily contact the project team to impose silly changes to schedules and new conditions of working even if they wanted to. There were no conference calls, or video conferences, no breakfast meetings with bosses and no calls with bosses either in the early morning or in the hotel rooms late at night. We were left to get on with our own work. Team morale was high as we governed what hours we worked there was no need to pretend that we were working when we were not. We did not mix up our social life with work in the office so telephone calls home were limited to one per day and this call was usually made from the hotel if time differences allowed. When we went to the office we just worked, there was no face book or twitter to fool around with. We never worked too long or stayed in the office if we did not need to be there.We did not need to pretend that we were committed to our jobs by sending emails at unsocial hours. We did the job point blank. Automated spreadsheets and project software were non-existent and any table or Gantt chart had to be kept simple for there was no room for pretty colours or even red ,green and yellow traffic lights. If the project was behind schedule we told our bosses. If we asked for extra resources, they knew that we had not considered this lightly and they flew in the personnel without having to fill in a form or write ten pages of justification. Programming and systems resources were not offshore; they worked from the same office and in an emergency they would be flown in to where we were working on site.

Compare this to what happens today, even if the management are fully committed and the business purpose of the project is well defined and communicated it is intensely difficult to get a project done. Team members are now unused to working independently and working on their own initiative away from home. Working conditions are becoming more and more onerous and staff are expected to be in the office for long hours rather than working effectively for a shorter period of time. Because the staff are expected to be in the office for the whole day they mix up their work with their social life that is why conference calls are arranged from school playgrounds, train stations and airports etc. The project staff are tired and unproductive from spending too long in the office and when they are called upon to be at work in an emergency or over a conversion weekend they are too tired to work effectively. Modern administration aids are a bureaucrats delight and project administration quickly becomes buried in spreadsheets, charts, dashboards , conference calls and automated piles of emails sent from issue logging systems and automated testing software. A plan is now just seen as an automated task list or even worse as a series of boxes on a spreadsheet. Few people realise that a plan has to be a written document which is about the purpose, budget and schedule of the project and how it needs to be organised to get things done. The Gantt chart should be an appendix at the back. Despite all the procedures for certifying the work and the workers, the quality of the planning, testing, training, analysis and programming is going down. Too many organisations are hell bent on controlling the staff rather than the work. No wonder project staff do not have the energy to think before they put pen to paper. It is easier to let the automated software do the thinking for them.

When I run projects, I try my best to reverse these trends and simplify the work and the communication. I try to improve the morale of the team by letting them get on with the job in their own way and think for themselves whilst maintaining high standards of work. I also try my best to relieve them of all the bureaucratic nonsense surrounding project work. Some of the team members get disconcerted if I tell them to go back to the hotel if I think they have been working too much or they are tired. They are also disconcerted that I do not want them to 'phone me outside of office hours unless there is a real emergency. Most ,however, quickly get used to this new simplified and more humane method of working. I encourage them to think for themselves and try and solve the problems among themselves. After all, Christopher Columbus did not send a carrier pigeon back to the King when there was a hole in the hull of one of his ships and ask him want to do: he repaired it on the spot. Lets get back to some that spirit, for then the projects might run a little better. Let us get some humanity back into running projects. I am not a technophobe but try to apply the most apt tool for the job in the most efficient way. But let us not be fooled by "technophilia" and the love of technology for its own sake as projects are run by people not by automated emails, conference call technology and spreadsheets.

It is my mission to get back some commonsense into running projects and I hope you agree with me.

Contact me on http://www.project99.co.uk/