Voices on Project Management

By Kevin Korterud

When I first started as a technology project manager, it was not uncommon for a project to have just one deliverable. All of the tasks in the project created the path that led to the single deliverable, which in many cases was a program, report or screen. Life used to be so easy!

As projects became more complex, the need grew for multiple project deliverables that lead to a complete solution. Deliverables now represent the “building blocks” that form a key foundational element of any project.

Whereas scheduling tasks is a fairly straightforward process that involves capturing durations, resources and successor/predecessor networks, scheduling deliverables comes with its own set of complexities. Deliverables don’t always behave in a linear manner like tasks­—so special considerations come into play with their scheduling. In addition, there are typically people and expectation factors that need to be part of a deliverable scheduling model.

Here are three essential reminders for properly scheduling deliverables:   

1. Deliverables Involve a Package of Tasks

Whereas tasks are singular items that stand alone in a work plan, deliverables have a few extra packaging steps in their path to completion.

One of the most dangerous scheduling mistakes to make with deliverables is to have a single task in a work plan that represents the deliverable. This is because of the variation in duration and effort that it takes to complete a deliverable.

Deliverables have a natural path to completion that involves a package of tasks, whose dynamics differ from normal tasks in a work plan. Project managers need to include these extra tasks that chart the lifecycle of a deliverable from initiation to completion.

For example, a sample set of deliverable task packaging would appear as follows:

You can tell from the above table that prior to scheduling deliverable task packages, project managers need to have a deliverable governance process in place. A deliverable governance process that identifies specific deliverable reviewers and a single approver are key to the effective scheduling of deliverables.

2. Deliverables May Require Task-like Linkages

We are all familiar with creating predecessor or successor linkages between tasks to form a linear series of work needed to achieve an outcome. Those linkages serve to drive schedule changes as prevailing project conditions occur.

Deliverables can require the same sort of linkages found in tasks. For example, if you have deliverables that lead to the creation of a marketing web page that involves multiple supplier deliverables, selected tasks in the deliverable package can contain task linkages. These linkages impose conditions which determine the pace at which related deliverables can be completed.

Let’s say there are three design documents from different suppliers required to create an overall design document. The build of the overall design document cannot finish before those three supplier design documents are all approved. So in the work plan, delays and schedule movements in the supplier design deliverables will drive the true completion date of the overall design document.

3. Resource Availability Impacts Deliverables

In addition to the scenario of having deliverables with dependencies, it is just as likely to have a set of deliverables that do not have any dependencies at all. These deliverables need to be completed by the end of the project but do not directly figure into the final outcome of the project. These are often process improvement deliverables that are needed for future projects that are not ready for execution.

When a project manager has a slate of unrelated deliverables, the optimal approach is to bundle them into agile-like sprints. The content of each deliverable sprint is determined by a balance of resource availability for the people who build, review and approve deliverables, as well as any form of relative priority. For example, if deliverable reviewers have low availability during a scheduled deliverable sprint, those deliverables can be pushed to a subsequent deliverable sprint.

Priority can also determine the content of deliverable sprints. Higher priority deliverables would displace lower priority deliverables to future sprints, even if work has begun on those deliverables. For example, if there is a strong need for a certain tool to be used by multiple projects, those deliverables would move into the current deliverable sprint. The deliverable sprint process allows for agility, while balancing value created from the deliverables.

As I shared earlier, life was so much easier when projects created one deliverable. Different times demand different approaches to managing deliverable schedules—especially on large transformations where there could be hundreds of dependent and independent deliverables. The last thing anyone wants to do is insufficiently manage deliverables: Leaving out one of those “building blocks” might cause the house to fall over.

What tips do you have for deliverable scheduling in today’s project ecosystem? Share your thoughts in the comments below.

By Ramiro Rodrigues

In the 2009 film Knowing, a boy finds a time capsule filled with documents from decades ago. His father, an astrophysics professor, then discovers that the messages list some recent and impending major disasters, and even predict a global calamity in the near future.

Apocalyptic visions of an imminent end to the world have always brought joy to the film industry—but they bump into the same logical limitations that are still impossible to overcome. As far as we know, we do not have an effective technology capable of predicting the future. Whether it is related to weather forecasting, economics or sociology, we are not able to tell, at present, precisely what will happen at a specific moment in the future.

