Home | | Software Project Management | Software Project Management: Activity Planning

Chapter: Software Project Management

Software Project Management: Activity Planning

1. Objectives 2. Project Schedule 3. Sequencing and Scheduling Activities 4. Network Planning Models 5. Forward Pass 6. Backward Pass 7. Activity Float 8. Shortening Project Duration 9. Activity on Arrow Networks 10. Risk Management 11. Nature Of Risk 12. Types Of Risk 13. Managing Risk 14. Hazard Identification 15. Hazard Analysis 16. Risk Planning And Control



1. Objectives

2. Project Schedule

3. Sequencing and Scheduling Activities

4. Network Planning Models

5. Forward Pass

6. Backward Pass

7. Activity Float

8. Shortening Project Duration

9. Activity on Arrow Networks

10. Risk Management

11. Nature Of Risk

12. Types Of Risk

13. Managing Risk

14. Hazard Identification

15. Hazard Analysis

16. Risk Planning And Control



1. Objectives of activity planning


            Feasibility assessment-Whether project can be finished within specified time scales


            Resource allocation


            Detailed costing-Cost?






2. Project schedules




–  Ideal activity plan


–  Activity risk analysis


–  Resource allocation


–  Schedule production


            Projects and activities


            Defining activities


            Identifying activities


Identifying activities


            The activity based approach


            The product based approach


            The hybrid approach




3. Sequencing and scheduling activities


            Project plan-bar chart





            Take into account availability of staff


            Way of allocation


4. Network-Planning Models


            A project is made up of a sequence of activities that form a network representing a project.


            The path taking longest time through this network of activities is called the “critical path.”


            The critical path provides a wide range of scheduling information useful in managing a project.


            Critical Path Method (CPM) helps to identify the critical path(s) in the project networks.


            CPM with a Single Time Estimate


   Used when activity times are known with certainty.


   Used to determine timing estimates for the project, each activity in the project, and slack time for activities.


            CPM with Three Activity Time Estimates (a.k.a. PERT)


   Used when activity times are uncertain.


   Used to obtain the same information as the Single Time Estimate model andprobability information.


            Time-Cost Models


   Used when trade-off information cost is a major consideration in planning.


   Used to determine the least cost in reducing total project time.


Example:. CPM with Single Time Estimate


Consider the following consulting project



Develop a critical path diagram ( network) and determine the duration of the critical path and Slacktimes for all activities


Draw the network


Compute early starts and early finish times (forward pass)


Compute late starts and l ate finish times (backward pass)


Compute Slack (LS-ES) per activity and Critical Path(s)


Example2. CPM with Three A ctivity Time Estimates


Develop a critical path diagram ( network) and determine the duration of the critical path and Slacktimes for all activities


Draw the network


Compute early starts and early finish times (forward pass)


Compute late starts and l ate finish times (backward pass)


Compute Slack (LS-ES) per activity and Critical Path(s) What is the probability of finishing this project in less than 53 days? What is the probability that the p roject duration will exceed 56 days?


            Time-Cost Models


            Sometimes it is possible to "crash" (expedite) some activities thus reducing the overall completion time for the entire project.


            Crashing an activity implies spending additional funds (e.g., overtime costs, hiring more workers, and so on) to get the task done earlier.




On many occasions reducing the project completion time that in turn reduces the fixed cost outlays can generate substantial savings.


Draw the CPM network, identify the CP


Identify the least cost activity(ies) on the critical path(s)


