Right on time, right on money--personal experience


Project management is taught at universities and through specialized courses.

Another way to learn is by studying real life experience. This presentation will show how to deliver infrastructure projects Right on Time, Right on Money, by design, rather than by the roll of dice [Rienhart (1998)].



This paper refers to personal experience of the author, who has spent a good number of years in production programming, design, construction, and estimating in various engineering industries such as aircraft, petrochemical, water and wastewater, energy, and rail. For the past 15 years, he has managing projects on communications rollouts and rail infrastructure.


This paper deals with issues mainly relating to rollout projects. However, any one of the issues that is discussed may be applicable to any type of project or product in a wide variety of industries.

First, the paper will discuss what rollout projects are. Second, it will discuss the handover of existing projects and the creation of new ones. Finally, it will talk about delivering projects on time and on budget by design rather than by the roll of dice.

Rollout Projects


In this paper, rollout is not considered to be a post-project enhancement of an infrastructure. The objective is not the same as in a true rollout.

A rollout here is defined as an activity that deploys a series of repetitive mini projects awarded as a single project. The individual mini project's cost and duration may be negligible but cumulatively the many mini projects may add up to many millions of dollars. This is important to understand. When working on the rollout of a base station network, the parent company never grasped the idea that it did not involve building singular sites, at say US$250 thousand each, but that they were involved in a mega-million dollar project.


The obvious question to ask is: Are a number of similar projects grouped together deemed a rollout?

Most recently, in managing the design and construction of a number of rail stabling yards—even though there were synergies, the objectives are not the same. So a group of similar projects is a “program” rather than a “rollout.”

Each portion of a rollout is repetitive. Completion of discrete units is relatively quick. Even though mistakes and/or opportunities are repetitive, they are few in numbers. However a mistake that is not immediately identified could be repeated throughout multiple sites, thereby multiplying the negative cost effect very quickly.

On the other hand if an opportunity for improvement is identified early, a repetitive saving will provide a very positive financial outcome.

It then follows that the planning and design stages are vital for successful, cost-effective rollout of projects.

Hand Me Down and Fresh Start Up Projects

Stop! Revive! Survive and Prosper!

More often than not, in receiving a new or hand-me-down project, enthusiasm and a sense of urgency take over. It is reasonable to assume that this burst of energy will be spent in getting things moving as fast as possible to demonstrate that the project is progressing at the speed of light. Unfortunately the light is—you guessed it—an oncoming train. Here comes another train wreck.

The Preference Is to “Sleep on It”

It is more important to “sleep on it” and spend one's energy understanding what is really required and how to get there. As with a long car trip, the strategy is to:

  • Stop—Disconnect in order to calm down.
  • Revive—Re-read the documentation, discuss with the sponsor, understand the sales team's view and thend user's requirements. See and understand the big picture as to the purpose and objectives of the project. Try to keep one's nose as far as possible from the computer screen. Take a bird's eye view.
  • Survive—Reconnect without rushing into it. Rollouts need to be seen as long-haul projects. Days or weeks “lost” are relatively minor in relation to the big picture.

Changing the Guard

Taking over an existing project is never easy. Not only does one inherit a well or badly run project, the new project manager may also be new to the group or the company. The existing team knows everything better than the new project manager, and often jealousy and personal agendas are at play.

There are many people with all sorts of agendas regarding contracts, which can result in damage to the project manager, the project and, in some instances, the company.

It may seem brutal, but the best action is to take no prisoners with the view that if the project does not look good— the project manager doesn't look good—and neither do the boss, the group and the company. It is suggested that people who are not acting in the best interest of the project be sidelined, promoted, or removed from the project.

Changing the Cultures and Structures

The same applies to dealing with inherent structures and cultures. One should consider advice that is given, but ultimately, it is the project manager's responsibility to assess what is best for the project and to act on it.

In 1965 Bruce Tuckman introduced a theory of “forming, storming, norming, and performing.” It is accepted that the formation of an effective and efficient group is a staged process and that it will take some time to get to the performing phase. While minimizing the storming phase as much as possible, it usually takes about 3 months for a group to reach its optimal performance.

The last or fifth stage of team development is that of “dissolving.” This stage is important as it relates to the creation of stepping-stones for possible future projects and potential future team members.

Many years ago, changes to some financial reporting documents brought tears to the eyes of one of the senior team members because the changes were made without consultation. Of course this was a mistake. One should consult much more, raise issues, take advice, consult/explain, and only then implement the change.

