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.


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 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.


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.


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.

3. Project reporting

Crucial decisions must be taken at five points during a project; these decision points correspond to the end of each project phase, and they call for recording the projects current status and writing an intermediate report. They also provide the opportunity to reconsider the project phases that are yet to come.

At these decision points, project leaders should consult with their clients regarding decisions about the project and adjust the control factors, if necessary. For example, if many new and unexpected requirements have emerged during the definition phase that could increase the costs considerably, it is useless to proceed with the original budget.

The decision points at the end of the phases are often go/no-go moments; they call for decisions regarding whether to proceed with the project or whether it should be discontinued.

Figuur 6: Vijf belangrijke beslismomenten bij een project

The following situation often occurs in organisations that do not work according to project phases: a project plan is initially written, in which the control factors are described. A timeline (Time) is specified, and a budget (Money) is prepared, a team is formed (Organisation), a goal is described (Quality) and the tools for information services surrounding the project are determined (Information). During a project, the project leader continues to make sure that the project remains somewhat within the total budget and the timeline, but makes no real adjustments. Near the end of a project, the project proves to cost more or to take longer than originally expected. The project is then scaled back to avoid further cost over-runs or delays. Unfortunately, the project result suffers.

Had the project leader in such a case worked with the six-phase model, the team would probably have already concluded in the design phase or perhaps even in the definition phase that the original timeline and budget were insufficient. If the project leader had made adjustments at that time, a simpler design could have been chosen that would have been less expensive and time-consuming to implement. Alternatively, more time, money or both could have been requested from the client. At any rate, the status of the project would have been clear months earlier, and it would have been possible to steer the project in a meaningful way.

Uncertainty in project plans

Projects involve uncertainty. At the beginning of a project, the exact amount of time that will be needed is not known, nor is the precise amount that the project will eventually cost. For some projects, it is even uncertain whether the intended goal will be reached at all. In a world of fast-paced change, the foundations of a project have sometimes already changed before the project is completed. This sometimes occurs because of technological developments or developments in the market or political arena.

When preparing project plans, project leaders can only estimate the control factors (i.e. time, money, team, quality goals and necessary information) of the project. As the project proceeds, more knowledge emerges about the project itself. In the initiation phase, only an idea exists. In the definition phase, the idea is refined according to requirements. In the design phase, possible designs are examined and developed, providing even more clarity. In the development phase, it becomes clear how the design should be realised. In the implementation phase, the actual project result is built, and in the follow-up phase, all of the loose ends are tied together.

Clarity increases as a project progresses. It is therefore pointless to make a detailed budget for the follow-up phase (which will take place later) during the initiation phase. At this stage, it is still possible for the project to proceed in any of a number of possible directions. The idea has yet to be elaborated. The exact form of the follow-up phase is probably also known only in the broadest terms. This is too little information upon which to base a realistic, detailed estimate for the follow-up phase. A broad outline of a budget is the most that can be expected at this stage.

Project plans therefore work as follows: a global budget is made for the entire project, along with a concrete budget for the next subsequent phase. For example, if a project team is preparing to enter the implementation phase (after the development phase), they are well aware of what must happen. At that point, it is possible to make a detailed budget for the implementation phase.

The global budget estimates for the total project must be adjusted after each phase. After each phase, there is more knowledge and decisions have been taken that allow the global budget to be completed in more detail. In this way, estimates of the total costs of the project become increasingly accurate after each phase.

Making a global budget for the entire project and a concrete budget for the next phase is important, and not only for the control factor of money. It is important to work from global to concrete for the other factors as well.
The process of making budget estimates can be summarised as follows:

Budgeting should occur before each phase.
Make or adjust the global budget for the entire project.
Make a concrete budget for the next phase.
All control factors should be reconsidered and re-estimated for each new phase.
Budgeting in this way (particularly with regard to time and money) is a realistic manner of coping with uncertainty, which is greater at the beginning of the project than it is at the end. It creates a problem, however, for organisations that are financed by government subsidies, social foundations or both. This is particularly true for organisations that conduct innovative, and thus uncertain, projects.

