CHAPTER – 6

FUNDAMENTALS OF SE AND REQUIREMENT

ENGINEERING
(Requirement Elicitation, Analysis, System Models)

Overview of Software Requirements

Software requirements provide a comprehensive foundation for system development by

describing the necessary functionalities, constraints, and qualities a system must
possess to meet stakeholder expectations. These requirements are systematically
derived through well-defined processes, ensuring alignment with user needs and
technical feasibility. At the core of this are two key types of requirements: user
requirements and system requirements. User requirements outline what users expect
from the system in broad, outcome-oriented terms, while system requirements specify
the detailed technical and operational aspects required to fulfill those expectations.
Requirements can further be classified into functional requirements, which define
specific tasks or operations the system must perform (e.g., processing payments or
generating reports), and non-functional requirements, which focus on performance
attributes like reliability, security, and usability.
The process of deriving and refining these requirements is known as requirements
engineering, encompassing several principal activities. Elicitation involves gathering
requirements from stakeholders through methods such as interviews, workshops, and
document analysis. Analysis refines these inputs, resolves conflicts, prioritizes
requirements, and ensures technical feasibility using tools like use case diagrams and
prioritization frameworks. Specification formalizes the requirements in clear, structured
formats, such as Software Requirements Specifications (SRS), ensuring they are
unambiguous and easily understood by both stakeholders and developers. Validation
confirms that the documented requirements align with the users’ needs and system
constraints through reviews, prototypes, and testing. Lastly, requirements management
ensures that the requirements remain relevant and consistent throughout the system's
lifecycle, adapting to changes in stakeholder needs or project scope.
By integrating these structured activities and techniques, the process of defining software
requirements ensures that the system is well-designed, meets user expectations, and
operates effectively within its intended environment. This comprehensive approach
serves as the blueprint for successful system implementation and long-term adaptability.

6.1 Requirements engineering

Requirements engineering is the process of defining the services that a system must
provide to meet customer needs and the constraints under which the system must
operate. It involves systematically establishing, analyzing, and documenting these
requirements to ensure they align with user expectations and technical feasibility. The
requirements themselves serve as detailed descriptions of the system's services and

149
 Fundamental of Engineering CH – 6

operational constraints, generated through the requirements engineering process. They

specify what the system is expected to do—such as tasks, functionalities, or
operations—without detailing how the system will accomplish these tasks. This
distinction ensures a clear separation between defining the objectives and designing the
implementation, enabling flexibility and precision in system development.

6.2 Requirements and Their Types

A requirement is a statement that specifies a system service, functionality, or constraint.
Requirements can vary widely, from high-level abstract descriptions of what a system
should do to detailed mathematical specifications that precisely define a function.
Requirements are typically classified into three types: user requirements, system
requirements, and software specifications.
6.2.1 User Requirements:
User requirements describe the functionality and constraints of the system in terms
understandable to users who may not have technical expertise. They are typically
represented using natural language, tables, or diagrams to ensure clarity. However,
using natural language may lead to challenges, such as balancing precision with
understandability, confusion between functional and non-functional requirements, and
amalgamation of multiple requirements into a single statement. To be effective, user
requirements should clearly describe both functional requirements (what the system
does) and non-functional requirements (system performance, security, etc.).

6.2.2 System Requirements:

System requirements provide a more detailed specification of the user requirements,
serving as the foundation for system design. They may also form part of a contract
between stakeholders and developers. These requirements are expressed using system
models and define the technical details of how the system should function. They bridge
the gap between user expectations and the implementation process.

6.2.3 Software Specifications:

Software specifications delve into even greater detail, providing technical and design-
oriented descriptions. They outline how the system will achieve the defined
requirements, often using formal models and precise technical language.

6.3 Definitions and Specifications of Requirements

Requirements can be broadly described and specified in the following ways:

Requirements Definition: This high-level description focuses on what the system must
achieve. For example, "The software must provide a means of representing and accessing
external files created by other tools."

Requirements Specification: This provides detailed technical elaboration, such as:

• The user must have the ability to define external file types.
• Each file type should be associated with a tool that can be applied.

150
 Fundamental of Engineering CH – 6

• External file types must be represented as icons on the user's display.

• Users must be able to customize these icons.
• Selecting an icon should apply the corresponding tool to the external file.

This structured approach ensures that requirements evolve from abstract statements to
detailed, actionable specifications, forming a robust foundation for system design and
implementation.

6.4 Functional and Non-Functional Requirements

Functional requirements define the specific services or functions a system should
provide. These requirements specify how the system reacts to particular inputs, behaves
in certain situations, and delivers expected outputs. Essentially, they capture the “what”
of the system functionality. For instance, in a library management system, a functional
requirement could state that users should be able to search for books by title, author, or
ISBN. Similarly, functional requirements may include detailed provisions such as allowing
users to access document viewers for reading files stored in the system or assigning a
unique identifier to every order, which can then be copied to a permanent storage location
for record-keeping.

On the other hand, non-functional requirements impose constraints on how the system
operates rather than what it does. These requirements often specify system qualities
such as performance, reliability, usability, and compliance with standards. For example,
they may dictate that the system must process user requests within a specific time frame,
follow specific development processes, or adhere to industry-standard security
protocols. While functional requirements address the primary capabilities of the system,
non-functional requirements ensure these capabilities are delivered efficiently and
effectively.

In addition to functional and non-functional requirements, systems may also include

domain requirements, which arise from the specific application domain. These
requirements encapsulate the unique characteristics, terminology, and practices
inherent to the domain, ensuring that the system aligns closely with domain expectations.
For instance, in a healthcare system, domain requirements might include the ability to
handle patient confidentiality per regulatory standards or support for medical
terminology used in diagnoses and treatments.

6.4.1 Examples of functional requirements

Functional requirements outline specific actions or capabilities that a system must
perform to meet user needs. These requirements are essential in defining what the
system is expected to do and serve as the foundation for the system’s design and
development.

1. Database Search: The user shall be able to search either across all the initial set of
databases or select a specific subset from the available options. This ensures that the
system provides flexibility and precision in data retrieval based on user preferences.

151
 Fundamental of Engineering CH – 6

2. Document Viewing: The system shall provide appropriate viewers to enable users to
read documents stored in the document repository. This functionality ensures that
users can seamlessly access and interpret stored data without requiring external
tools.
3. Order Identification: Every order shall be assigned a unique identifier, referred to as
ORDER_ID. Users shall be able to copy this identifier to the account’s permanent
storage area for tracking and reference purposes. This feature ensures efficient order
management and traceability within the system.

These examples illustrate how functional requirements translate user needs into specific
system functionalities, ensuring that the system delivers intended services effectively.

6.4.2 Requirements Precision, Completeness, and Consistency

The fundamental principle of requirements specification is that the requirements should
be precise, complete, and consistent. These qualities ensure that the requirements are
clear, well-defined, and conflict-free, forming a solid foundation for system development.

Precision:
Requirements must be stated precisely to avoid ambiguity and misinterpretation. They
should clearly define what is expected from the system without leaving room for multiple
interpretations. For example, rather than saying, "The system should be fast," a precise
requirement would specify, "The system should process user queries within two seconds
under normal operating conditions." Precision ensures that stakeholders have a common
understanding of the system’s capabilities.

Completeness:
A complete set of requirements includes descriptions of all functionalities and features
the system is expected to deliver. It must cover every aspect of the system, from primary
functions to ancillary services, leaving no gaps in understanding or expectations. For
instance, a complete requirements document for an e-commerce platform would specify
functionalities for product browsing, adding items to the cart, secure payment
processing, and order tracking.