What we have always had is a great will to take a chance and get it right. Since the beginning of time, man has ventured to predict the future and, during these attempts, we’ve come up with an ocean of predictions that have been proven wrong. But we don't give up.

A New Model of Scheduling

In today’s organizations, modern project management has to meet the need for schedule development that seeks, in a deterministic fashion, to set the estimated dates of future events related to people, project deliveries and work that will be executed. This usually is a great Achilles' heel in the field of project management. The organizational frustration that results from estimated scheduled activities that turn out to be incorrect is very common.

Why don’t they happen as expected? There are different reasons, usually related to people and intrinsic characteristics of the expected activities. But in essence, they happen because it still is impossible to predict the future. Of course, there are some strategies that can help mitigate the risks of the deterministic forecast, but in the end, they are only predictions.

However, we must understand that organizations need to estimate when the returns on their investments will be accessible for use. Some executives will say that there is no progress without clear and foreseen goals.

That’s right. But how do we get out of this complex scenario in which future dates are determined but do not happen as planned?

One trend that has been applied by industries such as consulting, engineering and research & development is the probabilistic forecast of schedules. In this case, with the assistance of simple statistical concepts, the forecasts of the activities and of the project are viewed as a whole, with probability ranges to conclude them.

It is not solely a mathematical solution; the change is conceptual. The idea is no longer to set, within the organization, the delivery estimates at certain dates grounded on the expectation that they will come true. Rather, the goal is to present length ranges that provide the company with a perspective that there is, for instance, a 68 percent, 95 percent or 99.7 percent chance that the project delivery will take place during the expected dates.

This change in principle allows for the understanding that one can never be 100 percent sure of what will happen in the future but, at the same time, enables the management of the risks involved with reasonable control.

This planning model can bring, in the near future, more maturity and quality to the management of schedules and deliveries.

Do you use this model in your organization? Share your thoughts below. 

By Lynda Bourne

As you may know, any monitoring and control process has three components. The first is establishing a baseline that you plan to achieve, the second is comparing actual progress to the plan to see if there are any differences, and the third is taking corrective or preventative action. Corrective actions fix existing problems, while preventative actions stop problems from occurring in the future.

This post looks at the middle phase. Before taking action to bring performance into alignment with the plan, make sure the variance you are seeing in the control systems is real. Corrective and preventative actions take time and usually involve costs, and there is no point in expending effort where it is not needed. 

The variance is the difference between two imprecise elements: the planned state and the actual situation. The plan is based on estimates and assumptions made some time ago about what may occur in the future. All plans and estimates have a degree of error built in; it is impossible to precisely predict the future of a complex system such as a project. Similarly, the measurement of the actual situation is prone to observational errors; key data may be missing or the situation misinterpreted.

So how do you decide if the measured variance is real and significant enough to warrant corrective action? I suggest considering the following:

1. Does the reported variance line up with your expectations?

2. Is the variance significant?

3. Is a solution viable?

Let’s explore these in depth.

Does the reported variance line up with your expectations?
If a cost report says there is a profit of US$10,000 in a work package where you expected to see a loss, there’s a high probability some of the actual costs have been missed. It’s likely either your expectations were misplaced or the measurements contain data errors. You need to resolve this question before moving on. When the variance and your expectations agree, you can be reasonably confident the information as measured is correct.

Try looking at a couple of different monitoring systems, such as cost and time. Do the two systems correlate, or are they giving you very different information on the same group of activities? If they correlate, perhaps your expectations are misplaced. If they are giving you different information, there may be data errors.

Is the variance significant?
Next, look at the significance of the difference. Point measurements are prone to error simply because you have to assume a lot. For example, you may be sure a 10-day activity has started, and equally sure it has not been completed. But if the work is about half done should you record it 40%, 50% or 60% compete?   

If the predicted slippage on the completion date for a key milestone over a series of reports is bouncing around, any single measurement within the noise factor is likely to be insignificant.

Trends, on the other hand, highlight issues. Sensible control systems have range statements that indicate the variance is too small to worry about if it is inside the allowed range. This general rule is modified to take trends seriously and to require action to correct negative variances close to a milestone or completion.

Is a solution viable?
This third question looks at viability. Can you take action to resolve the variance for a sensible cost? Some issues are simply outside your control, such as changes in the exchange rate. Risk planning and mitigation may have been able to minimize the issue in the past, but if you need the import this month, for example, you have no option but to pay the current price. 

