Project Planning in Software Engineering

Project Planning in Software Engineering

• Ian Sommerille. Software Engineering 9th Edition, chapters 22 – 26.

• IBM Rational Unified Process 7.0

• Charles G. Cobb. Making Sense of Agile Project Management: Balancing Control and Agility. 2011 by John Wiley & Sons.

Sources

Agenda

•Project Planning definition

•Project Planning according with RUP

•Project Planning according with Agile

Project Planning

• PP is the application of knowledge, skills, tools, andtechniques to project activities to meet projectrequirements. It is accomplished through theapplication and integration of the project managementprocesses of initiating, planning, executing, monitoringand controlling, and closing (PMBOK).

• Software engineering is a managed process. Thesoftware development takes place within anorganization and is subject to a range of schedule,budget, and organizational constraints.

Project Planning paradox:

• The project manager’s job is to ensure that thesoftware project meets and overcomes theseconstraints as well as delivering high-quality software.

• Good management cannot guarantee project success.However, bad management usually results inproject failure: the software may be delivered late,cost more than originally estimated, or fail to meet theexpectations of customers.

Project Planning

The success criteria for project management obviouslyvary from project to project but, for most projects,important goals are:

1. Deliver the software to the customer at the agreed time.2. Keep overall costs within budget.3. Deliver software that meets the customer’sexpectations.4. Maintain a happy and well-functioning developmentteam.

Project Planning challengesSoftware engineering is different from other types of engineering in a number of waysthat make software management particularly challenging. Some of these differencesare:1. Software is intangible: Software project managers cannot see progress by simplylooking at the artifact that is being constructed. Rather, they rely on others to produceevidence that they can use to review the progress of the work.2. Large software projects are often ‘one-off ’ projects: Large software projects areusually different in some ways from previous projects. Therefore, even managerswho have a large body of previous experience may find it difficult to anticipateproblems. Furthermore, rapid technological changes in computers andcommunications can make a manager’s experience obsolete. Lessons learned fromprevious projects may not be transferable to new projects.3. Software processes are variable and organization-specific: software processesvary quite significantly from one organization to another. Although there has beensignificant progress in process standardization and improvement, we still cannot reliablypredict when a particular software process is likely to lead to development problems.This is especially true when the software project is part of a wider systems engineeringproject.

Project managers responsibilities (I)

Most managers take responsibility at some stage for someor all of the following activities:

1. Project planning: Project managers are responsiblefor planning, estimating and scheduling projectdevelopment, and assigning people to tasks.

They supervise the work to ensure that it is carriedout to the required standards and monitor progress tocheck that the development is on time and withinbudget.

Project managers responsibilities (II)

2. Reporting: Project managers are usually responsible forreporting on the progress of a project to customers and tothe managers of the company developing the software. Theyhave to be able to communicate at a range of levels, fromdetailed technical information to management summaries.They have to write concise, coherent documents that abstractcritical information from detailed project reports. They must beable to present this information during progress reviews.3. Risk management: Project managers have to assess therisks that may affect a project, monitor these risks, and takeaction when problems arise.

Project managers responsibilities (III)

4. People management: Project managers are responsible for

managing a team of people. They have to choose people for

their team and establish ways of working that lead to effective

team performance.

Project managers responsibilities (IV)

5. Proposal writing: The first stage in a software project mayinvolve writing a proposal to win a contract to carry out an itemof work.The proposal describes the objectives of the project and how itwill be carried out. It usually includes cost and scheduleestimates and justifies why the project contract should beawarded to a particular organization or team.Proposal writing is a critical task as the survival of manysoftware companies depends on having enough proposalsaccepted and contracts awarded. There can be no setguidelines for this task; proposal writing is a skill that youacquire through practice and experience.

Project Planning (I)• Project planning is one of the most important jobs of a

software project manager. As a manager, you have tobreak down the work into parts and assign these toproject team members, anticipate problems that mightarise, and prepare tentative solutions to thoseproblems.