Consistency:
Consistency in requirements ensures there are no conflicts or contradictions within the
descriptions of the system's functionalities. For example, if one requirement states that a
report should generate data in PDF format and another specifies Excel format, this
inconsistency could lead to confusion. Requirements should align with each other and
avoid any overlap or contradiction in their descriptions.

In practice, achieving precise, complete, and consistent requirements is a significant

challenge. Complex systems often involve diverse stakeholders with varying needs,
making it difficult to address all expectations without ambiguities, omissions, or conflicts.
Nonetheless, striving for these qualities enhances the clarity and reliability of the
requirements document, which is crucial for successful system development.

152
 Fundamental of Engineering CH – 6

6.4.3 Ambiguous/Imprecise Requirement

The given requirement, while providing some details about the database functionality, is
ambiguous and leaves several critical aspects undefined or open to interpretation:

4.A.5: The database shall only support the generation and control of configuration
objects; that is, objects which are themselves groupings of other objects in the database.
The configuration control facilities shall allow access to the objects in a version group by
the use of an incomplete name.

Issues Identified:

1. What about non-configuration objects?

o The requirement specifies that the database supports only configuration
objects. It is unclear whether non-configuration objects, such as standalone
entities or other forms of data, are supported. This omission creates
uncertainty about the scope of database functionality for handling other
object types.
2. What about other database functionality?
o The requirement focuses exclusively on the generation and control of
configuration objects but does not address whether the database supports
other essential functions, such as querying, updating, or deleting data,
managing relationships, or enforcing constraints.
3. What about the level of service other than support?
o The term “support” is vague and does not specify the extent or quality of the
functionality provided. Does "support" imply creation, modification, deletion,
versioning, or something else? Additionally, no performance or reliability
metrics are mentioned, leaving the service level undefined.
4. Something else?
o The use of "incomplete name" for accessing objects in a version group is not
explained. Does it mean partial string matching, prefix-based matching, or
something else? There are no details about the rules, constraints, or
implications of using incomplete names, which could lead to inconsistent
interpretations and implementation.

153
 Fundamental of Engineering CH – 6

6.4.4 Non-functional requirement types

Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements

6.4.5 Non-functional requirements examples

Non-functional requirements specify the constraints and quality attributes of a system,
ensuring that it operates effectively within its intended context. They define how the
system performs rather than what it does. Below are examples categorized into product,
organizational, and external requirements:

Product Requirement:

4.C.8 – It shall be possible for all necessary communication between the APSE (Ada
Programming Support Environment) and the user to be expressed in the standard Ada
character set.

This requirement ensures that the product adheres to a specific character set standard,
supporting compatibility and standardization for communication between the system
and its users.

Organizational Requirement:

9.3.2 – The system development process and deliverable documents shall conform to the
process and deliverables defined in XYZCo-SP-STAN-95.

This requirement enforces adherence to a specified organizational standard for

development processes and documentation, ensuring compliance with internal policies
and structured workflows.

154
 Fundamental of Engineering CH – 6

External Requirement:

7.6.5 – The system shall not disclose any personal information about customers apart
from their name and reference number to the operators of the system.

This requirement addresses privacy and security concerns by restricting the disclosure of
sensitive customer data, aligning with external regulations and protecting user
confidentiality.

6.4.6 Non-functional requirements measures

Property Measure
Speed Processed transactions/second
User/Event respo nse time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to fail ure
Probability of unavailabi lity
Rate of failure occurrence
Availabi lity
Robustness Time to restart after failure
Percentage of ev ents caus ing failure
Probability of data corruption on failure
Portabili ty Percentage of target dependent statements
Number of target systems

6.4.7 Requirements Interaction

In complex systems, conflicts between non-functional requirements are common, as
these requirements often impose constraints that are difficult to reconcile. Resolving
these conflicts requires prioritization and trade-offs to meet the system's most critical
goals effectively.

Example: Spacecraft System

In a spacecraft system, conflicting non-functional requirements include:

• Minimizing Weight: To reduce the overall weight of the system, the number of separate
chips should be minimized.
• Minimizing Power Consumption: To conserve power, lower-power chips should be
used.

However, using lower-power chips often necessitates a higher number of chips, which
conflicts with the goal of minimizing weight.

155
 Fundamental of Engineering CH – 6

Resolution:
The most critical requirement depends on the mission’s objectives and constraints. If the
spacecraft’s design prioritizes minimizing weight to enable optimal payload capacity or
meet launch weight restrictions, this requirement may take precedence. Conversely, if
power availability is highly constrained, reducing power consumption may become the
primary focus. Prioritization requires a detailed analysis of the system's design trade-offs
and the mission's overall goals.

6.4.8 Domain Requirements

Domain requirements capture specific characteristics of the application domain but
often introduce challenges due to their complexity and implicit nature.

Example: Train Protection System

The deceleration of a train is defined as:

Dtrain = Dcontrol + Dgradient

where Dgradient is 9.81ms2 * compensated gradient/alpha and where the

values of 9.81ms2 /alpha are known for different types of train.

Problems Identified:

