Lecture 6

chapter 5
project management
topics:
5.1 management activities
5.2 project planning
5.3 project scheduling
5.4 risk management
objectives:
? the objective of this chapter is to give you an overview of software project management. when you have read this chapter, you will:
• know the principal tasks of software project managers
• understand why the nature of software makes software project management more difficult than other engineering project management
• understand the need for project planning in all software projects
• know how graphical representations (bar charts and activity charts) can be used by project managers to represent project schedules
• have been introduced to the notion of risk management and some of the risks that can arise in software projects.
? software project management is an essential part of software engineering.
? good management cannot guarantee project success. however, bad management usually results in project failure:
? the software is delivered late, costs more than originally estimated and fails to meet its requirements.
? software managers are responsible for planning and scheduling project development. they supervise the work to ensure that it is carried out to the required standards and monitor progress to check that the devdopment is on time and within budget.
? we need software project management because professional software engineering is always subject to organisational budget and schedule constraints.
? the software project manager s job is to ensure that the software project meets these constraints and delivers software that contributes to the goals of the company developing the software.
? software managers do the same kind of job as other engineering project managers. however, software engineering is different from other types of engineering in a number of ways. these distinctions make software management particularly difficult. some of the differences are:
1. the product is intangible the manager of a shipbuilding project or of a civil engineering project can see the product being developed. if a schedule slips, the effect on the product is visible-parts of the structure are obviously unfinished. software is intangible. it cannot be seem or touched. software project managers cannot see progress. they rely on others to produce the documentation needed to review progress.
2. there are no standard software processes in engineering disciplines with a long history, the process is tried and tested. the engineering process for some types of system, such as bridges and buildings is well understood. however, software processes vary dramatically from one organization to another. although our understanding of these processes has developed significantly in the past few years, we still cannot reliably predict when a particular software process is likely to cause development problems. this is especially true when the software project is part of a wider systems engineering project.
3. large software projects are often one-off projects large software projects are usually different in some ways from previous projects. therefore, even managers who have a large body of previous experience may find it difficult to anticipate problems. furthermore, rapid technological changes in computers and communications can make a manager s experience obsolete. lessons learned from previous projects may not be transferable to new projects. because of these problems, it is not surprising that some software projects are late, over budget and behind schedule. software systems are often new and technically innovative. engineering projects (such as new transport systems) that are innovative often also have schedule problems. given the difficulties involved, it is perhaps remarkable that so many software projects are delivered on time and to budget!
? software project management is a huge topic and cannot be covered in a single chapter. therefore, i simply introduce the subject here and describe three important management activities: project planning, project scheduling and risk management.
5.1 management activities
? it is impossible to write a standard job description for a software manager. the job varies tremendously depending on the organization and the software product being developed.
? most managers take responsibility at some stage for some or all of the following activities:
• proposal writing
• project planning and scheduling
• project cost
• project monitoring and reviews
• personnel selection and evaluation
• report writing and presentations
? the first stage in a software project may involve writing a proposal to win a contract to carry out the work. the proposal describes the objectives of the project and how it will be carried out. it usually includes cost and schedule estimates, and justifies why the project contract should be awarded to a particular organization or team.
? proposal writing is a critical task as the existence of many software organizations depends on having enough proposals accepted and contracts awarded. there can be no set guidelines for this task proposal writing is a skill that you acquire through practice and experience.
? project planning is concerned with identifying the activities. milestones and deliverables produced by a project. a plan is drawn up to guide the development towards the project goals.
? cost estimation is a related activity that is concerned with estimating the resources required to accomplish the project plan.
? project monitoring is a continuing project activity. the manager must keep track of the progress of the project and compare actual and planned progress and costs.
? although most organizations have formal mechanisms for monitoring, a skilled manager can often form a clear picture of what is going on through informal discussions with project staff.
? informal monitoring can often predict potential project problems by revealing difficulties as they occur. for example, daily discussions with project staff might reveal a particular problem in finding some software fault. rather than waiting for a schedule slippage to be reported, the software manager might assign some expert to the problem or might decide that it should be programmed around.
? during a project, it is normal to have a number of formal project management reviews. they are concerned with reviewing overall progress and technical development of the project and checking whether the project and the goals of the organization paying for the software are still aligned.
? the outcome of a review may be a decision to cancel a project.
? the development time for a large software project may be several years. during that time, organizational objectives are almost certain to change. these changes may mean that the software is no longer required or that the original project requirements are inappropriate.
? management may decide to stop software development or to change the project to accommodate the changes to the organizational objectives.
? project managers usually have to select people to work on their project. ideally, skilled staff with appropriate experience will be available to work on the project.
? however, in most cases, managers have to settle for a less-than-ideal project team. the reasons for this are:
1. the project budget may not cover the use of highly paid staff. less experienced, less well-paid staff may have to be used.
2. staff with the appropriate experience may not be available either within an organization or externally. it may be impossible to recruit new staff to the project. within the organization, the best people may already be allocated to other projects.
3. the organization may wish to develop the skills of its employees. inexperienced staff may be assigned to a project to learn and to gain experience.
? the software manager has to work within these constraints when selecting project staff however, problems are likely unless at least one project member has some experience with the type of system being developed.
? without this experience, many simple mistakes are likely to be made.
? project managers are usually responsible for reporting on the project to both the client and contractor organizations. they have to write concise, coherent documents that abstract critical information from detailed project reports.
? they must be able to present this information during progress reviews. consequently, if you are a project manager, you have to be able to communicate effectively both orally and in writing.
quality plan describes the quality procedures and standards that will be used in a project. see chapter 24.
validation plan describes the approach, resources and schedule used for system validation. see chapter 19.
configuration management plan describes the configuration management procedures and structures to be used. see chapter 29.
maintenance plan predicts the maintenance requirements of the system, maintenance costs and effort required. see chapter 27.
staff development plan describes how the skills and experience of the project team members will be developed. see chapter 22.
figure 5.1 types of plan
5.2 project planning
? effective management of a software project depends on thoroughly planning the progress of the project.
? managers must anticipate problems that might arise and prepare tentative solutions to those problems.
? a plan, drawn up at the start of a project, should be used as the driver for the project. this initial plan should be the best possible plan given the available information. it evolves as the project progresses and better information becomes available.
? as well as a project plan, managers may also have to draw up other types of plans. these are briefly described in figure 5.1.
? the pseudo-code shown in figure 5.2 sets out a project planning process for software development. it shows that planning is an iterative process, which is only complete when the project itself is complete.
? as project information becomes available during the project, the plan should be regularly revised. the goals of the business are an important factor that must be considered when formulating the project plan.
? as these change, the project s goals also change so changes to the project plan are necessary.
? at the beginning of a planning process, you should assess the constraints (required delivery dates, staff available, overall budget, etc.) affecting the project.
? in conjunction with this, you should estimate project parameters such as its structure, size, and distribution of functions. you next define the progress milestones and deliverables.
? the process then enters a loop. you draw up an estimated schedule for the project and the activities defined in the schedule are started or given permission to continue.
? after some time (usually about two to three weeks), you should review progress and note discrepancies from the planned schedule. because initial estimates of project parameters are tentative, you will always have to modify the original plan.
? as more information becomes available. you revise your original assumptions about the project and the project schedule. if the project is delayed, you may have to renegotiate the project constraint and deliverables with the customer.
? if this renegotiation is unsuccessful and the schedule cannot be met, a project technical review may be held. the objective of this review is to find an alternative approach that falls within the project constraints and meets the schedule.
? you should never assume that everything will always go well. problems of some description nearly always arise during a project.
? your initial assumptions and scheduling should be pessimistic rather than optimistic. there should be sufficient contingency built into your plan so that the project constraints and milestones need not be renegotiated every time round the planning loop.
establish the project constraints
make initial assessments of the project parameters
define project milestones and deliverables
while project has not been completed or cancelled loop
[)raw up project schedule
initiate activities according to schedule
wait ( for a while )
review project progress
revise estimates of project parameters
updating the project schedule
renegotiate project constraints and deliverables
if ( problems arise) then
initiate technical review and possible revision
end if
end loop
figure 5.2 project planning
5.2.1 the project plan
? the project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out the work.
? in some organizations, the project plan is a single document that includes the different types of plan (figure 5.1).
? in other cases, the project plan is solely concerned with the development process. references to other plans are included but the plans themselves are separate.
? the details of the project plan vary depending on the type of project and organization. however, most plans should include the following sections:
1. introduction: this briefly describes the objectives of the project and sets out the constraints (e.g., budget, time, etc.) that affect the project management.
2. project organization: this describes the way in which the development team is organized, the people involved and their roles in the team.
3. risk analysis: this describes possible project risks, the likelihood of these risks arising and the risk reduction strategies that are proposed.
4. hardware and software resource requirements: this specifies the hardware and the support software required to carry out the development. if hardware has to be bought, estimates of the prices and the delivery schedule may be included.
5. work breakdown: this sets out the breakdown of the project into activities and identifies the milestones and deliverables associated with each activity.
6. project schedule: this shows the dependencies between activities, the estimated time required to reach each milestone and the allocation of people to activities.
7. monitoring and reporting mechanisms: this defines the management reports that should be produced, when these should be produced and the project monitoring mechanisms used.
? you should regularly revise the project plan during the project. some parts, such as the project schedule, will change frequently other parts will be more stable.
? to simplify revisions, you should organize the document into separate sections that can be individually replaced as the plan evolves.
5.2.2 milestones and deliverables
? managers need information to do their job. because software is intangible, this information can only be provided as reports and documents that describe the state of the software being developed. without this information, it is impossible to assess how well the work is progressing, and cost estimates and schedules cannot be updatingd.
? when planning a project, you should establish a series of milestones. where a milestone is a recognizable end-point of a software process activity.
? at each milestone, there should be a formal output, such as a report, that can be presented to management. milestone reports need not be large documents. they may simply be a short report of what has been completed.
? milestones should represent the end of a distinct, logical stage in the project. indefinite milestones such as coding 80% complete that can t be checked are useless for project management.
? you can t check whether this state has been achieved because the amount of code that still has to be developed is uncertain.
? a deliverable is a project result that is delivered to the customer. it is usually delivered at the end of some major project phase such as specification or design.
? deliverables are usually milestones, but milestones need not be deliverables.

