340 likes | 567 Views
Project Management. November 26, 2012. Accounting. Macroeconomics. Engineering Economics. Operations Research Linear programming PERT/CPM Queueing Theory. Project Management Tools: Work breakdown structure: what there is to do Gantt Chart: times to do things
E N D
Project Management November 26, 2012
Accounting Macroeconomics Engineering Economics Operations Research Linear programming PERT/CPM Queueing Theory
Project Management Tools: Work breakdown structure: what there is to do Gantt Chart: times to do things Critical Path Method: dependencies; time/cost trade-offs
Work breakdown structure: what there is to do E.g., “Prepare beans on toast”
Prepare Beans on Toast Prepare Beans Prepare Toast Combine Open Can Slice bread Place Beans in saucepan Place bread in toaster Place Saucepan on stove Depress toaster button Light stove Remove toast from toaster Stir beans till warm Butter the toast
WBS activities should be mutually exclusive and collectively exhaustive The WBS allows us to calculate total project cost and personnel requirements It can include time estimates for each activity, but it doesn’t, by itself, allow us to calculate project duration.
CPM: Two conventions Can Open Heat Beans Beans Ready Open Can Beans onto toast Beans on Toast Ready Start AOA Bread cut Toast Ready Dummy Slice bread Toast Bread Open Can Heat Beans AON Beans onto toast End Start Slice bread Toast bread
Finding the critical path Open Can T: ES: EF: LS: LF: Heat Beans T: ES: EF: LS: LF: Beans onto toast T: ES: EF: LS: LF: Start End Slice bread T: ES: EF: LS: LF: Toast bread T: ES: EF: LS: LF: Add notation: “T” = time, “ES” = Earliest Start, “EF” = Earliest Finish “LS” = Latest Start, “LF” = Latest Finish
Finding the critical path Open Can T: 1:00 ES: EF: LS: LF: Heat Beans T: 5:00 ES: EF: LS: LF: Beans onto toast T: 1:00 ES: EF: LS: LF: Start End Slice bread T:1:00 ES: EF: LS: LF: Toast bread T:3:00 ES: EF: LS: LF: Fill in the times.
Finding the critical path Open Can T: 1:00 ES:0 EF:1 LS: LF: Heat Beans T: 5:00 ES: EF: LS: LF: Beans onto toast T: 1:00 ES: EF: LS: LF: Start End Slice bread T:1:00 ES: 0 EF:1 LS: LF: Toast bread T:3:00 ES: EF: LS: LF: ES for the first activity is zero, EF is ES + T
Finding the critical path Open Can T: 1:00 ES:0 EF:1 LS: LF: Heat Beans T: 5:00 ES:1 EF:6 LS: LF: Beans onto toast T: 1:00 ES:6 EF:7 LS: LF: Start End Slice bread T:1:00 ES: 0 EF:1 LS: LF: Toast bread T:3:00 ES:1 EF:4 LS: LF: For subsequent activities, ES is max(EF of all upstream activities), EF is ES + T
Finding the critical path Open Can T: 1:00 ES:0 EF:1 LS: LF: Heat Beans T: 5:00 ES:1 EF:6 LS: LF: Beans onto toast T: 1:00 ES:6 EF:7 LS: LF: Start End Slice bread T:1:00 ES: 0 EF:1 LS: LF: Toast bread T:3:00 ES:1 EF:4 LS: LF: For subsequent activities, ES is max(EF of all upstream activities), EF is ES + T
Finding the critical path Open Can T: 1:00 ES:0 EF:1 LS: LF: Heat Beans T: 5:00 ES:1 EF:6 LS: LF: Beans onto toast T: 1:00 ES:6 EF:7 LS: LF:7 Start End Slice bread T:1:00 ES: 0 EF:1 LS: LF: Toast bread T:3:00 ES:1 EF:4 LS: LF: The earliest finish of the final activity is also the latest acceptable finish for the final activity, assuming we don’t want the project completion to be delayed.
Finding the critical path Open Can T: 1:00 ES:0 EF:1 LS:0 LF:1 Heat Beans T: 5:00 ES:1 EF:6 LS:1 LF:6 Beans onto toast T: 1:00 ES:6 EF:7 LS:6 LF:7 Start End Slice bread T:1:00 ES: 0 EF:1 LS: 2 LF: 3 Toast bread T:3:00 ES:1 EF:4 LS:3 LF: 6 Then we do a second, backwards, pass through the network, where for each node, LF is min(LS of all downstream nodes) and LS is LF - T
Finding the critical path Open Can T: 1:00 ES:0 EF:1 LS:0 LF:1 Heat Beans T: 5:00 ES:1 EF:6 LS:1 LF:6 Beans onto toast T: 1:00 ES:6 EF:7 LS:6 LF:7 Start End Slice bread T:1:00 ES: 0 EF:1 LS: 2 LF: 3 Toast bread T:3:00 ES:1 EF:4 LS:3 LF: 6 Slack = 2 Slack = 2 The difference between EF and LF for a node is the slack for that activity
Finding the critical path Open Can T: 1:00 ES:0 EF:1 LS:0 LF:1 Heat Beans T: 5:00 ES:1 EF:6 LS:1 LF:6 Beans onto toast T: 1:00 ES:6 EF:7 LS:6 LF:7 Start End Slice bread T:1:00 ES: 0 EF:1 LS: 2 LF: 3 Toast bread T:3:00 ES:1 EF:4 LS:3 LF: 6 Slack = 2 Slack = 2 Activities with no slack are on the critical path
Crashing a Project Crashing an activity means spending more money in order to get it done faster (Important note: This doesn’t always work – see Brooks, “The Mythical Man-Month”) It’s obviously a waste of money to crash any activity that has slack.
Crashing a Project • Assume linearity: Crash cost – normal cost Crash cost/ unit time = Normal Time –Crash Time 2. Find minimum crash cost/unit time on the critical path 3. Reduce time as much as possible 4. Repeat
You own a start-up software company. You and your colleagues are planning the launch of a new computer. “Before we can start designing the Mark II, we need to complete three steps: there’s the market research, which will take about six weeks, there’s about five weeks of technical research needed to identify the best chip set, and meanwhile we’re going to have to raise capital to pay for all of this – we should allow four weeks for that. The good news is that all those activities can go on independently. When they’re all complete, we’ve reached Milestone 1 and we can start working on the hardware and software.” “That’s a dependency – we can’t write the software till we’ve got a machine to run it on.” “There’s a way round that: we can emulate the Mark II on a Mark I machine. It won’t run as fast, but we can use it for debugging. So we can develop the pre-prototype hardware, which should take about twelve weeks, and write software on an emulated machine at the same time – we should be able to get that done in ten weeks. Once both those things are done, we’re at Milestone 2.” “Once the pre-prototype hardware is done, we can adapt the software to run on it. That will take another twelve weeks. Meanwhile our hardware engineers can build the prototype Mark II. That’s going to be the longest step in the whole process – we’ll allow twenty-four weeks for that. And once those two steps are complete, we’re at Milestone 3.”
“Once we’re past Milestone 3, there’s a lot of things we can get started on. We can start designing the production version of the Mark II, and at the same time design the production tooling. Both those steps should take about sixteen weeks. We’ll also be in a position to release guidelines to applications developers, inside and outside the company. We can expect the first applications to be ready within twenty weeks, ideally just as the Mark II is put on the market.” “Milestone 3 is also the point at which we can start adapting the software to the prototype machine. Let’s allow eighteen weeks for that. ” “So when the production tooling and the production version of the Mark II are complete, and assuming the software for the prototype machine is ready by that time, we’ve at Milestone 4. Then all we’ve got to do is design the hardware packaging – call that a six-week job – adapt the software to the production version of the machine – allow twelve weeks for that – once the software is complete, we package that too, which shouldn’t take more than four weeks – and, as long as the applications developers are on schedule, we can put the machine on the market.” Represent the project as a Gantt chart, and calculate the earliest possible finish date.
2. Represent the project using both an AOA and an AON network diagram. Note that it may be useful to use `dummy arcs’ to represent the dependencies between some activities 3. Using the AON diagram developed in 2, perform a critical path analysis and complete a table showing the slack for each activity.
First, the Activity-on-Arc representation. The arcs are labelled according to the table below. We use dummy arcs, indicated by grey lines, to indicate that one activity cannot begin before others are completed. The milestones correspond to the nodes labelled `M’.
We next construct the AON network. This time we’ll use square nodes, and provide them with labels ready for a CPM analysis.
We can now begin the CPM analysis. We start going through the diagram, filling in the earliest start times. We define the earliest we can start as time 0, so this goes into the first row of boxes. Then we add the duration times to get the earliest each activity can finish. When we get to the second row of boxes, we apply the rule that the earliest an activity can start is the latest that any of the activities it depends upon can finish. All of the boxes in the second row depend on all of the boxes in the first row, so the earliest any of them can start is 6 weeks into the project.
We carry on in this way till we get to the bottom of the diagram, where we find that the earliest we can finish the project is in 76 weeks, the same answer as we got from the Gantt diagram. Then we start working our way back up the diagram, this time using the rule that the latest any activity can finish is the latest that any of the activities that depend on it can start. This gives us the `LF’ entry, and the `LS’ entry is the value of the LF entry minus the activity duration. When we’re done, the diagram should look like this, where we’ve marked the critical activities in yellow and the critical path in red:
4. You discover that a rival company is planning to put out a product that will compete with the Mark II. Every week that you can shorten your time to market is worth $1 000 000 in increased sales. You know that each of the relevant activities can be shortened by a certain percentage, with per-week costs as follows: What is your most profitable strategy?
We begin by noting that the cheapest activity on the critical path that we can crash is Market Research. We can reduce this to 5 weeks at a cost of $200 000. At that point, Technical Research comes onto the critical path, and this activity isn’t crashable.Packaging Software can also be crashed at $200 000 per week, so we can reduce this activity by 2 weeks. After each step we update the diagram. It occurs to us that it would be relatively easy to represent the diagram on a spreadsheet which would update the entries automatically. The next cheapest activity to speed up is software development. We crash the Production Software activity to six weeks, at a cost of $400 000 per week. Now we look at the Prototype Software activity. We can crash this by two weeks, and at that point Production Hardware comes onto the critical path. Crashing both activities together would cost too much. The next step is to look at the Prototype Hardware activity. We can crash this by twelve weeks. Finally we can crash the Pre-prototype Hardware activity by two weeks, after which the Software on Emulated Machine activity comes onto the critical path. Although it is possible to crash the development further still, the cost of doing so would be greater than the expected return, so we stop at this point. The final schedule is shown in the diagram below.