Project Management

A project is a temporary endeavour undertaken to create a unique

product, service or result. Temporary indicates that it has a definite
beginning and end. Projects involve doing something that has not been
done before and is therefore unique. Outcome of the project can be
tangible or intangible. Project Management is the application of
Knowledge, Skills, Tools and Techniques to Project activities to meet
Project requirements.

Float/Slack
In project management, float or slack is the amount of time that a task in
a project network can be delayed without causing a delay to:

Subsequent tasks (free float): Free Float is the amount of time that an
activity can be delayed without delaying the early start date of any
successor activity.

Project completion date (total float): Total Float is the amount of time
that an activity can be delayed from its early start date without delaying
the project finish date.

A critical path may have 'unused time' expressed as total float. For
example a project to measure seasonal variation in sunrise would take a
one minute measurement every day, followed by 23 hours and 59 minutes
of total float. Sunrise is on the critical path and there is no way to
schedule around it. Total float is associated with the path. If a project
network chart/diagram has 4 non-critical paths then that project would
have 4 total float values. The total float of a path is the combined free
float values of all activities in a path.

What exactly is the “Successful” Project?

You would think it would be relatively straightforward to describe the
attributes of a successful project. Well, let’s just say this endeavour has
kept more than a few “spin doctors,” “politicians,” and “history
revisionists” employed throughout organizations across our great land.

Why is this the case?

There are several reasons for this:
• There is a lack of universal harmony of what comprises project success
metrics. It seems that every project management educational source and
organizational process maturity standard has a slightly different definition
of project success.

Operations Book
• For many projects, the acceptance and success criteria are never
established or agreed to by all key stakeholders

• In many cases, an organization might define a project as successful

even when some of the textbook criteria for project success (such as
schedule, cost, and client expectations) are not completely met. This is
often the case if the project achieved strategic business or organizational
objectives.

• In other cases, a “cancelled” project might be a “successful” project if

there was a plan for one or more “go/no-go” decision points.

From a utopian, academic standpoint, the “ultimate” successful project

would be defined as a project that:

 Delivers as promised: Project produces all the stated deliverables

 Completes on-time: Project completes within the approved
schedule
 Completes within budget: Project completes under the approved
budget
 Delivers quality: Project deliverables meet all functional,
performance, and quality specifications
 Achieves original purpose: The project achieves its original
goals, objectives, and purpose
 Meets all stakeholder expectations: The complete expectations
of each key stakeholder are met, including all client acceptance
criteria, and each key stakeholder accepts the project results
without reservation
 Maintains “win-win” relationships: The needs of the project are
met with a “people focus” and do not require sacrificing the needs
of individual team members or vendors.

Participants on successful projects should be enthusiastic when the

project is complete and eager to repeat a similar experience.

Project Management Methodologies

Waterfall Model of Project Management
The original Waterfall method, as developed by Royce. The steps include
Requirements Determination, Design, Implementation, Verification, and

