1860 Module 6 Create the Project Schedule PDF
Document Details
Uploaded by FasterMistletoe
Tags
Summary
This document covers the high-level steps for creating a project schedule, including decomposing work packages into activities, determining dependencies, estimating durations, and allocating resources. It also describes different types of dependencies and how to estimate task durations, including using PERT method, and how to handle lead/lags. The document also highlights the importance of considering constraints and resource allocation.
Full Transcript
1. Start with the work packages from the WBS and decompose them into activities 2. Determine the order and dependencies for the activities 3. Estimate the duration for each activity 4. Estimate the type and number of resources required for each activity 5. Complete the schedule, ag...
1. Start with the work packages from the WBS and decompose them into activities 2. Determine the order and dependencies for the activities 3. Estimate the duration for each activity 4. Estimate the type and number of resources required for each activity 5. Complete the schedule, again chart, ensuring that all constraints are met and no over allocations of resources taking the activities from the previous page and sequencing them Finish-to-start (FS): logical relationship in which a successor activity cannot start until a predecessor activity has finished Finish to finish (FF): logical relationship in which a successor activity cannot finish until a predecessor activity has finished Start to start (SS): logical relationship in which a successor activity cannot start until a predecessor activity has started Start to finish (SF): logical relationship in which a successor activity cannot finish until a predecessor activity has started Different dependencies (activities) may have different precedent relationships ^ within work packages 1. E.g., inspector sign off before moving on 2. Check the electrical works before installing new lights 3. LCBO going on strike 4. Someone going on vacation 1. Comparing to similar projects 2. Asking the person doing the work 3. Start at the bottom of the activity list and calculate each task 4. You guestimate 5. Next page Ask ppl 3 estimates, best, worst, most likely - calculate the average PERT places more value on the ‘most likely’ - so you multiply the ‘most likely’ number first by 4, add the 3 estimates together, then divide by 6 Always look at the legend - top right square https://youtu.be/-TDh-5n90vk Box 1 - 0 days + 2 day duration = 2 early finish The 2 follows the 3 arrows and is the 1st box + the duration middle number = the next set of early finish The final number in the early finish becomes the start of the backward pass Float is the difference of the numbers between the forward & backward pass We do this because then when you delay one task, it will move the deadline of others Indicate the critical path in the predecessors column Only input duration - software will calculate start/end date The software will create the critical path for you This example was done in SmartSheet Lead - is when you can start another task before its finished if parts are ready Lag - is when you must wait, e.g., for feedback, before moving to the next task What can we sequence differently - what can we move around Crashing - adding more ppl to a task to make it go faster, or overtime There is more risk when you shorten projects high level scheduling steps to deliver value 1. Provides the high level direction for the development of the product 2. Contains new features or changes that the team gathers to achieve a specific outcome 3. Contains the features or changes that have been selected for a specific release 4. Contains the features or changes that have been selected for specific Sprint 5. The tasks required to complete the items in the Sprint backlog 6. The sum of all the product backlog items completed during a Sprint Least amount of effort or time to create to then be able to use as a demo and get feedback We need to be delivering value to the customer as quickly as possible Scrum is a time window that we do work The team needs to be self-organizing, self-planning, committed and gel together well The first monday is when the planning takes place team decides what can be done in sprint, based on the prioritized product backlog Daily scrums/stand-up meeting to discuss 1) what you worked on yesterday, 2) what you will work on today, 3) any issues ‘development work’ is just the work sprint review is when you give a demo to the customer retrospective is within the team and is a ‘lessons learned’ The client must say done to move on - they may want changes We welcome all feedback Epics are high level requirements - not very descriptive Breakdown into user stories that create features that customers want