figure 5.3 shows possible activities involved in requirements specification
? milestones may be internal project results that are used by the project manager to check project progress but which are not delivered to the customer.
? to establish milestones, the software process must be broken down into basic activities with associated outputs. for example, figure 5.3 shows possible activities involved in requirements specification when prototyping is used to help validate requirements.
? the milestones in this case are the completion of the outputs for each activity. the project deliverables, which are delivered to the customer, are the requirements definition and the requirements specification.
5.3 project scheduling
? project scheduling is one of the most difficult jobs for a project manager.
? managers estimate the time and resources required to complete activities and organize them into a coherent sequence. unless the project being scheduled is similar to a previous project, previous estimates are an uncertain basis for new project scheduling.
? schedule estimation is further complicated by the fact that different projects may use different design methods and implementation languages.
? if the project is technically advanced, initial estimates will almost certainly be optimistic even when you try to consider all eventualities. in this respect, software scheduling is no different from scheduling any other type of large advanced project.
? new aircraft, bridges and even new models of cars are frequently late because of unanticipated problems. schedules, therefore, must be continually updatingd as better progress information becomes available.
? project scheduling (figure 5.4) involves separating the total work involved in a project into separate activities and judging the time required to complete these activities.
? usually, some of these activities are carried out in parallel. you have to coordinate these parallel activities and organize the work so that the workforce is used optimally. it s important to avoid a situation where the whole project is delayed because a critical task is unfinished.