1. Understandability:
The requirement is expressed in domain-specific terminology (e.g., "compensated
gradient" and "alpha"), which might not be easily understood by software engineers
unfamiliar with the domain. This could lead to misinterpretation or implementation
errors.

2. Implicitness:
Domain specialists often assume that certain concepts, such as the significance of
the compensated gradient or the predefined values for different train types, are self-
evident. However, these implicit assumptions are not explicitly documented, making
it difficult for engineers to fully understand and implement the requirement correctly.

Recommendations:
To address these challenges:

• Use additional documentation or annotations to explain domain-specific terms and

their significance in the context of the requirement.

• Collaborate closely with domain specialists to ensure that all implicit knowledge is
made explicit and accurately captured in the requirements document.

• Provide examples or use cases to clarify how the requirements apply to different
scenarios.

By addressing these issues, domain requirements can be made more understandable

and actionable for software engineers while preserving the intent of the domain experts.

156
 Fundamental of Engineering CH – 6

6.4.9 Requirements Document

A requirements document serves as a critical artifact in the system development
lifecycle, providing a comprehensive description of the system's intended functionality,
constraints, and operational environment. It must address various aspects to ensure the
successful development, deployment, and maintenance of the system.

• Specify external system behaviour

• Specify implementation constraints

• Serve as reference tool for maintenance

• Easy to change

• Record forethought about the life cycle of the system (i.e. predict changes)

• Characterise responses to unexpected events

6.4.10 Users of a requirements document

Specify the requirements and

read them to check that they
System customers meet their needs. They
specify changes to the
requirements

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

Use the requirements to

System engineers understand what system is to
be developed

System test Use the requirements to

engineers develop validation tests for
the system

System Use the requirements to help

maintenance understand the system and
engineers the relationships between its
parts

157
 Fundamental of Engineering CH – 6

6.5 Requirements engineering process

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document

6.5.1 Feasibility Studies

A feasibility study is a short, focused evaluation conducted to determine whether a
proposed system is worthwhile and viable. It examines various factors to ensure the
system aligns with organizational objectives, contributes to strategic goals, and adds
value to the organization. The study also evaluates whether the system can be engineered
using current technology while staying within the allocated budget, making sure it is both
technically and financially feasible. Additionally, it assesses the system’s ability to
integrate seamlessly with existing systems, ensuring compatibility and operational
harmony across the organization.

6.5.2 Elicitation and Analysis

Elicitation and analysis, often referred to as requirements discovery or requirements
elicitation, involve technical staff working closely with stakeholders to uncover critical
aspects of the system. This process focuses on understanding the application domain,
identifying the services the system must provide, and defining the operational constraints
under which the system will function. Stakeholders, including end-users, managers,
maintenance engineers, domain experts, and trade unions, play an essential role in
shaping these requirements. However, the process can be challenging due to differing
perspectives, varying levels of understanding, and the complexity of translating domain-
specific knowledge into actionable requirements.

6.5.3 Problems of Requirements Analysis

During the requirements analysis process, several challenges may arise:

158
 Fundamental of Engineering CH – 6

• Unclear Requirements: Stakeholders often lack a clear understanding of what they

want from the system.

• Diverse Terminologies: Stakeholders may express requirements in their own domain-

specific terms, which can lead to misunderstandings.

• Conflicting Requirements: Different stakeholders may have conflicting priorities or

expectations.

• Influence of Organizational and Political Factors: Internal politics or organizational

dynamics may shape requirements in ways that do not align with technical or user
needs.

• Changing Requirements: Requirements may evolve during the analysis process due
to new insights, emerging stakeholders, or changes in the business environment.

6.5.4 Requirements Validation

Requirements validation ensures that the documented requirements accurately reflect
what the customer wants. This step is crucial because the cost of fixing errors in
requirements after system delivery can be up to 100 times higher than addressing them
during development.

Requirements Checking involves verifying the following aspects:

• Validity: Ensuring the requirements align with the customer’s needs.

• Consistency: Ensuring there are no conflicts between different requirements.

• Completeness: Ensuring all necessary requirements are included.

• Realism: Ensuring the requirements can be implemented with the available

resources.

• Verifiability: Ensuring the requirements can be tested to confirm their

implementation.

6.5.5 Requirements Validation Techniques

1. Reviews: Conducting systematic manual analysis of the requirements to

identify issues or ambiguities.

2. Prototyping: Creating an executable model of the system to validate the

requirements through direct interaction.

3. Test-Case Generation: Developing test cases for requirements to evaluate

their testability and ensure they can be verified during implementation.

4. Automated Consistency Analysis: Using tools to check the consistency of

structured requirements descriptions, ensuring there are no logical conflicts.

159
 Fundamental of Engineering CH – 6

These techniques collectively help ensure that the requirements are accurate,
actionable, and aligned with stakeholder expectations, reducing the risk of costly
errors during system development.

6.6 Software Project Management

Software project management is essential due to the inherent constraints on budget and
schedule imposed by the organization developing the software. It encompasses the
activities required to ensure that the software is delivered on time, within budget, and in
accordance with the specified requirements. These activities are critical for aligning the
project outcomes with the goals of both the developing and procuring organizations.

6.6.1 Distinctions in Software Management

Managing software projects involves unique challenges and distinctions compared to
other engineering disciplines. One significant difference is that the product is intangible,
making it harder to visualize and measure progress compared to physical products.
Additionally, software is uniquely flexible, allowing for changes and modifications at
various stages of development, which can lead to scope creep if not managed effectively.
Unlike well-established fields such as mechanical or electrical engineering, software
engineering does not have the same level of recognition as a formal discipline, and its
processes are not standardized. Moreover, many software projects are one-off
endeavors, meaning they lack the repetitive processes and efficiencies of mass
production systems.

6.6.2 Management Activities

Software project management includes a wide range of activities aimed at ensuring
project success. These activities involve proposal writing to define the project's scope
and objectives, project planning and scheduling to outline tasks and timelines, and
project costing to allocate resources effectively. Managers must also engage in project
monitoring and reviews to track progress, personnel selection and evaluation to
assemble and assess the project team, and report writing and presentations to
communicate updates to stakeholders.

6.6.3 Management Commonalities

While software project management has unique challenges, it also shares similarities
with general engineering project management. Many techniques used in engineering
management, such as risk analysis and resource allocation, are equally applicable to
software projects. Additionally, technically complex engineering systems often face
problems similar to those encountered in software systems, such as integration issues,
unforeseen complexities, and resource constraints.

160
 Fundamental of Engineering CH – 6

6.6.4 Project Staffing

Staffing a software project is often constrained by practical and organizational limitations.
It may not always be possible to appoint the ideal team members due to budget
restrictions that prevent hiring highly-paid specialists or the unavailability of experienced
staff. Organizations may also prioritize developing internal employee skills, assigning less
experienced individuals to gain hands-on experience. Managers must navigate these
constraints, especially during times of staff shortages, and find innovative solutions to
optimize team performance despite these challenges.

6.6.5 Project Planning

Project planning is one of the most time-intensive activities in software project

management. It begins during the initial concept phase and continues throughout the
project lifecycle, requiring regular updates as new information emerges. Effective
planning involves creating and maintaining a detailed schedule and budget while
supporting these with subsidiary plans for aspects such as risk management, quality
assurance, and resource allocation. As software development progresses, plans must be
revised to reflect changes in project scope, resource availability, and stakeholder
requirements, ensuring that the project remains aligned with its objectives.

6.6.6 Types of project plan

Plan Description
Quality plan Describes the quality procedures and standards that will be
used in a project.
Validation plan Describes the approach, resources and schedule used for
system validation.
Configuration Describes the configuration management procedures and
management plan structures to be used.
Maintenance plan Predicts the maintenance requirements of the system,
maintenance costs and effort required.
Staff development Describes how the skills and experience of the project team
plan. members will be developed.

161
 Fundamental of Engineering CH – 6

6.6.7 Project planning process

6.6.8 The Project Plan

A project plan is a critical document that outlines the framework for managing and
executing a software project. It specifies the resources available to the project, including
personnel, budget, and tools. Additionally, it defines the work breakdown structure, which
organizes the project into manageable tasks and activities. The plan also includes a
detailed schedule that lays out the timeline for completing each task, ensuring alignment
with overall project deadlines and objectives.

6.6.9 Project Plan Structure

The structure of a project plan typically consists of several key sections. The Introduction
provides an overview of the project, its objectives, and its scope. The Project Organisation
section defines roles, responsibilities, and the hierarchy within the project team. Risk
Analysis identifies potential challenges and outlines mitigation strategies to address
them. The plan also specifies Hardware and Software Resource Requirements, ensuring
that the necessary tools and infrastructure are in place. The Work Breakdown Structure
organizes the project into distinct tasks and activities, while the Project Schedule outlines
the timeline for these tasks. Finally, the plan includes Monitoring and Reporting
Mechanisms to track progress and communicate updates to stakeholders.

6.6.10 Activity Organization

Organizing project activities effectively is essential for ensuring tangible outputs that
allow management to assess progress. Each activity should contribute to producing
measurable results, providing clarity on the project's status. Milestones serve as the
endpoints of specific process activities, marking significant achievements or phases in
the project. Deliverables, on the other hand, are the tangible outputs or results that are
handed over to the customer, such as software prototypes, documentation, or final
system implementations. The Waterfall Process Model facilitates the straightforward

162
 Fundamental of Engineering CH – 6

definition of milestones, as it progresses sequentially through stages like requirements

analysis, design, implementation, testing, and deployment, making it easier to track
progress and assess completion at each stage.

6.6.11 Milestones in the Requirement Elicitation process

6.6.12 Project Scheduling

Project scheduling involves dividing the entire project into smaller tasks and estimating
the time and resources required to complete each one. This process ensures that tasks
are well-organized and can be worked on concurrently to make the best use of the
available workforce. By minimizing dependencies between tasks, scheduling helps avoid
delays that occur when one task must wait for another to be completed. Ultimately,
effective project scheduling relies heavily on the intuition and experience of the project
manager to balance task priorities and resource allocation.

6.6.13 Scheduling Problems

Several challenges can arise during the scheduling process. First, accurately estimating
the difficulty of problems and the associated cost of developing a solution can be a
complex and uncertain task. Additionally, productivity does not scale proportionally with
the number of people working on a task; simply adding more personnel does not
guarantee faster completion. In fact, adding people to an already delayed project can
exacerbate the issue due to the communication overheads introduced. Moreover,
unexpected events are an inevitable part of any project, which is why it is essential to
include contingency buffers in the planning to accommodate unforeseen circumstances
effectively.

163
 Fundamental of Engineering CH – 6

6.6.14 The project scheduling process

6.6.15 Bar charts and activity networks

Bar charts and activity networks are graphical tools used to illustrate a project schedule
effectively. These visual representations help in breaking down the project into
manageable tasks while providing clarity on task durations and dependencies. Tasks in
such charts are generally of appropriate size, spanning approximately one to two weeks,
ensuring they are neither too granular nor too broad.

Activity networks focus on task dependencies, highlighting the relationships between

tasks and identifying the critical path. The critical path represents the sequence of tasks
that directly affects the project's overall duration; any delay in these tasks will result in a
delay for the entire project. Activity networks are instrumental in visualizing the logical
flow of tasks and determining areas of high priority.

Bar charts, on the other hand, present the project schedule against calendar time. These
charts are ideal for showing start and end dates for tasks, making it easy to track progress
and timelines. They offer a straightforward way to monitor the schedule and
communicate project timelines with stakeholders. Together, these tools are invaluable for
effective project planning and management.

6.6.16 Task durations and dependencies

Activity 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)

