Online Postgraduate Courses for the Electronics Industry

Provided By The University of Bolton

• Home
• About Us
• Questions & Answers
• Courses
• Students
• Links

Useful Tools

Project Management for Microelectronics

2.0 Task Types & Task Relationships

We have already loosely defined a project as a collection of tasks.

In this unit we shall consider tasks and their attributes in some detail. We shall also consider the relationship between tasks and how tasks should be specified when planning a project.

Finally we shall consider how tasks are defined in Microsoft Project.

Unit Contents

• 2.1 Task Attributes
• 2.2 Task Relationships
• 2.3 Estimating Task Durations
• 2.4 Task Contingency
• 2.5 A Simple Network Diagram
• 2.6 Task Definitions in Microsoft Project
• 2.7 Task Constraints
• Exercises using Microsoft Project
• 2.8 Summary
• Suggested Reading

2.1 Task Attributes

A simple task is shown in Fig 2.1

Fig2.1

 

The task has a task identifier (in this case the task name), the estimated task duration (10 days), a start and an end node. These are examples of task attributes.

We shall now consider several task attributes, some of which have an obvious meaning and some that will need some explanation.

Task attributes are listed below:

1. The task identifier
2. The estimated task duration
3. The task start date - we shall deal in dates which are specific
4. The task completion (end) date
5. Task costs - we shall develop task costs as the module progresses
6. Task resources
7. Task contingency
8. Task risk
9. Task type - as specified in Microsoft Project

1. Task identifiers may include the task name, the task number and the task work breakdown structure code. MSP automatically assigns a task number to every task and the user, of course, defines the task name. We shall say more about work breakdown structures in a later unit.

2. Task duration may be defined in a variety of units such as minutes, hours, days weeks etc. In general we will use days as our unit of time, unless stated otherwise.

3 & 4. Tasks will be defined by start dates and end dates - not terms like the start of week 6, the end of May etc. Dates are specific and we want to communicate with people on the project in an unambiguous manner.

5. As above

6. Task resources will include people, materials, equipment and space. etc. Resources must be allocated to tasks during the planning phase of a project. Resources and their allocation will be dealt with in unit 3.

7. Task contingency is an important concept - it means we shall first estimate the "best" duration of a task and then make an allowance for things that might go wrong, so the task will have two estimated durations, the best and the worst estimate. We shall discuss contingency in more detail in section 1.5 of this unit.

8. Task risk is another important attribute: we shall discuss this in depth in unit 4.

9. Microsoft Project defines three task types, fixed unit, fixed work and fixed duration. It is important to understand the difference between these types and they are explained section 2.6 of this unit.

---------------------------------------------

We have really introduced the above task attributes in the context of project planning. However, once a project is underway some task attributes take on a new meaning. For example, estimated task duration will be replaced by actual task duration, estimated task cost will be replaced by actual task cost etc. Consequently the effort expended in project "house keeping" increases dramatically.

A project concerned with the development of a new ASIC based product may have 60 tasks, say, and each task has about 8 "estimated" and 8 "actual" attributes associated with it. In addition, as the project progresses, task attributes have to be monitored. All this means that the amount of work in planning, implementing and monitoring a project is extensive.

Until relatively inexpensive and effective software became available (such as MSP), project management, even for a single project was a daunting proposition.

[back to top]

2.2 Task Relationships

A project consists of a number of tasks, as illustrated in Fig. 2.2

Fig 2.2 A simple project

 

In Fig 2.2 time is assumed to flow from left to right. It is implied that task T1 must be completed before task T2 can be started, task T2 must be completed before task T3 can be started and task T3 must be completed before T4 can be started. Only when all the tasks are completed is the project completed.

The start end and end nodes can be thought of as special dummy tasks that take no time and have zero resources allocated to them etc. We shall call these tasks milestones. Milestones are important points in a project. In the above diagram the the start and end nodes are milestones.

Fig 2.2 is an example of a simple project network. We will make extensive use of network diagrams to illustrate concepts and principles.

