MGT/437 Project Management Session #2 University of Phoenix 02/12/2004 Brian Smithson 02/12/2004 MGT/437 #2 -- Brian Smithson 1
Agenda Review/Questions Session content PMI project framework Project Knowledge Areas Process Groups Mapping Process Groups and Knowledge Areas Phoenix material Triple Constraint Project Scope Work Breakdown Structure (WBS) Task Sequencing Gantt Charts Risk Assessment Integrating Questions Review and preparation for #3 02/12/2004 MGT/437 #2 -- Brian Smithson 2
Review/Questions Individual assignment Learning Team Assignment Assigned Reading 02/12/2004 MGT/437 #2 -- Brian Smithson 3
PMI Project Framework Specific areas of knowledge applied to Processes results in Project Activities 02/12/2004 MGT/437 #2 -- Brian Smithson 4
Knowledge Areas PMI identifies nine project knowledge areas: 1. Integration Management 2. Scope Management 3. Time Management 4. Cost Management 5. Quality Management 6. Human Resource Management 7. Communications Management 8. Risk Management 9. Procurement Management Knowledge areas are employed in a variety of processes during the life of a project 02/12/2004 MGT/437 #2 -- Brian Smithson 5
Project processes PMI identifies five process groups 1. Initiating 2. Planning 3. Executing 4. Controlling 5. Closing Initiating and Closing occur serially, at the beginning and end of a project (or project phase) Planning, executing, and controlling occur as parallel, interactive activites A project may consist of multiple phases, each of which is composed all five process groups 02/12/2004 MGT/437 #2 -- Brian Smithson 6
Interaction between process groups Source: A Guide to the Project Management Body of Knowledge (PMBOK), 2000 Edition 02/12/2004 MGT/437 #2 -- Brian Smithson 7
Relative activity levels in each process group Source: A Guide to the Project Management Body of Knowledge (PMBOK), 2000 Edition 02/12/2004 MGT/437 #2 -- Brian Smithson 8
Process groups in project phases Source: A Guide to the Project Management Body of Knowledge (PMBOK), 2000 Edition 02/12/2004 MGT/437 #2 -- Brian Smithson 9
Mapping Process Groups and Knowledge Areas into activities Process group/ Knowledge area Initiating Planning Executing Controlling Closing Integration Management Project plan development Project plan execution Integrated change control Scope Management Initiation Scope planning Scope definition Scope verification Scope change control Time Management Activity definition Activity sequencing Activity duration estimating Schedule development Schedule control Cost Management Resource planning Cost estimating Cost budgeting Cost control Quality Management Quality planning Quality assurance Quality control Human Resources Management Organization planning Staff acquisition Team development Communications Management Communications planning Information distribution Performance reporting Administrative closure Risk Management Risk management planning Risk identification Risk analysis Risk reponse planning Risk monitoring and control Procurement Management Procurement planning Solicitation planning Solicitation Source selection Contract administration Contract closeout 02/12/2004 MGT/437 #2 -- Brian Smithson 10
Phoenix material... 02/12/2004 MGT/437 #2 -- Brian Smithson 11
Triple Constraint Time, Cost, Performance or... Schedule, Budget, Scope or... Time to Market, Investment, Features and Quality Customer Satisfaction $ 02/12/2004 MGT/437 #2 -- Brian Smithson 12
Trade-offs Less money = more time smaller scope Shorter time = more money smaller scope Larger scope = more money more time $ 02/12/2004 MGT/437 #2 -- Brian Smithson 13
Constrain, enhance, or accept? Decide what s a hard requirement, what s a beneficial enhancement, and what s acceptable to your particular project For example: Cost is fixed, therefore budget must be constrained Customer is sensitive to timing, therefore it would be beneficial to accelerate the schedule if possible Given a constrained budget and a possibility of shortening the schedule, the scope of the project may need to be reduced 02/12/2004 MGT/437 #2 -- Brian Smithson 14
Project Scope Project charter Strategic plans Executive directives Customer requirements Regulatory/legal requirements Competitive parity Market research New innovation Last year s model Internal/departmental goals... Project Scope 02/12/2004 MGT/437 #2 -- Brian Smithson 15
Components of scope Project objectives Deliverables Major milestones Technical and quality requirements Limitations 02/12/2004 MGT/437 #2 -- Brian Smithson 16
Importance of stakeholder buy-in Customer Performing organization Sponsor (financial) End users Society Others Internal External Project manager Team 02/12/2004 MGT/437 #2 -- Brian Smithson 17
Scope creep Usually small, or seemingly small, changes Made with good intentions Made without applying the change control process Can have significant impact on cost, schedule, quality... Sometimes that impact is indirect and not apparent when the change is made 02/12/2004 MGT/437 #2 -- Brian Smithson 18
Work Breakdown Structure (WBS) Starts with the complete project statement Breaks down into smaller and smaller work elements Lowest level is an executable work package Project Sub project Deliverable Sub deliverable Cost account Work package 02/12/2004 MGT/437 #2 -- Brian Smithson 19
WBS benefits Enumerates all work in a hierarchy Helps ensure that work is defined and understood at a consistent level of detail Provides a framework for tracking cost and performance of related work and rolling up those measures by functional area All WBS work packages must appear in the execution plan 02/12/2004 MGT/437 #2 -- Brian Smithson 20
WBS example 02/12/2004 MGT/437 #2 -- Brian Smithson 21
Process Breakdown Schedule (PBS) Used for projects that have less well defined outcomes and are more process oriented 02/12/2004 MGT/437 #2 -- Brian Smithson 22
Project Network and Task Sequencing Project networks are typically composed of nodes (tasks) and arrows (sequential relationships); this is called Activity on Node (AON) Another technique, Activity on Arrow (AOA), is less frequently used Tasks are put in sequence only when they have a predecessor-successor relationship Yes: framing before wallboard, wallboard before paint No: place order for wood, order wallboard, order paint 02/12/2004 MGT/437 #2 -- Brian Smithson 23
Types of sequential relationships Most often used: finish-to-start (FS) Task A must be finished before task B can start Others: use with some caution Start-to-start (SS): task B cannot start until task A starts Finish-to-finish (FF): task B must finish when task A finishes Start-to-finish (SF): task B must finish when task A starts 02/12/2004 MGT/437 #2 -- Brian Smithson 24
Lag time Lag time is used to modify sequential relationship with a time delay Example: Start-to-start with 5 day lag Task B can start 5 days after task A starts Again, use with caution Anything other than Finish-to-start relationships are often overlooked or misunderstood on schedules and should not be used except when necessary 02/12/2004 MGT/437 #2 -- Brian Smithson 25
Diagram construction basics Time moves from left to right However, it s not really drawn on a scale or timeline Example: Task D comes after Task A Task C comes after Tasks A and B Task A has no defined time relationship to Task B, even though they appear to be in a parallel relationship. Task A and Task B, with no predecessors, will be scheduled to be done as soon as possible Task A Task C Task B Task D 02/12/2004 MGT/437 #2 -- Brian Smithson 26
Milestones Milestones are defined as zero-length tasks They can be used for two purposes: Identifying critical junctures in the project, such as phase beginnings/endings or deliverable dates Acting as a collection point for the endpoints of a group of related tasks. For example: Completion of programming, content, and graphics work for a web site: collect their finishing points to represent the predecessor for web site integration. 02/12/2004 MGT/437 #2 -- Brian Smithson 27
Task sequencing steps 1. Enter (or import) tasks and project milestones 2. Establish sequential relationships for closely related tasks Program, test, integrate software code. Design, review, revise, approve kitchen remodel plans. 3. Establish interrelationships between task sequences. Insert dummy milestones to aid the process if necessary. 4. Enter any hard date constraints, such as project start date or committed finish date. Enter such dates on milestones only create a new milestone for the purpose if necessary. 02/12/2004 MGT/437 #2 -- Brian Smithson 28
Task duration estimating steps 1. Get estimates from people who are most knowledgeable and/or accountable for the execution of the tasks. Historical information, or judgment based on experience, may be needed to account for the estimator s optimism or sandbagging. 2. Enter durations in terms of resource unit hours (i.e. person-hours), not in terms of calendar duration. This makes it possible for you to add bodies when appropriate to reduce the calendar duration later. 3. Make sure you have buy-in from those responsible for performance of the work. 02/12/2004 MGT/437 #2 -- Brian Smithson 29
Steps to complete the schedule Normally, you would apply actual resources at this point. We ll cover that in another session. Once you have a project start date, tasks sequenced, resource-unit durations established, and resources assigned, you will have a complete schedule that shows calendar start/finish dates for each task and for the project as a whole. The end date will be in 2013. Management wanted it in 2004. 02/12/2004 MGT/437 #2 -- Brian Smithson 30
Slack time and critical path Looking at your schedule, some tasks will have slack time and some will not. Slack time is the amount of time that a task could be lengthened or delayed without effecting the end date of the project. This will be more clear when we look at it on a Gantt chart. There will be at least one sequence of tasks from project start to project end in which all of the tasks have zero slack time. This sequence of tasks is called the Critical Path. 02/12/2004 MGT/437 #2 -- Brian Smithson 31
Critical path analysis If you need to reduce the overall length of your project or you want to know which tasks to monitor most closely: Look at the critical path(s) in your schedule. Any reductions you can make that go beyond the total slack for the path will have diminishing returns, because a new critical path will have been created. 02/12/2004 MGT/437 #2 -- Brian Smithson 32
So show me one already! Critical path Milestones Parallel activities 02/12/2004 MGT/437 #2 -- Brian Smithson 33
Gantt Chart Shows tasks and milestones along a timeline Popular with senior management Bars represent tasks Solid bars with down arrows are task groups Arrows represent task relationships long horizontal lines indicate slack time 02/12/2004 MGT/437 #2 -- Brian Smithson 34
Risk assessment overview Identify risks as early as possible Assess their potential impact and probability of occurrence Prioritize accordingly Assessment matrix Ratio/range based on past projects Probability analysis (e.g. PERT) Plan your responses Avoidance: change the plan to eliminate the condition or to protect the project from impact Transference: shift the consequences to a third party Mitigation: reduce the probability and/or consequences Acceptance: develop a contingency plan Monitor and respond 02/12/2004 MGT/437 #2 -- Brian Smithson 35
The importance of risk planning 02/12/2004 MGT/437 #2 -- Brian Smithson 36
Program Evaluation Review Technique (PERT) Instead of a single task duration estimate, you generate three estimates: Optimistic Most likely Pessimistic Assume a statistical distribution, such as 20% optimistic, 50% most likely, 30% pessimistic Run computer simulations 02/12/2004 MGT/437 #2 -- Brian Smithson 37
Integrating Questions What are the differences among milestones, deliverables, objectives, and goals? What is the relationship between scope, schedule, and risk? What is the relationship between schedule, precedence, and network flow? 02/12/2004 MGT/437 #2 -- Brian Smithson 38
Closing Questions? Assignments See the Course Syllabus for assignments Individual: reading assignment NETg WBS assignment Learning team: task analysis, part 2 of the paper due See you next week! 02/12/2004 MGT/437 #2 -- Brian Smithson 39