PLANNING

The first activity for project management at the beginning of projects is preparing a project plan.

Purpose

It enables:

a) Controlling of the project

b) Provides project information to management. Customers and the project team. Without a
project plan it is impossible to say whether the project is proceeding as it should – whether
the project will be finished by the deadline or finished within the budget.

Contents of the project plan

1. Definition of project activities and results or deliverables

2. Definition of dependencies between tasks
3. Resource estimation for each activity
4. Schedule of all activities including milestones and reviews
5. Resource budgets and loading estimates i.e. resource requirements over time for all
resources.

Challenge

Project planning is subject to uncertainty because in the beginning the project scope, costs,
schedules etc are not clear. They become known at the end of the project.

Solution

Do iterative planning – Do the planning in 3 phases

Project planning in 3 phases

1. Concept oriented plan

This plan is done in the very beginning as soon as rough system requirements are known. It
includes detailed descriptions of all tasks until the end of analysis. It includes all major
milestones (where known). The inputs to the initial planning are provided by the project
management (80%) and the other 20% is provided by the technical project staff.

2. The function-oriented plan

This is done after the analysis phase when the system functionality has been specified. Time
and cost estimates are more accurate. There is detailed planning of design and coding
phases. There is top level planning of testing and integration phases. It uses rough
estimation based on software metrics. Inputs to function-oriented planning are provided by
project management (50%) and project technical staff (50%).

3. Implementation-oriented plan
 This is done after the detailed design when detailed knowledge of the system is available.
Detailed estimates based on software metrics are now possible. Inputs to this
implementation-oriented plan is provided by project management (20%) technical project
staff (80%).

Each project plan is developed according to 5 steps:

1. Decompose the project into tasks

2. Define dependency relations between tasks

3. Estimate resource requirements for the identified tasks

4. Perform risk analysis for each task

5. Schedule the overall project by scheduling all individual tasks together

TASK DECOMPOSITION

For large projects you break them up into tasks. The work breakdown structure (WBS) is a list of all
the activities to be done to successfully complete a project. If an activity is not in the WBS list then
its not part of the project. The list of activities will enable the estimation of effort, size and cost of
completing a project. Therefore WBS is a prerequisite for any estimation activity.

Applying the WBS

A project consists of small, independent tasks. Each task can be further divided into subtasks e.g. of
an IT project – It can be divided into feasibility study, requirements analysis, design, coding, testing,
implementation and maintenance.

Requirements analysis can be further divided into tasks like interviewing a client, studying
organisational objectives, document sampling, compiling the SRS document {Note the above is a list
of subtasks}

[Partitioning in one level is almost impossible so we have to do multi-level partitioning]

Level 0 is the whole project. Level 1 are the main project components i.e. the development phases.
Level 2 there is task break down of level 1 activities. Note:- The output of partitioning is the work
break down structure.

Steps of creating a WBS

1. Brainstorm to arrive at broad tasks for a project

2. Refine the broad tasks – Refine the list of tasks that was compiled during brainstorm.
[Include adding more tasks, combining the existing ones or changing the arrangement of
tasks]

3. Categorizing tasks into logical headers – categorise each task into a logical task header e.g.
preparing test plans, preparing test cases, drawing up the test plans can be categorised as
 planning software testing. This ensures you have not missed out any task during
brainstorming.

Benefits of using a WBS

1. It gives the management an idea about the size and complexity of the project

2. It helps in planning, scheduling and monitoring a project realistically. [Each task can be
performed with measurable targets]

3. Used/acts as an input for various software planning and estimation tools

4. Resource staffing –helps you to identify project deliverables. Specifies tasks to be performed
and the resources required to produce the deliverables.

5. Cost budgeting and estimation – Since WBS provides us with the list of deliverables required
to complete the project, the list can be used to:- identify the cost required to produce these
deliverables. The costs can be combined to identify the total cost of the project.

6. Scheduling – the list of tasks can be used to create project schedules

7. Material procurement – WBS helps you identify the inputs required to produce the
deliverables of the project. A list of materials required can be created.

