1. Chapter 3: Project Management

2. Objectives Become familiar with estimation.
Be able to create a project work plan.
Understand why project teams use timeboxing.
Become familiar with how to staff a project.
Understand how computer-aided software engineering (CASE), standards, and documentation improve the efficiency of a project.
Understand how to reduce risk on a project.

3. Project Management Concerns

4. Project Management
The discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives
Cost
Schedule
Performance
PM is concerned with activities involved in ensuring that software is delivered on time and on schedule, and in accordance with the requirements of the organizations developing and procuring the software.
PMis needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software

5. PM Activities evolve over Phases
Inception
Elaboration
Construction
Transition

6. PM Artifacts in UP Software development plan Business case
Detailed plan for each iteration
Assessment of each iteration
Periodic status assessment
Work schedule
Project measurement database

7. PM in Inception Phase Conceive new project
Preliminary business case
Identify some risk, begin assessment
Evaluate project scope and risk
More detailed development of business case and risk assessment

8. Identifying Project Size

9. Cost Schedule Performance Trade-offs
Project management involves balancing trade-offs among the three key project parameters
Project
cheaper
better
These goals are always in tension. Good management involves compromise -- a creative balance between conflicting considerations.
You can have make it cheaper and better, but it will take longer, cheaper and sooner, but the quality will be lower, or better and sooner, but the cost will be higher. Of these three, quality tends to be at a political and economic disadvantage, because the effects of low quality are often not felt so immediately as high cost or delay in delivery.
sooner
Schedule
Quality/Performance

10. Estimating Project Timeframes

11. Function Point Approach
Estimate System Size
(function points and lines of code)
Estimate Effort Required
(person-months)
Estimate Time Required
(months)

12. Getting the Right Numbers for Estimation
Prior projects
Past experience
Industry standards
Detailed analysis
Estimation is usually done by the most experienced software developers. They have the past experience and often know the industry standards.

13. Estimation Guidelines
Estimate using at least two techniques
Get estimates from independent sources
Avoid over-optimism; assume difficulties
When you have arrived at an estimate, sleep on it
Adjust for the people who'll be doing the job -- they have the highest impact

14. Estimation Trade-offs
Size
Function points
Lines of code
Effort
Person-months
People available
Time
Months
Once you have used function points, LOC, or guesses to estimate the size the effort can be calculated in person months. But everyone may not be available when you need them so making a monthly schedule is needed to determine the amount of elasped time required for the project.

15. Calculate Function Points
List major elements of system
Determine total number of each element
Specify complexity index of each component (low, med., high)
Total index multiplied by number of components (TUFP)
These are the steps in calculating FP

16. Function Point Estimation : Step One
Complexity
Description Low Medium High Total
Inputs __x 3 __x 4 __x 6 ____
Outputs __x 4 __x 5 __x 7 ____
Queries __x 3 __x 4 __x 6 ____
Files __x 7 __x 10 __x 15 ____
Program __x 5 __x 7 __x 10 ____
Interfaces
TOTAL UNADJUSTED FUNCTION POINTS
Here we are simply listing the number of unique inputs, outputs, queries, file or database tables, and program interfaces.
This is certainly just an estimate. You do not really know yes since you may not have done enough analysis. Program interfaces are those things where you must communicate with another entity such another system. You will then need to place each of the them in a category. Some organizations have a standard they use for FPA calculations on what constitutes a low, medium and high element. But without one I usually use the 10/20 rule. If an input, output, query, file or table has 10 to 20 attributes it is a medium. For program interfaces, if the program interface has a supplied interface then it is simple, if I have to code to integrate to the interface then it is a medium and if I have to code the communication then it is high.

17. TUPF Example
Now you can calculate the TUPF using the numbers of elements you have in each category and the supplied value for that category.

