How to plan the schedule and calculate costs for a project

From EG1004 Lab Manual
Jump to: navigation, search


Many projects fail for one of two reasons: They had no plan to execute and lost their way, or they didn't have a clear view of how much money was required, and ran out.

The first issue is a prerequisite for getting the second issue right. If we don't know how we're going to do something, it is impossible to estimate how much it's going to cost.


The first task for any project is to create a project schedule. This document is the key part of the project, and everything else will flow from it. By now, you should have done the EG1004 Skill Builder on Microsoft Project (probably the most widely used product of its type in industry) and actually produced a schedule.

Most people making a schedule are overwhelmed by the size of the project. Initially, most projects look almost impossible to plan. However, obviously technical professionals are successful in planning projects, so all we need to do is learn from them.

The biggest mistake most people make who are planning a schedule is that they don't take enough time thinking about the project. It's tempting just to charge in and start mapping out tasks. As they seem to make progress, they begin to get overwhelmed by the detail. At the other end of the spectrum, a planner has no idea where to start. It's likely you'll find yourself in one of these two situations.

In both cases, stop and think about what it is that you're trying to accomplish. Usually this is easily said (in the case of EG1004 it's in the project assignments), but you should take time to fully understand what this overall mission statement means. For Engineers, this step is called project analysis, and sometimes it can be a lengthy process. Summarizing this activity into a single word, it's "What?":

  • What's the mission?
  • What's required of us?
  • What are the performance specifications?
  • What else do we need to know?

Once you've answered these questions and others like them, you now know what you have to do. Now we get to "How":

  • How will we achieve the mission? (Our design)
  • How will we make the design? (What steps)

There are two ways to approach this problem, and most professionals use them both. The first approach is to think sequentially: What steps do I need to take to accomplish this task? What order do I do them in? What steps can be done in parallel? The second approach is to think hierarchically: What are the components of the overall task? What components do they have?

Technical professionals call the result of the hierarchical approach a Work Breakdown Structure. Most schedules reflect this Work Breakdown Structure, where the major tasks are the Summary Tasks, and their components are the Detail Tasks, using Microsoft Project nomenclature. It is not at all unusual for Summary Tasks to consist of components which are also Summary Tasks, and so on, with the Detail Tasks being at the bottom. For a large project, there can be dozens of levels and thousands of tasks. In EG1004, we use the semester-long project for practice since it doesn't have that much detail.

In planning, professionals will alternate between thinking hierarchically and sequentially. Usually, they use the hierarchical technique at the higher levels, and think more sequentially at the lower levels. However, even when thinking hierarchically, it frequently helps to think in terms of how you would do the major tasks to figure out what the subtasks should be.

The most common flaw in any schedule is lack of detail. If you have tasks that last a long period of time, e.g., weeks, it is almost impossible to come up with an estimate – the task is just too big and too abstract.

We can resolve this by using a "divide and conquer" approach. We'll break down the big task into smaller tasks, and keep doing this until we have tasks that each last only several days. When we get a task this small we're much more comfortable in estimating the time to do it. You can still keep the big task if you want by making it a summary task of these detailed tasks. You can do this by using the task indent and outdent icons.

EG1004 Project Schedule

An EG1004 project lasts about 10 weeks. Using the guidelines in the preceding paragraph, this means the schedule should have AT LEAST 20 detailed tasks. Next, we can aggregate the detail tasks into summary tasks that identify the overall effort involved. For this size of project, there would be probably at least 3 summary tasks. Finally, we add the project milestones and due date, all as milestones (events with zero time).

In checking your schedule, make sure that you have the milestones that occur during the term. These will be contained in the course syllabus, and there are usually four of them. Check what's required for each milestone, and that you've included the tasks necessary to complete these requirements.


One very important component of the project is to accurately estimate costs. As business people, if we misestimate costs, the results are usually catastrophic. If we consistently estimate too high, we'll price ourselves out of the market and end up going out of business. If we consistently estimate too low, we'll lose money and go out of business. This means we have to make estimates that will allow us to make a profit, but still be competitive.

The EG1004 projects are designed to give you a feeling for what it's like to produce a product. At various points in the project we have different roles, acting as development engineers for most of the term building the prototype, marketing people in doing the final presentation, and manufacturing engineers in planning on how to produce our product in volume. In all these roles we worry about cost to insure that we stay in business.

Labor Rates