• The project plan, which is created at the start of aproject, is used to communicate how the work will bedone to the project team and customers, and to helpassess progress on the project.

• Project planning takes place at three stages in a projectlife cycle:

Project Planning (II)1. At the proposal stage, when you are bidding for a contractto develop or provide a software system. You need a plan atthis stage to help you decide if you have the resources tocomplete the work and to work out the price that you shouldquote to a customer.

2. During the project startup phase, when you have to planwho will work on the project, how the project will bebroken down into increments, how resources will beallocated across your company, etc. Here, you have moreinformation than at the proposal stage, and can therefore refinethe initial effort estimates that you have prepared.

Project Planning (III)3. Periodically throughout the project, when you modify your planin light of experience gained and information from monitoring theprogress of the work.You learn more about the system being implemented andcapabilities of your development team. This informationallows you to make more accurate estimates of how long thework will take. Furthermore, the software requirements are likelyto change and this usually means that the work breakdown has tobe altered and the schedule extended.For traditional development projects, this means that the plancreated during the startup phase has to be modified. However,when an agile approach is used, plans are shorter term andcontinually change as the software evolves.

The ugly true is that…Planning at the proposal stage is inevitably speculative,as you do not usually have a complete set ofrequirements for the software to be developed.Rather, you have to respond to a call for proposals based ona high-level description of the software functionality that isrequired. A plan is often a required part of a proposal, so youhave to produce a credible plan for carrying out the work.If you win the contract, you then usually have to replan theproject, taking into account changes since the proposal wasmade.

More about the reallity• The project plan always evolves during the development

process.• Development planning is intended to ensure that the

project plan remains a useful document for staff tounderstand what is to be achieved and when it is to bedelivered.

• Therefore, the schedule, cost estimate, and risks all haveto be revised as the software is developed.

More about the reallity (II)• If an agile method is used, there is still a need for a project

startup plan, as regardless of the approach used, thecompany still needs to plan how resources will beallocated to a project.

• However, this is not a detailed plan and should includeonly limited information about the work breakdownand project schedule.

• During development, an informal project plan and effortestimates are drawn up for each release of the software,with the whole team involved in the planning process

About the software pricing (I)

About the software pricing (II)

Project plan structure1. Introduction. This briefly describes the objectives of the project and sets out theconstraints (e.g., budget, time, etc.) that affect the management of the project.2. Project organization. This describes the way in which the development team isorganized, 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 andsupport 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 identifiesthe milestones and deliverables associated with each activity. Milestones are key stages inthe project where progress can be assessed; deliverables are work products that aredelivered to the customer.6. Project schedule. This shows the dependencies between activities, the estimated timerequired to reach each milestone, and the allocation of people to activities.7. Monitoring and reporting mechanisms. This defines the management reports thatshould be produced, when these should be produced, and the project monitoringmechanisms to be used.

Other critical plans (supporting)

The Project plan process

Project scheduling (I)• Project scheduling is the process of deciding how the

work in a project will be organized as separate tasks,and when and how these tasks will be executed.

• You estimate the calendar time needed to complete eachtask, the effort required, and who will work on the tasksthat have been identified.

• You also have to estimate the resources needed tocomplete each task, such as the disk space required on aserver, the time required on specialized hardware, such asa simulator, and what the travel budget will be.

Project scheduling (II)

• Both plan-based and agile processes need an initial project schedule,although the level of detail may be less in an agile project plan. Thisinitial schedule is used to plan how people will be allocated to projectsand to check the progress of the project against its contractualcommitments.

• In traditional development processes, the complete schedule isinitially developed and then modified as the project progresses.

• In agile processes, there has to be an overall schedule thatidentifies when the major phases of the project will be completed.An iterative approach to scheduling is then used to plan eachphase

• Scheduling in plan-driven projects involves breaking down thetotal work involved in a project into separate tasks and estimatingthe time required to complete each task. Tasks should normallylast at least a week, and no longer than 2 months.

