Voices on Project Management

By: Lynda Bourne.

Has agile killed the organization chart? The concept of business management evolved with the development of factories during the early days of the Industrial Revolution. Initially, factories followed the same system as pre-industrialized enterprises where the “Lord of the Manor”/owner made all of the significant decisions and told others what to do. But this straightforward command-and-control process was limited by the capacity of the owner to stay on top of the flow of information and decisions needed.

As organizations grew larger and more complex, the delegation of authority became necessary—but initially appears to have been very ad hoc and dependent on personalities. But as the concept of an organization evolved in the 19^th century, management structures became more formalized—and one of the early tools used to demonstrate the management hierarchy, and the division of labor, was an organization chart. The example below is from 1917:

This view of an organization give rise to concepts such as departmentalization, chain of command, span of control, centralization, work specialization and formalization. The business appears well organized (at least on paper), but is not very adaptive.

Traditional project management grew out of business management, and uses the organization breakdown structure (OBS) linked to the work breakdown structure (WBS) to define the person responsible for each element of the work. The OBS fulfils the same function as an organization chart in general business, defining the management hierarchy and reporting lines within the project or program.

But is this type of thinking useful in today’s flexible working environment? In one respect, knowing who is going to be responsible for delivering each element of the project and ensuring their work integrates with the other parts of the project is important, as is the need to balance the delegated levels of authority and responsibility with the capability of the assigned person.

The OBS is also useful for informing the people doing work who they need to keep informed of progress, issues and the completion of the task. These concepts are central to the way earned value management is designed with the management cells above becoming control accounts.

But does the effective management of human resources need a hierarchy, or can distributed responsibility work as effectively and more dynamically? There are many success stories built around self-organizing teams, cross-functional teams, and agile ways of working. And in business, matrix structures are probably more common than the hierarchic structure depicted by an organization chart.

The organization chart has been around for a very long time, but does the type of structure and management theories built around the concept of a management hierarchy really help at the project and program level when confronted with “alien” concepts such as self-organizing teams and agile? The two questions posed for discussion are:

1. Do you think the OBS is useful, and is something similar used in your project or organization?
2. What options are available—or need inventing—to replace the OBS in an agile, self-organizing workplace?

Lynda Bourne

To paraphrase Gen. George S. Patton, “A good plan, enthusiastically executed now, is better than a perfect plan next week.” The objective of this post is to suggest that too much emphasis is placed on developing ‘perfect plans’ that attempt to accurately predict future outcomes (a passive process)—and not enough on using the planning process to proactively influence the project’s future direction.

The thinking behind this proposition comes from American political theorist John H. Schaar, who said: “The future is not a result of choices among alternative paths offered by the present, but a place that is created—created first in the mind and will, created next in activity. The future is not some place we are going, but one we are creating. The paths are not to be found, but made. And the activity of making them changes both the maker and the destination.”[1]

In this frame, project plans become a guide to the pathway you are intending to make rather than a prediction about achieving something already fixed.

Unfortunately, the mathematical and scientific approaches to planning—particularly cost estimating and scheduling—have evolved in a way that implies that the plan is a factual statement of what will happen. This concept is embedded in contracts, law, and expert submissions going back decades. But is this approach the best way of achieving a good outcome? Fighting over what should have happened after it did not happen and allocating blame is not very useful, even in traditional industries.

My suggestion is that we adopt a more agile and adaptive approach to planning focused on engaging all of the important stakeholders. This type of collaboration is far more likely to craft success! Working with people to build a plan they are willing to commit to achieving is far better than telling them what the plan says they have to do. Then working with them to progressively adapt the plan to deal with the unfolding reality on your shared journey towards success is far more likely to optimise the eventual outcome.

The final project objectives of time, costs and outcomes are unlikely to change in most projects, but the pathway you chose to follow towards achieving these objectives is yours to make, adapt and improve along the way. The two key ingredients are building consensus and commitment with the stakeholders (particularly those involved in the work)—and then keeping them engaged. In this scenario, the project plans become a key communication tool and people are held accountable for achieving their commitments.

