Hazard

q uestion na I re Application factors

• Will the package need to interface w ith other (existing) systems?

• Are there likely to he large differences between alternative packages?

Staff factors

• Do the stafT at the college have experience in evaluating or procuring packages of this type?

• Do the Brightmouth College staff have experience of using similar packages? Project methods

• Can we use standard methods for this project?

• Does the college have established procedures for this type of project?

Hardware factors

• Will the project involve the purchase of new hardware?

• Will we be able to test candidate packages on the same hardware configuration as we w ill be operating?

Changeover factors

• Can we run a pilot system before complete changeover?

• Will the master tiles be convertible from the existing system?

Supplier factors

• Have we experience of purchasing software/hardware from the likely suppliers?

• How well established are the suppliers we are considering? Environment factors

• Are there any plans for reorganization within the college that could affect the system?

• Are there likely to be any changes in government legislation that could affect the project?

7.2 Amanda*S risk The risks that you add will clearly depend upon the answers you gave to the prioritization previous exercise and you might feel that your assessment of likelihood and impact is somewhat arbitrary. It is best to work in a small group when trying to estimate these figures - where you disagree with your colleagues over a figure then discuss why this is so. I-or this exercise, the exact numbers that you decide on are not as important as recognizing why you might not agree with each other.

Categorizing risk exposures is discussed in the paragraphs following the exercise and. although your will have more risks than discussed there, you should look for sensible cut-off points along the lines discussed.

The following arc illustrative of the actions that Amanda might consider.

• Changes to requirements specification during coding. This risk could be reduced by ensuring the original specification agreed at a senior level and adopting a high change threshold.

• Specification takes longer than expected. Review time estimates or break the activity down into smaller components and estimate each of them. Draw up contingency plans for shortening critical activities later in the project.

• Staff sickness affecting critical activities. Check availability of suitable agency analysis and programmers.

• Staff sickness affecting non-critical activities. Draw up rota of stand-by staff who might be recruited from other projects.

• Module coding takes longer than expected. Scrutinize estimating procedures and compare estimates with similar past projects.

• Module testing demonstrates errors or deficiencies in design. Use more stringent methods to validate design - formal methods or structured walkthroughs could be appropriate.

Table F.IO shows the activity duration estimates from Table 7.3 along with the calculated expected durations. tr.

Table F. 10 Calculating expected activity durations

7.3 Amanda's risk reductions strategies

7.4 Calculating expected activity durations

Activity durations (weeks)

Activity

Optimistic (a) Most likely (m) Pessimistic (/>) Expected (/,)

7.5 The forward pass to calculate expected completion date

The expected duration and the expected dates for the other project events arc shown in Figure 7.3. An expected duration of 13.5 weeks means that we expect the project to be completed half way through week 14. although since this is only an expected value it could finish earlier or later.

7.6 Calculating standard deviations

The correct values are shown in Figure 7.4. Brief calculations for events 4 and 6 are given here.

Event 4: Path A + C has a standard dev iation of 0.50-'+ 0.1V) = 0.53 Path B + D has a standard deviation of V(0.33J+ 0.25:) = 0.41 Node 4 therefore has a standard deviation of 0.53.

Event 6: Path 4 + H has a standard deviation of V(0.53J+ 0.08;) = 0.54 Path 5 + G has a standard deviation of V( 1. 17:+ 0.33:) = 1.22 Node 6 therefore has a standard deviation of 1.22.

7.7 Calculating z values

The value for event 5 is .IP'** = -0.43. for event 6 it is Jj*'^ = 1.23

1.17

I 22

7.8 Obtaining probabilities

Kvent 4: 11k : value is 1.89 which equates to a probability of approximately 3%. There is therefore only a 3% chance that we w ill not achieve this event by the target date of the end of week 10. Kvent 5: The c value is -0.43 which equates to a probability of approximately 67%. There is therefore a 68% chance that we will not achieve this event by the target date of the end of week 10.

To calculate the probability of completing the project by week 14 we need to calculate a new z value for event 6 using a target date of 14. This new z value is

This equates to a probability of approximately 35%. This is the probability of not meeting the target date. The probability of meeting the target date is therefore 65% (100%-35%).

Chapter 8

Smooching analyst-designer demand for stage 4 is reasonably easy. The design of 8.1 Smoothing module D could be scheduled after the design of module C. Stage 2 is more resource demand problematic as scheduling the specification of module I) to start after the completion of B would delay the project. Amanda might consider doing this if whoever is specifying module A could also be allocated to module D for the last six days - although she may well decide that drafting an extra person in to a specification activity is unsatisfactory.

If the activities arc scheduled at the earliest dates, then the plan still calls for four 8.2 Drawing a analyst-designers as shown in F;igure F.8. By delaying the start of some activities, revised resource however, Amanda is able to ensure that using three analyst-designers are sufficient histogram except for a single day. This is shown in Figure F.9.