Considering task T2 in Fig 2.2, T1 is called the immediate predecessor of Task 1, T2 is the immediate predecessor of T3 etc, The milestone S is the immediate predecessor of T1. It is a little surprising that if all the immediate predecessors of tasks in a project are known it is possible to draw the complete network diagram for the project.

Sometimes projects are planned from end to start. For example an exhibition that runs on a specified date may best be planned from end to start. In this case we consider the immediate successors of tasks- T4 is the immediate successor of T3, T3 is the immediate successor of T2 etc.

Fig 2.3 shows a more complex project.

Fig 2.3 A Simple Project with Concurrent Tasks

 

In Fig 2.3 T1 is the immediate predecessor of T2 and T5, and T3 and T6 are the immediate predecessors of T4.

T5 and T6 are carried out concurrently with T2 and T3. This is also called simultaneous engineering or parallel engineering.

Simultaneous engineering allows the project to be completed in a shorter time than if all the tasks are carried out serially.

Unfortunately simultaneous engineering carries more risk than serial engineering. For example, if T2 involves electronic hardware design and T5 involves the case design of a product, it may transpire that there is not enough room in the case for the hardware. We shall assess such risks in later units.

Microsoft Project looks at task relationships in the way we have described, but it also includes additional types of task relationships as illustrated in Fig 2.4.

Fig 2.4 Illustrating Task Relationships

 

Finish to Start relationship. Task T2 starts when task T1 finishes.

Example: mount PCB components then solder PCB components. We cannot solder components until they have been mounted.

Start to Start relationship. T4 stars when T3 starts.

Example: Glue case cover to case base and cure glue. We cannot cure the glue until the parts have been glued together.

Finish to Finish relationship. T8 finishes when T7 finishes.

Example: Final Test and Pack Product- final test must be completed before we finish packing the product.

Start to Finish relationship. T5 cannot finish until T6 starts

This relationship is seldom used.

The above relationships, which are called task dependencies, often appear artificial until the concepts of task lead and lag time are introduced.

These are best illustrated with examples. Consider the the tasks "paint case" then "fix display to case".

We could use a start to start dependency for the tasks but include a lag to allow the paint to dry before we fix the display to the case. This is illustrated in Fig. 2.5.

Fig 2.5 Illustrating Lag Time with a Start to Start Dependency

 

T3 represents the "paint case" task and T4 represents the "fix display to case" task. The 1d forces a 1 day delay for the paint to dry before the display can be fitted to the case.

Now consider lead time with a "finish to start" dependency. If lead time is used, the immediate successor to a task starts before its predecessor finishes. Consider the two tasks "Final Test" and "Pack Products". After several products have been tested, packing could commence so that testing and packing run concurrently. This is illustrated in Fig 2.6.

Fig 2.6 Lead Time with a Finish to Start Dependency

Task T1 represents "Final Test" and Task T2 represents "Packaging". The tasks have a "finish to start" dependency but a lead time of -9 hours has been included so that T2 starts 1 hour after T1 has started. Packaging is progressing as tested units become available. Note that lead times are entered as negative lags. The hours unit is specified by the letter h.

[back to top]

2.3 Estimating Task Durations

Estimating task durations is difficult and it seems that most people under-estimate task durations significantly.

Task durations can be:

• guessed
• "ball park" estimate
• estimated
• measured

2.3.1 Guessing

Guessing task durations is usually very dangerous and almost always leads to severe under estimates.

2.3.2 "Ball Park" estimate

A "ball park" estimate is an educated guess, for example if you have managed the development of several ASICs you should be able to give a "ball park" figure for the development time of another.

You should be very careful when giving "ball park" figures, people tend to ask for them in a hurry, frequently on the phone and once you have given them it is difficult to move away from them significantly. If you have given a "ball park" figure of 12 weeks for a task and it turns out to be 14 weeks when you plan it properly the new figure will probably be accepted. However if the planned figure turns out to 25 weeks it is unlikely that the new figure will be accepted without a great deal of explanation.