The analytical aspects of planning are still important, and should be used to support this approach. There is no point in committing to a plan that will deliver failure. What the analysis shows is the scope of the problem to be solved, and the solution is crafted with the project’s stakeholders. The trade-offs and challenges of project management don’t change; the difference is moving from a paradigm where the project manager tries to make people work to the plan, to one where the project manager leads the team in planning to achieve the project objectives and outcomes.

How flexible is the planning on your project?

[1] Legitimacy in the Modern State (ed. Transaction Publishers, 1981) - ISBN: 9781412827485

By Lynda Bourne

Anything that can go wrong will go wrong.

We’ve all heard—and have probably uttered—this epigram many times.

The origin of the phrase now known as Murphy’s Law is often attributed to U.S. Air Force colonel and flight surgeon Dr. John Paul Stapp, who directed research Project MX981 in the late 1940s. The objective was to determine the effect of gravitational forces (g-forces) on the human body—and to use this data to work out how to safely eject pilots from high-speed jet aircraft. The experiments involved rapidly accelerating and decelerating rocket sleds carrying varying payloads, including human volunteers. For many of these experiments, Stapp served as the volunteer so he could apply his medical knowledge directly to what he was feeling. Over the years, he collected a catalogue of broken bones and other injuries, but no one was seriously injured or killed in large part due to the application of Murphy’s Law.

To validate the experiments in Project MX981, Stapp required very precise measurements of the stresses being experienced by the volunteers. He became aware that Capt. Edward A. Murphy was working on another project involving centrifuges, which included designing very accurate systems to measure the g-forces exerted on the person in the centrifuge.

From Stapp’s perspective, Murphy’s sensors seemed to be ideal for accurately measuring the forces the person strapped to the rocket sled experienced. Murphy happily agreed to Stapp’s request to modify his sensors and shipped a couple to Stapp for use. However, the first experiment Murphy’s gauges failed completely: No measurements were recorded. When Murphy came out the morning after to investigate the failure, he found the gauges were oriented incorrectly and is reported to recall saying, “If there is more than one way to do a job and one of those ways will result in disaster, then somebody will do it that way.” Murphy had made accurate drawings of the gauges and instructed the people who would install them but had not made it clear that the gauges had to be positively oriented in only one direction.

The origins of Murphy’s Law lies in a conversation following this failure. Murphy recalled saying, “Well, I really have made a terrible mistake here, I did not cover every possibility.” Stapp replied: “Well that’s a good candidate for Murphy’s Law,” according to Nick T. Spark’s “A History of Murphy’s Law.”

The experiments continued with the final test run before the project was terminated. With Stapp as the volunteer, the test resulted in the sled accelerating from 0 to 630 miles (1,014 kilometers) per hour—the highest land speed of any human—in 5 seconds, creating a force of 20 Gs. The sled then stopped in 1.4 seconds, imposing 46.2 Gs of force on Stapp.

When asked many years later about the remarkable safety record of Project MX981, Stapp said one of the key factors was the application of Murphy’s Law: “The entire team adhered to Murphy’s Law, they always kept in mind whatever could go wrong would, so they made extreme efforts to think up what could go wrong and fix it before the test.”

While your project is unlikely to have the risk profile of a ride on a rocket sled, designing potential problems and failures out of the overall system pays dividends. Success is designed in, not tested in. To apply Murphy’s Law proactively, you need to think through everything before you start work. Ask yourself: When one part fails, does the system still work? Will it still function as it was supposed to do? What are the single points of failure? What are the processes someone can do incorrectly?

This type of thinking establishes potential critical failure points, where there’s a need to put redundancy into systems. It also pushes teams to ensure the opportunity for human error is eliminated wherever possible. There are formal approaches to applying Murphy’s Law, such as failure modes and effects analysis or reliability engineering used in system engineering and on the design of critical systems. But you probably don’t need to be this sophisticated on your project. Simply ask your team to think through what can go wrong and what can be done about it. This approach may be included in the project’s regular risk reviews or included in the agenda for the daily stand-up or other team meetings.

How will you apply Murphy’s Law with your team?

By Lynda Bourne