When activities are scheduled at their earliest start dates, the shaded area of each bar represents the activity's total float.

Week number

Spec»fy ovoran system

module A

I Specify module C

Check specifications Q Check specification C

Do&gn module A

Design module B

Oesi0n module C

Des^n module 0

*

}

4

*

*

7

14. JL

Figure F.8 Amanda \v revised Ixir chart and resource histogram.

Note that if the specification of module C were to be delayed for a further day, the project could be completed with only three analyst-designers, although its completion day would, of course, be delayed.

Once an activity is scheduled to start later than its earliest date, part of its total float will be used up* by that delay. The amount of total float that has been consumed in this way is indicated by the left hand portion of an activity's shaded bar.

Woe* numfry_

Spcoty overall system"

Spcoty overall system"

CtfeCfc Sp6CrftC£rti0fl Cl|

Check speofcatoosQ

CtfeCfc Sp6CrftC£rti0fl Cl|

Design module B

Des^n module C

Des^n module D

Design module B

Des^n module C

Des^n module D

Week numb*

Figure F.9 The effect of delaying some activity starts.

8.3 Identifying critical activities

The critical path is now as shown in Figure F.IO. Note the lag of 15 days against activity IoE/P/4, ensuring that its start is delayed until an analyst/designer is expected to be available.

However, the availability of an analyst/designer for IoH/P/4 is dependent upon IoE/P/3 or IoE/P/5 being completed on time - these two activities arc therefore also now critical in the sense that a delay in both of them would delay IoIi/P/4. which is on the normal critical path. These two activities, although not on the critical path, are, in that sense, critical.

8.4 Assigning staff Belinda must specify module B as she will then be available in time to start the to activities specification of module C. This leaves Daisy for the specification and design of module A. Belinda cannot do the design of module B as she w ill still be working on the module C specification when this needs to be done (6 days between days 56 and 66). This will have to be left to Tom, as he should be free on day 60.

Can you think of any other way in which she might have allocated the three team members to these activities?

Figure F.10 The critical activities after delaying the start of module C.

The easiest way to calculate the total cost is to set up a table similar to Table F. 11. 8.5 Calculating project costs

Table F. 11

Calculating the cost of Amanda's project

Analyst

Daily cost (£)

Days Required

Cost (£)

Amanda

300

110*

33.000

Belinda

250

50

12.500

Tom

175

25

4.375

Daisy

225

27

6.075

Gavin

150

30

4.500

Purdy

150

28

4.200

Justin

150

15

2.250

Spencer

150

25

3.750

Daily oncost

200

100

20.000

Total

90.650

• This includes 10 days for pcc-projcct planning and pot! project review.

• This includes 10 days for pcc-projcct planning and pot! project review.

Calculating the distribution of costs over the life of the project is best done as a per week or per month figure rather than as daily costs. The expenditure per week for Amanda's project is shown as a chart in Figure 8.9.

Chapter 9

9.1 Lines Of code as There are many reasons why the proportion of lines coded is not a good indicator a partial task completion indicator

9.2 Revising the timeline chart of completeness. In particular, you should have considered the following:

• the estimated total number of lines of code might be inaccurate:

• the lines of code so far w ritten might have been easier, or harder, to w rite than those to follow;

• a program is not generally considered complete until it has been tested - when 100% of its lines of code have been w ritten a program will still be incomplete until tested.

With more know ledge of w hat has been done and what is left to complete it might be possible to make a reasonable estimate of completeness. Breaking the development task into smaller sub-tasks such as software design, coding and unit testing might be of some assistance here.

At the end of week 8, the scheduled completion dates for drafting and issuing the tender need to be revised - note both need to be changed since they are both on the critical path (Figure F.I I).

Figure F.l 1 The revised timeline chart.

Subsequently, Brigette needs to show only the completion of each of these two remaining activities on the timeline chart - the project being completed by the Thursday of week 11 (Figure F.I2).

Planned Time

Planned Time

It should be apparent from Figure 9.12 that the initial activity, specify overall 9.3 Amanda's system, has slipped by one day. It may not be quite so obvious from Figure 9.12 earned value alone what else has happened to her project - inspection of Figure 9.12 and analysis Table 9.2 should, however, make it possible to see that specify module P has taken 2 days longer than forecast and specify module H has taken 5 days longer. Thus, the project has earned 34 workdays by day 35, 49 workdays by day 52 and 64 workdays by day 55.

From Figure 9.12 it is not possible to deduce the underlying causes of the slippage or to forecast the consequences for the project. The use of earned value analysis for forecasting is described later in Section 9.6.

9.4 The effects of Among the items most likely to be affected by the change are test data, expected specification results and the user handbooks.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment