One way of deciding what ought to be covered in 'software project management' is to consider what problems need to be addressed.
Traditionally, management has been seen as the preserve of a distinct class within the organization. As technology has made the tasks undertaken by an organization moa* sophisticated, many management tasks seem to have become dispersed throughout the organization: there are management systems rather than managers. Nevertheless, the successful project will normally have one person who is responsible for its success. Such people are likely to be concerned with the key areas that arc most likely to prevent success - they arc primarily trouble-shooters and their job is likely to be moulded by the problems that confront the project. A survey of managers published by Thayer, Pyster and Wood identified the following commonly experienced problems:
• poor estimates and plans;
• lack of quality standards and measures;
• lack of guidance about making organizational decisions;
• lack of techniques to make progress visible;
• poor role definition - who does what?
• incorrect success criteria.
The above list looks at the project from the manager's point of view. What about the staff who make up the members of the project team? Below is a list of the problems identified by a number of students on a degree course in Computing and Information Systems who had just completed a year's industrial placement:
• inadequate specification of work;
• management ignorance of IT;
• lack of knowledge of application area;
Further details of the survey can be lound in Major issues in software engineering project management' in IEEE Transactions on Software Engineering. Volume 7, pp 333-342
• lack of up-to-date documentation;
Stephen Flower's Software Failure, Management Failure. Wiley & Sons. 1996. is an interesting survey of failed computer projects
• prcccding activities not completed on time - including late delivery of equipment;
• lack of communication between users and technicians;
• lack of communication leading to duplication of work;
• lack of commitment - especially w hen a project is tied to one person w ho then moves;
• narrow scope of technical expertise;
• changing statutory requirements;
• changing software environment;
• deadline pressure;
• lack of quality control;
• remote management;
Note how many of the problems identified by the students stemmed from poor communications. Another common problem identified by this and other groups of students is the wide range of IT specialisms - an organization may be made up of lots of individuals or groups who w ill be expert in one set of software techniques and tools but ignorant of those used by their colleagues. Communication problems are therefore bound to arise.
What about the problems faced by the customers of the products of computer projects? Here are some recent stories in the press:
• the United States Internal Revenue System was to abandon its tax system modernization programme after having spent S4 billion:
• the state of California spent SI billion on its non-functional welfare database system:
• the £339 million United Kingdom air traffic control system was reported as being two years behind schedule;
• a discount stock brokerage company had 50 people working 14 hours or more a day to correct three months of records clerically—the report commented that the new system had been rushed into operation without adequate testing;
• in the United Kingdom, a Home Office immigration service computerization project was reported as having missed two deadlines and was nine months late;
• the Public Accounts Committee of the House of Commons in the United Kingdom blamed software bugs and management errors for £12 million of project costs in relation to an implementation of a Ministry of Agriculture computer system to administer farm subsidies.
Most of the stories above relate to public sector organizations. This may be misleading—private sector organizations tend to conceal their disasters and in any case many of the public projects above were actually being carried out by private sector contractors. Any lingering faith by users in the innate ability of IT people to plan ahead properly will have been removed by consideration of the 'millennium bug", a purely self-inflicted IT problem. On balance it might be a good idea not to survey users about their problems with IT projects!
1.9 Management control
Management, in general, can be seen as the process of setting objectives for a system and then monitoring the system to see what its true performance is. In Figure 1.2 the 'real world' is shown as being rather formless. Especially in the case of large undertakings, there will be a lot going on about which management should be aware. As an example, take an IT project that is to replace locally held paper-based records with a centrally-organized database. It might be that staff in a large number of offices that are geographically dispersed need training and then need to use the new IT system to set up the back-log of manual records on the new database. It might be that the system cannot be properly operational until the last record has been transferred. It might also be the case that the new system will be successful only if new transactions can be processed within certain time cycles. The managers of the project ought to be asking questions about such things as how effective training has been, how many records have still to be transferred to the new database and transfer rates. This will involve the local managers in data collection. Bare details, such as 'location X has processed 2(XX) documents' will not be very useful to higher management: data processing will be needed to transform this raw data into useful information. This might be in such forms as •percentage of records processed", 'average documents processed per day per person' and 'estimated completion date*.
In the example above, the project leader might examine the 'estimated completion date' for completing data transfer for each branch and compare this with the overall target date for completion of this phase of the project. In effect they are comparing actual performance with one aspect of the overall project objectives. They might find that one or two branches are not going to complete the transfer of details in time, and would then need to consider what to do (this is represented in Figure 1.2 by the box making decisions/plans). One possibility would be to move staff temporarily from one branch to another. If this is done, there is always the danger that while the completion date for the one branch is pulled back to before the overall target date, the date for the branch from which staff are being moved is pushed forward beyond that date. The project manager would need to calculate carefully what the impact would be in mov ing staff from particular branches. This is modelling the consequences of a potential solution.
Several different proposals could he modelled in this way before one was chosen for implementation.
Having implemented the decision, the situation needs to be kept under review by collecting and processing further progress details. For instance, the next time that progress is reported, a branch to which start" have been transferred might still be behind in transferring details. This might be because the reason why the branch has got behind in transferring details is because the manual records are incomplete and another department, for whom the project has a low priority, has to be involved in providing the missing information. In this case, transferring extra staff to do data input will not have accelerated data transfer.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.