A Critical Reflection on Project Management

Samuel Hindmarsh
School of Engineering and Computer Science
Victoria University of Wellington,
PO Box 600, Wellington, New Zealand
Email: Samuel.Hindmarsh@ecs.vuw.ac.nz

Introduction

An engineering project requires a high level of management in order to ensure a positive outcome.
Throughout this course, we have learnt what a project
is and why project management is important, along
with a number of tools and techniques for managing
a project. The real difficulty in management, however, is knowing how these techniques are relevant to
a given situation, and being able to apply these techniques accordingly. It is also important to be aware of
other team members, and it is this social intelligence
which can be the difference between a good project
manager and a successful one.

successful unless the project manager has high social

intelligence. The key to social intelligence is being
aware of other members of the projects team, and how
each member affects one another. This awareness of
the project comes partially from observing from a distance; however, the majority of a project managers
awareness comes from their ability to communicate
effectively with their team, and therefore their ability
in team management. The crux of project management is ensuring that the project stays in line with
reality at all times (Allan 2011a) this means staying
within budget and time constraints by giving reasonable estimates and managing the team effectively.
3

What is a Project and Project Management?

A project can be defined as a temporary and collaborative undertaking resulting in the creation of a
unique product or service. This definition outlines a
number of important qualities which are essential to a
project. For starters, a project must have a structure,
generally involving an ordered set of stages falling between start and end dates. A project will also have a
set budget; however, this may change as initial estimates are improved upon throughout the duration of
the project. Projects are also executed in an iterative
fashion, such that the plans are updated as details
of the project become clearer. Resources are always
required by a project, and are often provided by the
projects customer (Schwalbe 2008). Finally, the most
significant element of a project is noted in the last
few words of the definition: a unique result must be
obtained from any project. That is, a process which
results in achieving an aim which has been already
been accomplished cannot be considered a project
projects do not reinvent the wheel! The success of
a project has traditionally been measured using the
Iron Triangle (Atkinson 1999). In order for a project
to be successful according to the Iron Triangle, the
projects constraints and targets with regards to cost,
time and scope must be met. Although popular in
the past, the Iron Triangle has fallen out of favour as
the be-all and end-all measure of success due to its
exclusion of other important factors, such as benefits
to the project stakeholders.
Every project is risky by nature because, by definition, projects cover new ground. This uncertainty
means that projects are difficult to keep within budget, on time and to an acceptable level of quality.
Because of this, project management is vitally important in order to carry out a successful project. Project
management involves a variety of different tools and
techniques, such as planning tools, team management
and risk management however, a project cannot be

Structure of a Project

Before a project can be initiated, a business case must

first be established. A business case is the reason for
initiating a project, expressed in terms of socioeconomic benefits. The business case is built from the evidence gathered from carrying out a feasibility study,
stage zero of a project. A feasibility study is carried
out in order to answer the question, Can this project
be successful? Due to this nature, a negative outcome
from the feasibility study should result in the project
not proceeding; unfortunately, not all managers realise this, and occasionally some projects are initiated
despite being destined to fail from the start. The four
factors which must be considered during a feasibility
study include economic feasibility, social feasibility,
technical feasibility and operational feasibility. Economic feasibility refers to the balance between the
cost of the project and the expected benefit. Social feasibility refers to the whether the outcome of
the project will be a burden on employees, stakeholders, nature or culture. Technical feasibility considers whether the technology exists in order to execute
a successful project to the required level of quality.
Finally, operational feasibility takes the outcome of
the project into account and considers whether it will
cause undesired changes inside and outside the company. If and only if, after taking these four factors
into account, the project is deemed to have a positive
outcome with little or no negative side-effects, then
the project can proceed.
Once the project has been justified, the project
work may begin. In an engineering project, the work
is split into nine distinct stages. The initial stage is
the project initiation stage. This involves the creation of the Project Initiation Document (PID), a
document which outlines key details of the project.
These details include the project aim and objectives,
restrictions such as time frame and budget, as well
as a collection of risks and an allocation of the work
amongst team members. This stage is important as it
acts as an agreement between the stakeholders to exe-

cute the project, and as such should be signed by each