Most foundations and grant makers require a project proposal that includes a complete and firmly established budget before they will release funds for a project. An organisation that seeks financing for a project must therefore develop a complete, concrete budget at a very early stage. In the beginning, however, the project is still in the conceptual phase, and it is thus impossible to make a realistic cost estimate or timeline. Only after the design phase, when the idea has been elaborated and a design has been chosen, is there sufficient information to say how much the project will cost and how much time its implementation will take. This stage does not occur until several months after the grant application must be submitted.

One result of the way in which grant makers and foundations tend to work is that many organisations request amounts that are based on rough estimates of the project costs. Project activities are subsequently fitted to the budget that has been made available. This puts the project team in a tight position from the start, even though the most flexibility is needed in the early stages.

The process of elaborating concepts during the definition and design phases, therefore, often reveals that the timeline that was proposed in the grant application is not feasible. The budget may also prove inadequate, including too much for some items and not enough for others. Any additional requirements from the grant maker (e.g. no item may deviate more than five per cent) place the project team under immense pressure. Matters must be implemented in too little time and within a budget that is too tight. This situation often leads to considerable shuffling among the various items in the budget. Considerable text and analysis is then necessary in the project statement to explain why the desired result was not achieved.

The situation would improve if grant makers were to couple their financing onto the various phases instead of providing funds at one time in advance. The initial financing would then be intended for the definition and the design phases. The requirements would be investigated and a number of alternative designs would be prepared within this limited budget. A subsequent application based on these designs would then be submitted for implementation and follow-up. This would allow projects to avoid unnecessary pressure. An additional advantage would be that the expectations of the involved parties would be more realistic, saving time, money and disappointment.


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.

4. The sales representative and the politician

Project leaders should consider the environment within which their projects will take place. In other words, they should consider the ways in which decisions are taken within and about the project. A project may be located in one of two worlds: the world of the sales representative and the world of the politician.

The world of the sales representative revolves around profit maximisation, and stability is very important. Actions are based on mutual trust and are subject to the motto of, a deal is a deal. Relationships among sales representatives are important, and the behaviour that they exhibit is genuine. Power is decentralised.

In the world of the politician, the majority is important for getting things done. Loyalty to the group is thus important, even if a politicians opinion differs from that of the group on a number of points. Because the majority seldom consists of a single group, temporary coalitions are often necessary, sometimes with opponents or even enemies. Decisions emerge from a particular view of the world. In the world of the politician, references to certain facts are necessary to maintain good order; the end justifies the means. Power is centralised.

Figure 7: The sales representative and the politician (Illustration: Rachèl Harmsen)

Most people intuitively feel more attracted to the first of these two worlds; the second brings many negative associations to mind We don’t play politics here is a frequently heard remark in organisations, even if it is not true. Even though most people find the world of the sales representative the more attractive of the two, it has an important disadvantage. Decision-making according to profit maximisation works only for decisions in which clear cash flows are available. Decisions that involve such dilemmas or issues as investing more in education, the environment, health care, highways, research, defence or nuclear energy cannot be expressed as an unambiguous balance between profit and loss. The political model is the only possible model for such decisions. It is therefore necessary to play the political game.

By definition, social and subsidised organisations exist within the world of the politician. The financing of these organisations and their projects is completely or largely dependent upon the political will to support the organisation. The effectiveness of social organisations is not easily expressed in terms of cash flows. This is also true of the results of projects that are carried out by social organisations.

A young engineer once had to carry out an ambitious wind-energy project in a municipality somewhere in the country. Through an ingenious savings system, residents of the municipality could save for a number of windmills, with a goal of generating thirty per cent of the towns electricity needs with their own windmills. This would require ten windmills. The idea originated with one of the members of the town council.

The townspeople were considerably less enthusiastic about the savings programme than had been expected. With great difficulty, they were able to save enough to purchase one-half of a windmill. To prevent the idea from becoming a complete failure, the municipality decided to supplement the amount, so that at least one windmill could be installed.