People do remember "ball park" figures when the estimated figures exceed them significantly. If you don't have the experience don't give a "ball park" estimate.

2.3.3 Estimating

Estimated durations are the result of some process and/or experience. For example if you were asked how long it would take to climb the Empire State building using the emergency stairs you could guess or you could estimate. The Empire State building is about 1000 ft high - the height of a step is about 10 inches, so their are about 1200 steps. If it takes 2 seconds to climb a step, the time taken to climb all the steps is 600 seconds. That is 10 minutes.

Obviously the person climbing the steps would need to be fit. Fire fighters might be interested in making this kind of estimate.

In the case of the development of a microelectronics based new product, how can we make the estimates and, who should make them?

The project manager would not normally make estimates of task durations in isolation. He/she should consult with people, or the type of people, who will carry out the task.

So the durations for developing electronic digital hardware should be estimated principally by electronic hardware engineers, preferably with some prior experience. We should compare the complexity and similarity of the new hardware with hardware we have developed in the past. We should be extra careful not to miss out important sub-tasks, like documentation, design validation, the parts list, EMC testing, etc.

If we keep a simple record of how the estimates were made it gives us the opportunity to incrementally improve our estimates in the future. We shall consider incremental improvement in the unit on Project Reviews.

Software is notoriously difficult to manage: software engineers are often way out in their estimates of task durations. Software engineers should be given a reasonable amount of time to make estimates and should be encouraged to document their estimates clearly. When the project is complete, the actual task times should be compared against the estimated times with a view to making improvements. It is important not to blame people for being out in their estimates but rather to encourage them to learn from the new information.

If you are presented with a task that is new to you and the people in your company, treat it with respect and try to find people outside your organisation that have experience of it and would be prepared to help you. For example, if you decided to ultrasonically weld a cover to a case, and you have no experience of the technique, you will find that suppliers of the ultrasonic welding equipment will probably be prepared to help you.

[back to top]

2.4 Task Contingency

In the previous section we considered estimating task durations. In a given project we are likely to find several tasks that we can estimate with confidence, whilst others will be more problematic. An attribute that we have not mentioned so far is task contingency.

We shall introduce the idea of a task contingency factor, CF, which is a number greater than or equal to one.

If we estimate a task duration to be 10 days and we assume a task contingency factor CF = 1.2, it means we expect the task to take between 10 and 12 days (10*1.2).

So for each task the task CF represents our degree of uncertainty in estimating its duration.

Even tasks we are very sure of should be given a small CF, say 1.1.

Tasks we are not experienced in carrying out should be given a large CF.

For example, a software task that involves a language we are not familiar with, or that has a performance specification such as execution time that is very demanding in comparison with software we have previously developed, should be assigned a high CF. A CF of 2 is not unreasonable and CFs as high as 3 are just about acceptable. If the CF exceeds 3, the task is very high risk. We shall say more about task risks in unit 4 and discuss how risk and contingency are related.

You may feel that a CF of 2 or 3 is unreasonable, but if you think of high profile projects, such as large civil engineering projects or military development projects, they often overrun by several years. If we had estimated one year to bore a tunnel and it takes two, the CF should have been 2.0. Note that overruns in time are accompanied by overruns in costs, roughly speaking twice the time means twice the cost. That is 1 year and £1 billion become 2 years and £2 billion pounds, which is not going to please your customer.

Contingencies should be made at task level, not for the project as a whole. Assigning contingencies at task level allows problem tasks to be identified and focused upon. If the majority of tasks have a high CF associated with them, it means the project is probably high risk and senior management may reject it at the proposal stage.

To assign a contingency factor to a task:

• make the best estimate for its duration
• check to see how similar it is to tasks carried out in the past
• if its similar, assign a low CF to it
• if its very different, assign a high CF to it
• use judgment for inbetween cases.

When making estimates of task durations and assigning CFs, use personal experience and the experience of relevant people in your organisation. In special cases, ask people external to the organisation.

[back to top]

2.5 A Simple Network Diagram