Other situations are simply not worth the cost. There is no point in spending US$10,000 to correct a -US$5,000 variance. However, this decision has to take into account any effect on the client and your organization’s reputation. Cost overruns are generally internal, whereas late delivery and quality issues may have a significant reputational cost, affecting stakeholder perceptions.

Where a viable option exists to correct negative variances, corrective and preventative actions need to be planned, prioritized and implemented.  There is no point wasting time on a controls system that does not generate effective controlling actions.  

Closing Thoughts
I’ll leave you with two final thoughts. First, don’t forget about positive variances. Similar questions need to be asked in order to amend the plan to lock in gains. If your supplier is going to deliver some equipment three weeks ahead of schedule, can you reorganize the plan to make sure the installers are available three weeks sooner? If this is viable, make sure it happens in order to lock in a three-week gain. If you fail to take action, the installers will turn up on schedule and the gain generated by your supplier will be lost.

Second, implementing corrective and preventative actions requires the resources working on the project to do something different. Variances don’t correct themselves, and simply telling someone to catch up is unlikely to have any effect. Sensible management action, decisions and leadership are needed to physically change the situation so there is a correction in the way work is performed. This is a core skill of every effective manager.

I’d love to know: How do you deal with variances in your projects? Please share below.

By Ramiro Rodrigues

The term path is used for a sequence of activities that are serially related to each other.

Imagine, for example, that your colleagues have decided to organize a barbecue. After dividing up the work, you are responsible for hiring the catering services. For this task, you are likely to have to look for recommendations, check availability and prices, analyze the options and then choose the best one. These four activities are a path. In other words, they are a sequence of activities that must be carried out sequentially until a final goal is achieved.

A project manager’s job is to estimate the duration of each planned activity. And if we return to our example, we could consider the possible durations:

• Activity 1: Seek professional recommendations—three days
• Activity 2: Make contact and check availability and prices—six hours
• Activity 3: Analyze the options—one day
• Activity 4: Select the best option and confirm—two hours

This sequence of activities will last 40 hours, or five workdays. And since the whole barbecue has been divided among various colleagues, other sequences (or paths) of activities—such as choosing the venue, buying drinks, organizing football, etc.—will also have their respective deadlines.

The critical path will be the series of activities that has the longest duration among all those that the event involves.

Let's imagine that the longest path is precisely this hiring of the catering services. Since the process is estimated to take five days, the barbecue cannot be held at an earlier time. And if it were held in exactly five days, all the activities involved in the path have no margin for delay. This means that if, for example, my analysis of options is not completed on the date or within the duration planned, then the barbecue provider will not be selected in time, which will invariably lead to the postponement of the barbecue—and leave a bad taste in my co-workers' mouths.

Under the critical path method, there is no margin for delay or slack. If there is a delay in any activity on that (critical) path, there will be a delay in the project. At the same time, other "non-critical" paths can withstand limited delays, hence the justification of the term.

It is the duration of this path that is setting "critical" information for all projects—when all the work will have been completed.

Do you use the critical path method in your work? If so, what are your biggest challenges?

By Ramiro Rodrigues

We are experiencing a great contemporary paradox: In spite of state-of-the-art gadgets and collaborative communication tools, which should be streamlining and facilitating work, we feel increasingly burdened with more responsibilities and response requirements.

The clearest side effect is the epidemic feeling that we are always short of what we wish we could have read, produced or done.

Of course, the benefits that technology has brought us in recent decades are indisputable. The production of human knowledge has gained stratospheric scale. The world has become "flat"—economies are now deeply integrated, and long distances have been collapsed by hyperconnectivity. But this also means that a good share of the world's population can now compete for the same professional space as you and your company.

Perhaps this is why recurring publications about better management of time and its countless functions become the focus of attention for the most attentive visitors to bookstores.

When everything is urgent, in fact, nothing is. If everything has the same priority, there is no way for anything to stand out. Perhaps this is the central issue behind the stress so many people feel today. Once the urgency of demands is generalized, it becomes difficult to produce high-quality, timely results.

What’s the solution? Planning, planning and ... planning. Only a good deal of planning — structured and strategic — allows corporate and project leadership to stay focused on real priorities and meet the right attention needs of their teams.

For the individual, planning is also a personal survival tool for organizing and balancing work, personal and social demands.