Shorten the project completion time (CP) at the least cost Repeat until no more crashing is possible (or cost exceeds the benefits)


            Assume fixed costs = $1,000 day.


            Find the optimum time-cost schedule.


            CPM Assumptions/Limitations


            Project activities can be identified as entities. (There is a clear beginning and ending point for each activity.)


              Project activity sequence relationships can be specified and networked.


            Project control should focus on the critical path.


            The activity times follow the beta distribution, with the variance of the project assumed to equal the sum of the variances along the critical path. Project control should focus on the critical path.


            MS Project


            MS Project is very popular and inexpensive project management software.


            It is constantly improved (upgraded).


            Many independent software firms have developed “add-ons” to further improve or help users (managers) take full advantage of its capabilities.


            For example, probabilistic analysis (PERT approach) is not directly available in MS Project.


   CAUTION: “PERT” in MS Project refers to the AON network representation, and simplistic project duration calculations done by using either optimistic or most likely or pessimistic time estimates for all activities.


            Risk+ developed by C/S Solutions “is a comprehensive risk analysis tool that integrates seamlessly with Microsoft® Project to quantify the cost and schedule uncertainty associated with your project plans.”


            Reliable Construction Company Project


            This is a mini case/group exercise.



            The Reliable Construction Company has just made the winning bid of $5.4 million to construct a new plant for a major manufacturer.


            The contract includes the following provisions:


   A penalty of $300,000 if Reliable has not completed construction within 47 weeks.


   A bonus of $150,000 if Reliable has completed the plant within 40 weeks.




            How can the project be displayed graphically to better visualize the activities?


            What is the total time required to complete the project if no delays occur?


            When do the individual activities need to start and finish?


            What are the critical bottleneck activities?


            For other activities, how much delay can be tolerated?


            What is the probability the project can be completed in 47 weeks?


            Is it worth to expedite the activities to finish the project in 40 weeks?


– Assume activities with 7 or more weeks can be shortened by two weeks and the rest can be reduced by only one week.


– For simplicity assume that cost per week to expedite any activity is $30,000.





Three Time Estimates for the Project

5,6. Forward and backward pass


       Why Network Diagrams?


            Splits up the decision making process into


   Method/logic - the order in which tasks have to be completed


   Time – estimates for the time to completion can be added to each task


   Resources – these can be added and then analysis carried out


       Two Parts to the Analysis


            Forward Pass


   Calculates the Duration of the Project


            Backward Pass


Calculates the slack/float for each task and shows the critical path



To calculate the total duration of the Project…


For each task:


   Take the earliest start time (EST)


Calculate the Earliest finish time (EFT): 

EFT = EST+Duration



Backward Pass


To calculate the float for each task?


For each task:


   Take the latest start time (LST)


   Calculate the latest finish time (LFT):




LST = LFT-Duration





            Free float


   The time by which an activity may be delayed without affecting any specific activity


            Interfering float


   The diff between the total float and free float


            Reducing Project Duration


            Time Is Money: Cost-Time Tradeoffs


–  Reducing the time of a critical activity usually incurs additional direct costs.


   Cost-time solutions focus on reducing (crashing) activities on the critical path to shorten overall duration of the project.


–  Reasons for imposed project duration dates:


   Time-to-market pressures


   Unforeseen delays


   Incentive contracts (bonuses for early completion)


   Imposed deadlines and contract commitments


   Overhead and public goodwill costs


   Pressure to move resources to other projects


            Options for Accelerating Project Completion


            Resources Not Constrained


–  Adding resources


–  Outsourcing project work


–  Scheduling overtime


–  Establishing a core project team


–  Do it twice—fast and then correctly


            Resources Constrained


–  Fast-tracking


–  Critical-chain


–  Reducing project scope


–  Compromise quality


            Explanation of Project Costs


            Project Indirect Costs


– Costs that cannot be associated with any particular work package or project activity.



            Supervision, administration, consultants, and interest


–  Costs that vary (increase) with time.


            Reducing project time directly reduces indirect costs.


            Project Direct Costs


Normal costs that can be assigned directly to


a specific work package or project activity.


 Labor, materials, equipment, and subcontractors


– Crashing activities increases direct costs.


Reducing Project Duration


Project Cost–Duration Graph