Project scheduling representation (typical)

Risk in project planning

• Risk management involves anticipating risks that mightaffect the project schedule or the quality of the softwarebeing developed, and then taking action to avoid theserisks

• You should record the results of the risk analysis inthe project plan along with a consequence analysis,which sets out the consequences of the risk for theproject, product, and business. Effective riskmanagement makes it easier to cope with problemsand to ensure that these do not lead to unacceptablebudget or schedule slippage

Kind of risks• Project risks: Risks that affect the project schedule or resources. An

example of a project risk is the loss of an experienced designer.Finding a replacement designer with appropriate skills and experiencemay take a long time and, consequently, the software design will takelonger to complete.

• Product risks: Risks that affect the quality or performance of thesoftware being developed. An example of a product risk is the failure ofa purchased component to perform as expected. This may affect theoverall performance of the system so that it is slower than expected.

• Business risks: Risks that affect the organization developing orprocuring the software. For example, a competitor introducing a newproduct is a business risk. The introduction of a competitive productmay mean that the assumptions made about sales of existing softwareproducts may be unduly optimistic.

Examples

Risks Management

1. Risk identification: You should identify possibleproject, product, and business risks.2. Risk analysis: You should assess the likelihoodand consequences of these risks.3. Risk planning: You should make plans toaddress the risk, either by avoiding it or minimizingits effects on the project.4. Risk monitoring: You should regularly assessthe risk and your plans for risk mitigation and revisethese when you learn more about the risk.

Risks Management (II)

Risks Identification (I)1. Technology risks: Risks that derive from the software or hardwaretechnologies that are used to develop the system.2. People risks: Risks that are associated with the people in thedevelopment team.3. Organizational risks: Risks that derive from the organizationalenvironment where the software is being developed.4. Tools risks: Risks that derive from the software tools and othersupport software used to develop the system.5. Requirements risks: Risks that derive from changes to thecustomer requirements and the process of managing the requirementschange.6. Estimation risks: Risks that derive from the managementestimates of the resources required to build the system

Risks Identification (II)

Risks Analysis• During the risk analysis process, you have to consider each identified

risk and make a judgment about the probability and seriousness of thatrisk.

• There is no easy way to do this. You have to rely on your ownjudgment and experience of previous projects and the problems thatarose in them.

• It is not possible to make precise, numeric assessment of theprobability and seriousness of each risk. Rather, you should assign therisk to one of a number of bands:

1. The probability of the risk might be assessed as very low (0-10%), low (10–25%), moderate (25–50%), high (50–75%), orvery high (+ 75%).2. The effects of the risk might be assessed as catastrophic(threaten the survival of the project), serious (would causemajor delays), tolerable (delays are within allowedcontingency), or insignificant.

Analysis’ example

Risks Planning• The risk planning process considers each of the key risks

that have been identified, and develops strategies tomanage these risks.

• For each of the risks, you have to think of actions that youmight take to minimize the disruption to the project if theproblem identified in the risk occurs.

• You also should think about information that you mightneed to collect while monitoring the project so thatproblems can be anticipated

• Again, there is no simple process that can be followed forcontingency planning. It relies on the judgment andexperience of the project manager

Risks Planning example

Risks Planning strategies

• Avoidance strategies: Following these strategiesmeans that the probability that the risk will arisewill be reduced.

• Minimization strategies: Following thesestrategies means that the impact of the risk will bereduced.

• Contingency plans: Following these strategiesmeans that you are prepared for the worst andhave a strategy in place to deal with it.

Risks monitoring• Risk monitoring is the process of checking that your

assumptions about the product, process, and businessrisks have not changed.

• You should regularly assess each of the identified risks todecide whether or not that risk is becoming more or lessprobable.

• You should also think about whether or not the effects of the riskhave changed

• You should monitor risks regularly at all stages in a project. Atevery management review, you should consider and discusseach of the key risks separately.

• You should decide if the risk is more or less likely to arise and ifthe seriousness and consequences of the risk have changed.

