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 more 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 w ho is responsible for its success. Such people arc likely to be concerned with the key areas that are most likely to prevent success - they are 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;
• 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 w ho had just completed a year's industrial placement:
• inadequate specification of work;
• management ignorance of IT;
• lack of know ledge of application area;
Further details of the survey can be found 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;
• preceding 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 when a project is tied to one person who 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 will 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.
Stephen Flower s What about the problems faced by the customers of the products of computer
Software Failure. 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.
Management Failure. Wiley & Sons. 1996. is an interesting survey of failed computer projects
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 w ith 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 w ithin 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 2000 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 w hat the impact would be in moving staff from particular branches. This is modelling the consequences of a potential solution.
Several different proposals could be 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 staff 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.
Project objectives should To have a successful software project, the manager and the project team members be clearly defined. must know what will constitute success. This will make them concentrate on what is essential to project success.
There might be more than one set of users of a system and there might be different groups of staff who arc involved its development. There is a need for well defined objectives that arc accepted by all these people. Where there is more than one user group, then a project authority needs to be identified. Such a project authority has overall authority over what the project is to achieve.
This authority is often held by a project steering committee, which has overall responsibility for setting, monitoring and modifying objectives. The project manager still has responsibility for running the project on a day to day basis, but has to report to the steering committee at regular intervals. Only the steering committee can authorize changes to the project objectives and resources.
Effective objectives are concrete and well defined. Vague aspirations such as 4to improve customer relations' are unsatisfactory. Objectives should be such that it is obvious to all whether the project has been successful or not. Ideally there should be measures of effectiveness, which tell us how successful the project has been. For example. 4to reduce customer complaints by 50%' would be more satisfactory as an objective than 'to improve customer relations'.
In order to keep things manageable, objectives might need to be broken down into sub-objectives. Here we say that in order to achieve A we must achieve B. C and D first. These sub-objectives are also known as goah. steps on the way to achieving an objective, just as goals scored in a football match are steps towards the objective of winning the match.
This committee is likely to contain user, development and management representatives.
The measure can. in some cases, be an answer to simple yes-'no question. Did we install the new software by 1 st June?' for example.
Identify the objectives and sub-objectives of the Brightmouth College payroll Exercise 1.7 project. What measures of effectiveness could be used to check the success in achiev ing the objectives of the project?
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.