A community consultation process is mandatory for government-backed rollouts. A “mandatory” consultation process means that you must announce what you are going to do, you must listen to what the community says, and then the project manager decides what is best for the project. Mostly this is the plan that was already announced. This process will serve a project manager well. A project manager must be assertive without being arrogant—this line should never be crossed.

Success by Design


In the communications business, clients can make earnings every second and it is the project manager's role to help them do so. The earlier a project, or part of a project, is delivered—the more the client can earn and money may be reinvested to provide additional work.

Successful projects don't just happen. A Guide to the Project Management Body of Knowledge (PMBOK® Guide)— Fourth Edition (PMI, 2008), offers guidance in establishing and running successful projects. Nevertheless, giving someone a driving manual is no guarantee that they will be able to drive a car. In heavy engineering projects, poor management may take a while to detect, is unlikely to be corrected soon (or ever) due to a project's prolonged duration resulting in time and cost over runs.

In rollout projects, the multiplier effect and short duration of a majority of tasks or modules can cause sudden collapse of the project's deliverables, namely time, cost, and/ or quality. Quality is normally enforced by specified standards. Time is money; therefore if a quality project is to be delivered on time, attention must be paid to costs. Any mistake is costly. Undetected or poorly managed cumulative mistakes can be detrimental to the project.

Adequate, well thought out planning is therefore a must. We will not dwell on the whole planning process, but rather concentrate on the most important components, that of scope and the project's stated or unstated objectives.


In a project for rolling out fiberoptic infrastructure, the scope was to:

  1. Implement the rollout of approximately 800 km of fiber, connecting about 200 substations;
  2. Achieve connectivity of about 140 substations (about 70% of the required total rollout) broken into sub-networks staged for an independently delivered rollout of a new monitoring and control system;
  3. Connect a small number of substations to enable a new monitoring and control system to be tested; and
  4. Connect depots that were connected via third parties with licenses about to expire and/or with insufficient capacity.

Earlier project management concentrated on the full rollout of the 200 substations. Not much attention was paid to the delivery of the sites required for monitoring and control by the new system. No one paid any attention to a handful of substations that were needed for testing of the new monitoring and control system in the very early stages of the rollout. None of the earlier project managers were aware of licensing or capacity issues with the depots. Initially the scope was misunderstood.

The scope of another project required the design and build of three rail yard sections. The largest section had the highest priority. To get this section through the environmental process would have taken somewhere between 12 to 18 months. Such an extensive unplanned delay would have “killed off” the project due to a missed deadline. In a conversation with the sponsor on an unrelated matter, an off-the-cuff remark revealed the possibility of developing another portion of the project under an existing maintenance license, while the environmental issues on the larger portion progressed. A site visit and discussions with operations confirmed that this was doable.

During the same site visit it became apparent that one of the sponsor's requirements was unnecessary to achieve the site's purpose. When confirmed by survey, the project got back on track and several million dollars were saved. The requirement for the client's critical resources was reduced, and time to practical completion was minimized.

We have come to understand that the estimator and the sales team have totally different objectives from the project team. The sales team wants to sell, while the project team has to deliver. Nine times out of ten, the project team will be on the back foot even before the project starts. Therefore, project managers must gain a precise understanding of the scope that the sales team has sold and which scope the customer is expecting to receive. Many project managers who are assigned to projects and poorly briefed make the mistake of assuming that they know and understand the scope — only to discover that they don't.

Practical Completion

Understanding what practical completion means is vital.

In one of project, huge daily penalties were applied for not being able to get new train sets on the railroad for the required testing. Therefore ancillary deliverables, not required for train movements, were to be done post-practical completion.

In a recent communications rollout, only a handful of substations had to be connected for testing and only approximately 140 out of 200 substations required connectivity for the new monitoring and control systems. Even though the full rollout was completed on time, the practical completion was achieved months ahead of the scheduled rollout completion.

Strategy to Deliver


Once the project's purpose, objectives, and scope are understood, one needs to start working on strategies to deliver. The author uses a simple spreadsheet — a kind of mind map. It lists all of the necessary items, when they are required, how they can be achieved, where they can be done, and finally who has the capacity and the capability to do it. Initially there may only be a dozen or so items.

Looking at such a simple spreadsheet/ map one can decide on the overall strategy, which should include but not be limited to:

  • Whether to have centralized or decentralized monitoring and control,
  • Which parts can be delivered “ad hoc” or which will require meticulous planning,
  • Whether to contract in or contract out,
  • Whether there be specific teams or virtual teams and
  • What are the best ways to procure goods and services