stakeholder. The second stage is the requirements engineering stage, which involves collecting three types
of requirements: user requirements, which are the
requirements of the project as defined by the user;
project requirements, which are the requirements defined by the budget, timeframe, communication lines
and the project objectives; and the system requirements, which are the responsibilities the system must
fulfil. The system design stage is the third stage, and
can be considered to be the thinking stage. It involves
designing the structure and flow of data through the
use of charts and diagrams. Software construction is
the fourth stage, and comprises of either purchasing
commercially available software or building the software required by the system. Similarly, the hardware
purchase stage requires the acquisition of hardware
necessary for a complete system this may include
computer equipment and office equipment. The sixth
stage is the system testing stage: whilst testing is essential before, during and after every stage to ensure
the expected outcome is achieved, this stage tests the
system as a whole, and determines whether all the requirements are met after all, a project which has not
met the requirements cannot be considered a successful project. Once the system is confirmed to be free
of bugs and fulfils the requirements, installation can
proceed. This seventh stage considers how the new
system will integrate with the old system, or replace it
entirely. Once the system is installed, the project can
be closed-down. In order to close the project down,
a plan must be established for future upgrades to the
system. The finance department must also ensure all
outstanding payments have been made and received.
Finally, the on-going ninth stage is the maintenance
stage. Maintenance includes implementing the preprepared upgrade plan as required and fixing any bugs
which may occur in the system.
The stages of an engineering project are not simply executed concurrently in such a linear fashion,
but more often iteratively. In order to structure the
project, the stages are executed in an order specified by a lifecycle model. The Waterfall model is one
of the earliest lifecycle models and was proposed by
Winston Royce in 1970. It is regarded today as a
flawed model Royce himself noted that it is risky and
invites failure (Royce 1987) due to its rigidity and inflexibility; however, its simplicity makes it suitable for
smaller projects due to it having low overhead. For
other projects, the rigidity of the model has the undesired effect that any changes made down the waterfall
(for example, in the system testing stage) will not be
reflected upstream (for example, in the system design stage). Boehms spiral model attempts to rectify
this problem by introducing iterative development to
the project. When following the spiral model, the
project performs multiple cycles of design, risk analysis, development and user evaluation until the system
meets the requirements and upholds the required level
of quality. This iteration allows us to revisit stages
and make changes as required, resulting in a project
which is easier to amend. A more modern model, the
V model involves writing tests at every stage during
design and development, and performing the tests in
reverse order after development is complete. If any
test fails, the appropriate stage is revisited and the
model restarts from that stage. Each lifecycle model
has associated benefits, and choosing the appropriate model for a given project can help the project be
successful.

Planning a Project

Once the project has been justified and an appropriate lifecycle model chosen, it is possible to begin
planning the project. It is important to note that the
plans created at the beginning of a project are the
initial plans and are never finalised. In order for a
project to succeed, the plans must undergo continuous process improvement as more reliable estimates
are established. With this in mind, it is important
to realise that it is not possible to create the perfect
plan at the start, and time should not be unnecessarily wasted attempting to achieve such a feat. Instead,
a reasonable plan should be developed initially with
changes made throughout the projects lifecycle. One
of the advantages of creating plans is that it allows
us to visualize the information because humans generally learn visually, a number of planning tools have
been developed to aid with managing projects. The
first of these is the work breakdown structure (WBS),
a diagram which allows us to visualize the various
components of the project. Although it does not show
dependencies or give an indication of time, it is a good
method of keeping the team motivated. Motivation
is one of the keys to a positive project, as a motivated team will achieve a greater sense of satisfaction from their work and therefore apply themselves
with more effort, resulting in better quality work overall. The Gantt chart addresses the limitations of the
WBS by representing the tasks on a chart as a series of events with start and end dates. Dependencies
can also be shown on the Gantt chart with a minor
modification, making the Gantt chart a useful tool
overall for monitoring whether the project is running
to schedule. The precedence network is an important
alternative to the Gantt chart, as it introduces the
idea of multiple paths. Having these multiple paths
means introducing float (time for unexpected delays)
in between sections. It is important to keep the levels of float within reasonable constraints, as too high
a float will result in unnecessarily long development
time, whereas too low a float means there is no leeway
for running overtime during any one activity.
These planning tools are perfect for when a project
is without problems. However, all projects encounter
difficulties at some point, and how these difficulties
affect the project as a whole depends on how they
are managed. Throughout the project, a risk register must be kept in order to keep track of all possible
things which could go wrong, or risks, throughout the
project. Risks must be handled appropriately, as an
unmanaged risk can lead to human or financial detriments. These risks can be found anywhere from the
requirements to the design however, the biggest risk
to any project is people. Many projects fail because
the wrong people are doing the wrong jobs (this includes the project manager!), and this must be taken
into account. How the risks are managed depends on
their impact and the probability of them occurring.
If a high impact risk is highly likely to occur, the risk
must be prevented; if it is not very likely to occur,
a backup plan should be in place in the event that
it does occur. If a low impact risk is likely to occur,
it should be contained and controlled, whereas a low
impact, low probability risk can be ignored. If at any
time a risk eventuates, it becomes an issue and must
be dealt with accordingly.
5