164
 Fundamental of Engineering CH – 6

Activity network:

1 4/7 /03 15 da ys
15 da ys
M1 T3
8 da ys
T9
T1 5 da ys 4/8/03 2 5/8/03
2 5/7 /03
4/7 /03 T6 M4 M6
M3
star t 2 0 da ys 7 da ys
15 da ys
T7 T11
T2
25/7 /03 11/8/03 5/9/03
10 da ys 10 da ys
M2 M7 M8
T4 T5 15 da ys

T10 10da ys
1 8/7 /03
T12
M5

2 5 da ys
T8 Finish
19/9/03

Activity timeline:

4/7 11/7 18/7 2 5/7 1/8 8/8 1 5/8 22/8 2 9/8 5/9 12/9 1 9/9

Star t
T4
T1
T2
M1

T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Finish

165
 Fundamental of Engineering CH – 6

Staff Allocation

4/7 1 1/7 18/7 2 5/7 1/8 8/8 15/8 2 2/8 2 9/8 5/9 1 2/9 19/9

Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10

Jim T7

Mary T5

6.7 Critical Path Calculation

The critical path for a project is a key concept in project management and represents the
sequence of tasks that determines the shortest possible time to complete a project. To
calculate the critical path, the first step is to develop a detailed network diagram. This
diagram is constructed using an accurate activity list derived from the Work Breakdown
Structure (WBS), ensuring all tasks and dependencies are accounted for. Once the
network diagram is in place, the duration of each activity must be estimated, as these
durations are essential for identifying the critical path.

The calculation process involves determining the total duration of all possible paths
through the network by summing the durations of activities on each path. The longest path
through the network is designated as the critical path. Despite being the longest path in
terms of duration, it represents the shortest time required to complete the project
because any delays on the critical path directly impact the project's overall timeline.

The significance of the critical path lies in its impact on project scheduling. If any activity
on the critical path takes longer than planned, the entire project will be delayed unless
the project manager intervenes with corrective actions. Effective management of the
critical path often requires creative solutions, such as reallocating resources, optimizing
processes, or revising schedules, to prevent delays and ensure the project remains on
track.

166
 Fundamental of Engineering CH – 6

6.7.1 Program Evaluation and Review Technique (PERT)

• When there is a high degree of uncertainty about the individual activity duration
estimates, the network analysis Program Evaluation and Review Technique (PERT) can be
used to estimate project duration.

• PERT applies the critical path method (CPM) to a weighted average duration estimate.

• This approach was developed at about the same time as CPM, in the late 1950s, and it
also uses network diagrams

• PERT uses probabilistic time estimates—duration estimates based on using optimistic,

most likely, and pessimistic estimates of activity durations—instead of one specific or
discrete duration estimate, as CPM does.

• To use PERT, you have to calculate a weighted average of each project activity using the
following formula in order to have duration estimate of the project.

• By using the PERT weighted average for each activity duration estimate, the total project
duration estimate is calculated by taking the risk or uncertainty in the individual activity
estimates into account.

• Suppose that one of the activities was to design an input screen for the system. Someone
might estimate that it would take about two weeks or 10 workdays to do this activity.

167
 Fundamental of Engineering CH – 6

• Without using PERT, the duration estimate for that activity would be 10 workdays

• Using PERT, the project team would also need to estimate the pessimistic and optimistic
times for completing this activity.

• Suppose an optimistic estimate is that the input screen can be designed in eight
workdays, and a pessimistic time estimate is 24 workdays. Applying the PERT formula,
you get the following:

• Instead of using the most likely duration estimate of 10 workdays, the project team would
use 12 workdays when doing critical path analysis. These additional two days could help
the project team get the work completed on time.

• The main advantage of PERT is that it attempts to address the risk associated with
duration estimates. Because many projects exceed schedule estimates, PERT may help
in developing schedules that are more realistic.

• PERT’s main disadvantages are that it involves more work than CPM because it requires
several duration estimates, and there are better probabilistic methods for assessing
schedule risk.

6.7.2 Difference between PERT and CPM

168
 Fundamental of Engineering CH – 6

