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/
No comments:
Post a Comment