Operations Book
Maintenance. Other models change the Requirements phase into the Idea
phase (or break the Requirements phase out into Planning and Analysis.
Furthermore, some models further break the Design phase out into
Logical and Physical Design sub-phase, however, the basic underlying
principles remain the same.

The Waterfall method makes the assumption that all requirements can be
gathered up front during the Requirements phase. Communication with
the user is front- loaded into this phase, as the Project Manager does his
or her best to get a detailed understanding of the user's requirements.
Once this stage is complete, the process runs "downhill".

The Design phase is best described by breaking it up into Logical

Design and Physical Design sub-phases. During the Logical Design
phase, the system's analysts makes use of the information collected in the
Requirements phase to design the system independently of any hardware
or software system. Once the higher-level Logical Design is complete, the
systems analyst then begins transforming it into a Physical Design
dependent on the specifications of specific hardware and software
technologies.

The Implementation phase is when all of the actual code is written.

Phase belongs to the programmers in the Waterfall method, as they take
the project requirements and specifications, and code the applications.

The Verification phase was originally called for to ensure that the
project is meeting customer expectations. However, under real-world
analysis and design, this stage is often ignored. The project is rolled out to
the customer, and the Maintenance phase begins.

During the Maintenance phase, the customer is using the developed

application. As problems are found due to improper requirements

Operations Book
determination or other mistakes in the design process, or due to changes
in the users' requirements, changes are made to the system during this
phase.

The Waterfall method does have certain advantages, including: • Design

errors are captured before any software is written saving time during the
implementation phase.

 Excellent technical documentation is part of the deliverables and it is

easier for new programmers to get up to speed during the
maintenance phase.
 The approach is very structured and it is easier to measure progress by
reference to clearly defined milestones.
 The total cost of the project can be accurately estimated after the
requirements have been defined (via the functional and user interface
specifications).
 Testing is easier as it can be done by reference to the scenarios
defined in the functional specification.

Unfortunately, the Waterfall method carries with it quite a few

disadvantages, such as:

 Clients will often find it difficult to state their requirements at the

abstract level of a functional specification and will only fully appreciate
what is needed when the application is delivered. It then becomes very
difficult (and expensive) to re-engineer the application.
 The model does not cater for the possibility of requirements changing
during the development cycle.
 A project can often take substantially longer to deliver than when
developed with an iterative methodology such as the agile
development method. ("The Waterfall Development Methodology",
2006).

Agile Project Management

Agile Project Management is one of the revolutionary methods introduced
for the practice of project management. This is one of the latest project
management strategies that is mainly applied to project management
practice in software development.

Therefore, it is best to relate agile project management to the software

development process when understanding it.
From the inception of software development as a business, there have
been a number of processes following, such as the waterfall model. With
the advancement of software development, technologies and business
requirements, the traditional models are not robust enough to cater the

Operations Book
demands. Therefore, more flexible software development models were
required in order to address the agility of the requirements. As a result of
this, the information technology community developed agile software
development models.

'Agile' is an umbrella term used for identifying various models used for
agile development, such as Scrum. Since agile development model is
different from conventional models, agile project management is a
specialized area in project management.

The Agile Process

It is required for one to have a good understanding of the agile
development process in order to understand agile project management.

There are many differences in agile development model when compared

to traditional models:

 The agile model emphasizes on the fact that entire team should be a
tightly integrated unit. This includes the developers, quality assurance,
project management, and the customer.
 Frequent communication is one of the key factors that makes this
integration possible. Therefore, daily meetings are held in order to
determine the day's work and dependencies.
 Deliveries are short-term. Usually a delivery cycle ranges from one
week to four weeks. These are commonly known as sprints.
 Agile project teams follow open communication techniques and tools
which enable the team members (including the customer) to express
their views and feedback openly and quickly. These comments are then

Operations Book
 taken into consideration when shaping the requirements and
implementation of the software.

Scope of Agile Project Management

In an agile project, the entire team is responsible in managing the team
and it is not just the project manager's responsibility. When it comes to
processes and procedures, the common sense is used over the written
policies.

This makes sure that there is no delay is management decision making

and therefore things can progress faster. In addition to being a manager,
the agile project management function should also demonstrate the
leadership and skills in motivating others.

This helps retaining the spirit among the team members and gets the
team to follow discipline.
Agile project manager is not the 'boss' of the software development team.
Rather, this function facilitates and coordinates the activities and
resources required for quality and speedy software development.

Responsibilities of an Agile Project Manager

The responsibilities of an agile project management function are given
below. From one project to another, these responsibilities can slightly
change and are interpreted differently.

 Responsible for maintaining the agile values and practices in the

project team.
 The agile project manager removes impediments as the core function
of the role.
 Helps the project team members to turn the requirements backlog into
working software functionality.
 Facilitates and encourages effective and open communication within
the team.
 Responsible for holding agile meetings that discusses the short-term
plans and plans to overcome obstacles.
 Enhances the tool and practices used in the development process.
 Agile project manager is the chief motivator of the team and plays the
mentor role for the team members as well.

Critical Chain Project Management

Critical Chain Project Management was developed and publicized by Dr.
Eliyahu M. Goldratt in 1997.

Operations Book
Followers of this methodology of Project Management claim it to be an
alternative to the established standard of Project Management as
advocated by PMBOK® and other Standards of Project Management.

The Critical Chain Method has its roots in another one of Dr. Goldratt’s
inventions, namely, The Theory of Constraints (TOC). This Project
Management Method comes into force after the initial Project Schedule is
prepared, which includes establishment of the task dependencies. The
evolved Critical path is reworked based on the Critical Chain Method. To
do so, the methodology assumes constraints related to each task.

A few of these constraints are listed out below:

 There is a certain amount of uncertainty in each task

 Task durations are often overestimated by the Team Members or Task
Owners. This is typically done to add a safety margin to the task so as
to be certain of its completion in the decided duration.
 In most cases, the tasks should not take the time estimated, which
includes the safety margin, and should be completed earlier.
 If the Safety Margin assumed is not needed, it is actually wasted. If the
task is finished sooner, it may not necessarily mean that the successor
task can start earlier as the resources required for the successor task
may not be available until their scheduled time. Hence, the saved time
cannot be passed on to finish the Project early. On the other hand, if
there are delays over and above the estimated schedules, these delays
will most definitely get passed on, and, in most cases, will
exponentially increase the Project Schedule.

With the above assumptions, the Critical Path Methodology of Project

Management recommends pooling of the task buffers and adding them at
the end of the Critical path

The Critical Path Project Management defines three types of Buffers -

 Project Buffer - The total pooled buffer shown above, is referred to as

the Project Buffer.
 Feeding Buffer - In a Project Network, there are path/s which feed into
the Critical path. The pooled buffer on each such path represents the
Feeding Buffer to the Critical Path resulting in providing some slack to
the critical Path.
 Resource Buffer- This is a virtual task inserted just before critical chain
tasks that require critical resources. This acts as a trigger point for the

Operations Book
 resource, indicating when the critical path is about to begin.

As the Progress of the Project is reported, the Critical Chain is

recalculated. In fact, monitoring and controlling of the Project primarily
focuses on utilization of the Buffers. Hence the Critical Chain Method
considers the basic Critical Path based Project Network and Schedule to
derive a completely new Schedule.

The Critical Path Project Management Methodology is very effective in

organizations which do not have evolved Project Management Practices.
However, the methodology does not advocate multi-tasking, and in
Projects with complex Schedule Networks, the results of implementing the
Critical path Methodology have proven to be deterrent to the overall
Project Schedule. In addition, there is no standard method for calculating
and optimizing the Project Buffers. The Critical Path Project Management
Methodology has had a fair amount of success in manufacturing domains
though it has not achieved any noteworthy success in the IT Sector.

Triple Constraint
All projects are carried out under certain constraints:

Operations Book
• Cost • Time • Scope

These three factors (commonly called 'the triple constraint') are

represented as a triangle.

Each constraint forms the vertices, with quality as the central theme:

 Projects must be delivered within cost

 Projects must be delivered on time
 Projects must meet the agreed scope – no more, no less
 Projects must also meet customer quality requirements

Process Groups
Project Management Processes can be organized into 5 process groups
(IPECC):

Initiating Process Group

The initiating process group involves the processes, activities, and skills
needed to effectively define the beginning of a project. Setting all permits,
authorizations, and initial work orders in place to secure an effective and
logical progression of initial project activities sets the stage for
subsequent success throughout all project phases.

Planning Process Group

The Planning Process Group sets forth the processes needed to define the
scope of the project, set strategic plans in place to maximize workflow,
and begin to assemble priority lists and plan team needs. This process
group also addresses a more narrow clarification of all project goals and
expectations and puts in place the project infrastructure necessary to
achieve those goals according to the timeline and budgetary constraints.

Executing Process Group

The executing process group involves managing teams effectively while
orchestrating timeline expectations and reaching benchmark goals.

Monitoring and Control Process Group

Processing change orders, addressing on-going budget considerations,
and mitigating unforeseen circumstances that may affect a team’s ability
to meet initial project expectations are all part of the Monitoring Process

Operations Book
Group.

Closing Process Group

The Closing Process Group involves closing all aspects of the process and
submitting necessary paperwork on time

GANTT chart:
A Gantt chart is a type of bar chart that illustrates a project schedule.
Modern Gantt charts also show the dependency relationships between
activities and current schedule status. An example of Gantt chart for a
software development project is as shown in the following image.

Operations Book