Monitoring and Controlling a Project

During its execution, a project must be closely monitored to ensure it is meeting its objectives and ma-

jor problems do not arise. This involves the project

manager observing, watching and making themselves
aware of what is going on within the project. Monitoring a project is meaningless, however, if the discoveries do not contribute to controlling the project.
In order to attain this control, it is important to be
able to successfully manage a team this will allow
you to obtain the highest quality work from the team
members.
Team management is often considered to be the
essence of project management, as all other areas are
simply ways to ensure the required work is extracted
from the team. A team implies collaboration and
communication, and ensuring the team masters these
two techniques leads to successful projects. These
techniques are important as team members rely on
each other and must be aware of each other they
must have high levels of social intelligence. Communication is especially important, as it helps to motivate
team members as well as increase their creativity. It is
important to note that communication should be undertaken with team members and not to them. This
implies that listening to what the team members have
to say is equally important as speaking to them. In
order to keep team members happy, project managers
must consider three sets of needs: the tasks needs, the
teams needs and the individuals needs. This is important in order to coerce the required results from
the team members. The effort required here depends
on the type of person the project manager is dealing
with. If the team member is a Theory X person, it
may be difficult to encourage them to put the required
effort in, as they are naturally lazy and uncooperative, and find work distasteful. On the other hand, a
Theory Y person is more willing to put in the work
provided they gain satisfaction from doing the work
and they believe in the objectives of the project. It
is also important to note that the two types of person will have a different hierarchy of needs. Project
managers need to realise that both of these types of
people may exist within a team, and they should be
handled differently. Regardless of whether they are
Theory X or Theory Y people, most team members
will find that it is more difficult to do what is right
than what is easy (Allan 2011b); therefore, the team
members need to be managed in order to obtain work
which meets the customer requirements.
6

Implementation and Documentation

Documentation is an important part of any information system, as the value of a system is severely reduced if the intended users are unable to operate it.
Because of this, incomplete or erroneous user documentation can lead to a failed project. Documentation is also important during the execution of the
project. For example, the requirements document is
essential in order for a project team to implement a
system meeting the user requirements. Similarly, the
project must have planning documents so that the
project manager can keep track of the progress made.
By writing documentation, you are forcing yourself to
think about the project it is only through thinking
about the project that good decisions can be made
and a successful outcome achieved.
Configuration management is an often overlooked
technique within project management, but plays an
important role both during the feasibility study before the project begins, and also during the execution
of the project. The core concept behind configuration management involves the collection and maintenance of data concerning the hardware and software

of computer systems (Simon & Dennis 1993) during

the development and implementation of the project;
it refers to keeping everything in the right place at
the right time. This is crucial while the feasibility
of the project is being established, as it must be ensured that the end product is able to be integrated
with the current systems in the company. This task
is only feasible if some form of record of the hardware
and software within the company has been kept. This
record-keeping is the most essential tool for configuration management. Keeping such records is also advantageous in times of trouble for example, insurance
companies will only pay out for damages to or theft of
hardware if proof of ownership is produced; this cannot be done if there is no evidence that the hardware
was in the building at the time. The project manager
must communicate with the configuration manager to
ensure the project will fully integrate with the companys existing technology.
7

Conclusion

As team management is such an important part of

managing a project, the ability to work and communicate effectively with others is one of the most
important traits of a successful project manager.
Along with planning and other structuring techniques
and tools, a project manager is able to keep the
team members working to their potential and creating a product which meets the stakeholders requirements a necessity for a positive project. Armed with
this knowledge regarding project management, future
project managers will have a much greater chance
of succeeding in completing projects on time, within
budget and to a high standard and most importantly,
satisfying clients.
References
Allan, G. W. (2011a), ENGR301 lecture, 3rd march
2011.
Allan, G. W. (2011b), ENGR301 lecture, 8th march
2011.
Atkinson, R. (1999), Project management: cost, time
and quality, two best guesses and a phenomenon,
its time to accept other success criteria, International Journal of Project Management 17, 337342.
Royce, W. W. (1987), Managing the development of
large software systems: concepts and techniques, in
Proceedings of the 9th international conference on
Software Engineering, ICSE 87, IEEE Computer
Society Press, Los Alamitos, CA, USA, pp. 328
338.
Schwalbe, K. (2008), Introduction to Project Management, 2nd edn, Course Technology Press, Boston,
MA, United States.
Simon, J. & Dennis, G. (1993), Methods of tracking
intersystem configuration management dependencies, Journal of Systems Management.