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 Lynda Bourne

In my previous post, Innovation and Design Thinking, Part One, I focused on the personal and cultural aspects of innovation. But having an innovative idea is only a small part of the challenge. To create value, the bright ideas need to be transitioned into practical products or solutions that can be applied, sold or used.

Well-managed projects are a key element in building the new product or solution, but traditional project management, even agile project management, is rarely sufficient.

One well-established technique that bridges the gap between an idea and a practical project: design thinking.

Design Thinking

The original concept of design thinking was built around problem-solving with a shift in emphasis from traditional analysis toward innovation and synthesis. Design thinking tends to be promoted by its advocates as a complete solution to delivering innovation within an organization. A typical model looks like this: 

There are many models, with minor differences, to explain the process. But they all involve the following basic steps:

• Understand and empathize. Using observations and qualitative data, create stories that help define the problem. Understanding the context and culture of the people involved helps you to empathize with the problem. As with agile, the design thinking approach is focused on the end users’ needs.
• Define the problem or opportunity. Research and find patterns in these insights, then diagnose the problem. Translate the diagnosis into a defined plan.
• Ideate, prototype and test. Here’s where the creativity comes in. The first round of “solutions” should really be treated as a jumping off point for more in-depth iterations. Create simple prototypes that test possible outcomes, so mistakes are noted and fixed early on.
• Implement and learn. The entire process can be cyclical, especially when it comes to ideating, prototyping and testing. After implementing the solution, feedback facilitates the refining of ideas.

The problem with these models is a lack of process around creating the solution. My suggestion is using design thinking to link the creation of a culture that encourages the development of innovative ideas (the focus of my last post) with the use of project management to deliver results.

I believe that bringing project management disciplines into the design thinking process—starting from the validation of the design brief (is the proposed solution feasible, viable and desirable?) through to the delivery of the innovation and realization of benefits—is likely to result in a more cost-effective outcome in a reduced timeframe.

Innovative thinking should be encouraged within every organization. But you need pragmatic innovation to move the best of these ideas from an abstract concept to a proven concept that delivers value. Melding design thinking and project management seems to be one way of achieving this objective.

What do you think? Share your thoughts in the comments below.

By Mario Trentim

There's an old saying: "A fool with a tool is still a fool.” And I’ve heard many project management professionals say that best practices and good methodology are more important than project management tools and software.

Do you agree? By the end of this article, you might change your mind.

A Brief Story of a Failed Methodology

I've been working as a project manager since 2001. In my early days, as an engineer, I was responsible for the technical and managerial aspects of projects. In 2010, as I moved up the ladder in my organization (the Air Force), I was assigned to implement and operate a Project Management Office (PMO). Considering that we didn't want to make large investments up front, my focus was on creating a methodology, developing templates and designing and delivering training. To my surprise, only a few of my recommendations were implemented, even though abiding by the PMO guidelines was mandatory.

I started investigating the reasons. It turned out that it was not that people didn't know the methodology, nor that they did not want to follow it. It was just too much work.

You know the drill: A project manager is assigned to a project, searches the intranet, finds the PMO site, then reads the "project management manual" and any other supporting documents for the methodology. Finally, the project manager copies and pastes files from a shared folder, and starts filling in all the templates (scattered in different files and different formats).

Truth be told, the project managers usually started on the right foot. The problems appeared as the project progressed, because it was a huge effort to keep all files updated and integrated in a coherent fashion.

Although I am talking about experiences from 2010 to 2014, many organizations unfortunately still find themselves in a similar situation today.

Productivity goes down. Project failure rates go up. And as the organization demands more training, it creates more controlling processes, auditing and extra reports—resulting in even more work.

The Solution

When I first came across Project Portfolio Management (PPM) and Enterprise Project Management (EPM) software in 2003, I didn't think it would be a big deal. By 2010, I was convinced that you cannot increase portfolio and project management maturity without software.

To be able to implement a standard toolset across projects, the PMO usually starts with paper-based or Excel-based approaches. The risk is that they settle for less by not evolving into using enterprise-level business applications.

Is adopting a particular tool or software a requirement to project management success? No. But the use of project management tools increases maturity.

People often say that they will acquire a corporate project management tool once their organization is "mature enough." Going back to the beginning of this article, I am very aware of the fact that a tool is useless if you don't know how to use it. However, once you already have basic knowledge and processes, a tool can speed up the learning process—skyrocketing productivity.