18. Adjusted Processing Complexity -- Step 2
In this next step you have to adjust your TUFP by time consuming characteristics of a system. Some managers simply have an index of the types of systems they are developing and know what the complexity factor will be. They then use that to multiply the TUFP. The complexity factor can range anywhere from .65 to 1.4 for the most complex system. If you use the complexity items, they are evaluated on a scale of 1..5 where 5 indicates more complex system characteristics. Data communications deals with if you have to write or write interfaces for some of your data communications software for your own system. It does not include just using data communications. Heavy use configuration deals with having software that must run with peak times and heavy users so the code may need to be tuned. Transaction rate deals with if you are having heavy traffic also causing you to perhaps tune the transactions you send, database updates, or code efficiency. End user efficiency has to do with if particular characteristics have to be added to increase the efficiency. Complex processing has to do with writing code that is very difficult to write such as real time code, scheduling code, code with heavy state machines, etc. Installation ease may cause you to have to write extra programs to make the installation go smoothly at each location or at even one location. Multiple sites require a configuration management making sure all systems are on the same page. Performance may cause you to have to rewrite portions of your software to obtain the specified performance rate. If functions are distributed, this causes you to have to assure all functions are in sync at various sites and perhaps to write particular software for heterogeneous environments. Online data entry requires editing, help notes, that cause writing software to take more time. Online updates of transactions require the software to be very reliable and the database to be well tuned to assure performance does not degrade and efficiency is not lost. Operational ease also may take more time. Having software that is adaptable to new environments, also takes time.

19. Function Points Estimation : Step Four
Adjusted Project Complexity
= (0.01 * Project Complexity)
Total Adjusted Function Points =
Adjusted Project Complexity * TUFP
After summing up the project complexity it is multiplies by 0.01 and added to .065 (the lowest number). This gives you the adjusted project complexity that is multiplied by the TUFP to yield the adjusted function points

20. Function Point Estimation
Processing Complexity (PC): __7______
(From Step 2)
Adjusted Processing
Complexity (PCA) = (0.001 * __7_ )
Total Adjusted
Function Points: _0.72 * _338_ = 243
(TUFP -- From Step 1)

21. Converting Function Points to Lines of Code
Language
LOC/Function Code Point C
COBOL
JAVA
C++
Turbo Pascal
Visual Basic
PowerBuilder
HTML
Packages
(e.g., Access, Excel)
130
110 55 50 30 15
10-40
The table shows the approximately number of LOC per function point. You can calculate the LOC from this table from the adjusted function points.
Source: Capers Jones, Software Productivity Research

22. Final Step Multiply function points
Approximate lines of code per function point in the chosen language
If you chose C, then 243 function Points times 130 lines of code = 31,590 total lines of code

23. Estimating Effort Function of size and production rate COCOMO model
converts a lines-of-code estimate into a person-month estimate
For moderate-size projects multiply thousands of lines of code by 1.4 to get the number of people to assign to the project
Now you have the LOC in thousands. Multiply it by 1.4 to get the man months needed to do the project

24. COCOMO Estimation Calculation
Effort = 1.4 * thousands-of-
(in Person- lines-of-code
Months)
Example:
If LOC = Then...
Effort = (1.4 * 2000) = Person Months
Now this does not mean that 28 people can do this project in 1 month. Some things take elasped time. The knowledge of that elasped time is also important. Experience shows us how many people can do this project.

25. Estimating Schedule Time
Rule of thumb for estimation
Schedule Time (months) =
3.0 * person-months1/3
One rule of thumb, if you do not have the experience is to multiple 3.0 times the person months to get the schedule time

26. Estimation Guidelines
Estimate using at least two techniques
Get estimates from independent sources
Avoid over-optimism; assume difficulties
When you have arrived at an estimate, sleep on it
Adjust for the people who will be doing the job; they have the highest impact

27. Reconsider Buy/Build Decision

28. Creating and Managing the Workplan

29. Developing Work Plans
A work plan, is a dynamic schedule that records and keeps track of all tasks to be accomplished over the course of the project
Created after a project manager has a general idea of the project’s size and rough schedule
The work plan is usually the main item in a project management software application