Those who work within large public or government company frameworks will know that to acquire a single human resource or place a simple goods order can take several months. Yet, one is expected to deliver the project within the specified time and cost. Normally the contractor or the alliance partner is not a labor hiring or procurement company and therefore can't provide the necessary resources. So what should a project manager do? Simply reframing or rephrasing a requirement for goods or service with specific deliverables and/or outputs may suffice.

Based on past experience, coming in on time and on budget was never the result of squeezing the last drop of blood from the contractor or the client. The delivery on time and on budget is linked directly to having the right strategic solutions.

It is preferable to do as much as is possible today rather than tomorrow. If a program shows a specific task to be completed in a month's time, do it today if it ties into the current work and time and resources permit. A strategy that offers flexibility is essential.

A word of warning, in a past project that was delivered ahead of time and on budget, some managers expressed frustration at having some sites ready, but not connected for a number of months. It is obvious there was inadequate communication. As for lesson learned — tell people not only what you are doing but also why you are doing it.

Tactics to Deliver

Attention to tactics for delivering a project is also necessary. As in sport, the project manager's actions may inadvertently and sometimes deliberately test the rules. One can use the law, media, cajoling, sidelining of people, manipulation of processes and procedures, or whatever it takes (legally, of course) to further projects that a team is working on. If a strategy allows maximum flexibility, improvisation is possible.

Working with professionals has an advantage of not needing to tell them how to do their job. The project manager should be able to clearly communicate what the needs are, what outputs are expected and when they are needed, and allow the team provide all that is necessary. The project manager should simply monitor the deliverables, not the process by which it is delivered.

Generally it is best not dwell on detail. However, when necessary, ask questions and drill down until satisfied that the issue is fully understood. The emphasis is solely on the issue. Once this is understood, all else falls into place. Sometimes “the issue” has nothing to do with the project whatsoever, and the best way to “see it” is by getting a bird's eye view on the matter.

Change Management

Scope Creep

We all know about scope creep — the project manager's nemesis. We all like to oblige and often a change is approved without appropriate consideration of its effect on the end result, that of the project's delivery on time and on budget.

On rollout projects, even a trivial change in scope may have a detrimental effect on the project's outcome. One suggestion is to “sleep on it.” A 24-hour period is a good time to allow one to make sense of most requirements. In the author's view, the best solution for dealing with “scope creep” is to create a “new” project with separate funding rather than to attach bits and pieces to the original project.

A project manager should be able to explain to the sponsor that a change will require additional work (a new business case, funding approval, etc.), but eventually the sponsor will be rewarded with having “all” projects delivered on time and on budget.


To accommodate any change. first assess the project's risk. If a change has to be accommodated, make sure that it is documented meticulously, noting the risks, resource requirements, costs, and effect on the overall project's delivery.

On rollouts, not enough attention is given to “like for like” requests. Running 10 km of overhead fiber is not the same as running 10 km of fiber in a trench through rock. Pouring concrete in a town's center with all the facilities is different than pouring concrete miles away from the nearest front gate.


Many project managers are “forced” to use the project's contingency to pay for scope creep. This is a mistake and should be avoided.

Some project managers work on projects that do not have a contingency and have an allowance for specific risks only. Target adjustment events (TAEs) are used for “unknown unknowns.”

It then follows that if there are no contingency funds in a project then scope creep simply does not occur.

If a contingency exists, use it to fund only “known unknowns” and/ or “unknown unknowns,” as required, for the “original” project and not to fund “scope creep.”




The author likes to work with flat organizational structures and small team(s) with as few individuals as possible, carefully avoiding the creation of “bottle necks.”

Consider a performance-based, do and charge, “open book,” no-value contracts. On large rollouts where there are a sufficient number of sites, it is best to have two contractors focusing on a common project goal. The competition is in the performance. To engage more than two contractors may not be wise, as there may not be enough work to generate sufficient profit to motivate three or more contractors. Having worked on such contracts as both a contractor and a client, the author suggests that these are the best value for the money. The contractor does not have to cost in any risks, whatever is required for the project is done in a timely manner, and there are no arguments as to whether the required work is in the contract or not. Adequate monitoring and controls ensure that the charged costs are appropriate. Succinct contract documents written in plain English are recommended.

Lately preference is for non-competitive alliances for publicly funded projects. The author has insufficient data to comment if this is the best way to deliver projects on time and on budget.

Virtual Teams

Rapid deployment of multiple sites in various geographical areas favors “rubber band” virtual teams expanding and shrinking as required. For teams to function with the necessary effectiveness and efficiency, there is the need for rigid, well-designed processes and procedures, and exceptional training.

Shared Resources in Large Enterprises