8. Managing change control – you can be able to identify whether a given task is in the scope
of the project or not. This can help to identify whether a suggested change in the project
should be entertained or not.

TASK DEPENDENCY DEFINITION

Tasks identified during task decomposition have dependencies among each other so there is need to
identify the dependencies.

Types of task dependencies

1. Finish to start – after one task is finished the next task can start e.g. after design coding can
start.

2. Finish to finish – two tasks must start at the same time and finish at the same time e.g.
beginning of development and documentation

3. Partial finish to start – one task starts when another task is partially complete e.g. module
integration can start when coding is partially complete.

Notations for representing task dependencies

You can use various graphical methods like CPM – CRITICAL PATH ANALYSIS and the PERT chart –
program evaluation and review techniques – however, dependencies can only be finish to start. The
Gantt chart is able to represent the different task dependencies.

The CPM (In this module we will just look at CPM)

 - Activity network

- Used to illustrate the project schedule

- Show dependencies between the different activities making up the project

- You can use a project management tool to generate an activity network

- Tasks are shown as labelled boxes. Dependencies are shown as connecting lines between
boxes. The relative position of boxes is not related to task position in time.

- Milestones and project deliverables are represented by rounded rectangles

- Can also include the start date of the activity

- Shows activities which can be carried out in sequence

- Critical path – the path that will take the longest time. It is the minimum time required to
finish the project. The average schedule of the project depends on the critical path. It
indicates the tasks to closely watch to avoid project delay. Any slippage in the completion of
any critical activity causes project delays.

Examples:

Task Duration(weeks) Precedents

A 7

B 4

C 6 A

D 4 B

E 5 B

F 9 E

G 5 E, F

H 3 C, D

Task Duration (days) Dependencies

T1 8

T2 15

T3 15 T1(M1)

T4 10

T5 10 T2, T4(M2)

T6 5 T1, T2(M3)

T7 20 T1(M1)

T8 25 T4(M5)

T9 15 T3, T6(M4)

T10 15 T5, T7(M7)

T11 7 T9(M6)

T12 10 T11(M8)

- Delays in activities which do not lie on the critical path, however, need not cause an overall
schedule slippage. So long as the delays do not extend these activities so much that the total
time exceeds the critical path, the schedule will not be affected.

Float (Free slack)

- Is the amount of time that a task in a project network can be delayed without causing a
delay to subsequent tasks and project completion date.

- Float is associated with the path. If a project network diagram has 4 non-critical paths then
the project would have 4 total float values.

- If an activity on the critical path gets delayed, the project will get delayed. What if other
project activities get delayed? How will such delays impact the project schedule? How long
can you wait for an activity to complete before it impacts the project completion?

Calculate the float

- Determine the critical path

- Then calculate the float – which is the duration of activity delay that the project can tolerate
before the project comes in late.
- Float for any activity on the critical path is zero – if any activity on the critical path is delayed,
the project will be late.

Example

TASK DURATION(DAYS) DEPENDENCIES

A 5

B 3 A

C 1 B

D 3 B

E 4 B

F 4 E

G 6 F

H 8 G

I 8 C, D, H

Calculate float - Identify the number of paths. Find the critical path and the activities which are
not on the critical path then calculate the float.

- Float for each activity on path 1:- 38 – 19 = 19days

- Float for each activity on path 2:- 38 – 17 = 21days

Interpreting results:-

Float – informs amount of extra time for each activity.

D can come in 19 days late. C can come in 21 days late - The project will still be delivered on
time. But if they are delayed more than the float, the project will be delayed. When this happens
the critical path of the project will change (ideally this should not happen)

Benefits of CPM

- Provides a graphical view of the project

- Predicts the time required to complete the project

- Shows which activities are critical to maintaining the schedule and which are not

Note:- CPM can be updated as the project progresses

Estimate resource requirements for each task

ESTIMATES

The four main types of estimates are:

1) Subjective
2) Parametric
3) Comparative
4) Analytical