You'll be seeing a lecture later in the term about project planning and control, including how to estimate and track costs. One aspect of the presentation is about labor rates. For the purposes of starting the project, you should use a "fully burdened" labor rate (definition of this will be at the lecture), which you can estimate at $50 per hour.

Prototype Labor Hours

The second part of the labor costs is how many hours are needed to produce the product. For an engineer, this can be extremely challenging, but we have tools to help us. When we do the project schedule, we assign "resources" to do the tasks. For the project, it's typically the names of the team members working on that task. You can also put a percentage of time that "resource" will be working on the task. For example, assuming an eight hour day, if you plan to work on that task two hours each day, you'd be working 25% of the time on that task. That is the percentage you can put on your schedule. If you do this for all the detail tasks on the schedule you'll have the total number of hours the various "resources" work on the project.

The Prototype Labor Estimate

You now have an estimated labor rate for each resource, and estimated labor hours for each resource. If you multiply the rate by the hours, you'll get the total cost for that resource to work on the project. Add up all the resources, and you have the total labor cost for the project. You can also get this information off the "Project Summary" window for the project.

Production Labor Hours

Next, you'll have to estimate how many hours it would take to build a production unit. You can usually use your prototype schedule and labor hours to deduce this. All the design tasks can be ignored, and you only have to count the hours used to actually build the prototype. This number is your production labor hours

Production Labor Estimate

Like the prototype, you can now multiply the production labor hour estimate by the labor rate to arrive at a production labor estimate.


The next stop in planning for production is materials. Usually this is easy since you have done a cost estimate for your prototype using the cost data supplied to you. You should review your materials list again and see if anything can be omitted to save money. This will give you materials cost for each unit of production.

Total Prototype Cost

You can now take the materials needed to make the prototype and the prototype labor estimate, and add them up to get a total prototype cost. This is the number we want you to present at each of the milestones as well as the final presentation.

Total Production Cost

When we're producing a quantity of units, we need to include several factors in coming to a unit price that will allow us to make money and stay in business:

  1. Recovering our unit production costs. This includes the material costs described above, plus the production labor estimate also given above.
  2. Recovering our prototype costs. We spent money making the prototype, and we'll get that money back by including that cost in the production units. Take the total prototype cost you found above, and divide it by the expected production run. Typically 100 units for the project. This is the "tax" on each production unit so you can recover your prototype costs.
  3. Profit. So far we've covered our costs and won't go bankrupt, but nobody is going to want to invest money in a company that doesn't reward them with a profit for the risk they took. Also, you won't win every project you do, so you need profit from the other projects to cover your costs on the project you lose. Profit can be very subjective. Obviously, if you are making a product that is extremely attractive and customers want badly, you can charge a high profit margin (luxury cars and SUVs are examples of this). On the other hand, if you're in a "commodity" market with many competitors, cost is a major issue, and profits have to be razor thin (retail stores tend be examples of this). For the sake of the project and its high technical content, we can assume we can have a reasonable profit margin of about 10%.

Putting all this together, we'll now arrive at the total production cost. Add the unit production cost in Item 1 above to the prorated prototype cost in Item 2 to get overall cost. Add the 10% profit to this number and you have your total production cost.

Production Rate

The next thing to consider is how fast you would make your production line run. Each of the project specifications says to consider how you would produce 100 copies of your project. It would be very shortsighted to make all 100 at one time and then go out of business. It would be much more reasonable to assume some "period of performance", which is the time that you'd be making and delivering your production products. A typical period of performance might be six months or a year, depending on how urgent the customer's requirement is. For the sake of discussion, we'll assume that the period of performance is a year. This means you'll have to make 100 units in that year, or two a week.

Once you have this rate, you have to estimate the lead time it will take to get materials. You'll have to pay for the first few weeks of production before you make revenue from these units. However, once the line gets going you can use the revenue from the units shipped and billed to pay for the cost of more units. Finally, as the line is making the last few units there is no material cost, but you are collecting revenue. Finally, you'll be expending labor money the entire time the production line is running. When you put all these factors together, you can see that you'll be losing money at the beginning, and will move to breaking even and making money in the middle, and making a lot of money at the end (just before we go out of business). Presumably the influx of cash at the end of the production run will be used to fund your next project so you can stay in business. This cycle is called cash flow, where cash flows out in the beginning for material bills and paychecks, and flows in via revenue from the units built.


Being able to generate a realistic, usable schedule and calculate costs accurately is critical to any business person, including engineers. This article just scratches the surface of the issues involved, but should give you an appreciation for the considerations needed to go into business and stay in business.

Return to Table of Contents