For Project Managers and anyone involved in delivering change to an organisation learning lessons is an important part of your job. Ensuring lessons are logged and shared helps businesses evolve by avoiding the same pitfalls and also repeating activities that went well.
I have always been extremely passionate about lessons learned and if done well, consistently and the organisation has a good process, can really help companies mature. Unfortunately all too often i have seen many projects avoid producing lessons learned and It is a sad fact that some organisations just don't value the benefit lessons learned can bring.
In my view a couple of the reasons why lessons learned are not valued is that:
- An organisations governance group e.g. PMO does not ensure this activity is carried out
- If the lessons document is produced there is no library for anyone to refer to and so the document goes into a black hole, gathering virtual dust
Why Computer Systems Failed in 1971
A few years ago i was given a handout which was dated 1971 titled 'Some Reasons for Failure of Computer Systems'. This highlights some reasons for failure of computer systems back in a early 1970's.
What i find interesting is that most of the difficulties faced in 1971 are still present today.
So whilst it seems we continue to repeat some of the same errors some 40 years later we can try to mitigate the risks as best as we can.
The handout from 1971 included the following lessons:
- LACK OF MANAGEMENT INVOLVEMENT - The involvement of the line managers with computer system development is necessary to provide the required guidance and authority for the design of successful systems. This is particularly vital where large integrated systems covering more than more department or function are concerned. Lack of involvement leads to poor integration and a system which may not meet user requirements.
- POOR COMMUNICATION - This may exist between computer staff within the installation and also between computer staff and users. At worst, it results in a system users cannot or will not use which does not provide the required information in the required form at the required time. In the design and implementation of all systems there is a need for both formal and informal communication between designers, implementers and users.
- INEXPERIENCED COMPUTER STAFF - Staff may be inexperienced in either the applications of the computer or in the particular type of computer to be used or both. This is a most serious problem and can cause more, if not all, of the other problem areas mentioned. This rapid rate of technological change makes it very difficult to achieve the desired level of experience in systems development staff.
- UNCLEAR OBJECTIVES - Without a clear statement of objectives, understood by users and computer staff, an inadequate functional specification or requirements to meet the objectives will results. In the worst case this can result in providing solutions to the wring problems. The identification of objectives in a form helpful to systems development is extremely complex and the difficulty should not be minimised.
- POOR DESIGN OF COMPUTER SUB SYSTEM - The results of bad system design as usually found in poor performance which created processing bottlenecks, long response times, high usage of computer resources etc... There are many areas where poor design can affect the final system e.g. file organisation, input / output formats and procedures, difficulty in enhancement etc...
- INADEQUATE STANDARD SOFTWARE - Most systems are dependent on some software provided by the hardware manufacturer, e.g. operating systems, compilers etc... Such software which is unproven, late or does not meet the required specification in terms of facilities or performance can seriously disrupt a user's plan and the ultimate performance of its system. It can result in increased costs to rewrite or redesign a piece of standard software.
- INCORRECT HARDWARE CONFIGURATION - An erroneous choice of equipment or configuration affects design and performance. It can result in over or under utilisation or may give rise to problems in enhancement in the field. It is often difficult to arise at an optimum configuration where balanced utilisation of peripherals, storage and processors can be obtained, particularly where a mixture of applications is implemented on one machine.
- LACK OF PROGRAMMING STANDARDS - This can lead to problems in implementation where programming / module interfaces does not match and difficulties are experienced in assembling and testing the system. The use of documentation and specification standards is important and training for all programmers in the particular methods to be adopted may well be necessary.
- OPTIMISTIC TIMESCALES - Poor planning or inexperience often leads to optimistic timescales resulting in delays in implement, higher than budgeted costs and management frustration. Effective planning and monitoring of progress by using up to date techniques greatly assists in achieving deadlines.
- POOR TESTING ENVIRONMENTS - Without adequate testing, test data and facilities, difficulties will be experienced in satisfactory testing of the system Problems may only come to light after implementation and may result in complaints by users or customers, lack of confidence in the computer and the continuance or private or manual systems.
- UNCONTROLLED MODIFICATIONS - Most systems can benefit from modification and enhancements but they must be planned, budgeted, agreed and properly recorded if confusion, higher costs and delays are not to result. The effects or even an apparently simple modification be have major ramifications on the total system.
- LACK OF DOCUMENTATION - A properly documented system will contain system, programming, operational and user aids. Without this, maintenance and enhancement of the system can be become impossible and user appreciation of the potential of the system is lost.
Have you experienced any of these? Do you agree we face the same challenges today?