Software project management is a huge task that is concerned with management activities such as project planning, project scheduling and risk management. In addition, issues of software management are also inherent to the task. Such issues include managing people, software cost estimation and quality management. Careful planning at the beginning of a project is very important – it distinguishes success from failure.
1. Work done
a. Project function – The work done throughout the project and does not relate to any specific phase of development.
b. Activity – a major unit of work that has identifiable beginning and ending states, consumes resources (e.g. computer time), and produces work products (e.g. budget, source code, user manual, etc). An activity may consist of a number of tasks, where a task is defined as the smallest unit of work.
Note that a project function takes a global view of work done on the project whereas an activity is work related to a specific phase in the development of the project.
2. Milestone – a date set on which a work product (/activity) is completed. Note that in order to determine when a milestone is reached, it must pass a series of reviews performed by fellow team members and/or the client. For example, the date on which coding is completed and 'passes review'.
At each milestone, a report should be produced and presented to management. The report need not be large, but should represent the end of a distinct, logical stage in the project. Indefinite milestones such as “Coding is 80% complete” which are virtually impossible to validate are useless for project management.
3. Baseline – a reviewed and agreed upon work product.
4. Deliverable – A project result that is delivered to the customer. It is usually delivered at the end of some major project phase (e.g. specifications, design, etc…).
Deliverables are usually milestones, but milestones need not be deliverables. For example, a milestone can be an internal project result which is used by the project manager to check progress, but not delivered to the client.
5. Work package – defines the work product, staffing requirements, duration, resources, names of person(s) responsible and acceptance criteria for work product.
The failure of many large software projects in the 1960s and 1970s was the first indication of difficulties of software management. This was in the era of the software crisis where the product was delivered late, over budget and was often flawed. The root cause was not the incompetence of the programmers or the managers but the approach adopted by the management in tackling the oftentimes mammoth objective.
The need for management is an important distinction between professional software development and amateur programming. The project manager must work within the time and budget constraints to deliver a high quality project. Good management does not guarantee a successful project. However, bad management usually results in failure. The manager’s responsibilities include:
· Planning and scheduling the project development
· Supervising the work to ensure that quality standards are maintained (see notes on testing)
· Monitoring progress and make sure that development is on schedule and within budget.
· Personnel selection and evaluation
· Report writing and presentations
The software project management plan addresses the three concerns that are essential for a successful project:
Figure 1 , below, shows how resource consumption Rc varies with development time, t. The constant, k, is the value of t, which corresponds to the maximum consumption.
Effective management depends on thoroughly planning the progress of the project. The project manager must anticipate problems that might arise and prepare tentative solutions to those problems. At the start of the project, an initial plan is drawn up, using the currently known information, and used as a guideline. This plan then evolves with the project. Note that the planning process starts with an assessment of the constraints (required delivery date, staff availability, and overall budget etc…) affecting the project. This is carried out in conjunction with an estimation of project parameters such as its structure, size and distribution of functions. The progress milestones and deliverables are then defined. The process then enters a loop. A schedule of the project is drawn up and the activities defined in the schedule are initiates or given permission to continue. After a given period of time (usually 2-3 weeks), progress is reviewed and discrepancies noted. Because initial estimates of project parameters are tentative, the plan will always need to be modified.
As more information is made available, the plan may need to be revised; any resulting delays will require a renegotiation of the project constraints and deliverables with the customer. If unsuccessful then a project technical review may be held to try to find an alternative approach to the development with falls within the constraints and meets the schedule.
The project manager is also responsible for developing other plans along with the project plan. These other plans include:
Quality plan – Describes the quality procedures and standards that will be used in a project.
Validation plan – Describes the approach, resources and schedule used for system validation.
Configuration management plan – Predicts the configuration management procedures and structures to be used.
Maintenance plan – Predicts the maintenance requirements of system maintenance costs and effort required.
Staff development plan – Describes how the skills and experience of the project team members will be developed.
Note that in some organisations, the project plan may be a single comprehensive document including all the different types of plans. Alternatively, the project plan focuses solely on the development process and refers to the other types of plans. In this case, these other plans are contained in a separate document. Assuming this to be the case, then the project plan usually includes the following sections:
1. Introduction – Describes the objectives of the project and sets out the constraints (e.g. budget, time, etc.) which affect the project management.
2. Project organisation – Describes the way in which the development team is organised, the people involved and their roles in the team
3. Risk analysis – Describes the possible project risks, the likelihood of these risks arising and the risk reduction strategies that are proposed.
4. Hardware and software resource requirements – Describes the hardware and support software required to carry out the development. If the hardware has to be bought then estimates of the prices and the delivery schedule should be included.
5. Work breakdown – Describes the breakdown of the project into activities and identifies the milestones and deliverables associated with each activity.
6. Project schedule – Describes the dependencies between activities, the estimated time required to reach each milestone and the allocation of people to activities.
7. Monitoring and reporting mechanisms – Describes the management reports which should be produced, when they should be produced and the project monitoring mechanisms to be used.
This is a tricky and demanding task to tackle because of Murphy’s Law. Consequently, the schedule should always be revised (/updated) to reflect any new projected targets dates as more information regarding the project becomes available. Experience from scheduling other projects is handy, but should not be used as the basis for scheduling other projects unless the project being scheduled is similar to previous projects. This is due to the fact that different project may use different design methods and implementation languages. Other complications that may delay the project and cause scheduling problems include:
· Staff falling ill or leaving the project
· Hardware failures
· Underestimation of resources needed
Project scheduling involves:
1. The separation of the total work involved in the project into separate activities and judging the time required to complete these activities.
2. Co-ordination any parallel activities so that the workforce is used optimally. This is to avoid the situation where the whole project is delayed because a critical task is unfinished.
A realistic project schedule should also allocate time for ‘just in case scenarios’. The rule of thumb is that the project schedule is developed for an ideal scenario, and then the time is extended to cover any anticipated problems. A further contingency factor may then be added to cover any unanticipated problems.
Gantt charts and activity networks are two indispensable graphical notations that may be employed by the project manager to illustrate the project schedule. This makes the job of assimilating critical information much easier, thereby enabling a more efficient scheduling process.
To increase the success probability of the project it is important that the project manager anticipates any risks that may affect the project schedule, the quality of the software being developed, or the organisation that is developing the software. In addition, the manager should take steps to mitigate against these risks. The results of the risk analysis should be documented in the project plan along with an analysis of the consequences of a risk occurring.
Risk may arise due to loosely defined requirements, difficulties in estimating the time and/or resources needed for the software development, dependence on individual skills and rapidly changing requirements due to changing customer needs.
The process of risk management is iterative and continues throughout the project. As illustrated in Figure 1, it involves four critical stages.
1. Risk identification – Possible project, product and business risks are identified.
2. Risk analysis – The likelihood and consequences of these risks are assessed. The risk is may be categorised as below:
· Very low i.e. risk probability < 10%
· Low i.e.10% < risk probability < 25%
· Moderate i.e. 25% < risk probability < 50%
· High i.e. 50% < risk probability < 75%
· Very high i.e. risk probability > 75%
3. Risk planning – Plans to address the risk (avoidance or minimising) are drawn up.
4. Risk monitoring – The risk is constantly assessed and plans for risk mitigation are revised, as more information about the risk becomes available.
Software production
Different organisations have different ways of producing software. However there basic criteria which my be used to compare the different organisations. These include:
Software Documentation Standards:
· Self-documenting – the product can be understood simply by reading the source code.
· Documentation- intensive – detailed documentation is provided at each stage of the life-cycle.
Intensity of Testing:
· Detailed testing – 50% of the budget
· Minimal testing – allow the user to thoroughly test the product; devote minimal time in testing but spend considerable time and effort in fixing faults detected by the user.
Maintenance
· A major preoccupation
· Leave maintenance to others – this is the case in many research organisations e.g. universities.
The difficulty with software production on the whole can be roughly divided into two categories – essence and accidents. Essence refers to the difficulties that are inherent to the software production and cannot be changed. Such difficulties include
1. Complexity – this is related to the number of modules that will be required. Software of any size is organised into modules as this is the best technique to ensure that the scope of the software is broken down into manageable sections. However, the larger the project, the greater the number of modules required and hence the complexity increases accordingly.
2. Conformity – Software is made to conform to an existing (manual) system. Thus, the software must conform to the system and not the system to the software. Consequently, the software unnecessary complexity because it has to interface with an existing system.
3. Changeability – Request are made for changes to software because
a. Software must model reality and hence it must change
b. If software is found to be useful then there are pressures to extend its functionality
c. Software survives beyond the lifetime of hardware, hence it must be modified to run on new hardware.
4. Invisibility – The inability to represent software visually makes software difficult to comprehend. It also hinders communication between software professionals. Flowcharts, data flow diagrams and case tools are useful in software development, however, they do not embody every aspect of the product as a whole.
5. Intangibility – Software cannot be seen or touched. The project manager must then rely on others to produce the documentation needed to review progress.
6. There are no standard software processes – There is no clear understanding between the software process and product types. Unlike other engineering disciplines where the process for a particular system (e.g. building a bridge) is well understood, the software process has not currently reached this stage. Although the software process has developed significantly over the last few years, there is still no way to predict with certainty when a particular process is likely to cause development problems.
7. Large software projects are often ‘one-off’ projects – These projects are often different from previous projects. While managers do have a large body of experience, it may not be transferable to the new projects. This may be due to rapid technological changes in computers and communications.
|
Copyright ©
Adrian Als &
Charles Greenidge, 2003 |