figure 5.4: the project scheduling process
? project activities should normally last at least a week.
? finer subdivision means that a disproportionate amount of time must be spent on estimating and chart revision. it is also useful to set a maximum amount of time for any activity of about 8 to 10 weeks. if it takes longer than this, it should be subdivided for project planning and scheduling.
? as i have already suggested, when you are estimating schedules, you should not assume that every stage of the project will be problem free. people working on a project may fall in or may leave, hardware may break down, and essential support software or hardware may be delivered late.
? if the project is new and technically advanced, certain parts of it may turn out to be more difficult and take longer than originally anticipated.
? as well as calendar time, you also have to estimate the resources needed to complete each task.
? the principal resource is the human effort required. other resources may be the disk space required on a server, the time required on specialized hardware such as a simulator, and the travel budget required for project staff.
? a good rule of thumb is to estimate as if nothing will go wrong, then increase your estimate to cover anticipated problems. a further contingency factor to cover unanticipated problems may also be added to the estimate.
? this extra contingency factor depends on the type of project, the process parameters (deadline, standards, etc.) and the quality and experience of the software engineers working on the project.
? i always add 30% to my original estimate for anticipated problems then another 20% to cover things i hadn t thought of.
? project schedules are usually represented as a set of charts showing the work breakdown, activities dependencies and staff allocations.
? software management tools, such as microsoft project, are usually used to automate chart production.
5.3.1 bar charts and activity networks
? bar charts and activity networks are graphical notations that are used to illustrate the project schedule. bar charts show who is responsible for each activity and when the activity is scheduled to begin and end.
? activity networks show the dependencies between the different activities making up a project.
? bar charts and activity charts can be generated automatically from a database of project information using a project management tool.