Risks monitoring example

Project planning according with RUP (I)

• In the Rational Unified Process, the Project Managementdiscipline provides the framework whereby a project iscreated and managed. In doing so, all other coredisciplines—Requirements, Analysis and Design,Implementation, Test, and Deployment—are utilized aspart of managing the project.

• The RUP Project Management discipline utilizes theproject management principles—balancing competingobjectives, managing risk, and overcoming obstacles todeliver the “right” product—and enables RUP projectmanagers to manage software projects in a way that willsignificantly increase the probability of deliveringsuccessful software

Project planning according with RUP (II)

The Project Management discipline has three purposes:• To provide a framework for managing software-intensive

projects• To provide practical guidelines for planning, staffing,

executing, and monitoring projects• To provide a framework for managing risk

Key artifacts for PP in RUP (I)Business CaseThis artifact provides the necessary information from a businessstandpoint to determine whether this project is worth investing in. For acommercial software product, the Business Case should include aset of assumptions about the project and the order of magnitudereturn on investment (ROI) if those assumptions are true. The ProjectManager checks these assumptions again at the end of the Elaborationphase, when the scope and plan are defined with more accuracy.Noncommercial software has a range of other aspects that need to becaptured, including but not limited to the following:• Alignment of the product of this project (software product or service)

with business goals and project vision• Improvements or efficiencies expected to be realized as a result of this

software• Role played by the product of this project in enabling the core business• Other areas that will rationalize the investment

Key artifacts for PP in RUP (II)Software Development Plan• The purpose of this artifact is to gather all the information

necessary to control the project.• This artifact describes the software development

approach and is the top-level plan generated and usedby the managers to direct the development effort.

• This artifact provides a project overview, describes theproject team and a project plan (by phases), andserves as a reference to iteration plans for eachiteration (within a phase). This artifact, therefore, iscomprehensive and includes a number of artifactsdeveloped during the Inception phase.

Key artifacts for PP in RUP (III)

Software Development PlanMain components of SDP• Measurement Plan• Risk Management Plan• Product Acceptance Plan• Problem Resolution Plan• Quality Assurance Plan

Key artifacts for PP in RUP (IV)

• Iteration Plan• Review Record• Risk List• Issues List• Status Assessment• Work Order• Deployment Plan

RUP Planning in differents levels

Don’t forget the RUP structure

Project planning according with Agile (I)

• Unlike plan-driven approaches, in agile projects thefunctionality of these increments is not planned in advancebut is decided during the development.

• The decision on what to include in an incrementdepends on progress and on the customer’s priorities.

• The argument for this approach is that the customer’spriorities and requirements change so it makes sense tohave a flexible plan that can accommodate these changes

Project planning according with Agile (II)

There are two important benefits from this approach to taskallocation:1. The whole team gets an overview of the tasks to becompleted in an iteration. They therefore have anunderstanding of what other team members are doing andwho to talk to if task dependencies are identified.2. Individual developers choose the tasks to implement;they are not simply allocated tasks by a project manager.They therefore have a sense of ownership in these tasksand this is likely to motivate them to complete the task.

The planning game (XP)

Difficulties in agile planning

• A major difficulty in agile planning is that it is reliant oncustomer involvement and availability. In practice, this canbe difficult to arrange, as the customer representative mustsometimes give priority to other work. Customers may be morefamiliar with traditional project plans and may find it difficult toengage in an agile planning project.

• Agile planning works well with small, stable development teamsthat can get together and discuss the stories to be implemented.However, where teams are large and/or geographicallydistributed, or when team membership changes frequently, it ispractically impossible for everyone to be involved in thecollaborative planning that is essential for agile projectmanagement. Consequently, large projects are usually plannedusing traditional approaches to project management.

Contrasting (typical PP)

Contrasting (typical Agile PP)

Comparisons (I)

Comparisons (II)

Comparisons (III)

Comparisons (IV)

Thanks for your [email protected]