I was recently involved in a discussion about why some projects fail and others succeed, even when they’re completed in similar circumstances. The most common determinant of project outcomes—both positive and negative—boiled down to the way the people delivering the project work together. A cooperative and committed team underpins success.

This led me to think about the key requirements for creating a committed and cooperative team. And while the concepts below aren’t  new, consistently creating the environment to allow them to flourish can prove challenging.  

In my opinion, the three most important factors are:

1) An agreed-upon objective: Defining the project objective in a way people understand is the starting point. For one person, a “great website” may mean a technical marvel with all the bells and whistles. But for someone else, it may mean a simple, easy-to-use presence. It’s up to project leaders to get the team aligned—committing to an objective that’s not going to be delivered creates disenchantment.

2) An efficient team organization. Options can range from self-organizing teams to traditional leader-follower models. What really matters is that the team works in a coordinated and organized way, and this requires good, multidirectional communication to work.

3) Trust between team members. This last element is probably the most important—and least understood. You don’t need to like someone to trust them. In fact, you don’t even need to know someone to trust them.  In an emergency, for example, it’s common to see a group of strangers form into a self-organized team and work together—often in quite dangerous situations—so things are stabilized. This is often referred to as “swift trust.” More traditional trust builds on reputation and observed experiences. Either type works, but you need trust. Without that, you’re not going to rely on the other people in the group to do the right thing to help you and the rest of the group achieve your shared objective.

In the modern world, people work on projects in all sorts of ways: virtually, in agile scrums, in traditional hierarchical teams and in myriad groupings. The people may come from one organization or many. Regardless of the group structure, one thing remains true: Project success comes down to effective teamwork. 

What are your tips on creating an environment that allows project teams to flourish?

By Lynda Bourne

Every decision involves making a choice between alternatives, with the project leader picking from a number of options. This selection is influenced by information (albeit sometimes insufficient) and preferences rooted in values and ethics. In these circumstances, the modern trend of risk-based decision-making can be seen as a tautology: Every decision involves uncertainty and therefore incorporates an element of risk.

The worst option is to delay a decision until all of the necessary information is available—and, as a consequence, all of the opportunities have evaporated. So how do you make good decisions? The starting point is to accept there will be uncertainty in all true decisions—and the outcome matters. You have to choose between different options while navigating any number of obstacles ahead of you: incomplete information to support the decision, no clear best path and unknown outcomes of some options. The challenge is to make the best decision in the available timeframe balancing risk and reward. No process can guarantee a good outcome every time, but working through a pragmatic process can help improve outcomes.

Your decision-making process needs to:

• Define the objectives or outcomes you seek. This frames why you need make this decision and what success may look like.
• Consider the risk of each of the alternatives is by assessing the level of uncertainty and the nature of the possible outcomes. Educated guesses are okay.
• Rank the options based on the level of risk exposure and the probability of achieving the required objectives. A weighted decision-making matrix may help, but remember to keep costs and benefits in mind a well.
• Make the decision and move on to implementation.

Getting the weighting right is central to this approach. In some situations, particularly when safety is involved, dull, safe but expensive may be the best choice, particularly if the cost is not particularly significant in the overall project budget. Think about investing in the security layer for any on-line finance or ordering system, for example. In other situations where failure is only going to cause some embarrassment, innovative but risky solutions may be better, particularly if the cost is low. Case in point: No one can predict when a website will become ultra-successful (go viral), but you won’t be successful if you don’t try. Investing US$10,000 in an option that has a 10 percent chance of making US$1 million is a good investment (but prudent managers have plan B ready to roll).

There’s no way to ensure the best decision is made, and often no way of knowing if the decision you’ve taken was the best—you cannot re-run history. But you can measure bad outcomes; the worst decision is no decision. The next-worse option is a late decision. This always costs a lot of money and may result in opportunities being missed. And the next worse option after that are timely decisions based on a wrong premise—usually out of trying to avoid all risk.

If you avoid those pitfalls, you’re likely to be making a well-founded decision. This is the realm of competent managers. But you’ll also need luck on your side to be seen as making a “really good” decision. And for that, you make your own luck, to quote author Ernest Hemmingway. Deciding to make effective decisions is a choice you need to make.

What does your decision-making process look like?