Constructing a Project Cost–Duration Graph


            Findtotal direct costs for selected project durations.


            Find total indirect costs for selected project durations.


            Sum direct and indirect costs for these selected project durations.


            Compare additional cost alternatives for benefits.


            Constructing a Project Cost–Duration Graph


            Determining Activities to Shorten


–  Shorten the activities with the smallest increase in cost per unit of time.


–  Assumptions:


            The cost relationship is linear.


            Normal time assumes low-cost, efficient methods to complete the activity.


            Crash time represents a limit—the greatest time reduction possible under realistic conditions.


            Slope represents a constant cost per unit of time.


            All accelerations must occur within the normal and crash times.


Activity Graph

Cost–Duration Trade-off Example



Practical Considerations


Using the Project Cost–Duration Graph


Crash Times


Linearity Assumption


Choice of Activities to Crash Revisited


Time Reduction Decisions and Sensitivity


What if Cost, Not Time Is the Issue?


Commonly Used Options for Cutting Costs


–  Reduce project scope


–  Have owner take on more responsibility


–  Outsourcing project activities or even the entire project


–  Brainstorming cost savings options


            Constructing a Project Network




   Activity: an element of theproject that requires time.


   Merge activity: an activity that has two or more preceding activities on which it depends.


   Parallel (concurrent) activities: Activities that can occur independently and, if desired, not at the same time.


Activity-on-Node Fundamentals


   Path: a sequence of connected, dependent activities.


Critical path: the longest path through the activity network that allows for the completion of all project-related activities; the shortest expected time in which the entire project can be completed. Delays on the critical path will delay completion of the entire project.


Forward Pass Computation


Add activity times along each path in the network (ES + Duration = EF).


Carry the early finish (EF) to the next activity where it becomes its early start (ES) unless…


The next succeeding activity is a merge activity, in which case the largest EF of all preceding activities is selected.


Backward Pass Computation


Subtract activity times along each path in the network (LF - Duration = LS).


Carry the late start (LS) to the next activity where it becomes its late finish (LF) unless...


The next succeeding activity is a burst activity, in which case the smallest LF of all preceding activities is selected.


Determining Slack (or Float)


Free Slack (or Float)


   The amount of time an activity can be delayed without delaying connected successor activities


Total Slack


   The amount of time an activity can be delayed without delaying the entire project


The critical path is the network path(s) that has (have) the least slack in common.


Sensitivity of a Network


The likelihood the original critical path(s) will change once the project is initiated.


§  Function of:


The number of critical paths


The amount of slack across near critical activities



9. Activity-on-Arrow Network-Building Blocks

Activity-on-Arrow Network Fundamentals


1 Partial AOA Koll Network


2 Activity – on-Arrow Network


3 Activity – on-Arrow Network Forward Pass


4 Activity-on-Arrow Network Backward Pass



10  Risk Management


The proactive management of risks throughout the software development lifecycle is important for project success.


The risk management practice, which involves risk identification, analysis, prioritization, planning, mitigation, monitoring, and communication


software development risks that seem to reoccur in educational and industrial projects

a risk-driven process for selecting a software development model


1Risk Identification


In the risk identification step, the team systematically enumerates as many project risks as possible to make them explicit before they become problems. There are several ways to look at the kinds of software project risks.


There are some specific factors to consider when examining project, product, and business risks. Some examples of these factors are listed here, although this list is meant to stimulate your thinking rather than to be an all-inclusive list.


People risks are associated with the availability, skill level, and retention of the people on the development team.


Size risks are associated with the magnitude of the product and the product team. Larger products are generally more complex with more interactions. Larger teams are harder to coordinate.


Process risks are related to whether the team uses a defined, appropriate software development process and to whether the team members actually follow the process.


Technology risks are derived from the software or hardware technologies that are being used as part of the system being developed. Using new or emerging or complex technology increases the overall risk.



Tools risks, similar to technology risks, relate to the use, availability, and reliability of support software used by the development team, such as development environments and other Computer-Aided Software Engineering (CASE) tools.