30. Developing a WorkPlan Identify tasks in the project
Estimate task length
Determine task dependencies
Specify to whom task will be assigned
List deliverables
Once a general estimate is make for the project, the manager creates a project plan. It list the important tasks that must be done in the project. The level of deail for this plan depends of what is needed. Generally there is a high level general plan then the next week or month is done in more detail. Above are the steps done to develop a work plan. There are two methods of creating a work plan. It can be by product or by phases in the SDLC. If it is by phases, then you would see tasks related to the steps of the software development process (in our case UP). If it is by product, then the workplan would include items such as create product 1, product 2,etc.

31. A Workplan Example Work Plan Information Example
Name of task Perform economic feasibility
Start date ` Jan 05, 2001
Completion date Jan 19, 2001
Person assigned Mary Smith, sponsor
Deliverable(s) Cost-benefit analysis
Completion status Open
Priority High
Resources needed Spreadsheet
Estimated time 16 hours
Actual time hours
Here is an example of some workplan information

32. Identifying Tasks Top-down approach Methodology
Identify highest level tasks
Break them into increasingly smaller units
Methodology
Using standard list of tasks

33. Work Breakdown Structure
Specify high level tasks
Break down each step into smaller tasks and number them in a hierarchical fashion
WBS can be done in two ways
SDLC phase
Product
If a project manager wishes to begin from scratch and not use the deliverables or tasks deliniated by the development process model (UP), then they simply begin with high level tasks, and break them down…..

34. Top Down Task Identification
Phases with
high level steps
Phases
Work Plan Deliverables Estimated Assigned
hours To *
Here is an example of the top down task identification.
You begin with the phases, then the phases with the high level steps of those phases, then tasks identified in the work plan. Usually deliverables are associated with the work plan tasks. Hours can be assigned to the tasks and assignments of personnel can be made.

35. Work Breakdown Structure

36. WBS Problems
They tend to be specific to the design of the information system being developed
Too many levels of detail too early on in the SDLC for large projects or too few for small projects.
Since they are project specific, they are very difficult to compare across projects.
WBS are used by business people but not as often by software developers unless mandated. Software engineers prefer to use perts and gantts.

37. Gantt Chart

38. Gantt Chart
The Gantt chart is a horizontal bar char showing the task planned for the project, obtained from the workplan. It displays it graphically so you can see how you are doing from a picture rather than text. You can create a Gantt from a spread sheet easily or use project management software if available. The Gantt chart include an ID which is simply a number for the task, the name of the task, the duration of the task (remember task can overlay one another if more people are on the project). The start and finish time. And most importantly the predecessor. The predecessor is a task that must be completed BEFORE this task can begin. A column can be given for the person(s) who are assigned to the project or the name can be out from the graphical display of the time required to do this project. In the right hand side there is a time table either weekly, monthly, quarterly, or yearly. The time table has the tasks drawn out so you can see what depends on what and who is assigned. This makes it VERY clear is one person gets behind what impact it has on the rest of the project. These charts should be visible. When I am a project manager they are pasted daily or weekly on my door so everyone can see. If someone comes in to talk about a delay, I stand outside my door and discuss this delay. In that way EVERYONE knows there is an issue with the plan.

39. Another Style of Gant Chart

42. For more examples, see http://www.ganttchart.com/Examples.html .

43. PERT Project Evaluation and Review Technique (PERT) US Navy, 1957
Systematic method of estimating project length, and monitoring progress
Uses systematic serialization algorithm based on
Dependences
Resource availability
Adds administrative oversight to critical paths
Critical path = sequence of tasks such that if any case on the CP is delayed so is the whole project
PERT charts are simply another way of graphically showing the tasks and their interrationships. While the Gantt is good for those working on the project, PERTS are better for upper level management. They show similar information as the Gantt. PERTS also allow you to define optimistic estimates and pessimistic estimates so you can see the range of time it may take you on the project.

44. PERT Estimation PERT uses three time stimates:
Optimistic, O
Most likely, M
Pessimistic, P
Time Estimate = O + 4 * M + P

45. Pert Chart Used to communicate task dependencies
Allows easier visualization of tasks on a critical path
It seems there are more than one form of PERT chart. In the classical form there is only one kind of node which represents completion of a work product or other milestone event, and the tasks are represented by edges. See, for example and
See for a short tutorial on PERT.

46. Another kind of PERT Chart
Observe the tasks (rectangles), the estimated task durations, the milestones (lozenges), the milestone deadlines, the task dependencies (edges), and the critical path.

47. Another Variation

48. And another

50. And another variant

51. PERT vs. Gantt

52. CONTROLLING AND DIRECTING THE PROJECT

53. Typical Margins of Error for Well-done Estimates
Phase Deliverable Cost (%) time (%)
Planning System Request
Project Plan
Analysis System Proposal
Design System Specification
Source: Boehm et al. (1995)
This table shows some typical margins of error for estimates to let you know how much fudge factor you may need on your project.

54. The Hurricane Model Time Project Stage
Beginning a project resembles a hurricane… it begins not too bad but can really rev up.

55. fig_03_09
fig_03_09

56. Evolutionary WBS organize in a standard manner across all projects
create in an incremental and iterative manner
first evolutionary WBS done with initial aspects of the project
Later on more details are added to the WBS.
Comparable to earlier projects based on cost and schedule estimation
A good way to use the WBS for software development is to organize a standard template for WBS based on the methodology. This helps us use them like perts and gantts.

57. Managing Scope Scope creep -- a major cause of development problems
JAD and prototyping
Formal change approval
Charging for changes
The smaller points here suggest some methods for limiting scope creep and
are worth pointing out to the students. The last in the list allows users to
make changes -- but adds to the costs that they must allocate to the project.

58. Scope Management
Scope creep happens when new requirements are added to the project after the original project scope was defined and “frozen.”

59. Timeboxing Steps Set the date for system delivery
Prioritize the functionality that needs to be included in the system
Build the core of the system (the functionality ranked as most important)
Postpone functionality that cannot be provided within the time frame
Deliver the system with core functionality
Repeat steps 3 through 5 to add refinements and enhancements

60. Project Risk A risk comprises three elements:
an undesirable event,
an estimate of the severity of the consequences of the event
a likelihood that the event will occur
The amount of risk a project is exposed to is a good measure of the viability of the project

61. Managing Risk

62. Classes of Risk
Direct risk that the manager can control to some extent
Indirect risk that the manager cannot influence
In managing a project the aim is to control risk so we try to avoid indirect risk where possible.

63. Risk Control Three strategies:
Risk avoidance - reorganize the project so you are not exposed to the risk
Risk transfer -find other stakeholders to share the risk
Risk acceptance - decide to live with the risk and to take the occurrence of the risk as a possible contingency to be taken account of in the planning process

64. Risk Acceptance Risk mitigation
Try to reduce the likelihood or the impact of a risk.
e.g. if we decide to choose a particular supplier for a component we can identify an alternative supplier with a similar product that could be used if the original supplier fails to deliver.
Contingency planning
Construct “what if” plans on the basis of the risk occurring

65. Risk Assessment - Overview
Do risk assessment
Take/plan actions to reduce risk
Revise assessment
Remember, Grady Booch, notied that projects mainly fail because the risk is not managed. To manage risk you first must assess your risk. This is typically done at the end of each phase if not more often. Then once risk are identified and their importance known, actions called risk mitigations must be done to reduce the risks. For example if the project is being done in Java and no more than a few of your staff is trained on Java…. Then do some training to reduce this risk and perhaps have the new people code some sample programs before you begin to further reduce the risk, or organize pair programming between experienced and notices to mitigate the risks. After the mitigation actions are done revise the assessment to see if the risk is still present.

66. Classic Mistakes Overly optimistic schedule
Failing to monitor schedule
Failing to update schedule
Adding people to a late project
Allowing requirements creep
Some of the common mistakes made by project managers are thinking they can do more than they actually can. Failing to monitor the schedule and recognize when things are going south. Failing to update the schedule so people are AWARE that the project is slipping. And finally adding people to a LATE project ONLY makes it later because the people who WERE working now hove to stop and tell the new folks where the bathroom is or how to get their ID, as well as all the things they already know about the system so the new person can be productive. etc…

67. Staffing the Project

68. Staffing Attributes
Staffing levels will change over a project’s lifetime
Adding staff may add more overhead than additional labor
Using teams of 8-10 reporting in a hierarchical structure can reduce complexity

69. Increasing Complexity with Larger Teams
Large projects do not necessarily get done faster with large teams. The communication between team members increases the more members you have. Management of large projects is done by partitioning systems into smaller more manageable systems or tasks.

70. Staffing the Project Determine average number of people needed
Divide total person-months of effort by the optimal schedule
Adding more people will not reduce schedule
Create a staffing plan
Roles required for the project
Reporting structure

71. Example Reporting Structures
Project Manager
Functional Lead
Analyst
Technical Lead
Programmer

72. Key Definitions
The staffing plan describes the kinds of people working on the project
The project charter describes the project’s objectives and rules
A functional lead manages a group of analysts
A technical lead oversees progress of programmers and technical staff members
Staffing a project is determining how many people should be assigned to the project at what time. It includes matching people’s skills with the tasks that need to be done in the project. The staffing plan tells how the people will be working on the project
The project charter, made up when the project was first created describes what the objectives of the project are and how and how the staffing should be generally done. A project charter is a deliverable defined by the Project Management Body of Knowledge (PMBOK). The functional lead manages the analysts and the technical lead oversees the IT staff. Analysts are not always technical analyst they may be business analysts. .

73. Motivation Use monetary rewards cautiously Use intrinsic rewards
Recognition
Achievement
The work itself
Responsibility
Advancement
Chance to learn new skills

74. Motivational Don’ts Assign unrealistic deadlines Ignore good efforts
Create a low-quality product
Give everyone on the project a raise
Make an important decision without the team’s input
Maintain poor working conditions

75. Conflict Avoidance Strategies
Clearly define roles and project plans
Make sure the team understands how the project is important to the organization
Develop detailed operating procedures and communicate these to the team members
Develop a project charter
Develop schedule commitments ahead of time
Forecast other priorities and their possible impact on project

76. Coordinating Project Activities

77. CASE Tools
Computer-Aided Software Engineering (CASE) tools automate some or all of the development process
Not a silver bullet, but advantages include:
Reduced maintenance costs
Improve software quality
Enforce discipline
Some project teams even use CASE to assess the magnitude of changes to the project

78. Standards Examples Formal rules for naming files
Forms indicating goals reached
Programming guidelines
Can you think of more examples?
The book lists a long set of examples on page 81. If you have a lot of students
with their books open, you might pass up spending time having the students
come up with examples. Otherwise, this is a valuable exercise.
You might also ask whether there are times when it is better NOT to use
standards.

79. Standards Types of Standards Example Documentation standards
The date and project name should appear as a header on all documentation.
Coding standards
All modules of code should include a header that lists the programmer, last date of update, and a short description of the purpose of the code.
Procedural standards
Report to project update meeting on Fridays at 3:30 PM.
All changes to a requirements document must be approved by the project manager.
Specification requirement standards
Name of program to be created
Description of the program’s purpose
User interface design standards
The tab order of the screen will move from top left to
bottom right.
Accelerator keys will be provided for all updatable fields.

80. Documentation Good documentation happens up front
Documentation that occurs only at the tail end of a project/phase is not very useful
Project binder(s) are best practices containing
All internal communications (e.g. minutes from status meetings)
Written standards
Letters to and from the business users
Deliverables from each task

81. Summary Project Management Identifying Project Size
Creating And Managing the Workplan
Staffing the Project
Coordinating Project Activities