Department of Computer Science Department of Computer ScienceReferences
Cotterell, M., Hughes, B. (1995). Software Project Management. London: Thomson Computer Press.
Yeates, D., Cadle, J. ( 1996). Project Management for Information Systems (Second Edition). London: Pitman. Lectures will touch on aspects appearing through Chapters 3 - 10.
Project management is about more than planning & controlling work through a development lifecycle. Project management really begins the moment a suggestion is put forward that will result in some kind of non-trivial change taking place.
It is sometimes vague as to when precisely a particular project comes into existence, it may begin very formally with heavily prescribed procedures to be followed, or on the back of a fag packet, going from inception to coding with almost indecent haste.
Whichever way the change comes to be identified as being desirable, it will require some level of planning, monitoring and control if it is to end successfully.
So how do you determine whether a subject of change should be managed within a project structure or not?
Which of these would you suggest are projects & which are not? why?
1. going on holiday
2. amending a report program to include an additional piece of information
3. producing an edition of a newspaper
4. organising a wedding
5. building the Channel Tunnel
6. implementing a bought-in software package (e.g. text & document processor)
7. a second year programming assignment for a computing student
8. investigating a computer system fault reported by an end user
9. reskilling all factory workers after new manufacturing machinery has been installed
10. amending a hospital bed allocation system to allow for inclusion of temporary beds
11. writing a new medication administration report - estimated as 10 man days of effort.
One approach which has been taken to identify those activities which should be managed within a formal framework is based on the complexity level of the work.
Trivial = 1 person working for a few days to a few weeks. For this no formal approach might be needed.
Simple = 3 - 4 programmer analysts working for 6 - 12 months. For this a formal approach will be beneficial.
Difficult = 6 - 12 programmer analysts working for 2 - 3 years. For this a formal approach is necessary.
There are of course gradations between, so that work complexity is a continuum rather than discrete levels. This is why it can be difficult to determine whether project management methodology should be applied.
Project Characteristics
Work which should be managed within a project structure, generally has the following characteristics:
Non-routine: something has to happen which is not a routine or repetitive task.
Specific objective / product: something has to be carried out or specific products are to be created
Time constrained: there is a time limit set by which the task is to be completed. Time constraint may be in terms of lapse time or in terms of man years. e.g. by the year 2000 is a lapse time constraint., 2 man years is the expression of labour required.
Cost constrained: there is a limit set on how much can be spent.
Resource constrained: there is a limit set on number of people or what hardware / software can be deployed.
Measurable project output: the results of the project can be examined and assessed
Part of a larger project: it may be a sub-project e.g. providing an organisation with a total solution -a sub-project may be the design & development of a payroll system.
Requires planning: there are more than 7 pieces of information - i.e. it cannot be done in your head.
Involves different disciplines/ specialisms: needs multiskilling - usually > 1 person
Requires several phases: may be undertaken as a set of phases - e.g. phase 1 includes financial accounting, payroll & personnel applications, phase 2 involves purchasing & inventory control and phase 3 the sales & marketing systems.
Complexity: projects often involve staff external to a department / organisation - may also require co-ordination of hardware & software suppliers, training of internal staff, co-ordination of activity across sites and even countries.
Project Lifecycle
A project begins life well before the development lifecycle plays its part. Where the software supplier and software user are two separate organisations, there will be a process involving initial contact, bid submissions from different vendors and contract negotiations.
This of course may be skipped where the software supplier and user come from within the same organisation. In this case, the project process may begin at project start up.
Project Start Up is an extremely important stage and often sets the scene for the success or failure of a project. It is at this point that what is to be carried out is documented. This may include the objectives that the system is to satisfy, the scope of the project, what interfaces it may need to have and what constraints will apply. A feasibility study may be carried out or one may already exist, and the report from this will contain this information but it may need to be checked to ensure that it is still correct.
Why the project is being carried out also needs to be documented. How much will it cost against what are the benefits. This is an important item so that the project costs can be monitored against initial agreed estimates. A decision may need to be taken to disband the project if the overrun is too high.
Who is to be involved in the project and what their roles are need to be agreed. It must be clear who has what responsibilities.
Project Plans are drawn up to specify how the project will proceed and when each activity will be carried out. These plans include a technical plan detailing what activity is to be done when, a resource plan detailing who is needed when, and what equipment is needed, a quality plan detailing what criteria are used to ensure quality of product and conformance with company strategy, a risk analysis, and a configuration management plan.
The Development Stage encompasses the bulk of the development life cycle. The requirements analysis, specification, logical and physical design, implementation and testing will be monitored and controlled. All plans created in the previous stage will be the focus for this control, being specified in greater detail than was possible earlier on in the project.
The Completion Stage involves delivery of the system with all its documentation, training of end users, acceptance testing, live running and handover. Reports on the project will be prepared detailing how well it went, were costs kept within budget etc., what lessons may be learnt for next time.
The Operational Stage concerns ongoing running, modifications / changes which may be required in the light of ongoing usage and after about 6 months, a post-implementation review should be carried out to assess how effective the system has been in meeting the business objectives outlined at project start-up.
Project Start Up
Early on in the project lifecycle, a feasibility study may be undertaken. This will involve a number of activities aimed at evaluating the project against strategic, technical and economic criteria so that a firm decision can be made as to whether it is viable to proceed with a project or not.
The potential system software should be evaluated within the context of the organisation's overall business strategy. Any new system should be consistent with the overall goals and objectives of the company. For example, installing software which cannot handle currency exchange for a company which has as one of its goals to move into the international market, would be an inconsistency.
Typical issues to check:
Consistency with organisation's objectives
Consistency with IT plan
Effect on existing departmental/organisational structure - e.g. is there any overlap of functionality
What additional management information will the system provide?
What implications are there for staffing levels or job functions?
What implications are there for the customer's perceptions of the company?
The proposed system should also be evaluated for technical feasibility. Does the new system require additional hardware or software to be purchased? Would any required purchases be consistent with the IT strategy for the organisation?
A cost-benefit analysis must also be carried out, to ensure that the cost of developing and maintaining the system does not outweigh the potential benefits from having it in place.
Costs are generally straightforward to identify.
Development costs - e.g. employment costs of project staff, development tools etc.
Setup costs - costs of implementing new system, e.g. file conversions, training costs
Operational costs - ongoing costs of running finished system
Benefits tend to be more difficult:
Direct benefits - benefits accrued directly from operation of proposed system e.g. reduction in manpower requirements resulting in lower wage bills
Assessable indirect benefits - secondary benefits such as error reduction which can be expressed in terms of lower costs
Intangible benefits - benefits which are more difficult to quantify, such as enhanced job interest, leading to reduced staff turnover and lower costs.
Calculating Cost Benefit
In working out cost benefits analysis, it is important to present the findings so that management can see the projected cash flow. That is, when money has to be committed and when returns on the investment can be expected.
There are a number of methods for calculating cash flow - two of these are:
- calculate the net profit
- calculate the payback period.
Net Profit
The net profit of a project is the difference between the total costs of a project and the total income over the lifetime of the project.
Year Project 1 Project 2 Project 3 Project 4
0 -100,000 -1,000,000 -100,000 -120,000
1 10,000 200,000 30,000 30,000
2 10,000 200,000 30,000 30,000
3 10,000 200,000 30,000 30,000
4 20,000 200,000 30,000 30,000
5 100,000 300,000 30,000 75,000
Net Profit 50,000 100,000 50,000 75,000
Year 0 represents the initial investment, and cashflows are calculated at year ends.Project 3 shows greatest net profit but has a high investment cost - may carry a lot of risks. Looking at the net profit figure also does not inform us of the pattern of cash flow. Project 1 has a lower cash flow for years 1 - 4 than project 3 although they have the same net profit.
Payback Period
Using the payback period, the focus is on how long it takes to recoup the investment.
The project with the shortest payback period is often chosen over others.
Q: What is the payback period for each of the above projects?
This method is straightforward but does not take account of additional profitability that a project may carry after the project has paid for itself.
Return on Investment (ROI)
This may also be known as the Accounting Rate of Return (ARR). It allows the net profitability of projects to be compared against the investment required.
A standard formula is:
ROI = average annual profit X 100
total investment
So, for example, Project 1 has a net profit of £50,000 and an initial investment of £100,000. To calculate the ROI:
Average annual profit = net profit
project lifetime= 50,000
5= 10,000
ROI = 10,000 X 100
100,000= 10%
Q: What is the ROI for the other projects and decide on this basis which produces the best return on investment.
There are other methods such as net present value and internal rate of return which take account of profitability of a project and the cash flow timing as well as comparisons with other forms of capital investment.
Project Risk
In evaluating a project during the feasibility analysis, it is also usual to assess the risks of undertaking a project.
One way of doing this is to draw up a matrix of potential risks, the importance of the risk and the likelihood of the risk. For example...
Risk Importance Likelihood
Software never completed or delivered H
Project cancelled after design stage H
Software delivered late L M
Development budget exceeded < 20% L M
Development budget exceeded > 20% M L
Maintenance costs higher than estimated L L
Response time targets not met L H
Projects with a lot of High importance risks which are Highly likely may not be pursued.
Project Roles
A Project Sponsor is generally someone from the business who is responsible for ensuring that the system meets the business objectives. It is usually someone who has 'clout' and can authorise expenditure or call a halt to a project if need be. Normally someone at senior management or executive level is assigned this role . e.g. a Financial Director may be the sponsor for a new accounting system.
The Project Manager may be appointed by the sponsor or by the head of IT. The Project Manager is responsible for ensuring the project meets its objectives within time and cost. There are many duties which belong to the Project Manager but the main one is to plan, control and manage the project through to completion.
The User is the person who will operate the system on a day-to-day basis and is involved in requirements definition and specification as well as being involved in acceptance testing, training etc.
A Risk Manager may be required for large projects to identify, classify & quantify risks and implement risk reduction strategies.
A Quality Manager may be required for large projects to develop quality procedures and advise on how they should be followed.
The Chief Analyst, Chief Designer, Database Administrator, Configuration Librarian may be separate roles. May be shared with other projects.
A Team Leader may be put in charge of a small group of staff, e.g. programmers. Schedules, monitors & directs work on a daily basis in accordance with technical plan.
Although each project may not have all the above, there is a critical necessity to have a clear understanding of who will make the major decisions about the scope and direction of a project, who will ultimately accept it and exactly what responsibilities are agreed for each role.
Organisational Structures
As well as understanding the roles that are undertaken by members of a project, it is useful to be able to see the project team within the context of a whole organisation.
Typically, steering committees exist to provide high level direction from within the business for the usage of IT so that the focus is always on business objectives. This group normally contain senior managers and / directors. Depending on the organisation, this group may also identify and prioritise projects.
Within the PRINCE approach to project management, there is also an IT Executive Committee which is responsible for translating the overall business objectives into specific projects.
PRINCE also defines a project board on which sits the person appointed by the Executive Committee to represent the business interests (i.e. the sponsor), a senior user and a senior IT person, such as the IT Director or Systems Development Manager.
The Project Team includes all those people involved in the day-to-day running of the project, from the Project Manager to the trainee programmer! A project team may be made up of people from outside organisations, a number of different sites of the same organisation, and a number of different departments. There may be social and cultural differences to manage (e.g. working abroad or in a different part of the country), and there may be hard business decisions to make. (e.g. the project has to be greatly cut down for business reasons and some staff may have to be made redundant - who should be let go??).
Development Lifecycles
The Waterfall Model: development carried out over a series of stages. Each stage is completed before the next one is begun. Output from one stage inputs to the next stage.
Validation checks correspondence between a product (e.g. system feasibility) and its purpose. Is the right thing being built?
Verification checks correspondence between how a product is supposed to be built and how it is actually built.
The 'b' Model: 70% - 80% of an application's life is spent in maintenance. The 'b' Model addresses this by including analysis, design, and development of system changes.
The 'V' Model: progression from initial concept to coding and testing of individual units of code is shown on left side - progression through testing of modules, integrated modules and integrated system, shown on right side.
Includes QA into the lifecycle, specifying when deliverables are due and how they should be verified.
The Incremental Model: illustrates a phased delivery approach. Separate elements of a system are brought into operation on a staggered timescale. Requirements must be clearly defined to ensure internal consistency between different sets of code.
All of the above are variants of the waterfall model.
The Spiral Model: takes a different approach to the waterfall models. When the requirements cannot be easily defined or the environment is unstable, an evolutionary approach may be taken.
The same cycle of activities may be repeated until clear requirements and solutions are agreed. Introduces setting of objectives, analysing risks and planning as necessary activities.
SSADM: a popular structured method approach to system analysis and design. Defines a set of techniques which can be applied from the feasibility study through to the physical design of the system. It does not therefore cover implementation and ongoing maintenance.
SSADM is based on a waterfall model but may also involve a limited use of the spiral model in relation to the use of prototyping.
From this we can see that there are a number of approaches which can be made in the development of a software system. Which model is applied will depend on constraints such as time, cost, quality, resources and risk.
The project manager must have an understanding of the benefits and drawbacks of each approach so that the most appropriate development lifecycle can be chosen for the project.
Summary
Project management is about:
- evaluating potential changes and managing the change within an organisation
- understanding the precise role of the project within the company's business plan
- understanding the role of others within the organisation in relation to the project
- organising a good line of sight to the project for everyone who needs it - i.e. provide appropriate lines of communication
directing and controlling the activities required to deliver the agreed solution within agreed timescales and an agreed budget.
Last Updated: 13/11/98 by M.Wood@herts.ac.uk
© University of Hertfordshire Higher Education Corporation (1998)