Organizational and managerial risks are derived from the environment where the software is being developed. Some examples are the financial stability of the company and threats of company reorganization and the potential of the resultant loss of support by management due to

a change in focus or a change in people.


Customer risks are derived from changes to the customer requirements, customers’ lack of understanding of the impact of these changes, the process of managing these requirements changes, and the ability of the customer to communicate effectively with the team and to accurately convey the attributes of the desired product.


Estimation risks are derived from inaccuracies in estimating the resources and the time required to build the product properly.


Sales and support risks involve the chances that the team builds a product that the sales force does not understand how to sell or that is difficult to correct, adapt, or enhance.


2 Strategies for Risk Management:


During the software development process various strategies for risk management could be identified and defined according to the amount of risk influence. Based upon the amount of risk influence in software development project, risk strategies could be divided into three classes namely careful, typical, and flexible (Boban, M. et.). Generally, careful risk management strategy is projected for new and inexperienced organizations whose software development projects are connected with new and unproven technology; typical risk management strategy is well-defined as a support for mature organizations with experience in software development projects and used technologies, but whose projects carry a decent number of risks; and flexible risk management strategy is involved in experienced software development organizations whose software development projects are officially defined and based on proven technologies (Boban, M. etc.).


3 Categories of risks: Schedule Risk:


Project schedule get slip when project tasks and schedule release risks are not addressed properly.


Schedule risks mainly effect on project and finally on company economy and may lead to project failure.

Schedules often slip due to following reasons:

Wrong time estimation


Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.


Failure to identify complex functionalities and time required to develop those functionalities.

Unexpected project scope expansions.


Budget Risk:

Wrong budget estimation.

Cost overruns

Project scope expansion


Operational Risks:


Risks of loss due to improper process implementation, failed system or some external events risks.

Causes of Operational risks:

Failure to address priority conflicts

Failure to resolve the responsibilities

Insufficient resources

No proper subject training

No resource planning

No communication in team.


Security in System Development


Risk Analysis & Management needs to be a part of system development, not tacked on afterwards


Baskerville's three generations of methods


1st Generation: Checklists


Example: BS 7799 Part 1


2nd Generation: Mechanistic engineering methods


Example: this risk analysis method


3rd Generation: Integrated design


Not yet achieved




The meanings of terms in this area are not universally agreed. We will use the following


Threat: Harm that can happen to an asset


Impact: A measure of the seriousness of a threat


Attack: A threatening event


Attacker: The agent causing an attack (not necessarily human)


Vulnerability: a weakness in the system that makes an attack more likely to succeed


Risk: a quantified measure of the likelihood of a threat being realised


Risk Analysis involves the identification and assessment of the levels of risk, calculated from the


   Values of assets



   Threats to the assets


   Their vulnerabilities and likelihood of exploitation


Risk Management involves the identification, selection and adoption of security measures justified by


   The identified risks to assets


   The reduction of these risks to acceptable levels


Goals of Risk Analysis:


All assets have been identified


All threats have been identified


   Their impact on assets has been valued


All vulnerabilities have been identified and assessed


Problems of Measuring Risk


Businesses normally wish to measure in money, but


Many of the entities do not allow this


   Valuation of assets


–  Value of data and in-house software - no market value


–  Value of goodwill and customer confidence


   Likelihood of threats


–  How relevant is past data to the calculation of future probabilities?


–  The nature of future attacks is unpredictable


–  The actions of future attackers are unpredictable


   Measurement of benefit from security measures


–  Problems with the difference of two approximate quantities


–  How does an extra security measure affect a ~10-5 probability of attack?


Risk Levels


Precise monetary values give a false precision




Better to use levels, e.g.


   High, Medium, Low


–  High: major impact on the organisation


–  Medium: noticeable impact (“material” in auditing terms)


–  Low: can be absorbed without difficulty


   1 - 10


Express money values in levels, e.g.


   For a large University Department a possibility is