figure 5.5 task durations and dependencies
? to illustrate how these charts are used, i have created a hypothetical set of activities as shown in figure 5.5. this table shows activities, their duration, and activity interdependencies.
? from figure 5.5, you can see that activity t3 is dependent on activity t1. this means that t1 must be completed before t3 starts.
? for example, t1 might be the preparation of a component design and n, the implementation of that design. before implementation starts, the design should be complete.
? given the dependencies and estimated duration of activities, an activity chart that shows activity sequences may be generated (figure 5.6). this shows which activities can be carried out in parallel and which must be executed in sequence because of a dependency on an earlier activity.
? activities are represented as rectangles
? milestones and project deliverables are shown with rounded comers.
? dates in this diagram show the start date of the activity and are written in british style, where the day precedes the month.
? you should read the chart from left to right and from top to bottom.
? in the project management tool used to produce this chart, all activities must end in milestones. an activity may start when it’s preceding milestone (which may depend on several activities) has been reached.
? therefore, the third column in figure 5.5 shows the: corresponding milestone (e.g., m5) that it reached when the tasks finish (see figure 5.6).
? before progress can be made from one milestone to another, all paths leading to it must be complete. for example, when activities n and t6 are finished, then activity t9, shown in figure 5.6, can start.

figure 5.6: an activity network
? the minimum time required to finish the project can be estimated by considering the longest path in the activity graph (the critical path).
? in this case, it is 11 weeks of elapsed time or 55 working days. in figure 5.6, the critical path is shown as a sequence of emboldened boxes. the critical path is the sequence of dependent activities that defines the time required to complete the project.
? the overall schedule of the project depends on the critical path. any slippage in the completion in any critical activity causes project delays because the following activities cannot start until the delayed activity has been completed.
? however, delays in activities that do not lie on the critical path do not necessarily cause an overall schedule slippage. so long as these delays do not extend these activities so much that the total time for that activity plus future dependent activities does not exceed the critical path, the project schedule will not be affected.
? for example, if t8 is delayed by two weeks, it will not affect the final completion date of the project because it does not lie on the critical path.
? most project management tools compute the allowed delays, as shown in the project bar chart. managers also use activity charts when allocating project work.
? they can provide insights into activity dependencies that are not intuitively obvious. it may be possible to modify the system design so that the critical path is shortened.
? the project schedule may be shortened because of the reduced amount of time spent waiting for activities to finish.
? inevitably, initial project schedules will be incorrect. as a project develops, estimates should be compared with actual elapsed time. this comparison can be used as a basis for revising the schedule for later parts of the project.

figure 5.7: activity bar chart
? when actual figures are known, the activity chart should be reviewed. later project activities may then be reorganized to reduce the length of the critical path.
? figure 5.7 is a complementary way of representing project schedule information.
? it is a bar chart showing a project calendar and the start and finish dates of activities.
? sometimes these are called gantt charts, after their inventor. reading from left to right, the bar chart clearly shows when activities start and end.
? some of the activities shown in the bar chart in figure 5.7 are followed by a shaded bar whose length is computed by the scheduling tool. this highlights the flexibility in the completion date of these activities. if an activity does not complete on time, the critical path will not be affected until the end of the period marked by the shaded bar.
? activities that lie on the critical path have no margin of error and can be identified because they have no associated shaded bar.
? in addition to considering schedules, as a project manager you must also consider resource allocation and, in particular, the allocation of staff to project activities.
? this allocation can also be input to project management tools and a bar chart generated that shows when staff are employed on the project (figure 5.8).
? people don t have to be assigned to a project at all times. during intervening periods they may be on holiday, working on other projects, attending training courses or engaging in some other activity.
? large organizations usually employ a number of specialists who work on a project when needed. in figure 5.8, you can see that mary and jim are specialists who work on only a single task in the project. this can cause scheduling problems.
? if one project is delayed while a specialist is working on it, this may have a knock-on effect on other projects. they may also be delayed because the specialist is not available.


