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/