Viewing Posts by Lynda Bourne
By Lynda Bourne
How much detail is too much? Traditional views tend to favour a management approach built on the assumption more detail is better, and to a point this is undoubtedly correct, insufficient detail in a plan of any type is a sure way to fail – ‘just-do-it’ at the overall project level does not help.
But looking at the ‘Coastline Paradox’ and using the length of a coastline as a synonym for the duration of a project suggests there is a point where too much detail is counterproductive.
The coastline paradox states that as you increase the detail by using smaller units of measure, the measured length of the coastline increases. If you use a small enough unit of measure, the length becomes infinite. For a more detailed explanation see: The Coastline Paradox Explained https://en.wikipedia.org/wiki/Coastline_paradox
So, what does this mean for project controls and project management? No one navigating a ship into a UK port would be happy using a map where the smallest measurement was 50 km, significantly more detail is needed, but they do not need absolutely everything about their intended destination. What’s needed is useful information at an appropriate level of detail, the same goes for you, when navigating your car in a strange city:
Finessing project plans to present useful information at the right level of detail is not easy, decisions have to be made!
Take a typical risk register, if you tried listing every conceivable risk, the document would emulate the ‘coastline paradox’, and be of almost infinite length, which means the register is never finished and the project does not start. Conversely, miss one or two significant risks and the project team may have a very unpleasant experience, possibly causing the project to fail. Pragmatic guidelines about the risks to be considered are needed and these have to be tailored to the project. Similar guidelines are needed for the schedule, cost plan and all of the other sub-plans needed for a project.
How much detail do you feel is appropriate for your projects?
 Image source: Understanding Design, The challenge of informed consent. Dr. Lynda Bourne, 27th November 2014; maps of North Sydney
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 19th 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:
Is Planning Predictive or Persuasive?
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.”
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?
 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?