figure 5.8 staff allocation vs. time chart
5.4 risk management
? risk management is increasingly seen as one of the main jobs of project managers. it involves anticipating risks that might affect the project schedule or the quality of the software being developed and taking action to avoid 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. effective risk management makes it easier to cope with problems and to ensure that these do not lead to unacceptable budget or schedule slippage.
? simplistically, you can think of a risk as something that you d prefer not to have happen. risks may threaten the project, the software that is being developed or the organization. there are, therefore, three related categories of risk:
1. project risks are risks that affect the project schedule or resources. an example might be the loss of an experienced designer.
2. product risks are risks that affect the quality or performance of the software being developed. an example might be the failure of a purchased component to perform as expected.
3. business risks are risks that affect the organization developing or procuring the software. for example, a competitor introducing a new product is a business risk.
? of course, these risk types overlap. if an experienced programmer leaves a project, this can be a project risk because the delivery of the system may be delayed. it can also be a product risk because a replacement may not be as experienced and so may make programming errors. finally, it can be a business risk because the programmer’s experience is not available for bidding for future business.
? the risks that may affect a project depend on the project and the organizational environment where the software is being developed. however, many risks are universal-some of the most common risks are shown in figure 5.9.
? risk management is particularly important for software projects because of the inherent uncertainties that most projects face. these stem from loosely defined requirements, difficulties in estimating the time and resources required for work on only a single task in the project. this can cause scheduling problems.
? if one project is delayed while a specialist is working on it, this may have a knock-on effect on other projects. they may also be delayed because the specialist is not available.
? software development, dependence on individual skills and requirements changes due to changes in customer needs. you have to anticipate risks, understand the impact of these risks on the project, the product and the business, and take steps to avoid these risks.
? you may need to draw up contingency plans so that, if the risks do occur, you can take immediate recovery action. the process of risk management is illustrated in figure 5.10. it involves several stages:
1. risk identification: possible project, product and business risks are identified.
2. risk analysis: the likelihood and consequences of these risks are assessed.
3. risk planning: plans to address the risk either by avoiding it or minimizing its effects on the project 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.
? the risk management process, like all other project planning, is an iterative process which continues throughout the project. once an initial set of plans are drawn up, the situation is monitored.
? as more information about the risks becomes available, the risks have to be re-analyzed and new priorities established.
? the risk avoidance and contingency plans may be modified as new risk information emerges.
? you should document the outcomes of the risk management process in a risk management plan. this should include a discussion of the risks faced by the project, an analysis of these risks and the plans that are required to manage these risks.
? where appropriate, you should also include in the plan results of the risk management process such as specific contingency plans to be activated if the risk occurs.


figure 5.9: possible software risks

figure 5.10: the risk management process
5.4.1 risk identification
? risk identification is the first stage of risk management. it is concerned with discovering possible risks to the project. in principle, these should not be assessed or prioritized at this stage, although, in practice, risks with very minor consequences or very low probability risks are not usually considered.
? risk identification may be carried out as a team process using a brainstorming approach or may simply be based on experience. to help the process, a checklist of different types of risk may be used.
? there are at least six types of risk that can arise:
1. technology risks: risks that derive from the software or hardware technologies that are used to develop the system.
2. people risks: risks that are associated with the people in the development team.
3. organizational risks: risks that derive from the organizational environment where the software is being developed.
4. tools risks: risks that derive from the case tools and other support software used to develop the system.
5. requirements risks: risks that derive from changes to the customer requirements and the process of managing the requirements change.
6. estimation risks: risks that derive from the management estimates of the system characteristics and the resources required to build the system.
? figure 5.11 gives some examples of possible risks in each of these categories. when you have finished the risk identification process, you should have a long list of risks that could occur and which could affect the product, the process and the business.