1) Subjective
When asked to give a estimate at the proposal stage before a proper specification is available, a
contractor may be prepared to give a “ball park” figure. This is a subjective assessment of costs
based on past experience and “hunch”. It clearly depends on the amount of factual information
available but by its very nature has an accuracy of between =−20 to 40%

2) Parametric
At the budget preparation stage, a parametric estimate may well be the cheapest method. By
using well known empirical formulae in which costs are related to physical characteristics, a
good estimate with an accuracy of 10 to 20% can be obtained. For example an architect is
able to give an approximate cost of a house by multiplying the cube (length×breadth×height)
of the finished structure by a cost/cubic metre value which varies with the desired quality of
construction. Similarly an office block can be costed per square metre of lettable floor area, or
a road by the mileage which includes even bridges and cuttings.

3) Comparative
When a new project or work package can be compared with a similar (preferably recent) one,
having the same basic features, a comparative estimate will give a fair cost of the new work.
Due allowance must be made for location, inflation and any significant differences, but an
accuracy of +/−10% should be possible.

4) Analytical
Once all the specification and main layout drawings have been prepared, an analytical estimate
can be prepared. Here every component and work package consisting of labour and materials,
must be individually costed and the results summated. Labour can be estimated using work
norms and materials costs can be obtained from suppliers. The accuracy of such an estimate
should be +/−5%
In all cases a contingency allowance should be added to the estimate.

Estimating effort

Why measure effort for the project?

- Enables you to derive cost estimates that are critical for project management

- If you make an incorrect measurement of effort at the beginning of a project, this results in:-

Inaccurate project plans and frequent slippages

Can also lead to inaccurate cost estimates – which lead to steep cost deviations
between estimated and actual cost values.
Note:- Estimation of resources, cost and schedule requires experience. It requires access to good
historical information.

Techniques used to estimate effort

- SLOC [source lines of code] Effort is directly related to the SLOC. Programs with larger SLOC
take more time to develop.

- FP [function points]

- COCOMO [constructive cost model]

Using SLOC to estimate the size of the project

- Used to calculate the size of an IT project by estimating the number of lines of code in a
program. These are the source lines of code that are delivered as part of the product.

- Why determine the size of the project at the beginning? The project size helps determine
the resources, effort and duration of the project.

- The effort spent on creating the source lines of code is expressed in relation to thousand
lines of code [KLOC]

- SLOC method is an objective method of estimating the size because there are no multiple
ways of calculating the lines of code. Effort is directly related to the SLOC – programs with
larger SLOC take more time to develop but functionality might not be correlated with SLOC
e.g. few lines of code may offer more functionality.

- You can use the SLOC technique to estimate the effort required for a project when the
programming language and the technology to be used are defined. SLOC requires that the
technology or language remains unchanged throughout the project.

- When counting the SLOC, consider the following:-

a) Only the delivered lines of code are included in SLOC calculation e.g. test drivers and
other support software are not part of the number of lines developed for a project.

b) Only the SLOC written by the programming team is counted (this excludes the code
created by application generators)

c) Only executable statements are counted as SLOC. (Excludes the comments inserted to
improve the readability of programs). Declarations are counted as SLOC.

Limitations of using the SLOC

- SLOC is language-dependent. The effort required to calculate source lines of code might not
be the same for all languages e.g. to conceive and write 8 lines of code that accomplish a
task in the assembly language may require 15 minutes and you may however, require only 5
minutes to complete the same lines of code if it is written in VB.
 - Their use in estimation requires a level of detail that may be difficult to achieve (you
estimate the lines of code to be produced long before analysis and design have been
completed)

Estimating the effort using the constructive cost model – cocomo

This is another estimation technique. It uses cost driver attributes to calculate the effort and
duration of a project. It has three levels of implementation and with each level, the complexity of
the model increases. The following are the levels of the cocomo technique

a) Basic COCOMO

b) Intermediate COCOMO

c) Advanced COCOMO

Basic COCOMO computes software development effort (and cost) as a function of program
size. Program size is expressed in estimated thousands of source lines of code (SLOC),
(KLOC).