In the first draft of the final report, the engineer thus wrote that the result was quite disappointing. Such a report, however, would mean loss of face for the council member, who therefore urged a reformulation. The text ultimately came to read as follows: The project is a great success; the municipality has demonstrated its support for the environment and has made its however modest contribution to the fight against climate change. The young engineer was initially unaware of the political framework of this project. In order to prevent future projects from the council member from getting off the ground, he was forced to play (along with) politics.

It is more difficult to carry out a project in a political environment than it is to carry one out in the environment of the sales representative. Decisions surrounding a project depend upon the political game and not on what would be most effective for the project. The catalyst for beginning a project is often political, and it therefore determines the force fields with which the project team is confronted.

Because of a re-organisation, it was necessary for a number of organisations to merge and cooperate. This re-organisation was mandated from above and involved, among other things, replacing a number of small-town local affiliates with a central office in the region. This meant that employees would have to travel much farther to their work. The work itself changed as well; many fewer positions for highly educated workers were available after the re-organisation. A portion of the personnel had to seek positions outside of the organisation or to other positions that were substantively much less interesting. There was therefore considerable resistance to the re-organisation, even though it would mean considerable improvement in service for the customers if it proved successful. Finally, the re-organisation was to be carried by the personnel themselves, under the supervision of a project leader.

The project leader initially had difficulty getting the project started. The team members who were to carry out the work kept finding excuses not to do their jobs. There was always a problem or setback, and there was considerable discussion. The discussions usually shifted to the question of whether the project itself was a good idea. The project leader would then defend the project it would mean a great improvement for the customers but he was unable to generate any enthusiasm for the project.

Once the project leader realised that many of the workers did not (fully) support the project, he decided to focus first on the task of reducing resistance to the project. He accomplished this by taking the time to visit the various affiliates. He also talked more with the supervisors and employees, often informally at the coffee machine. By developing a better relationship with a number of the formal and informal power-holders, he was able to kick-start the project when it faltered. The project remained difficult, but the political approach worked much better than had the rational approach that he had tried initially.

A guide for playing politics would exceed the scope of this book. In short, the political game often takes place at the level of relationships and power relations. In a business environment, the product itself is more in the foreground.

Project leaders should realise that projects that are carried out with social organisations always involve at least some element of politics. To make projects successful, project leaders in this situation would be wise not to detach themselves from the political game. Instead, they should seek to play it as well as possible while providing substantive direction to their projects.

5. Waterfall versus Agile projectmanagement

The six-phase model is a waterfall model. In other words, the phases take place in succession. Just as it is impossible to swim upstream against a waterfall, the pure waterfall method does not allow returning to a phase after it has been completed. During the implementation phase, it is not desirable to decide to adapt the design, thereby bringing implementation to a standstill. For a number of reasons (see e.g. McConnell, 1996; Kroll, 2004; Chromatic, 2003; Stapleton, 2002), the waterfall method is usually less suited to software-development projects.

Software development is a creative process.
It is nearly impossible to identify all of the requirements (functionalities) beforehand.
Estimating the amount of time that will be necessary to implement a functionality is quite difficult.
It should be possible for all intermediate results to be tested by users throughout the entire trajectory of the project.
Cyclical methods of project management
Conditions for cyclical project management
Risks of cyclical project management

Software development is a creative process

To outsiders, software development appears to have more to do with engineering than it does with inventing. It does, however, correspond to inventing in a number of ways. In the process of invention, one never knows in advance precisely what is going to happen.

The designers and programmers who write new software must conceive of solutions for the problems that are set before them. Regardless of the many methods and prescriptions for work, writing programming code remains largely new and therefore largely uncertain. Programmers can choose their solutions out of millions of possibilities that are written in dozens of programming languages, and which operate according to thousands of hardware configurations and in dozens of software platforms. Although this freedom does offer a number of advantages, it also makes the project more difficult to manage than traditional projects (e.g. construction or building projects).