5.4.2 risk analysis
? during the risk analysis process, you have to consider each identified risk and make a judgment about the probability and the seriousness of it. there is no easy way to do this-you must rely on your own judgment and experience, which is why experienced project managers are generally the best people to help with risk management.
? these risk estimates should not generally be precise numeric assessments but should be based around a number of bands:
? the probability of the risk might be assessed as very low «10%), low (l0-25%), moderate (25-50%), high (50-75%) or very high (>75%).
? the effects of the risk might be assessed as catastrophic, serious, tolerable or insignificant.
? you should then tabulate the results of this analysis process using a table ordered according to the seriousness of the risk. figure 5.12 illustrates this for the risks identified in figure 5.11.
? of course, both the probability and the assessment of the effects of a risk may change as more information about the risk becomes available and as risk management plans are implemented. therefore, you should updating this table during each iteration of the risk process.
? once the risks have been analyzed and ranked, you should assess which are most significant. your judgment must depend on a combination of the probability of the risk arising and the effects of that risk.
? in general, catastrophic risks should always be considered, as should all serious risks that have more than a moderate probability of occurrence.
? boehm (boehm, 1988) recommends identify and monitoring the top 10 risks, but i think that this figure is rather arbitrary. the right number of risks to monitor must depend on the project. it might be 5 or it might be 15.
? however, the number of risks chosen for monitoring should be manageable. a very large number of risks would simply require too much infonnation to be collected. from the risks identified in figure 5.12, it is appropriate to consider all 8 risks that have catastrophic or serious consequences.


5.4.3 risk planning
? the risk planning process considers each of the key risks that have been identified and identifies strategies to manage the risk. again. there is no simple process that can be followed to establish risk management plans. it relies on the judgment and experience of the project manager.
? figure 5.13 shows possible strategies that have been identified for the key risks from figure 5.12. these strategies fall into three categories:
1. avoidance strategies: following these strategies means that the probability that the risk will arise will be reduced. an example of a risk avoidance strategy is the strategy for dealing with defective components shown in figure 5.13.
2. minimization strategies: following these strategies means that the impact of the risk will be reduced. an example of a risk minimization strategy is that for staff illness shown in figure 5.13.
3. contingency plans: following these strategies means that you are prepared for the worst and have a strategy in place to deal with it. an example of a contingency strategy is the strategy for organizational financial problems in figure 5.13.


figure 5.12 risk: analysis

figure 5.13: risk management strategies
? you can see here the analogy with the strategies used in critical systems to ensure reliability, security and safety. essentially, it is best to use a strategy that avoids the risk. if this is not possible, use one that reduces the chances that the risk will have serious effects. finally, have strategies in place that reduce the overall impact of a risk on the project or product.
5.4.4 risk monitoring
? risk monitoring involves regularly assessing each of the identified risks to decide whether or not that risk is becoming more or less probable and whether the effects of the risk have changed.
? of course, this cannot usually be observed directly, so you have to look at other factors that give you clues about the risk probability and its effects. these factors are obviously dependent on the types of risk.
? figure 5.14 gives some examples of factors that may be helpful in assessing these risk types.
? risk monitoring should be a continuous process, and, at every management progress review, you should consider and discuss each of the key risks separately.

figure 5.14: risk factors
key points
? software management is distinct from other engineering management. software is intangible. projects may be novel or innovative so there is no body of experience to guide their management. software processes are not well understood.
? software managers have diverse roles. their most significant activities are project planning, estimating and scheduling. planning and estimating are iterative processes. they continue throughout a project. as more information becomes available, plans and schedules must be revised.
? a project milestone is a predictable outcome of an activity where some formal report of progress should be presented to management. milestones should occur regularly throughout a software project. a deliverable is a milestone that is delivered to the project customer.
? project scheduling involves the creation of various graphical plan representations of part of the project plan. these include activity charts showing the interrelationships of project activities and bar charts showing activity durations.
? major project risks should be identified and assessed to establish their probability and the consequences for the project. you should make plans to avoid, manage or deal with likely risks if or when they arise. risks should be explicitly discussed in each project progress meeting.

references:
1- based on software engineering, 7th edition by ian sommerville