COCOMO applies to three classes of software projects:

 Organic projects are relatively small, simple software projects in which small teams with
good application experience work to a set of less than rigid requirements.
 Semi-detached projects are intermediate (in size and complexity) software project in which
teams with mixed experience levels must meet a mix of rigid and less than rigid
requirements.

 Embedded projects are software project that must be developed within a set of tight
hardware, software, and operational constraints.

The basic COCOMO equations take the form

Effort Applied (E) = ab(KLOC)bb [ person-months ]

Development Time (D) = cb(Effort Applied)db [months]
People required (P) = Effort Applied / Development Time [count]

where, E is the effort applied in person-months, D is the development time in chronological

months, and KLOC is the estimated number of delivered lines of code for the project
(expressed in thousands). P is the people required. The coefficients ab, bb, cb and db are given
in the following table:

Software project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

Basic Cocomo is good for quick, early, rough order of magnitude estimates of software costs,
but its accuracy is necessarily limited because of its lack of factors to account for differences
in hardware constraints, personnel quality and experience, use o f modern tools and
techniques, and other project attributes known to have a significant influence on software
costs.

Intermediate COCOMOs
The basic model is extended to consider a set of "cost driver attributes".

There is an additional step of calculating the Effort Adjustment Factor (EAF)

The factor is calculated by assigning ratings to 15 cost driver attributes. The cost drivers relate to the
various aspects of IT projects that can be grouped into four major categories, with each a number of
subsidiary attributes:-

 Product attributes
o Required software reliability

o Size of application database

o Complexity of the product

 Hardware attributes

o Run-time performance constraints

o Memory constraints

o Volatility of the virtual machine environment

o Required turnabout time

 Personnel attributes

o Analyst capability

o Software engineering capability

o Applications experience

o Virtual machine experience

o Programming language experience

 Project attributes

o Use of software tools

o Application of software engineering methods

o Required development schedule

The values of each cost driver are filled in by an organisation based on experience. Each of the 15
attributes receives a rating on a six-point scale that ranges from "very low" to "extra high" (in
importance or value). Usually in organisations, the average rating is assigned a static value of 1.0.
To calculate EAF, find the product of the cost values. Typical values for EAF range from 0.9 to 1.4.

Ratings
Very Very Extra
Cost Drivers Low Low Nominal High High High
Product attributes
Required software reliability 0.75 0.88 1.00 1.15 1.40
Size of application database 0.94 1.00 1.08 1.16
Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65
Hardware attributes
Run-time performance constraints 1.00 1.11 1.30 1.66
Memory constraints 1.00 1.06 1.21 1.56
Volatility of the virtual machine environment 0.87 1.00 1.15 1.30
Required turnabout time 0.87 1.00 1.07 1.15
Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Software engineer capability 1.42 1.17 1.00 0.86 0.70
Virtual machine experience 1.21 1.10 1.00 0.90
Programming language experience 1.14 1.07 1.00 0.95
Project attributes
Application of software engineering methods 1.24 1.10 1.00 0.91 0.82
Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development schedule 1.23 1.08 1.00 1.04 1.10

The same basic equation for the model is used, but fifteen cost drivers are rated on a scale
of 'very low' to 'very high' to calculate the specific effort multiplier and each of them returns
an adjustment factor which multiplied yields in the total EAF (Effort Adjustment Factor). The
adjustment factor is 1 for a cost driver that's judged as normal.
In addition to the EAF, the model parameter "a" is slightly different in Intermediate COCOMO
from the basic model. The parameter "b" remains the same in both models

The Intermediate Cocomo formula now takes the form:

E=ai(KLoC)(bi).EAF

where E is the effort applied in person-months, KLoC is the estimated number of thousands of
delivered lines of code for the project, and EAF is the factor calculated above. The coefficient ai and
the exponent bi are given in the next table.

Software project ai bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
The Development time D calculation uses E in the same way as in the Basic COCOMO.

Advanced COCOMO (In this course we will not look at advanced COCOMO)

Applicability of COCOMO

- Used when the size of the project is extensive and the requirements of the project are
vague.
- Suitable for complex and sophisticated projects that are expected to operate within
intensive hardware, software and personnel constraints.