6.8 Float in Project Management`

In project management, float, also known as "slack," refers to the flexibility within a
project schedule. It measures the amount of time a task can be delayed without
affecting subsequent tasks or the overall project completion. Tracking float is crucial for
maintaining a project schedule and ensuring timely delivery of tasks.

There are two main types of float: Free Float (FF) and Total Float (TF). Free float is the
amount of time a task can be delayed without delaying the start of its immediate
successor task. The formula for calculating free float is:

Free Float (FF)=Earliest Start of Next Task−Earliest Finish of Current Task

Free float is helpful in determining which tasks should be prioritized and which can be
deferred to a later date. Tasks with zero or low float should be prioritized to avoid
impacting other tasks. Conversely, tasks with high float can be scheduled with more
flexibility since they do not immediately affect other tasks.

Total float, on the other hand, is the amount of time a task or project can be delayed
without delaying the project’s overall completion. The formula for total float is:

Total Float (TF)=Project Deadline−Finish Date of Last Task on the Critical Path

Monitoring total float is critical for keeping the overall project on schedule. If total float
nears zero, it indicates a crunch time where the final tasks must be completed
efficiently to meet the project deadline.

169
 Fundamental of Engineering CH – 6

Let’s consider an example of float in a practical scenario: a kitchen renovation project.

The critical path of the project includes tasks such as drywall installation, cabinet
installation, plumbing/electric work, and floor installation. These tasks are essential and
have zero float, meaning any delay in them will directly impact the project’s timeline.
However, non-critical tasks like painting and decorating have more flexibility. For
instance, painting can be completed anytime after drywall installation, giving it a high
float. Similarly, decorating can start after painting, so it also has some float.

In this scenario, float plays a significant role in prioritizing tasks. Tasks on the critical
path (with zero float) must be completed on time to avoid project delays. Tasks with
higher float can be deprioritized and scheduled later, as they don’t immediately affect
the critical path.

Float is not just a technical measure in network diagrams but a powerful tool for project
teams to understand their schedules better. Monitoring total float ensures the project
remains on track. If total float approaches zero, it is crucial to allocate additional
resources or optimize schedules to prevent delays. In some cases, project managers
may need to inform stakeholders about potential schedule changes to manage
expectations.

Float is a key component of the Critical Path Method (CPM), which helps project
managers schedule activities efficiently. However, calculating float manually can be
complex, especially for large projects. Professional project management software
automates float calculations, identifies critical paths, and provides real-time insights,
making it easier to manage schedules effectively.

In conclusion, float is a vital concept in project management that ensures schedules are
flexible and realistic. Understanding and monitoring float allows project managers to
prioritize tasks, manage resources effectively, and complete projects on time.

170
CHAPTER – 7
Resource levelling and scheduling

7.1 Acquiring the Project Team

Today, many organizations face a growing shortage of IT staff. Regardless of the state of
the job market, acquiring skilled and qualified IT professionals remains crucial for
organizational success. A well-known saying emphasizes this: "A project manager who is
the smartest person on the team has done a poor job of recruiting." This highlights the
importance of recruiting individuals with diverse skills and expertise to enhance the team.
Beyond recruitment, it is equally vital to assign the right type and number of people to
projects at the appropriate times. Effective resource assignment, resource
loading/scheduling, and resource leveling are key to ensuring project success.

7.2 Resource Assignment

After developing a project staffing management plan, project managers collaborate with
other organizational departments to assign personnel or acquire additional human
resources needed for their projects. Strong influencing and negotiation skills are often
essential for project managers to secure internal personnel for their projects. However,
organizations must ensure that individuals are assigned to projects that best align with
their skills and organizational needs.
The primary outputs of resource assignment include project staff assignments, resource
availability information, and updates to the project staffing management plan. Many
project teams also find it helpful to create a project team directory for better coordination.
Organizations that excel in staff acquisition typically have well-defined project staffing
plans. These plans specify the number and type of people currently available and the
additional resources anticipated for current and upcoming activities.
An essential aspect of staffing plans is maintaining an accurate and comprehensive
inventory of employees' skills. When there is a mismatch between the skills of available
employees and the needs of the project, it is the project manager's responsibility to work
with senior management, HR managers, and other stakeholders to address training and
staffing gaps. It is also critical to establish robust procedures for hiring subcontractors
and recruiting new employees.
Since the Human Resource (HR) department is primarily responsible for hiring, project
managers must work closely with HR to address any recruitment challenges. Retention of
IT professionals is another priority, and innovative approaches can help achieve this. For
example, some consulting firms incentivize current employees by offering them a dollar
for every hour worked by a new recruit they referred. This motivates employees to attract
new talent and helps in retaining them within the organization.
Offering personalized benefits is another effective strategy for retaining IT professionals.
For instance, allowing employees to work four days a week or offering flexible remote work
 Resource levelling and project cost control CH – 7

options can cater to individual needs. As competition for skilled IT professionals

intensifies, organizations must adopt innovative and proactive recruitment and retention
strategies while considering the needs of both employees and the organization. To make
sound project staffing decisions, project managers should study best practices from
leading companies and address the growing trend of forming virtual project teams, where
members collaborate remotely.

7.3 Resource Loading/Scheduling

Project time management often employs tools like network diagrams to develop project
schedules. However, traditional scheduling approaches tend to focus solely on timelines,
often overlooking resource utilization and availability. This is where critical chain
scheduling becomes significant, as it addresses both time and resource constraints.
One measure of a project manager's success is their ability to balance trade-offs among
performance, time, and cost. While additional resources may occasionally be added to a
project during crises at little or no cost, such situations are rare. Typically, resolving trade-
offs requires additional costs. The project manager's goal should be to achieve project
success without extending timelines or increasing costs. Effective human resource
management is key to achieving this goal.
Once resources are assigned, project managers can employ two techniques to optimize
resource usage: resource loading and resource leveling.

Resource Loading refers to the amount of individual resources that a project schedule
demands during specific time periods. This helps project managers understand how a
project impacts organizational resources and individual schedules. Resource histograms
are commonly used to illustrate variations in resource demands over time. These visual
tools can help identify staffing needs and problems, such as overallocation.
Overallocation occurs when insufficient resources are available to perform assigned
tasks within a given timeframe. It can arise from poor resource assignment or unrealistic
estimates of required work hours. To address this, project managers must provide
accurate estimates, recognizing that typical workers are only productive for 70–80% of
their assigned hours. For example, if an employee is scheduled for 40 hours of work in a
week, they are likely to achieve 28–32 hours of productive work. While exceptions exist, it
is unrealistic to expect 100% productivity.

Resource Leveling is a technique used to resolve resource conflicts by delaying tasks. Its
primary purpose is to create a smoother distribution of resource usage. Resource leveling
focuses on using resources efficiently, often driving scheduling decisions, including start
and finish dates.
Project managers analyze the network diagram to identify areas of slack or float and
resolve resource conflicts. For example, noncritical tasks may be delayed to address
overallocation without impacting the overall project timeline. In some cases, reducing
overallocation may require extending the project completion date.
Resource leveling addresses resource constraints often seen in critical chain scheduling.
If a resource is overallocated, the project manager can adjust the schedule to resolve the
conflict. Conversely, if a resource is underutilized, the schedule can be modified to
improve resource usage. The goal of resource leveling is to minimize variations in resource
loading by shifting tasks within their slack allowances.

172
 Resource levelling and project cost control CH – 7

Resource leveling offers several benefits. First, when resources are used consistently,
less management is required. For instance, managing an employee scheduled for 20
hours a week for three months is simpler than managing someone whose workload
fluctuates weekly (manage the same person for 10 hours one week, 40 the next, 5 the
next, and so on). Second, resource leveling can support just-in-time inventory policies for
subcontractors or other expensive resources. Third, it reduces confusion and
administrative workload associated with fluctuating labor levels, benefiting project
personnel and accounting departments. Finally, resource leveling improves morale by
providing employees with stability and predictability in their assignments, reducing
stress.

Project management software can automate resource leveling, but project managers
must review the results carefully. Automated leveling can inadvertently extend project
timelines or allocate resources inappropriately. To ensure effective leveling, project
managers should seek input from team members proficient in project management
software. This collaborative approach helps achieve optimal resource utilization without
compromising the project’s constraints.

Example for Resource Levelling and scheduling

173
 Resource levelling and project cost control CH – 7

7.4 Project Cost Control

7.4.1 What is cost?

A popular cost accounting textbook defines cost as "a resource sacrificed or foregone to
achieve a specific objective." Similarly, Webster’s dictionary defines cost as “something
given up in exchange.” Costs are typically measured in monetary terms, such as rupees,
which must be paid to acquire goods and services. Since projects consume resources
and cost money, it is crucial for project managers to understand project cost
management.
Many IT professionals often react skeptically to cost overrun information, recognizing that
initial cost estimates for IT projects are frequently unrealistic or based on unclear
requirements, leading to predictable overruns. Additionally, many IT projects involve
untested technologies or business processes, which inherently carry risks and unplanned
costs. While cost overruns are sometimes expected, using effective project cost
management tools can change this perception.

7.4.2 What is Project Cost Management?

Project cost management encompasses the processes required to ensure that a project
team completes a project within its approved budget. This includes two crucial elements:
defining the project and securing an approved budget. Project managers are responsible
for ensuring accurate time and cost estimates, realistic budgets, and stakeholder
satisfaction while continuously working to control and reduce costs.

There are four key processes involved in project cost management:

• Planning Cost Management: This involves determining the policies, procedures, and
documentation for planning, executing, and controlling project costs. The main
output is a cost management plan.
• Estimating Costs: This process involves approximating the costs of resources
needed for project completion. The outputs include activity cost estimates, basis of
estimates, and updated project documents.
• Determining the Budget: This step allocates the overall cost estimate to individual
work items to establish a baseline for performance measurement. Outputs include a
cost baseline, project funding requirements, and project documents updates.
• Controlling Costs: This involves monitoring and controlling changes to the project
budget. The outputs include work performance information, cost forecasts, change
requests, project management plan updates, and organizational process assets
updates.

174
 Resource levelling and project cost control CH – 7

7.4.3 Basic Principles of Cost Management

Most members of an executive board have a better understanding of financial terms

than IT terms and are more interested in finance. IT project managers must be proficient
in presenting and discussing project details in both financial and technical terms. They
must also understand several cost management concepts, including net present value
analysis, return on investment, and payback analysis.

Profits are defined as revenues minus expenditures. To increase profits, a company can
either increase revenues, decrease expenses, or achieve both. Executives often prioritize
profits over other considerations. For instance, estimating that an e-commerce
application will increase revenues by 10% for a $100 million company is only meaningful
when the profit margin is considered. Profit margin is the ratio of profits to revenues, with
examples including a 2% margin for $2 in profits per $100 in revenues.

Life Cycle Costing offers a comprehensive view of a project’s costs throughout its
entire life cycle, including both development and support costs. This approach allows
accurate projections of financial costs and benefits, considering the total cost of
ownership. For example, a customer service system might be developed over 1–2 years
but be operational for 10 years. Project managers, with assistance from financial experts
in their organizations, should create estimates of the costs and benefits of the project
for its entire life cycle. The net present value (NPV) analysis for such a project would
include the entire 10-year span of costs and benefits.

Cash Flow Analysis helps determine the annual costs and benefits of a project, leading
to an understanding of the resulting cash flow. This analysis is crucial for calculating NPV
and aiding top management in selecting projects. If too many high-cash-flow projects are
initiated in a single year, a company’s financial stability might be compromised.

Tangible and Intangible Costs and Benefits are critical for defining a project’s value.
Tangible costs or benefits, such as $100,000 spent on a feasibility study, are easy to

175
 Resource levelling and project cost control CH – 7

measure in rupees. Intangible costs or benefits, like goodwill or prestige, are harder to
quantify. Tangible and intangible costs and benefits are categories for determining how
well an organization can define the estimated costs and benefits for a project. Tangible
costs or benefits are easy to measure in rupees. Intangible costs or benefits are difficult
to measure in rupees.
For example, personal time spent researching or using company-owned resources may
constitute intangible costs, while increased productivity or reputation might represent
intangible benefits.

• If a company completed a project feasibility study for $100,000, its tangible cost is
$100,000.
• If a government agency estimated that it could have done the study for $150,000, the
tangible benefits of the study would be $50,000 to the government.
• Suppose John and few other people spent their own personal time using government-
owned computers, books, and other resources to research areas related to the study.
• Although their working hours and the government-owned materials would not be
billed to the project, they could be considered intangible costs
• Intangible benefits for projects often include items like goodwill, prestige, and general
statements of improved productivity that an organization cannot easily translate into
dollar amounts.

Direct Costs are directly linked to creating a project’s products or services, such as
employee salaries or hardware purchased specifically for a project. Project managers
should focus on controlling direct costs. For example, direct costs includes the salaries
of people working full time on the project and the cost of hardware and software
purchased specifically for the project. In contrast, Indirect costs are not directly related
to the products or services of the project, but they are indirectly related to performing
work on the project. For example, indirect costs would include the cost of electricity,
paper towels, and other necessities in a large building that houses 1,000 employees
who work on many projects. Indirect costs are allocated to projects, and project
managers have very little control over them

Sunk Costs refer to money already spent and irretrievable, much like a sunken ship.
Decisions about project investments should not factor in sunk costs. For example, if $1
million has already been spent on an unsuccessful project, this amount should not
influence the decision to continue funding it. Suppose John’s office had spent $1 million
on a project over the past three years to create a geographic information system, but
had never produced anything valuable. If his government were evaluating what projects
to be funded in the next year and an official suggested continuing to fund the geographic
information system project because $1 million had been spent on it already, the official
would incorrectly be making sunk cost a key factor in the project selection decision.

Learning Curve Theory states that when tasks are repeated, unit costs decrease over
time in a predictable pattern. For instance, the first handheld device in a project may
cost significantly more to produce than the thousandth unit. Suppose a project would
potentially produce 1,000 handheld devices that could run the new software and access
information via satellite. The cost of the first handheld unit would be much higher than
the cost of the thousandth unit. Learning curve theory can help estimate costs on

176
 Resource levelling and project cost control CH – 7

projects that involve the production of large quantities of items. Learning curve theory
also applies to the amount of time required to complete some tasks.

Reserves are budgeted amounts set aside to manage cost risks by considering the
future situations that are difficult to predict. Contingency Reserves account for known
unknowns, such as expected turnover rates. Contingency reserves allow for future
situations that may be partially planned for (sometimes called known unknowns) and
are included in the project cost baseline. For example, if an organization knows it has a
20 percent rate of turnover for IT personnel, it should include contingency reserves to
pay for recruiting and training costs of IT personnel. while Management Reserves cover
unpredictable events and it is not included in the project cost. For example, if a project
manager gets sick for two weeks or an important supplier goes out of business,
management reserve could be set aside to cover the resulting costs.

By understanding and applying these principles, project managers can ensure better
control over project costs and improve overall financial outcomes.

7.4.4 Planning Cost Management

Planning cost management is the first step in project cost management. It involves
determining how costs will be managed throughout the project’s life. The project manager
and other stakeholders collaborate using expert judgment, analytical techniques, and
meetings to create the cost management plan. This plan can be either informal and broad
or formal and detailed, depending on the project’s requirements.
A cost management plan typically includes several key components. It defines the level
of accuracy required for cost estimates and specifies the units of measure to be used,
such as staff hours or monetary values like rupees. It also includes organizational
procedures links, which align costs with the organization’s cost control procedures, and
sets control thresholds to determine acceptable variance levels before corrective action
is necessary. Additionally, it outlines the rules of performance measurement,
specifying methods for assessing project performance, and the reporting formats to be
used for cost performance reports. Finally, it provides process descriptions that detail
procedures for managing costs, including handling cost-related changes.

7.4.5 Controlling Costs

Controlling costs involves monitoring and managing changes to the project budget, and it
can be achieved through two key techniques: Earned Value Management (EVM) and
Project Portfolio Management.

EVM is a project performance measurement technique that integrates scope, time, and
cost data. By comparing actual project data to the cost performance baseline, project
managers can determine whether the project is meeting its scope, time, and cost
objectives.
Key components of EVM include:
Baseline: The original budget plus any approved changes.
Actual Information: Data such as whether a work breakdown structure (WBS) item was
completed, how much of the work was done, start and end dates, and actual costs.

177
 Resource levelling and project cost control CH – 7

EVM requires calculating three values for each activity or summary activity from the
project’s WBS:

• Planned Value (PV): Also called the budget, this is the approved total cost
estimate planned to be spent on an activity during a specific period.
• Actual Cost (AC): The total direct and indirect costs incurred in accomplishing
work on an activity during a specific period.
• Earned Value (EV): An estimate of the value of the physical work completed,
based on the original planned costs and the rate of progress.

Additionally, the Rate of Performance (RP) measures the ratio of actual work completed
to the percentage of work planned to have been completed at any given time.

Project Portfolio Management involves managing all projects or investments within an

organization as a single, interconnected portfolio. This approach allows organizations to
assess and control their projects more effectively. Modern tools and software provide
visual summaries of project performance, using color-coded indicators such as green,
yellow, and red to represent projects that are on track, facing minor issues, or
encountering major problems, respectively.
Organizations typically follow five levels of project portfolio management, ranging from
basic to advanced. At the simplest level, all projects are consolidated into a single
database. Next, projects are prioritized based on their importance or value. The third level
involves dividing projects into budgets according to their type, such as utilities,
incremental upgrades, or strategic investments. Automation is introduced at the fourth
level, streamlining project management processes. Finally, the fifth level applies
advanced portfolio management techniques, such as modern portfolio theory, which
uses risk-return tools to map project risks on a curve.
By understanding how individual projects align with the overall portfolio, project
managers can ensure their work contributes to the organization’s goals while keeping
costs under control.

178
 Resource levelling and project cost control CH – 7

7.5 Risk management

7.5.1 Overview of Risk management

Risk management is the process of identifying potential risks and creating strategies to
minimize their impact on a project. A risk refers to the likelihood of an adverse
circumstance occurring during a project, and these risks can be broadly categorized into
three types:
Project Risks: These risks affect the project’s schedule or resources, potentially causing
delays or increasing costs.
Product Risks: These risks impact the quality or performance of the software or product
being developed, leading to functionality or reliability issues.
Business Risks: These risks influence the organization responsible for developing or
procuring the software, possibly affecting its operations or goals.

Software risks:

Risk Affects Description

Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a change of organisational management with
different priorities.
Hardware unavailability Project Hardware that is essential for the projec t will not be
deli vered on schedule.
Requirements change Project and There will be a larger number of changes to the
product requirements than anticipated.
Specification delays Project and Specifications of essential interfaces are not available on
product schedule
Size underestimate Project and The size of the system has been underestim ated.
product
CASE tool under- Product CASE tools which support the project do not perform as
performance anticipated
Technology change Business The underlying technology on which the system is b uilt is
superseded by new technology.
Product competition Business A competitive product is marketed before the system is
completed.

7.5.2 The Risk Management Process

Risk management involves the following key steps:

1. Risk Identification: This step focuses on identifying potential risks related to the
project, product, and business. It involves listing all possible issues that could arise
during the project.

179
 Resource levelling and project cost control CH – 7

2. Risk Analysis: Once risks are identified, they are analyzed to assess their likelihood
and potential impact. The probability of each risk is categorized as very low, low,
moderate, high, or very high. The risk effects are classified into four levels:
o Catastrophic: Significant damage or failure.
o Serious: Major disruptions or consequences.
o Tolerable: Manageable but noticeable issues.
o Insignificant: Minimal impact.
3. Risk Planning: After analyzing risks, plans are created to either avoid or minimize their
effects. This step involves devising strategies to handle risks effectively, such as
contingency plans or preventive measures.
4. Risk Monitoring: Throughout the project, identified risks are monitored to track their
status and assess whether they have been mitigated or require additional action. This
step ensures risks are managed proactively and adjustments can be made as
necessary.

7.5.3 Risk identification

Technology Risks: These arise from the use of unproven or rapidly changing technologies,
which may result in unforeseen challenges or failures during project development.
People Risks: These are related to the skills, availability, or performance of team
members, such as insufficient expertise or high turnover rates.
Organizational Risks: These stem from issues within the organization, including lack of
support, resource constraints, or conflicts between departments.
Requirements Risks: These occur when project requirements are unclear, constantly
changing, or not well understood, leading to potential scope creep or rework.
Estimation Risks: These are linked to inaccurate cost, time, or resource estimates,
potentially resulting in delays or budget overruns.

180
 Resource levelling and project cost control CH – 7

Risk type Possible risks

Technology The database used in the system cannot process as many transactions per second
as expected.
Software components that should be reused contain defects that limit their
functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management are responsible for
the project.
Organisational financial problems force reductions in the project budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements that require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.

7.5.4 Risk analysis

Risk Analysis involves evaluating the likelihood and potential impact of each identified
risk. The probability of a risk occurring can be categorized as very low, low, moderate, high,
or very high. The consequences of the risk can be classified based on its effects, which
may range from catastrophic (severe project disruption), serious (significant delays or
costs), tolerable (manageable impact), to insignificant (minimal effect on the project).
This analysis helps prioritize risks and focus on the most critical ones.

Risk Probability Effects

Organisational financial problems force reductions in Low Catastrophic
the project budge t.
It is impossible to recruit staff with the skills required High Catastrophic
for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused contain Moderate Serious
defects which limit their functionality.
Changes to requirements that require major design Moderate Serious
rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.

181
 Resource levelling and project cost control CH – 7

Risk Probability Effects

The database used in the system cannot process as Moderate Serious
many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant

7.5.5 Risk planning

Risk Planning involves analyzing each identified risk and devising strategies to manage
them effectively. The first approach is avoidance strategies, which aim to reduce the
likelihood of the risk occurring by taking preventive measures. The second approach is
minimization strategies, which focus on mitigating the potential impact of the risk on the
project or product. Additionally, contingency plans are prepared to address risks if they
materialize, ensuring the project can proceed with minimal disruption. These strategies
collectively help in managing risks proactively and maintaining project stability.

Risk management strategies

Risk Strategy
Organisational Prepare a briefing document for senior management
financial problems showing how the project is making a very important
contribution to the goals of the business.
Recruitment Alert customer of potential difficulties and the
problems possibility of delays, investigate buying-in
components.
Staff illness Reorganise team so that there is more overlap of work
and people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-
components in components of known reliability.

182
 Resource levelling and project cost control CH – 7

Risk Strategy
Requirements Derive traceability information to assess requirements
changes change impact, maximise information hiding in the
design.
Organisational Prepare a briefing document for senior management
restructuring showing how the project is making a very important
contribution to the goals of the business.
Database Investigate the possibility of buying a higher-
performance performance database.
Underestimated Investigate buying in components, investigate use of a
development time program generator

7.5.6 Risk monitoring

Risk Monitoring emphasizes the regular evaluation of identified risks to determine if their
likelihood or potential impact has changed over time. This involves reassessing each risk
to understand whether it is becoming more or less probable and whether its
consequences have shifted. Regular monitoring ensures that emerging risks are identified
and managed promptly. Key risks should be discussed in management progress meetings
to maintain oversight and ensure effective risk control throughout the project lifecycle.

Risk types and indicators

Risk type Potential indicators
Technology Late delivery of hardware or support software, many reported
technology problems
People Poor staff morale, poor relationships amongst team member,
job availability
Organisational Organisational gossip, lack of action by senior management
Tools Reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powered workstations
Requirements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported
defects

183
CHAPTER – 10
Project control
10.1 Monitoring and Controlling Project Work

On large projects, many project managers state that 90 percent of the job involves
communicating and managing changes. Changes are inevitable on most IT projects, so
it’s important to develop and follow a process to monitor and control changes. Monitoring
project work includes collecting, measuring, and disseminating performance
information. It also involves assessing measurements and analyzing trends to determine
what process improvements can be made. The project team should continuously monitor
project performance to assess the overall health of the project and identify areas that
require special attention. The project management plan, schedule and cost forecasts,
validated changes, work performance information, enterprise environmental factors, and
organizational process assets are all important inputs for monitoring and controlling
project work.
The project management plan provides the baseline for identifying and controlling project
changes. A baseline is the approved project management plan plus approved changes.
For example, the project management plan includes a section that describes the work to
perform on a project. This section of the plan describes the key deliverables for the
project, the products of the project, and quality requirements. The schedule section of
the project management plan lists the planned dates for completing key deliverables, and
the budget section of the plan provides the planned cost of these deliverables. The project
team must focus on delivering the work as planned.
If the project team or someone else causes changes during project execution, the team
must revise the project management plan and have it approved by the project sponsor.
Many people refer to different types of baselines, such as a cost baseline or schedule
baseline, to describe different project goals and performance required towards meeting
them more clearly. Schedule and cost forecasts, validated changes, and work
performance information provide details on how project execution is going.
The main purpose of this information is to alert the project manager and project team
about issues that are causing problems or might cause problems in the future. The project
manager and project team must continuously monitor and control project work to decide
if corrective or preventive actions are needed, what the best course of action is, and when
to act. Important outputs of monitoring and controlling project work include change
requests and work performance reports.
Many organizations use a formal change request process and forms to keep track of
project changes. Work performance reports include status reports, progress reports,
memos, and other documents used to communicate performance in the project. Change
requests include recommended corrective and preventive actions and defect repairs.
Corrective actions should result in improvements in project performance. Preventive
 Project control CH – 10

actions reduce the probability of negative consequences associated with project risks.
Defect repairs involve bringing defective deliverables into conformance with
requirements.

10.2 Performing Integrated Change Control

Integrated change control involves identifying, evaluating, and managing changes

throughout the project lifecycle. The three main objectives of integrated change control
are influencing the factors that create changes to ensure that changes are beneficial,
determining that a change has occurred, and managing actual changes as they occur.
To ensure that changes are beneficial and that the project is successful, project managers
and their teams must balance trade-offs among key project dimensions, such as scope,
time, cost, and quality. To determine that a change has occurred, the project manager
must know the status of key project areas at all times. In addition, the project manager
must communicate significant changes to top management and key stakeholders.
Top management and other key stakeholders do not like surprises, especially ones that
mean the project might produce fewer benefits, take longer to complete, cost more than
planned, or create products of lower quality. Managing change is a key role of project
managers and their teams. It is important that project managers exercise discipline in
managing projects to help minimize the number of changes that occur.
Important inputs and outputs to the integrated change control process are as follows:
inputs include the project management plan, work performance information, change
requests, enterprise environmental factors, and organizational process assets. Outputs
include approved change requests, a change log, and updates to the project management
plan and project documents.

10.2.1 Change Requests

Change requests are common on IT projects and may occur in many different forms. They
may create minor or major impacts on a project and can be oral or written, formal or
informal. For example, a project team member responsible for installing a server might
ask the project manager if it is acceptable to order a server with a faster processor than
planned.
The server is from the same manufacturer and has the same approximate cost. The
project manager might give verbal approval at the progress review meeting of the project
because this change is positive and doesn’t have negative effects on the project.
Nevertheless, it is still important that the project manager document this change to avoid
any potential problems in the future.
The appropriate team member should update the scope statement to include the new
server specifications. However, many change requests can have a major impact on a
project. For example, customers who change their minds about the number of hardware
components they want as part of a project will have a definite impact on the scope and
cost of the project.
Such a change might also affect the project’s schedule. The project team must present
such significant changes in written form to the project sponsor, and there should be a
formal review process for analyzing and deciding whether to approve these changes.

266
 Project control CH – 10

10.2.2 Change Control System

Change is unavoidable and often expected on most IT projects. Technologies change,

personnel change, organizational priorities change, and so on. A good change control
system is also important for project success.
A change control system is a formal, documented process that describes when and how
official project documents may be changed. It also describes the people authorized to
make changes, the paperwork required for these changes, and any automated or manual
tracking systems that the project can use to track the changes and update.
A change control system often includes a change control board, configuration
management, and a process for communicating changes. A change control board (CCB)
is a formal group of people responsible for approving or rejecting changes to a project.
The primary functions of a CCB are to provide guidelines for preparing change requests,
evaluating change requests, and managing the implementation of approved changes. An
organization could have key stakeholders for the entire organization on this board, and a
few members could be rotated based on the unique needs of each project.
By creating a formal board and a process for managing changes, overall change control of
the project will be improved. Configuration management is another important part of
integrated change control.

Configuration management ensures that the descriptions of the project’s products are
correct and complete. It involves identifying and controlling the functional and physical
design characteristics of products and their support documentation.
Configuration management specialists are responsible for identifying and documenting
the functional and physical characteristics of the project’s products, controlling any
changes to such characteristics, recording and reporting the changes, and auditing the
products to verify conformance with requirements.
Another critical factor in change control is communication. Project managers should use
written and oral performance reports to help identify and manage project changes. One
of the most frustrating aspects of project change is not having everyone coordinated and
informed about the latest project information.
It is the project manager’s responsibility to integrate all project changes so that the project
stays on track. The project manager and staff members must develop a system for
notifying everyone affected by a change in a timely manner.
E-mail, real-time databases, cell phones, and the Web make it easy to disseminate the
most current project information. Project managers must also provide strong leadership
to steer the project to successful completion.
They must not get too involved in managing project changes. Project managers should
delegate much of the detailed work to project team members and focus on providing
overall leadership for the project in general.
Remember, project managers must focus on the big picture and perform project
integration management well to lead their team and organization to success.

10.3 Project audit and project termination

10.3.1 Closing Projects or Phases

267
 Project control CH – 10

The final process in project integration management is closing the project or phase. This
involves finalizing all activities and transferring the completed or cancelled work to the
appropriate stakeholders. The primary tool and technique used in this process is expert
judgment. The main inputs to this process are the project management plan, accepted
deliverables, and organizational process assets. The key outputs of closing projects
include the final product, service, or result transition, as well as updates to organizational
process assets.

10.3.2 Final Product, Service, or Result Transition

Project sponsors are usually most concerned with ensuring they receive the final
products, services, or results they expected when they approved the project. For items
produced under contract, the formal acceptance or handover typically includes a written
statement confirming that the contract terms and requirements were properly met. For
internal projects, this might include a project completion form or a similar
acknowledgment of project closure.

10.3.3 Organizational Process Asset Updates

The project team is responsible for providing a comprehensive list of project
documentation, project closure documents, and historical information in a useful format.
This information becomes a valuable organizational process asset. Typically, project
teams produce a final project report, which often includes a transition plan detailing the
work to be undertaken during the operational phase following project completion.
Additionally, teams often write a lessons-learned report at the project's conclusion. This
report can serve as an invaluable resource for future projects. Many organizations also
conduct post-implementation reviews to evaluate whether the project achieved its
objectives. Information gathered from these reviews is also stored as an organizational
process asset for use in future projects.

10.3.4 Use of Project Management Software

Project management software plays a vital role in developing and integrating project
planning documents, executing project management plans, monitoring and controlling
project activities, and managing integrated change control. Small project teams may rely
on low-end or midrange project management software to coordinate their work
effectively. For larger projects, organizations can benefit from high-end tools offering
enterprise project management capabilities. These tools integrate all aspects of project
management and provide comprehensive support for managing complex projects.

268