As an analogy, imagine that you already have basic knowledge in math and finance. When should you buy a financial calculator, such as HP-12C? Only after five years of calculation amortization by hand? I doubt this would be the smartest choice. After all, you don’t have to become an expert bike runner before you can buy a bicycle.

In project management, some of the foundational concepts can be taught by using flip-charts, sticky notes and simple Excel spreadsheets. But you cannot teach people how to create a solid and realistic schedule and cost baselines without project management software. It is just not feasible. It is not that it is impossible. Actually, in the 1960s and 1970s, the Polaris and Apollo projects were planned without the help of software tools (nonexistent at the time). But planning for those projects took a long time.

Today, we live in a modern world in which the project life cycle is shorter. We manage multiple projects at the same time, and there is more volatility and uncertainty. Project managers have to evolve as well.

How to Implement PPM and EPM Tools

Project Portfolio Management or Enterprise Project Management is a corporate platform to manage portfolios, programs, projects and resources enterprise-wide. The PMO is ideally positioned to lead project management tool selection because it understands the big picture from different project managers, team members and business units. When assessing specific project management tools, take into consideration:

1. Functions and features
2. Implementation requirements and interfaces
3. Application maintenance, support and upgrades
4. Availability of vendors
5. Cost (including customization, licenses and more)

Depending on the size of the organization, you might prefer to execute a pilot before rolling out the tool to the entire organization. It is important to keep stakeholders engaged and informed by sharing:

• Advance announcements
• Senior management sponsorship and endorsement
• The implementation schedule
• User training

A word of caution: Do not underestimate the effort needed to implement a project management tool enterprise-wide.

In the meantime, please leave your comments and questions 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 Dave Wakeman

I’m heading to London in a few weeks and while I’m there, I’m going to catch a bunch of Premier League matches. My team, Tottenham Hotspur, has had an up-and-down season—changing coaches in November, and then getting a new manager, José Mourinho. 

As I was thinking about my travel plans, I also started thinking about how managing a soccer team is a lot like managing a project. And, to take it even further, I started asking myself what we can learn from some of soccer’s best managers. 

Flexibility Counts 

As I mentioned, Tottenham had to change managers this season. In switching from Mauricio Pochettino to José Mourinho, the team found itself working under an entirely new system. Pochettino was known for speed, pressing and intensity. Mourinho was known for being more tactical, controlling and playing a style of soccer that many don’t feel is pretty.     

The challenge for Mourinho is that he came into the team in the middle of the season, so he needed to adapt to the team he had—not build the one he wanted. That meant his Tottenham team has been a lot less defensive oriented, and a bit higher scoring than a typical Mourinho-coached team. 

This reminds me of projects where we don’t always have the time, resources or skills that we would hope to have. In these cases, we need to be flexible. Is there a way to shift the timing of certain parts of the project to fit your schedule? Can you manage all the different stakeholders with their different styles of communication and their different goals? 

In soccer, you deal with complex situations that don’t lend themselves to simple or rigid solutions. When managing a project, we see the same situation occur. This means that we have to understand where we are going and be able to adjust on the fly when the situation changes, so we can get to our destination. 

Communication Matters

I think communication is one of the key skills that coaches and project managers share. I’ve always said 90 percent of a project manager’s job is communication and 10 percent is everything else. 

In watching soccer managers, I have a sneaking suspicion that the same ratio applies. Like project managers, they have to have a great deal of technical skill, but they also have to be willing and able to delegate and let other folks deliver their vision. 

In other words, it is difficult to do everything yourself. And being the public face of the project or team requires the leader to deal with key stakeholders like the media, the sponsor and the team. 

In both scenarios, communication is more than just answering questions or giving orders. Both managers spend lots of time listening to other people so that they can make decisions or adjustments, and so they have a finger on the pulse of the teams they are leading. 

Success Isn’t Guaranteed

This should seem obvious, but every project comes with a bit of risk. The same goes with managing a soccer team. Just saying that success isn’t guaranteed isn’t nearly enough. But knowing that failure is a possibility impacts the way that we all approach our jobs. 

Project leaders spend a lot of time thinking through risk management, risk mitigation and change management. Similarly, soccer managers are thinking about how their formations will impact the game, gaps in talent and a multitude of other factors that could be the difference between success and failure. 

To me, this concept gets interesting when you think about success. It requires us to do all of the same things, like understanding risk, being flexible and willing to change and communicate effectively. 

These are only my top three ways that a soccer manager is like a project manager. What would you add? Let me know below!