Project, People, Processes and Products Project management skills – schedule, monitoring, risk...
-
Upload
wendy-mary-may -
Category
Documents
-
view
214 -
download
1
Transcript of Project, People, Processes and Products Project management skills – schedule, monitoring, risk...
Project, People, Processes and Products
• Project management skills – schedule, monitoring, risk management, …
• People management skills – delegation, mentoring, staffing, promoting, evaluating, training, …
• Process management skills – life cycle model processes and deliverables
• Product management skills – quality control, metrics, …
The 5 functions of management• Planning – selection of missions and objectives, commitment
of resources and scheduling of actions• Organizing – structure of role for people, assignment of
responsibilities and authorities• Staffing – hiring, retaining, training, evaluating, promoting
people• Leading – create a healthy working environment to motivate
people and help achieving results• Controlling – taking corrective actions if actual performance
deviates from planned performance, rewarding and disciplining people
5 Management functions
Project management activities
• Project startup – at the beginning– Estimation, staffing, training, scheduling, risk
identification …
• Project execution – during the project– Control, reviews, SQA, risk monitoring, …
• Project closeup – at the end– Post mortem evaluation, archiving, …
Top 10 reasons why projects fail
• Inadequately trained and/or inexperienced project managers• Failure to set and manage expectations• Poor leadership at any and all levels• Failure to adequately identify, document and track requirements• Poor plans and planning processes• Poor effort estimation• Cultural and ethical misalignment• Misalignment between project team and business it serves• Inadequate or misused methods• Inadequate communication, including progress tracking and
reporting
Estimation techniques
• Estimation during project startup• Time and effort to be included in initial project
schedule• Avoid overestimation or underestimation• Micro level and macro level estimation– Macro level: not detailed, based on Kilo line of
code– Micro level: detailed, more accurate,
Estimation techniques
• Requirements level estimation – black-box, high level– Function point, feature point, use case point
• Implementation level estimation – white box, low level based on code– COCOMO
Empirical estimation models• E = (a + (b x Sizec )) x F
– a, b and c are model coefficients that are empirically obtained, – Size is the estimated size of the project in KLOC– F is a product of factors influencing project estimates.
• In the Bailey-Basili model:
E = (5.5 + (0.73 x Size1.16) x F– The same general equation is also used to estimate the effort for
projects where the Size is estimated in terms of function points needed.
• In Kemerer model: E = (-37 + 0.96 x Size) x F– F depends on project complexity factors.
Function point metrics• Complexity of software and the effort needed to develop it are a function of
the number and type of five different kinds of functional components that can be obtained and assessed at the requirements specifications phase. – internal files (IF) corresponding to the database files that are created and
maintained within the application to develop.– external files (EF) corresponding to the files owned and maintained by other
applications, but are used by the application to develop.– external inputs (EI) corresponding to the inputs that affect the control flow and
internal logic of the application leading to the creation and maintenance of data.– external outputs (EO) corresponding to the data leaving the application to
different output devices, files or external systems.– external inquiries (EIQ) corresponding to simple user queries resulting in
responses to them.
Example 10.1• Suppose the software to develop has 1 EIs, 3 EOs, and
1 UI, all of simple complexities, the number of unadjusted function points (UFP) would then be 3*1+4*3+3*1 = 18.
• In addition, it has 2 Eis and 1 UI of average complexity, and 1 EI, 1 EO, 1 IF and 3 EF of high complexity.
• Similar computations should be performed for the remaining average and complex components.
• The total number of UFPs is: (3*1+4*3+3*1) + (4*2+4*1) + (6*1+7*1+15*3+10*1) = 98 UFPs.
A rating from 0 to 5 is assigned to each factor.
Their sum is computed to obtain a value for S.
Computing the adjusted function points (AFP)
• The overall complexity factor F is then computed using the equation:
CF = 0.65 + 0.01 x S
– CF will be within the range 0.65 to 1.35. – The number of adjusted function points (AFP) is
UFP x CF
Reconciling estimations
• Another approach the manager can take to reduce the risk of underestimation is to produce estimates using different techniques and performed by different experts. Differences between the estimated efforts can then be reconciled using statistical analysis techniques.
• For example, if the three estimates, ELow, EHigh and EMid are obtained, such that ELow < EMid < EHigh, the value for E that can be used is computed using the equation:
E = (ELow + 4 x EMid + EHigh) / 6
Mapping AFP to Effort
• m = f 3*j / 27 person-months. • j depends on the type of the software application
involved and the capabilities and expertise of the development team and varies from 0.39 to 0.48.
• In Example 10.1, if we consider j = 0.43, the number of person-months would be 13.71
• Average number of LOC per function point in the C and Java are 162 and 63, respectively
• In Example 10.1, the estimated number of lines would be about 15 KLOC of C code or 6 KLOC of Java code.
FP estimation excel sheet
<<FP sheet>>Assumptions:Effort exponent is 0.43Cost per day is 400 $20 working day per month65 Java lines of code per AFP
Use case point (UCP) estimation
• By Kamer in 1993 – an extension of FP method based on UCM.
• Based on steps or transactions in a Use Case• Unadjusted Actor Weight (UAW), Unadjusted Use
Case Weight (UUCW)• Unadjusted Use Case Point UUCP = UAW + UUCW• Adjusted UCP AUCP = UUCP x TCF x ENVF
TCF = 0.6 + 0.01 x TF , TF is sum of weighted values
EF = 1.4 – 0.03 x ENVF , ENVF is sum of all weighed values
Computing the effort
• 25 person-hours per AUCP• Use case PlaceOrder: complex use case, 3
actors: buyer is complex and warehouse and accounting are simple
• UAW = 5, UUCW = 15, UUCP = 20• TF = 38.5, TCF = 0.985, ENVF = 21.5, EF = 0.755• AUCP = 20 x 0.985 x 0.75 = 14.87• Effort is (14.87 x 25) / 7hrs/day = 53.11 days
UCP estimation excel sheet
<<UCP Sheet>>Assumptions:Person-Hours per AUCP is 257 hours of work per day400 $ per day
COCOMO
• Constructive Cost Model by Boehm in 1981 Based on estimated program size in KLOC
• Basic – no consideration for factorsE = a x Sizeb D = c x Ed
P = E / D• Intermediate – considers effort adjustment factor• Detailed – adjustment factors for different phases of
development
Example 10.3
• Semi-detached software, estimated 100 KLOC.• Estimated effort in person-months
E = 3 x 1001.12 = 521 person-months, D = 2.5 x 5210.35 = 8.93 months and P is E / D = 58.36 persons.
• The formula used in intermediate COCOMO is:• E = a x Sizeb x EAF• where coefficients a and b are given in Table 10.9, Size is
the estimated KLOC and EAF computed using the cost drivers rating table.
Example 10.4
• For the same semi-detached software project we have considered in Example 10.3, the ratings and corresponding multipliers for each of the 15 factors are shown in Table 10.11.
• The EAF for this project is 1.63. • The effort E in persons-months is
3 x 1001.12 x 1.63 = 849.78 persons-months.
Risk Management• One main reason for project failure: inability to deal
adequately with anticipated or unanticipated problem• Ideally all risks must be anticipated by manager• Software risk: a problem occurring during the
development of the software and the consequence of that problem.
• Continuous process: Risk engineering cycle• Aim: make timely and informed decisions and take
appropriate risk control actions to deal with the risk– Prevention, detection, response
Risk management planning• Planning involves startup risk management
activities for the software project. • Meetings for – defining the risk efforts – risk management budget and schedule– assigning risk responsibilities within the development
group and beyond– defining the interactions with other stakeholders– deciding on the templates, risk taxonomies and other
standards and procedures to follow.
Risk identification• First step in a risk management process• Risk identification requires the expertise of application domain
experts in addition to general project management experience. • Early identification reduces the costs incurring should the risk occur. • Late identification may limit the available risk mitigation solutions
and make them costlier• A formal process involving the various stakeholders may be needed
for complex high stakes projects. • Involve reviewing project documents to identify potential problems,
conducting information gathering techniques including brainstorming and interviewing, and performing checklist evaluation.
Types of risks
• Product risks and its capabilities– Examples of risks in this category are the unfeasibility of a
requirement, the bad performance of a selected design solution, and the insecurity of an access control mechanism.
• Process risks– Examples of risks in this category are the unfamiliarity of the
development team with the adopted process model, the unsuitability of the adopted process model, and the potential communication problem and lack of team coherence.
• Technical and developmental risks– Examples of risks in this category are the unfamiliarity of the
development team with the development system, and the unfamiliarity of the team with the tools and techniques used.
Project risks
• Project risks are technical and non-technical risks related to project management style, project plan, effort estimation, risk planning, and project dependencies and constraints.
• Examples of technical project risks are the underestimation of effort for scheduled project activities, the inadequacy or lack of project progress monitoring methods, the unavailability of third party software when needed, and the project constraints are unfeasible and overly restrictive.
• Examples of non-technical people-related project risks include the lack of synergy among team members, and the lack of communication among the various project stakeholders.
Getting risks
• To cover all potential risks, the manager must be experienced, rely on the expertise of others in the organization, consider different published project risks taxonomies, and participate in brainstorming sessions with other project stakeholders to elicit potential software risks. Identified risks must also be well documented and maintained.
• Each risk is assigned to an owner. The risk owner is a developer who will be responsible for following up on the planning, tracking and control of the risk.
Risk analysis (assessment)• After identifying the risks, they must be assessed and verified for
appropriateness and applicability. • The likelihood of their occurrence and their impacts on the project
schedule, cost and quality must be evaluated either qualitatively or quantitatively.
• In a qualitative assessment, the risk likelihood (RL) ranges from very low, low, medium, high to very high.
• The risk impact (RI) ranges from negligible, minor, tolerable, significant, to major. In a quantitative assessment, risk likelihood and risk impacts are continuous.
• In a quantitative assessment, the risk exposure (RE) for each risk can
then be computed as follows: RE = RL x RI
Risk prioritization
• For example, if the risk likelihood is 25%, and its impact is the loss of 1000 $, then the risk exposure is 250 dollars.
• Based on the risk exposure, identified risks can then be assigned different priorities. A risk priority can be very low, low, medium, high or very high.
• Obviously, high exposure risks should be dealt with very thoroughly since they will most probably be assigned a very high priority.
• The main challenge in analyzing the risks is to find the correct likelihood of occurrence of each risk and its exact impact. – Use interviews and meeting with internal experts or consultants in the
application domain.
Risk planning
• A risk response plan must be designed for every risk identified.
• A risk response plan aims at enhancing the opportunities to counter the risk and to reduce the threats it poses to the project.– Avoidance, mitigation, acceptance and
transference
• The different types of risk actions are developed and prioritized.
Risk reduction leverage
• The aim of a risk action is to reduce the risk exposure. The risk reduction leverage (RRL) can be computed for every risk action as follows:
• RRL = (Exposure before reduction – Exposure after reduction) / Risk action cost– if a risk action costs $2000 and reduces the risk exposure
from $100000 to $20000, the RRL would be 40.• Clearly, for the same risk action cost, the higher the RRL, the
better is the return on investment leading to a lesser exposure. • The RRL can be used to assess the effectiveness of the possible
risk control actions and to decide on the most effective action with the highest return on investment.
Risk avoidance and risk mitigation
• Risk avoidance actions to prevent the risk from occurring.– Examples are actions to improve the communications
among team members and to increase by 20% the efforts estimated for critical activities in the project schedule to deal with the risk of project delivery delays.
• Risk mitigation actions to reduce the risk impact should it occur. Timely and planned actions to reduce the likelihood and impact of a risk are typically taken when the risk is unavoidable but its impact could be very costly. – An example of a mitigation action is the development of a
disaster recovery plan to deal with the risk of a natural or man-made disaster.
Risk acceptance and risk transference
• Risk acceptance meaning no action is to be taken should the risk occur. – Typically, very low impact and low exposure risks are accepted
and their costs are assumed without further actions.• Risk transfer actions to shift the responsibility of dealing with the
risk and taking the appropriate action to a third party should the risk occur. – The third party could be an insurance company or a financial
institution. – Risk transference are normally considered when dealing with
non-technical risks such as contracts, financing risks and natural disasters.
Risk tracking
• An ongoing activity based on the monitoring of the risks by continuously checking the conditions for their occurrences.
• The proper implementations of risk actions are also monitored. • Risk tracking techniques includes periodic risk status reports,
and the monitoring of key risk indicators. • The early detection of the imminence of a risk occurrence is
desirable since it enhances the preparedness of the team to initiate, implement and control the risk actions planned earlier.
• Once a risk is realized, the planned risk actions are activated to deal with that risk.
Risk control
• Risk control is part of the overall project control dealing with the proper implementation of the control actions and risk plan.
• If corrections to the actions or to their implementations are needed, updates to the risk management plan will be made.
• Risk control may involve risk reassessment, risk audits and risk status meeting.
• These risk control activities are normally needed when some identified risks are not being dealt with according to plan or if the manager notices the occurrence of an unusual number of unanticipated risks.
Risk communication
• Risks must be communicated to the concerned stakeholders.• Failing to communicate risks and risk plans gives a false sense of
protection against the occurrence of these risks. • To properly follow up and control risks, risks must be
communicated to different units within the organization and to the different levels of management.
• Risks may need to be communicated to the client’s organization. – For example, the client must be aware of the risks related to
changes to the requirements and the implication consequences of such changes on the project schedule.
Scheduling and tracking projects
• Schedule is influenced by available resources and estimations
• Tracking project progress to avoid delays and take timely necessary actions
• To manage and track a large project, the project manager needs to divide the project work into related tasks.
• Tasks need to be structured around the phases of the life cycle model adopted by the development company.
Project tasks
• A task has an identity and a purpose, a duration, a start time, a list of predecessor tasks if any, and the resources needed to complete it.
• Predecessor tasks are those tasks needed prior to the start of the task at hand.
• Resources include human, software, hardware and possibly financial resources.
• A milestone is a particular point in time at which the task is completed. Breaking the project into small and manageable tasks will allow the early detection of lateness in a project.
• Task duration need not be too long or too short
Tracking techniques
• Different techniques can be used to track or monitor the progress of a project.
• Monitoring the adherence to completion dates or milestones set for the project tasks can be achieved by conducting progress review meetings, or by periodically reporting the progress achieved so far.
• Once early signs of lateness are detected, the manager can intervene in different ways depending on the severity of the problem and the causes of lateness.
Representing project tasks
• The tasks of a project can be summarized in both a tabular or graphical form.
• A typical template for the tabular representation of a project schedule includes one row per task.
• Columns correspond to the attributes of the task including the task id, task name, duration, start date, finish date, and the predecessor task(s) if any.
• A task whose duration is 0 day is called a milestone task. It is used to represent the termination of a phase or a group of tasks in the project schedule.
Task network• A graphical representation of a project schedule. • Composed of nodes and directed arcs joining them. • A node represents a task and includes its name and its duration. • A directed arc between two nodes represents the dependency
of the sink node or task on the completion of the start node or task.
• The task represented by the sink node cannot start until all the predecessor tasks have successfully terminated.
• Initial tasks are represented by nodes with no incoming edges.
Final tasks are represented by nodes with no outgoing edges.
Task network
• The project length is the duration in days of the longest path in the task network, the length of the project critical path.
• Given the available resources, including human and other system resources, and the tasks dependencies between the tasks the manager must exploit the concurrent execution of tasks to its fullest.
• The concurrent execution of tasks leads to better resource utilization and to shorter project length.
Example
• A project schedule table composed of 9 tasks including a milestone task.
• Task A is the initial task, task H is the final • A critical path (CP) on the task network is the longest
duration path from start to finish. • A task network may have more than one CP all
having the same total duration. A task that is included in a CP is called a critical task. Any delay in the completion of a critical task leads to a delay in the project termination.
Monitoring CP
• Closely monitor the progress made on critical paths. • For critical tasks, the earliest start date and latest start date are
equal. No delays can be afforded on these tasks. • Example has 2 CPs in the project schedule – duration is 16 days:
A-C-D-F-H-M and A-C-E-G-H-M. • Non-critical tasks may have different earliest start and latest
start dates without compromising the scheduled project termination date or milestone.
• The task slack time for a non-critical task is (latest start – earliest start). The slack time represents the flexibility that the manager has in scheduling non-critical tasks. The slack time for a critical task is 0.
Example 10.6
Earned value analysis
• Technique for the quantitative assessment and measurement of progress made in a project
• Percent of project completeness• Given an estimate in Person-Months of effort needed
for each scheduled task• BCWSi – Budgeted Cost of Work Scheduled for Task i
is the estimated effort • Progress made at time T: sum of all BCWSi of all tasks
that should have been completed at time T– BAC Budget at Completion
Earned value analysis
• BCWP – Budgeted Cost of Work Performed at time T• BCWP is the sum of the BCWSs for tasks that have been
completed at time T• ACWP – Actual Cost of Work Performed• SPI is the Schedule Performance Index = BCWP/BCWS
– Measure of performance
• BCWP/BAC indicates the percentage of work completed at time T
• Schedule variance SV = BCWP – BCWS– Negative variance SV means over-budget project
Earned value analysis (EVA)• EVA can be used to find estimate and variance at the
completion of the project given the situation at T and the estimated efforts for the remaining tasks
• Estimate at Completion – EAC = BAC/CPI – EAC = (BAC – BCWP)/CPI + ACWP
• Variance at Completion– Projection of the final cost variance of the project– VAC = BAC – EAC
• Schedule at Completion (SAC)– SAC = BAC/SPI
Example 10.7• 20 tasks, 200 P-M• At T, 6 tasks should have
been completed• Only 5 were completed• BCWS = 67 P-M• BCWP = 58 P-M• SPI = BCWP/BCWS = 0.91• SV = BCWP – BCWS = -9• % of completeness
BCWP/BAC = 29%• ACWP = 61.5• CPI = BCWP/ACWP = 0.94
• CV = BCWP-ACWP = -3.5• EAC = BAC/CPI = 212• VAC = BAC – EAC = -12• SAC = BAC/SPI = 219
IEEE 1058 – the software project management plan (SPMP) document• Standard for communicating a software
project plan
5. Managerial process plan
• Project startup: estimation, staffing and HR, training• Project work plan: work activities, resource allocation
and budget• Project control plan: methods and tools to control
schedule, budget, quality, reporting and metrics collection
• Risk management plan: identification, assessment, prioritization, monitoring, controlling, mitigation.
• Project closeout; analysis of metrics, assessment of success
6. Technical process plan• Process model plan– Life cycle model to follow; activities, methods,
techniques, tools and deliverables• Infrastructure plan– Project development environment– Procedures, policies, standards and facilities needed
to operate and maintain the environment• Product acceptance plan– Criteria for accepting the product by the client– Tools and methods used to verify these criteria
7. Supporting plans
• SCM plan (chapter 9)• Verification and validation plan• Documentation plan• Reviews and audit plans• Subcontractor management plan• Process improvement and metrics collection plans
8. Additional plans
• Safety plan• Installation and deployment plan• User training plan• Integration plan• Conversion and transition plan• Maintenance and support plan