The network diagram for a simple project is shown in Fig 2.7.

Fig 2.7 A Simple Network Diagram

 

Note: numbering the task as shown will help when you carry out the exercises in this unit.

Task details for the network shown in Fig 2.7 are shown in Table 2.1.

The column labeled Task ID contains all the task names, T2, T3, etc. and the start nodes and finish nodes which are milestones. Note that milestones may be treated as dummy tasks of zero duration. We shall use such milestones frequently in MSP.

The predecessors means immediate predecessors, note that some tasks have more that one immediate predecessor.

The path through the network coloured red is called the critical path, this is the time it takes to complete the project. If any of the tasks on the critical path takes longer than estimated, the project will be completed later than planned. The project manager must identify the tasks on the critical path and monitor them carefully.

All the tasks in the network must be completed for the project to be completed. There are some types of tasks, such as recurring meetings, that terminate when when the project ends. We shall consider these in later units.

The cost of carrying out the project is the sum of the task costs.

Note that tasks off the critical path have an attribute called slack. For example, task T10, which has a duration of only 2 days, may be started when the project starts, or 2 days before T8 is due to end without affecting the project completion time.

The slack associated with task T10 is the duration of T2 + duration of T7 + Duration of T8 - duration of T10.

Slack is a valuable tool for the project manager. For example, if resources required to complete task T10 are required to complete task T7, T10 can be delayed until T7 is completed and the resources become available to carry out Task T10, without affecting the completion time of the project.

It should always be remembered that money is a resource- slack may be used to improve the cask flow of a project. Expensive tasks that are not on the critical path can be delayed.

It is possible to have more that one critical path and if we take advantage of the full slack for a task the path its on may become critical.

When a project is in progress the critical path may change if tasks off the critical path take longer than planned and/or tasks on the critical path are completed sooner than planned.

Microsoft Project works out the critical path for a project and also task slack, as well as a host of other task attributes and parameters, so we can concentrate on the management function.

[back to top]

2.6 Task Definitions in Microsoft Project

In addition to the task attributes and relationships we have considered so far, MSP also uses attributes and constraints that are particular to it. We shall now consider these briefly.

MSP uses the following scheduling formula for each task:

Task Duration * Units = Task Work

When you specify any two of the above variables MSP calculates the third.

• Task Duration
  This may be entered by the project planner in appropriate units.
• Units
  Units refers to the resources used on the task. For example, if the units are set to 2.0 it would mean two units of resource are used on the task. The most common unit of resource is people and if two people are used on a task it means the task units = 2.
• Task Work
  This is the actual real work associated with a task, so if it takes two people two days to complete a task, the task work is 2 * 2 = 4 people-days.
• However, in MSP "units" have no units. They may be expressed as a percentage or as a decimal number. Consequently, in MSP, work has the dimensions of time. In the above example, the task work is 4 days in MSP.

A task may be entered in MSP as Fixed Duration, Fixed Units or Fixed work. It is important to know the difference between these task types and, in particular, where to use them.

However, in order to use these task types they must have resources allocated to them. We shall be dealing with resources in the next unit and we shall see how to use fixed duration, fixed work and fixed units task then.

[back to top]

2.7 Task Constraints

Microsoft Project allows constraints to be assigned to tasks, such as "start no later than", "must finish on" etc. There are 8 constraint types and for each constraint type you must enter a date. In general constraints should be applied only where necessary so that MSP can be free to calculate task start and finish dates etc. Each time you enter a constraint you impose restrictions on MSP.

[back to top]

2.7 Summary

In this unit we have considered:

• Task Attributes
• Task Relationships
• Task Duration
• Task Contingency
• Network Diagrams
• Critical Path
• Slack
• MSP Task Types: FS, SS, FF, SF
• MSP Task Constraints: Start no later than, etc.

We recommend that you use this unit for reference purposes until you are familiar with all the task parameters and attributes and know when and where to apply them.

[back to top]

back to top]

[back to top]

Updated: 10/07/08 RA

Site Search

Powered by Google
Site Map