Managing a project

By June 20, 2015

Adopting the six phases creates clarity in a project, thereby making it easier to
administer. What exactly does managing a project entail?
First, project leaders and project teams are involved with the following
components:
1. Team
A project team is comprised of a group of people who will realise the project result.
The group is often comprised of people who have various backgrounds, each of
whom contributes knowledge and skills.
2. Goal
A product result (or goal) is desired. After a project has been completed, something
has been realised. A new piece of software has been written, a re-organisation has
been carried out or a bridge has been built. The project goal is sometimes vague or
less firmly established. In many projects, it is necessary to adapt the goal as the
project proceeds.
3. Limited resources
The amount of time and money that is available for completing a project is always
limited. No project is completely free of time pressure.
4. Uncertainty (risk)
One characteristic feature of projects is that their success is never guaranteed
beforehand. Even if the desired goal is already being reached, it is uncertain
whether it will be achieved within the available budget or within the proposed time.
It is not unusual for a project to take three times as long and to cost twice as much
as originally estimated. It is also not unusual for only thirty per cent of the original
project team members to be working on the project upon its completion.
Although project managers must attend to many matters, they actually direct
projects along only five parameters:
Time
Money
Quality
Organisation
Information
These five parameters, which are often known as the ‘control factors’, are
described further below. The control factors appear in project plans, progress
monitoring and project reporting.