- Can be used when the software development environment is new to an organisation.

- Can be used when you don’t have baseline data about past projects.

Using function points for estimating the effort

The International Function Points Group (IFPUG) defines functions points as a "measure software
size by quantifying the functionality provided to the user based solely on logical design and
functional specifications"

Function Point Analysis (FPA) calculates the size of a software project and estimates the total effort
required to complete it.
Size is measured as the number of function points in the project and effort is measured in total man-
hours. Size is measured from a functional, or user, point of view. Therefore, the size estimate is
constant regardless of computer language, development methodology or technology.

A function point is a rough estimate of a unit of delivered functionality of a software project.

To calculate the number of function points for a software project one counts all the user inputs, user
outputs, user inquiries, number of files and number of external interfaces splitting them up in
simple, average and complex ones.

 Number of user inputs

Each user input that provides distinct application oriented data to the software is counted.
 Number of user outputs
Each user output that provides application oriented information to the user is counted. In
this context "output" refers to reports, screens, error messages, etc. Individual data items
within a report are not counted separately.

 Number of user inquiries

An inquiry is defined as an on-line input that results in the generation of some immediate
software response in the form of an on-line output. Each distinct inquiry is counted.

 Number of files
Each logical master file is counted.

 Number of external interfaces

All machine-readable interfaces that are used to transmit information to another system are
counted.
By multiplying these found countings using the table below a total count is created. Once the
function is identified and categorized into a type, it is then assessed for complexity and assigned a
number of function points.
Weighting factor
Measurement parameter
Simple Average Complex

Number of user inputs 3 4 6

Number of user outputs 4 5 7

Number of user inquiries 3 4 6

Number of files 7 10 15

Number of external interfaces 5 7 10

Note:- The standard values for weights are followed globally and they are
determined/provided by IFPUG.

For example:- If there are 25 user inputs of weight average, 5 user outputs of weight
complex, 10 user enquires of weight average, 5 files of weight complex and 20 external
interfaces of weight complex

Then the count total which represents the unadjusted function points (UFP) is as calculated
below:- (25x4)+(5x7)+(10x4)+(5x15)+(20x10) = 450FPs

UFP = 450

Adjusted function points (AFP)= count total (UFP) x [0.65 + 0.01 x SUM(F i)]

= 450 x [0.65 + 0.01 x 42]

= 481.5

0.65 and 0.01 are constant values that have been determined based on the experience compiled
from multiple projects.

The only part of the formula I haven't explained yet is the SUM(Fi) part. This is a number that says
something about the Technical complexity. It is the sum of 14 cost factors. It is generated by giving a
rate on a scale of 0 to 5 for each of the next questions. The higher the rate the more important the
function is.

Note:- The values are subjective decisions of an organisation. Some factors may be assigned
different values by different organisations.

1. Does the system require reliable backup and recovery?

2. Are data communications required?

3. Are there distributed processing functions?

 4. Is performance critical?

5. Will the system run in an existing, heavily utilized operational environment?

6. Does the system require on-line data entry?

7. Does the on-line data entry require the input transaction to be built over multiple screens or
operations?

8. Are the master files updated online?

9. Are the input, outputs, files or inquiries complex?

10. Is the internal processing complex?

11. Is the code designed to be reusable?

12. Are conversions and installation included in the design?

13. Is the system designed for multiple installations in different organizations?

14. Is the application designed to facilitate change and ease of use by the user? SUM(Fi) = 42

Using the FPs for initial estimation:-

- If it is estimated that to complete one FP of work it requires 10hours and the total estimated
FP is 200 then to complete that project you need 200 x 10 which is 2000hours. A working
day is 8 hours long thus 2000/8 = 250 person days. A person will need250 days to complete
the work. Assuming there are 20 working days in a month, then you require 250/20 = 12.5
person months. This implies that to complete 200 FP of work a person needs 12.5 months. If
there are 2 people they will need 6.25 months