Sharing resources in large companies is one of the toughest challenges for a project manager. Working in an environment where there are 500 projects to be delivered with available resources to deliver only about 300 is a challenge. When your project is number 399 on the list and it is taken off the master schedule, it becomes an issue. One needs to understand what the critical resources are, where the bottlenecks are, who pulls whose strings, and how you can get around the problem, namely how you can supplement if not acquire these critical resources.

The rate structure of everyone associated with a project also needs to be understood. Many of us look at minimizing costs, however, we should always look at how budgets, costs, and contingencies can be used to a project's best advantage.


Rollouts are comparable to working in a sausage factory due to their repetitiveness. It is very difficult to motivate people involved in a sausage-making production line.

Incentives/ Disincentives


Often there is discussion as to whether there is a difference in motivating blue or white collar staff. It is likely that there is not. You will find that the best motivator is training. The only drawback is that most training is done during business hours when the project loses its most valuable resource — people.

Hence the preference would be to train people on weekends. Find ways to encourage this by enacting a formula that benefits the project, its staff, and their families. Weekends away with staff and families can be planned for each quarter (or as required) for the project's rollout.

Ensure that staff is appropriately trained, that the staff's partners are entertained (not necessarily by the company) and that all share at least one meal a day together. These weekends away are great for training, motivation, and communication among staff who, in some cases, rarely see each other. This especially applies to national rollouts and virtual teams. You may want to involve contractors to share in these costs. Essentially they are all on the same project team! Be sure to comply with the company's corruption/maladministration policies and guidelines.


Overtime cost descriptions as “time and a half” or “double time” are misleading. When rates were analyzed on one previous contract, the percentage difference between a “normal” and an “overtime” rate was less than the project's contingency percentage. Therefore, overtime was encouraged. It was later discovered that once people exceeded their allowable limit, they took time in lieu. After a short time there was no one left to do the work. To compensate, the level of overtime was adjusted to a few hours below the allowable limit. This encouraged people to stay interested in the project and discouraged them from wandering off to other projects in search of more overtime.

Flexibility-Enabling Concepts

Many years ago while working on the design of petrochemical plants for large American corporations, the author found it difficult to deal with the comprehensive “red” books full of very rigid procedures, processes, and standards. Later, the same rigidity was despised when estimating some small water and wastewater treatment plants for large corporations in Australia. It took a while to realize that, in order to be flexible, one must have very rigid systems in place. It sounds illogical, but based on experience, it can be shown that in order to build or operate anywhere, by anyone, at any time, a very rigid but modular systems must be in place.

In order to maximize rigidity, but maintain flexibility, one must develop design and construction packages as modules. Optimum-sized modules facilitate implemented changes without causing havoc with other modules. However absolute attention must be given to the module's match point(s).

Continuous Improvement

Modern project management requires delivery of continuous improvement. This is fine, but on rollout projects there may be serious consequences. Consideration must be given to whether the improvement is worth incorporating or not. Implement each change separately or in blocks of changes. Implement the change in the already built infrastructure or only in future builds. Question whether the change is a scope creep or a necessity, whether to implement the change in the already built infrastructure or only in the forthcoming builds, and whether the part change implementation will affect the operations and maintenance after the rollout has been completed? One must bear in mind that each change will have a multiplying effect with consequences on the bottom line and timely project delivery.

Tools Overload

It's probably difficult to drive a Ferrari in the desert. The same logic applies to tools used in project management. If you have 200 sites and wish to maintain flexibility managing multiple contractors and resources on multiple sites using project management software that shackles you to the screen, then software is not helpful. Instead try using a simple spreadsheet with “flags” following the KISS method (keep it simple stupid). Adhere to dates. Flag what must happen in three days’ time and ensure that it happens on that day or sooner. Deal with finances in exactly the same fashion. There is no point worrying about funds already spent. Flag 80%, 60%, 40% etc., of the remaining funds and manage them appropriately.


One needs to communicate with stakeholders all the time. Particular attention should be given to the project sponsor. It doesn't matter if the project is small or large, or important or unimportant — try to touch base with the sponsor on a daily basis, either formally or informally. Try to be as succinct as possible, truthful, and allow time for feedback. In this way, the sponsor knows what is going on and, more importantly a relationship built on trust (no surprises) is developing with a prospective future provider of work.

Yes, We Have No Bananas Today

We all like to be known as the “nice guy.” Those of you who play competitive team sports will affirm that in a team, if you do not perform, you are going to know about it from the coach, the team, and the booing audience. There is absolutely no reason why the project manager, the team, and the customer can't do exactly the same.