Time
The time factor manifests itself in a project in the form of deadlines for tasks and
the amount of time that these tasks may take. Managing time involves ensuring
that tasks are completed on time.
Time in project plans:
Determine which activities should take place in which phase.
Estimate how long each activity will take
Determine the order in which activities should be completed.
Allocate people and materials.
Allocate activities over time.
Determine the (most important) deadlines.
Time in progress monitoring:
Monitor progress.
Monitor deadlines.
Adjust schedules.
Time in project reporting:
Report on the actual timeline.
Analyse and explain why some tasks proceeded much more quickly or much
more slowly than expected.
Time schedules are based on a work-breakdown structure (WBS). A WBS is a
decomposition of the tasks that must be completed in order to achieve the project
result. Developing a time schedule requires knowing the amount of time that is
needed for each task, who will complete each task and when. One frequently used
tool for planning time is the bar chart or Gantt chart (see (1) Material purchasing
(2) Material testing (3) Compile testing report (4) Edit report (5) Information days
Figure 5 A variety of software packages is available for making and maintaining bar
charts (see Appendix 3).
Figure 5: Gantt chart or bar chart, which is commonly used for time planning.
A rapidly growing organisation was continually taking on more projects. As the
company continued to become busier – its products were in great demand – the
personnel began to feel pressured to work in a frenzy to complete all of the work
that needed to be done. The personnel wanted more people to be hired. Because of
the cost, management was hesitant to do so, and they pressured the existing
personnel to work harder. How much work could the team actually handle? This
question apparently had no good answer, as the organisation had no timeregistration
system.
When a new project was started, an estimate was made of the number of
hours that was thought necessary, but no one ever checked during or after the
project to determine whether this number of hours was actually needed. Project
leaders were nonetheless urged to keep their projects under control. The project
leaders protested that, without time records, they had no oversight over the
projects. After all, because they had no insight into the number of hours that were
used to carry out the tasks of a project, and there was absolutely no chance of
adjustment.
One project leader decided to register hours with his team. The registration
showed that the project ultimately needed four times as many hours as had been
originally estimated. After reprimanding the project leader for allowing the project
to get so far out of hand, the management decided to introduce a time-registration
system.
After several months, a number of bottlenecks became apparent. It was
revealed that nearly all of the projects had been budgeted too narrowly. In
practice, personnel who had been assigned to work on a project for one hundred
hours often proved to need three times as many hours. This transparency was
accompanied by new dilemmas. One the one hand, there were indeed too few
personnel to carry out the projects well. Additional personnel were needed. The
costs of sufficient personnel were considerable. On the other hand, the projects had
apparently been sold far too cheaply (for too few hours) to customers. The
management was afraid that they would not receive any more orders if they began
to charge more hours in their estimates.
Money
The money factor manifests itself in the project budget. The management of money
within a project involves ensuring that the costs remain within the budget. Given
that the majority of the costs in most projects are comprised of labour costs, the
factors of money and time (the number of labour hours) are closely intertwined.
Money in project plans:
Determine the fees of the team members.
Estimate the hours for the team members.
Assign budgets to team members for specific tasks.
Determine costs for material and tools.
Money in progress monitoring
Monitor cash flow.
Negotiate with suppliers.
Determine whether the original cost estimates are still accurate.
Adjust budgets.
Negotiate with customer and/or client concerning budget adjustments.
Money in project reporting:
Compile financial reports and statements.
Analyse definitive financial report.
Quality
The project result must fulfil a number of quality requirements. This also applies to
the various intermediate products of the project. When managing a project, it is
particularly important for quality requirements to be determined, agreed upon and
recorded in writing during the definition phase. These requirements should never
remain implicit. A clear list of requirements can be checked at the end of the
implementation phase. This can allow the project team to prove that they have
carried out the project according to specifications. Additional quality requirements
may be specified for various tasks within the project. For example, a particular task
can be carried out only by certified personnel.
Quality in project plans:
Establish the desired quality of the project result and the intermediate products
(this takes place primarily in the definition phase).
Establish the desired quality of the carrying out of the various activities in the
project.
Quality in progress monitoring:
Test the (intermediate) results.
Address any quality problems.
Quality in the project reporting:
Confirm that the desired quality has been attained.
Address any complaints (particularly in the follow-up phase).
Perfectionism impedes project management. A pragmatic attitude toward the
quality levels of a project can be expressed as ‘Good enough is good’. Projects that strive to achieve the highest possible level of quality are often at great risk of never
being completed.
Organisation
Within a project, the team must be managed. In the narrowest sense, team
management involves determining who will do what from the list of activities. In
broader terms, it also involves all of the soft skills (e.g. motivational techniques,
communication skills, leadership styles) that are needed to achieve a goal with a
group of people. Regardless of their importance, these soft skills exceed the scope
of this handbook.
Organisation in project plans:
Assemble the team.
Assign authority.
Assign tasks to team members.
Make agreements concerning the availability of people with other (project)
managers and higher management.
Organisation in progress monitoring:
Direct the team.
Monitor human aspects (soft skills).
Mediate between the parties who are involved in the project.
Information
The information factor concerns how, by whom and on which basis decisions can be
taken. Who may decide about which matters in the project? Is it the project leader,
the client or a substantive expert within the team? What will be archived and by
whom? Will tools (e.g. project website, issue tracker, e-mail notification, joint
agenda) be used? These and other informational questions must be answered
before a project can be started. Organisations that regularly work with projects
have a number of tools (e.g. Word templates) on hand for handling information
within a project.
Information in project plans:
Which information must be provided to whom and in which form?
Which information will be recorded, distributed and archived?
Which information tools will be used?
Information in progress monitoring:
Arrange for periodic consultation.
Ensure that the right information is provided to the right person.
Determine whether agreements have been met.
Information in project reporting:
Write the project report.
Appendices 6 through 9 of this handbook provide a number of samples of
information forms that can be used for exchanging information exchange within a
project:
Issue list
Action-and-decision list
Risk log
Meeting report
The issue list contains all of the points that must be discussed. This list must be
discussed regularly. For keeping track of progress and registering decisions that
have been taken, a model for an action and decision list has been included. A risk
log has been included to help document risks that are identified during a project.
These risks must then be discussed in the next meeting of the project team and,
where necessary, eliminated. Finally, a standard meeting report has been included
as an example of how to compiled and archive this type of report. Appendix 3
contains an overview of helpful tools by third parties.
One important aspect of securing the information concerning a project is that
all decisions should be reproducible. Decisions are often taken orally and not
archived. Regardless of how clear such decisions may seem at the time for both
parties, they must eventually appear in writing. If this is not possible, the
undocumented decision can become a source of misunderstanding or even conflict.
Many projects are delayed by various interventions from outside (e.g. ‘this is
even more important’, ‘this is better politically’, ‘the customer wants us to work on
something else first’). Keeping a personal log for recording this type of intervention
can help project workers identify the cause of project delays.