Note:- In addition to calculating the Size of the Software and , effort required to complete the
software, FPs can also be used to quote the price of the software, get the time required to complete
the software.

Note:- The function points can be converted to an equivalent number of SLOC. That can be done by
multiplying the number function points with a factor that is different for every programming
language. This factor describes how many source lines it takes to implement 1 function point.

The table below is a table of language equivalencies. Some common values are as follows:

Language SLOC per Function Point

C++ default 53
Cobol default 107
Delphi 5 18
HTML 4 14
Java 2 default 46
Visual Basic 6 24
SQL default 13

So, to implement 481.5 function points using Java 2 would require approximately the following
number of SLOC: 481.5*46 = 22 149 SLOC
Then you can estimate the effort, duration and number of people required to do the project.

Advantages of using the FP model

- Is language and technology-independent. You can use FPs to estimate any type of project.

- Can also be used to estimate effort, cost, and schedules of projects that use the prototyping
and spiral models. [such projects have uncertain user and project requirements]

- You can use FP as a project estimation technique, when you anticipate changes in the middle
of a project [uses a subjective and holistic approach for project estimation]

Limitations of using the FP

- Uses data from past projects for assigning weights and the information domain values. It is
important for the organisation to have developed similar projects in the past.

- FP provides a vague estimation

Software cost estimation

Some cost estimation may be required at an early stage of the project before detailed schedules are
drawn up to:- establish a budget for the project OR to set a price for the software for a customer.

Parameters involved in computing the total cost of a software development project:-

a) Effort costs – these are the dominant costs. The costs include paying software engineers,
support staff, costs of networking and communication, costs of central facilities such as
library, recreational facilities etc, and costs of social security and employee benefits.

b) Hardware and software costs including maintenance – relatively cheap

c) Travel costs – can be significant where a project a project is developed at different sites –
relatively low for most projects. Use of e-mail, fax and teleconferencing can reduce the
travel required.

d) Size of project

Software costing must be carried out objectively but it must take into consideration broader
organisational, economic, political and business considerations.

Factors to be taken into consideration:-

a) Market opportunity – a development organisation may quote a low price because it wishes
to move into a new segment of the software market. Accepting a low profit on one project
may give the opportunity of more profit later. The experience gained may allow new
products to be developed.

b) Cost estimate uncertainty – if an organisation is unsure of its cost estimate, it may increase
its price by some contingency over and above its normal profit.
 c) Contractual terms – a customer may be willing to allow the developer to retain ownership of
the source code and reuse it in other projects. The price charged may then be less than if the
software source code is handed over to the customer.

d) Requirements volatility – if the requirements are likely to change, an organisation may lower
its price to win a contract. After the contract is awarded, high prices may be charged for
changes to the requirements.

e) Financial health –developers in financial difficulty may lower their price to gain a contract. It
is better to make a smaller than normal profit or break even than to go out of business.

Because of the above there may not be a simple relationship between the price to the customer for
the software and the development costs. Project pricing usually involves senior management in the
organisation as well as software project managers.

Creating project plans and schedules

- A plan that specifies the way a project has to be executed

- It is a road map for the various activities in a project

- It determines duration of the project. Determines the start and end dates of a particular
activity and of the complete project. Determines the cost and effort required for a particular
activity and for the entire project.

- Used for monitoring the project progress by comparing the planned and actual schedule for
various activities

- Specifies the stages when a specific resource will be required and the time period for which
the resource will be required

- Specifies the dates for key project deliverables

To create an accurate project schedule, you need to create the following:-

- Requirements baseline – categorise requirements into various phases of software

development

- Work breakdown structure WBS

- Project management plan – contains information about delivery dates, estimated team size,
frozen requirements and the communication plan

- Estimate effort – specify the amount of resources required to complete the project

- Resource allocation – allocation of resources to various activities that need to be performed

and resource loading – managing resources so that you can get the most from them.

There are tools and techniques that are used for scheduling projects. Examples of such tools are:-
the Gantt chart, PERT and CPM.
Limitations of the Gantt chart

- Does not specify the earliest or latest time of completing an activity

