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.