–  High


–  Medium


–  Low


Risk Analysis Steps


Decide on scope of analysis


   Set the system boundary


Identification of assets & business processes


Identification of threats and valuation of their impact on assets (impact valuation)


Identification and assessment of vulnerabilities to threats


Risk assessment


Risk Analysis – Defining the Scope


Draw a context diagram


Decide on the boundary


   It will rarely be the computer!


Make explicit assumptions about the security of neighbouring domains


   Verify them!


Risk Analysis - Identification of Assets



Types of asset




   Software: purchased or developed programs




   People: who run the system


   Documentation: manuals, administrative procedures, etc


   Supplies: paper forms, magnetic media, printer liquid, etc






–  Goodwill


–  Organization confidence


–  Organisation image


Risk Analysis – Impact Valuation


Identification and valuation of threats - for each group of assets


          Identify threats, e.g. for stored data


   Loss of confidentiality


   Loss of integrity


   Loss of completeness


   Loss of availability (Denial of Service)


          For many asset types the only threat is loss of availability


          Assess impact of threat


   Assess in levels, e.g H-M-L or 1 - 10


   This gives the valuation of the asset in the face of the threat


Risk Analysis – Vulnerabilities


•  Identify vulnerabilities against a baseline system



For risk analysis of an existing system


– Existing system with its known security measures and weaknesses For development of a new system

–  Security facilities of the envisaged software, e.g. Windows NT


–  Standard good practice, e.g. BS 7799 recommendations of good practice


For each threat


Identify vulnerabilities


   How to exploit a threat successfully;

Assess levels of likelihood - High, Medium, Low


   Of attempt


Expensive attacks are less likely (e.g. brute-force attacks on encryption keys)


   Successful exploitation of vulnerability;


Combine them


Risk Assessment


Assess risk


If we had accurate probabilities and values, risk would be


   Impact valuation x probability of threat x probability of exploitation


   Plus a correction factor for risk aversion


Since we haven't, we construct matrices such as



Responses to risk


Avoid it completely by withdrawing from an activity


Accept it and do nothing


Reduce it with security measures


Risk management


Risk management is concerned with identifying risks and drawing up plans to minimisetheir effect on a project.


A risk is a probability that some adverse circumstance will occur


Project risks affect schedule or resources;


Product risks affect the quality or performance of the software being developed; Business risks affect the organisation developing or procuring the software.

The risk management process


Risk identification


Identify project, product and business risks;


Risk analysis


Assess the likelihood and consequences of these risks;


Risk planning


Draw up plans to avoid or minimise the effects of the risk;


Risk monitoring


Monitor the risks throughout the project;




14. Hazard Identification


Systematic Processes


What Constitutes a Hazard?


A real or potential condition that, when activated, can transform into a series of interrelated events that result in damage to equipment or property and or injury to people.


Safety Managers View




   An implied threat or danger, a potential condition waiting to become a loss




   Required to initiate action from potential to kinetic


   May be a:


   Component out of tolerance


   Maintenance failure


   Operator failure


   Any combination of other events and conditions


When Do We Look for Hazards?


The 5 Common Phases of a Systems Life Cycle


   Conceptual - Research

   Design  (Validation & Verification)

   Development (Full-scale engineering & production)

   Operational Deployment

   Termination & Disposal


Hazard Severity


A key factor in establishing a common understanding of a safety programs goal


MIL-STD 882 suggests four categories


Cat 1: Catastrophic


Cat 2: Critical


Cat 3: Marginal


Cat 4: Negligible


15. Hazard Analysis Methods


Failure Modes & Effects Analysis (FMEA)


   Systematic look at hardware piece by piece

   Review of how each component could fail


   Considers how a failure effects other components, sub-systems and systems as a whole

   Risk assessment accomplished (severity & probability)

Risk Assessment Code (RAC) assigned


