What follows are my thoughts about the realities of project execution – the implementation of our project plan. This paper is designed as a primer for NZIM Diploma in Project Management students who are about to attend Module Three (Project Execution) of this NZQA-approved Level 5 qualification.
My first thought is that no project execution will be better than its plan, although of course there is a point beyond which the value of our time spent planning diminishes, at which point it’s better to implement rather than augment. Otherwise our plan might resemble my daughter’s exam study schedule that is continually revised as time slips by until the night-before panic.
Yet for some people, planning is their forte. I recall a road project in Auckland where the project manager who planned the project handed the plan to his deputy to implement. The project manager had a participatory style appropriate for planning and the implementer had a more expeditor get-on-with-it style. So rather than have the project manager attempt to change his management style, there was simply a change of project manager, which seems fair enough given that management gurus tell us it’s very hard for managers to suddenly change their style. The Hersey-Blanchard Situational Leadership doctrine, where leaders are expected to adapt their style to the situation, seldom works well in practice I suggest.
Anyway, back to the topic – our baseline project plan is simply a basis for change as reality is revealed during execution and things go bump in the night. Careful plan version control is clearly important to avoid confusion – to ensure we are all signing from the same song sheet as the saying goes. In fact, managing project execution is not unlike conducting a choir to ensure everyone is singing in harmony.
After we have planned our project (Develop Phase) and had our sponsor sign off on our proud production, we will be ready to implement our project (Execute Phase); the third phase in our generic project management life cycle shown diagrammatically below. It includes Dilbert’s one-word descriptions of each phase. Hopefully our sponsor is not the pointy-haired one.
The two white lines on the diagram show the accumulating total cost of a project as we spend money and the diminishing likelihood of risk (although the impact of risk is likely to increase as we proceed). At project completion there is no uncertainty. At that point we know for sure whether we have a disaster or hopefully something much better, at least in terms of budget and schedule performance, which are the immediate and traditional indicators of our project management performance, whereas a successful project is one that adds value – the benefits exceed the costs. These benefits are usually realised until some time after we have finished and departed our project. If nothing else, this reality means we should ensure that we have sufficient time and money to do the job properly. Usually our detailed planning will reveal any shortfalls, at which time we need to talk trade-off options with our sponsor. If our project is a firm fixed price job set by a salesperson (possibly motivated by their commission), we could be really challenged unless profitable variations proliferate, but this is not a good way to do business, particularly if we want more business.
The execution phase involves putting the project plan into action. It’s now that we coordinate and direct project resources to achieve the project goal. As the project unfolds, it’s our job to direct and manage each task on the project, every step of the way. That’s what happens in the execution phase; we follow the plan we’ve put together and handle any problems and deviations that arise, some of which may require us to do some re-planning. It’s pointless adhering to our baseline plan if it’s proving to be wrong.
The execution phase is where we do the work to produce the output(s) or deliverable(s). The word deliverable means anything our project delivers. Deliverables are what remain behind at project completion. The deliverables for our project include all of the products or services that we produce for the client (owner), customer (user) or sponsor (funder). The final deliverable will then have its own lifecycle during which period our project’s business case benefits are hopefully achieved as the deliverable fulfils its purpose.
The tasks undertaken to build each deliverable will vary depending on the type of project we undertake. For instance, engineering and telecommunications projects will focus on using equipment, resources and materials to construct each project deliverable, whereas computer software projects may require the development and implementation of software code to produce each project deliverable. The tasks required to build each deliverable should be clearly specified in our project plan.
Our job as project manager is to direct the work, but we need to do more than produce the final deliverable. We also need to keep track of how well our team performs and keep in touch with other stakeholders – those individuals and groups who can affect the project or are affected by it. We keep the project on track with careful monitoring and control to ensure the final deliverable is built on time, within budget and is of appropriate quality. Quality means conformance with specifications. To meet the project quality objective we need deliverable specifications that are clear and unambiguous, which means quantifiable measures rather than adjectives and adverbs. However, while specifications need to be precise, definite and concrete, they should also allow some latitude where appropriate. Rather than 200mm, a range such as 195-205mm may be fine. If we don’t allow for some tolerance in our specifications where this is practicable, costs invariable skyrocket. Also, off-the-shelf components are usually cheaper and more readily available now and in the future, than are specially manufactured items.
Monitoring means checking for variance (that’s the difference between planned and actual performance) and control is about taking corrective action should that variance look to exceed tolerance limits. The expression “exact estimate” is an oxymoron. We need reasonable latitude for some slippage and over-expenditure depending on uncertainty factors such as project novelty and complexity. We can’t manage nebulous projects to tight tolerances, well not without a constant headache and continuous cap-in-hand visits to our project sponsor.
When we find a problem, we can’t necessarily just make a change to resolve things, because what if the remedy is too expensive or takes too long? We will need to look at how it affects the project parameters (time, cost, scope, quality, risk and benefits). We will then have to figure out if it is worth making the change. Anytime we need to make a change (variation) to our plan, we need to start with a change request. Whoever proposes the change usually prepares this request. Any change to our project needs to be documented so we can decide and record what needs to be done, by when, and by whom. If the change request affects the project parameters as defined in the project charter document, we will need to submit the request, if we agree with it, together with our recommendations to our project sponsor for approval, all before we implement that change. Let the sponsor be the bad guy who says “not approved”, rather than we upset our stakeholder relationships.
The execution phase will usually be the longest project phase with the most work effort (person-hours) and resource use. As a result costs are usually highest during this phase. We will also experience the greatest conflicts over the project schedule in this phase. We may find that the actual time to do the scheduled work is longer than the amount of time we estimated and planned on. When we absolutely have to meet the deadline (a date-driven project) and we are running behind, we can sometimes find ways to do tasks more quickly by adding more resources to critical path tasks. That’s called “crashing” which seems an unfortunate term. Crashing the schedule means adding resources or moving them around if they are suitably multi-skilled to shorten project duration. Crashing always costs more and doesn’t always work. There’s no way to crash a schedule without raising the overall cost of the project. So, if the budget is fixed and we don’t have any extra money to spend, we can’t use this technique. Some other trade-off may be possible.
To some extent the number and seriousness of the challenges we face during project execution depend on the priority given our project. If our project is of lower priority we are more likely to lose resources than get extra resources, typically because higher priority projects, whose costs have been under-estimated (sometimes deliberately) have priority call on our organisation’s resource pool. This is why we prioritise projects – resource limitations. Unfortunately, junior project managers are likely to be allocated lower priority projects, in which case we need to be good at resource-constrained scheduling. This occurs when our task schedule is dictated by the availability of resources – those resources left over after higher priority projects have been satisfied. This problem will be worse if we have a sponsor who doesn’t defend our project’s priority.
Sometimes we’ve got two or more project critical path tasks planned to occur in sequence, but we can do them at the same time. This is called “fast-tracking” the project. However, this can be a risky technique. There’s a chance we might need to redo some of this work we do concurrently. Crashing and fast-tracking are schedule compression techniques.
Interestingly enough, the execution phase is generally considered by our team members to be when the project starts since project team members are only minimally involved prior to the execution phase. At this point, the project plan should be approved and the project starts in earnest, often with the procurement of resources. It’s a good idea not to go firm with procurement contracts until the sponsor has approved the project plan, although we could invite bids for work and materials on the basis that these bids will not necessarily be approved unless the project plan is approved. In fact, managing contracts is becoming a greater part of our job as more project work is outsourced. Sometimes our entire project is outsourced, or the project we manage has been awarded to our organisation as a result of competitive tendering.
Essentially, the project team (might include employees, contractors, sub-contractors, consultants and suppliers) follows the plan and builds the final deliverable. This might be the preparation of software, the building of a house, the implementation of newly defined processes or countless other project outputs. Now all of this seems straightforward and even easy in a perfect world. In fact, in a perfect world, we wouldn’t need us project managers because everything would go as planned. However, in the real world it’s our job to help the team get through the execution phase by carefully managing resources, schedules, risks, issues, variations and a myriad of other challenges. Essentially our job is to remove obstacles to our team’s successful performance. Keep in mind that not all changes are bad. In fact, any change to our project is good as long as it enhances what it is the project set out to do.
The execution phase is literally where we do the work of building the project deliverable. As the clock ticks and money is spent, it is imperative to keep track and keep control of time and cost. A tracking Gantt chart will help us monitor progress and will allow us to see how to adjust tasks (if at all possible) to keep on track. Of course to do this we are reliant on clear, timely and relevant information. If our default progress reporting system isn’t giving us such information, we need to change it pronto. And we shouldn’t depend exclusively on written reports. They often suffer from editorialising.
Better we also talk regularly with our project team members one-on-one, making it easier for them to tell us the truth and the whole truth. And we should be cautious about “exception reporting” whereby we only get reports when things are going wrong. In other words, be wary of “no news is good news.” Our people might be reluctant to tell us bad news when they can’t balance this somewhat with good news. And good news allows us to reward people and publish our project successes. However, exception reporting might apply to our reports to our project sponsor and their reports to management, but they need to tell us about the format and frequency of any reports they require from us.
Whatever reports are needed by the sponsor should be mentioned in the project charter. If not, we need to discuss this with our sponsor since it is very important they be kept informed about progress and problems. We don’t want our sponsor to say stuff like “If only I had know…” and from that viewpoint it’s better to email routine reports in case memories get fuzzy when the shit hits the fan. Us project managers can be convenient scapegoats when things go wrong, although sometimes we are indeed to blame, unless of course we can blame contractors or sub-contractors or suppliers or anyone lower down the food chain – just joking – as project managers we’re responsible. The buck stops with us. One of our responsibilities is to even recommend to our project sponsor to scrap a project when the goal/objectives can’t be met or other constraints inhibit proper completion. We project managers find this one of the hardest things to do as it is in our blood to overcome obstacles and deliver results. And sometimes our project might be stopped prematurely even though we are on schedule and within budget. The problem might be changed project priorities or perhaps the rationale for our project has evaporated. Then we need to plan for project’s closure.
During project execution everyone seems to want to add or change the project objectives, particularly the scope and while we can’t blame them, we do have to control them. Oracle seemed to achieve its America’s Cup turnaround success through continual variations to their yacht during project execution. We call this practice “progressive elaboration”, which is not to be confused with uncontrolled changes that make their way into the project without being properly processed. Such uncontrolled changes are called “scope or feature creep” – not to be confused with progressive elaboration. Scope creep if ignored has been likened to death by a thousand cuts or death through accumulative effect of lead poisoning. Be wary of requests that start with expressions such as “while you’re on the job, I wonder if you could …” because your project might then become the victim of scope creep. Better we find out specifically what extra work is involved, cost the variation and formally advise the consequence for the budget and schedule.
There can be no changes to project objectives without our sponsor’s approval. Also, stakeholders seem to come out of the woodwork during this phase regardless of how hard we tried to include them during the last two phases. And remember, some stakeholders may not be happy about the project, in which case we may need to contend with protesters or even saboteurs. It’s just that now the project is becoming real for them. Be sure to keep everyone informed in a timely fashion about the good, the bad and the ugly. The more they all know, the fewer surprises they will have come delivery. Consider regular status reports and meetings. Well, actually be a bit careful about meetings as they can disrupt work, particularly those never-ending meetings we call at short notice. Perhaps meetings are only needed when we are required to collectively plan, problem-solve or decision make. Also, it’s very useful to precede our meetings with an agenda so people can prepare and follow-up our meetings with an action plan showing who is to do what by when, where when is an achievable specific date. There are a host of other techniques to keep in touch. The over-riding monitoring and control mantra is “to solve it easily, detect it early.”
Sometimes our plans have to be changed due to circumstances that are beyond our control, and even organisational politics seem to have a way of surfacing during project execution. The key to successful execution is to remember that our job as a project manager is to manage the process of project management, and the execution phase is just another piece of that process. But, expect the unexpected, keep a cool head and realise that our leadership skills are on display to everyone (not just our team) during project execution. It would be nice if we could now sit back and watch everything happen as per our plan, but that’s not going to happen. Earned Value Analysis (EVA) is a useful tool to track progress and make projections. As project manager we need to be looking ahead and further ahead than any other member of our team. We might maintain an EVA-based control chart that shows project cost and schedule performance.
One further thing warrants special mention – the lessons learned log. This log, electronic or hard copy, needs to be easy to use and readily available for project team members to record stuff they learn as they implement the project plan. If this log is not maintained, there is typically some half-arsed attempt to recall lessons at the end of the project when team members are becoming increasingly involved in other projects and business-as-usual catch-up work. While not all lessons will be applicable to our next project, some doubtlessly will be. Therefore when we start our next project, we should review the lessons learned, risk and issues logs from similar previous projects, particularly the issues log since these were problems not recognised and managed as risks. They can be added to our risk list. Of course we must not use the lessons learned log to chastise people. Do this and entries will soon dry up. And here are some other things that a busy project managers may need to do during this execution phase:
- Allocates work
- Analyses reports
- Approves payments
- Arranges reviews and audits
- Arranges contracts
- Assesses team members’ performance
- Builds relationships
- Celebrates successes
- Checks time sheets
- Clarifies and updates role and responsibilities
- Coaches and mentors
- Communicates with stakeholders
- Conducts trade-offs among project parameters
- Controls damage
- Coordinates resources
- Counsels team members
- Delegates work packages
- Escalates issues
- Establishes targets
- Evaluates tenders
- Forecasts project cost and duration
- Gives praise
- Holds meetings
- Implements change
- Keeps a project journal/diary
- Leads the project team
- Listens to stakeholders
- Maintains control
- Maintains project registers and files
- Makes decisions
- Manages conflict
- Manages issues
- Manages health and safety
- Manages risk
- Monitors variance
- Manages variations
- Negotiates for resources
- Practises politics
- Prepares task briefs
- Prepares updates for newsletters
- Procures resources
- Produces deliverables
- Provides advice
- Re-estimates time, cost and resource needs
- Re-negotiates resources and constraints
- Reports progress
- Rewards achievements
- Schedules and reschedules work
- Shares learning
- Smoothes and levels resources
- Solves problems
- Takes corrective action
- Tracks project performance
- Visits sites and stakeholders
- Writes reports.
It is during this phase in particular that our people skills will be needed, including those of delegation, negotiation, conflict management, communication, motivation, teambuilding and leadership. In fact, the term “Project Leader” seems rather more appropriate than does the term “Project Manager” given the importance of these people skills. Once we are familiar with the use of project management tools and techniques, it’s always the people who make the difference. See you soon.