- Does not show the critical path of a project

- Does not show dependencies of the activities on other activities (although now Microsoft
project can help show the dependencies).

Problems associated with adding more staff to a project

When a project starts getting delayed, more staff can be added to help finish it on time but to a limit.

Brooks’ Law states that adding manpower to a late software project makes it later (delays it even
more). Brooks adds that "Nine women can't make a baby in one month."

His reasons are indicated below:-

1. The learning curve
New staff needs to learn about the project they join. New staff needs to be trained by the
old staff – this means that the old staff cannot continue to work on the project causing more
delays (unproductive time)
2. Increased communication overhead
The more people work on a project the more people have to communicate with each other.
The number of communication paths between team members rapidly increases.
(Communication takes up work time and productivity is reduced)

Brooks points to two main factors that explain why it works this way:

1. It takes some time for the people added to a project to become productive. Brooks
calls this the "ramp up" time. Software projects are complex engineering endeavours,
and new workers on the project must first become educated about the work that has
preceded them; this education requires diverting resources already working on the
project, temporarily diminishing their productivity while the new workers are not yet
contributing meaningfully. Each new worker also needs to integrate with a team
composed of multiple engineers who must educate the new worker in their area of
expertise in the code base, day by day. In addition to reducing the contribution of
experienced workers (because of the need to train), new workers may even have
negative contributions – for example, if they introduce bugs that move the project
further from completion.
2. Communication overheads increase as the number of people increases. Due to
combinatorial explosion, the number of different communication channels increases
rapidly with the number of people.[3] Everyone working on the same task needs to
keep in sync, so as more people are added they spend more time trying to find out
what everyone else is doing.

Exceptions and possible solutions

3. Brooks's law is often cited to justify why projects keep being late, despite management
efforts. However, there are some key points in Brooks's law that allow exceptions and open
the door for possible solutions.[4][5]
4. The first point is to note that Brooks's law often applies to projects that are already late. [6]
Projects can be brought back into (or kept in) control if people are added earlier in the
process.[7] It is also important to determine if the project is really late, or if the schedule was
originally overly optimistic. Scheduling mistakes account for a large number of late projects.
Correcting the schedule is the best way to have a meaningful and reliable time frame for the
project's completion.[8]
5. The quantity, quality and role of the people added to the project also must be taken into
consideration. One simple way to circumvent the law on an overrun project is to add more
people than needed, in such a way that the extra capacity compensates the training and
communication overhead.[9] Good programmers or specialists can be added with less
overhead for training.[10] People can be added to do other tasks related with the project, for
example, quality assurance or documentation; given that the task is clear, ramp up time is
minimized.[11]
6. Good management and development practices also help to minimize the impact of Brooks's
law. The modern practices of continuous integration, test-driven development, and iterative
development significantly reduce the inter-developer communication overhead, and thus
allow for better scalability. New tools for software development and documentation also
help to minimize the ramp up time, making it simpler for new programmers to get involved
in the work. Design patterns simplify the distribution of work, because the entire team can
do its part within the framework provided by that pattern. The design pattern defines the
rules that the programmers follow, simplifies communication through the use of a standard
language, and provides consistency and scalability. Finally, good segmentation helps by
minimizing the communication overhead between team members. Smaller sub-problems
are solved by a smaller team, and a top-level team is responsible for systems integration. For
this method to work, the segmentation of the problem must be done correctly in the first
place; if done incorrectly, this can make the problem worse, not better, by impeding
communication between programmers working on parts of the problem which are actually
closely coupled, even when the project plan has decreed that they are not.
7. Some authors – see, for example, Creating a Software Engineering Culture by Karl E.
Wiegers – have stressed the importance of the social and political aspects of the work
climate as determinants of the effectiveness of individual programmers and the project
team as a whole. Rather than depending on heroes to carry the day with extraordinary
efforts, Wiegers argues that a team of ordinarily-skilled individuals can repeatedly deliver
timely results in the right work environment. Efforts to improve the effectiveness of teams
can ameliorate, if not eliminate, the consequences of Brooks's law.