Fault Tree Analysis (FTA)


   Detailed review of a specific undesirable event

   Deductive in nature

   Top-down effort



   Normally reserved for critical failures or mishaps

            May be qualitative or quantitative


            Operating Hazard Analysis (OHA)


   Also known as Operating & Support Hazard Analysis (O&SHA)

   “What if” tool brings user into the loop


            Integrates people and procedures into the system


   Diagrams the flow or sequence of events

            Project Evaluation Tree (PET) may be used for OHA accomplishment


   Systematic evaluation of man, machine, & procedures





A risk is an event or condition that, if it occurs, could have a positive or negative effect on a project’s objectives. Risk Management is the process of identifying, assessing, responding

to, monitoring and controlling, and reporting risks. This Risk Management Plan defines how risks associated with the<Project Name> project will be identified, analyzed, and managed. It outlines how risk management activities will be performed, recorded, and monitored throughout the lifecycle of the project and provides templates and practices for recording and prioritizing risks by the Risk Manager and/or Risk Management Team.


Risks related to IT systems or applications must be identified and documented based on the methodology in NIST SP 800-30, Risk Management Guide for Information Technology Systems. IT system or application weaknesses must be identified on an associated plan of action and milestones (POA&M) and tracked in accordance with HHS POA&M guidelines. Appropriate protective measures must be taken to safeguard sensitive IT system or application weaknesses or vulnerabilities from unauthorized disclosure.




Each major risk (those falling in the Red & Yellow zones) will be assigned to a risk owner for monitoring and controlling purposes to ensure that the risk will not “fall through the cracks”.

For each major risk, one of the following approaches will be selected to address it:


        Avoid Eliminate the threat or condition or to protect the project objectives from its impact by eliminating the cause


        Mitigate Identify ways to reduce the probability or the impact of the risk


        Accept Nothing will be done

        Contingency –Define actions to be taken in response to risks

        Transfer Shift the consequence of a risk to a third party together with ownership of the response by making another party responsible for the risk (buy insurance, outsourcing, etc.)




The level of risk on a project will be tracked, monitored and controlled and reported


throughout the project lifecycle. [Describe the methods and metrics that will be used to track the project’s risk status throughout the lifecycle as well as how this status will be reported to the

stakeholders/ management.]


Risks will be assigned a risk owner(s) who will track, monitor and control and report on the status and effectiveness of each risk response action to the Project Manager and Risk

Management Team on a <insert timeframe>.

A “Top 10 Risk List” will be maintained by the PM/Risk Manager or IPT and will be reported as a component of the project status reporting process for this project.


All project change requests will be analyzed for their possible impact to the project risks. As Risk Events occur, the list will be re-prioritized during weekly reviews and risk


management plan will reflect any and all changes to the risk lists including secondary and residual risks.


Management will be notified of important changes to risk status as a component to the Executive Project Status Report. [State timeframe, i.e., every two weeks]

The Risk Manager (PM) will:


            Review, reevaluate, and modify the probability and impact for each risk item [timeframe, as needed, every two weeks, etc.]


            Analyze any new risks that are identified and add these items to the risk list (or risk database).


            Monitor and control risks that have been identified

            Review and update the top ten risk list [timeframe, as needed, every two weeks, etc.]


            Escalate issues/ problems to management [List factors that would need to be escalated to management. Examples: documented mitigation actions are not effective or producing the desired results; the overall level of risk is rising.]

The Risk Owner will:


            Help develop the risk response and risk trigger and carry out the execution of the risk response, if a risk event occurs.


            Participate in the review, re-evaluation, and modification of the probability and impact for each risk item on a weekly basis.


            Identify and participate in the analysis of any new risks that occur.

            Escalate issues/problems to PM that,


Significantly impact the projects triple constraint or trigger another risk event to occur.

Require action prior to the next weekly review

Risk strategy is not effective or productive causing the need to execute the contingency plan.



Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail
Software Project Management : Software Project Management: Activity Planning |

Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.