Of course, on the other hand, the customer, the team, and the project manager must cheer the team and the star players. Hi fives and hugging in team sports are spontaneous. Why isn't this done in project management? A win is a win — isn't it?

Communications Strategy

Very few people include coffee shop meetings in their communication strategy — but, they work. It is a good idea to deal with issues on a one-on-one basis outside of the formal meeting room environment. Taking a meeting outside into a semiformal coffee shop setting, with a set agenda and with groups of up to 20 people from different sections of the organization, can be very productive.

Listening Skills

We have built communications networks and use modern communication technology daily. Most of us hate seeing people talking amongst themselves during meetings, and without even an apology, answering mobile phones, checking email, and sending text messages. As a result they miss half of what is being said and see only half of the body language. Any wonder that projects flounder!

It is very productive to give absolute and undivided attention to the person you are speaking with—not taking calls, nor allowing any distractions, not even taking notes. When taking notes, ask people to wait till you have finished — listening is hard work and we all should work very hard at listening.

Say “No” More Often

The more times a project manager says “no,” the more successful the person is as a project manager. Note, however, there are many ways to say “no.” No one likes to be told “no” (Margerison, 1987).

Projects Going South

Stop, Revive, Survive!

Have you ever seen a successful project abandoned by its project manager? You should note that, for better or worse, no one remembers the project manager's predecessor. The job and the responsibility for the project are now entirely in the hands of the current project manager.

It is important not to rush things. If necessary, halt the project totally (!) and allow work to continue only on sections that have no effect on the project's eventual outcome. When a problem occurs resulting in delays, a competent project manager will accept that the project is already late or over budget and that another week or two of delays may cause additional pain, but it is unlikely to have any more adverse effect on the eventual outcome. In the scheme of things this delay may need to be tolerated. It is actually more likely that the delay and its considered management will have a positive effect on project's delivery.

When you have a serious problem or you get bogged down you should revert to:

  • Stop—Disconnect in order to clear the head.
  • Revive—Read, gather as much information as possible, and discuss at length. Go back to basics then summarize and prepare a simple mind map to help in visualizing the project status. Review, analyze, and reformulate strategies, processes, and procedures.
  • Survive and Prosper—Reconnect without rushing into it. Days or weeks lost are relatively minor in relation to the big picture. Be acutely aware that, as a project manager, each decision made could be right or wrong. If the wrong decision is made — say so, accept the blame, and get on with it. Give well-considered directions with confidence. Be confident, not cocky.

One must believe that the project can be delivered on time and on budget in order to convince others of the same. Actions speak much louder than words, so make sure that the progress is not only visible but also purposeful.

There are many ways to skin a cat. This simple approach to managing projects enabled the author to deliver projects on time and on budget, time after time, by design rather than by the role of dice.


Rienhart, L. (1998). The dice man. Woodstock, NY: Overlook Press, Peter Mayer Publishers, Inc.

Tuckman B. (1965). Team development model. Retrieved from http://www.businessballs.com/tuckmanformingstormingnormingperforming.htm

Margerison C. J. (1991). If only I had said, New York, NY: Mercury Books Division of W. H. Allen & Co.

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® guide)— Fourth edition. Newtown Square, PA: Author.

©2010 Tom Klein
Originally published as part of Proceedings 2010 PMI Global Congress – Melbourne, Australia



Related Content

  • Project Management Journal

    Narratives of Project Risk Management member content locked

    By Green, Stuart D. | Dikmen, Irem The dominant narrative of project risk management pays homage to scientific rationality while conceptualizing risk as objective fact.

  • Project Management Journal

    Identifying Subjective Perspectives on Managing Underground Risks at Schiphol Airport member content locked

    By Biersteker, Erwin | van Marrewijk, Alfons | Koppenjan, Joop Drawing on Renn’s model and following a Q methodology, we identify four risk management approaches among asset managers and project managers working at the Dutch Schiphol Airport.

  • Project Management Journal

    Collective Mindfulness member content locked

    By Wang, Linzhuo | Müller, Ralf | Zhu, Fangwei | Yang, Xiaotian We investigated the mechanisms of collective mindfulness for megaproject organizational resilience prior to, during, and after recovery from crises.

  • PMI Case Study

    Saudi Aramco member content open

    This in-depth case study outlines a project to increase productivity with Saudi Arabian public petroleum and natural gas company, Saudi Aramco.

  • PM Network

    A certeza da incerteza member content open

    By Fewell, Jesse Por mais que ansiamos por um retorno pré-pandêmico, é ingênuo pensar que as velhas formas de trabalho um dia voltarão - mesmo para o ágil.