Categorie archief: 2. Managing a project

2. Managing a project

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:

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 4: A (portion of a) WBS of a project

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 time-registration 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

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.