This article addresses the importance of periodically revisiting project assumptions and leveraging organizational process assets in order to maximize earned value for both a project and the organization.
According to the PMBOK® Guide 5th Edition, Project Assumption is “A factor in planning process that is considered to be true, real or certain, often without any proof or demonstration”. Having assumptions in your project plan is a necessary part of being a project manager; however, as a project moves forward, we often neglect to revisit and validate assumptions, creating unnecessary risk to the project.
The Polynesians: How an incorrect assumption cost Europeans almost 300 years of scientific knowledge
“The explanation requiring the fewest assumptions is most likely to be correct.”
― William of Ockham
When European traders started crossing the Pacific early in the 16th Century, they came across archipelagos and islands thousands of miles from any continental shore, almost all of which were inhabited by thriving populations, similar in culture and traditions. The Europeans, assumed Polynesians, were a simple people, incapable of governing even the most primitive of societies. This assumption was in contrast to the fact that these “stone age” people had settled a series of over 4000 small islands across an expanse of ocean larger than the continental United States. In order to support their preconceived beliefs, the Europeans developed elaborate theories of how the islands came to be occupied, such as an imagined antediluvian southern continent that allowed settlement across an expanse of ocean that was “so vast that the human mind can scarcely grasp it.” For the next 200-odd years, Europeans, confident in their knowledge, chose to believe that they were the only ones with the capability to navigate the seas and continents.
In the late 18th century, Europe underwent the second great age of discovery. Driven by enlightened goals, explorers again set sail in the Pacific; this time to chart the islands, study the fauna and inhabitants, and stake out new territory for their respective sovereigns.
When Captain James Cook set sail to the South Pacific and part of an international effort to determine the distance between the earth and the sun by observing the transit of Venus, he did something unheard of by previous European explorers: he learned the languages and customs of the islanders, choosing to develop friendships, establish relationships, and even learning how a single culture navigated the vast expanse of between Easter Island, Hawaii and New Zealand using only simple canoes.
It was during these travels that Captain Cook came to know Tupaia, a Polynesian Arioi (priest). Tupaia was brought into the expedition at the insistence of Sir Joseph Banks, the expedition’s official botanist. When Captain Cook asked Tupaia for details of the area, Tupaia was able to draw charts with an area 40% larger than the continental United States, listing over 120 islands. With discoveries such as this, the Royal Societies of Europe continued to study the Polynesians, discovering that this seemingly simple culture was arguably the most accomplished seafaring people in the history of navigation.
Had the Europeans chosen to challenge their assumption of the Polynesian culture early in the 16th century, the treasure and lives they paid to establish trade routes, navigational knowledge and experience could have been used in advancing knowledge, arts and research; enriching millions of lives and families throughout the globe.
How many times have we neglected to see a solution to a problem because of assumptions that went unchallenged during a project?
Invalid assumptions often have significant consequences
This next vignette presents what can happen when a project manager refuses to update or change an assumption based on facts or inputs from the team.
One of my most frustrating experiences as a (much younger) project manager involved a project inherited mid-flight and on life-support; the project was over budget, team members were discouraged and resources were being pulled (taken from the “beatings will continue until morale improves” school of management); in short, the project was circling the drain.
After comfortably positioning the Albatross around my neck, I dove into the project plan and supporting historical documents to obtain a situational understanding of the project. As almost anyone who has inherited a project that has gone south can attest, the process of determining the health of a project is like fog: from a distance it looks solid and clear, but it turns nebulous when you get closer. Dealing with stakeholders and team members becomes more difficult as self-preservation kicks in, compounding the difficulty in getting the project back on track and moving in the right direction.
Over the next two weeks, I baselined the project, and work progressed closer to the forecasted schedule. Despite my best efforts, one task stubbornly insisted on moving my budget and schedule in a direction that did little to help my blood pressure. On its surface, its level of complexity for this task did not seem in line with the difficulty it had given the project; it was just a simple implementation of Voice over IP (VoIP), not unlike the ones that are done by Project Managers thousands of times per day. Having gotten the project back on track, sans this single bad apple, it was clear what I had to do next.
“Efficiency is doing the thing right. Effectiveness is doing the right thing.”
― Peter F. Drucker
Based on the current progress reports and project documentation, the VoIP was performing well: tasks were well defined, resources were allocated and work was being performed in a competent, deliberate manner. Yet, the VoIP work was consuming far more resources than similar work in the past, creating a paradox that had suddenly became one of my top priorities. As the new PM, I took what little goodwill capital I had built up and arranged meetings with the subject matter experts in the IT and Networking teams outside of the project to try and get a better understanding of the issue. I used a collaborative approach to the meetings, taking great pains to ensure individuals and supervisors understood the intent was to work together to solve the problem; not to establish blame. Once trust was built, a common theme throughout the meetings became clear: The project plan made an assumption for this work based on the previous experience of the former project manager. Like many projects, the project plan was fast tracked to meet organizational goals, resulting in unvetted assumptions and, more importantly, creating the perception that the project did not value the input of stakeholders and subject matter experts.
After the project kickoff, the IT and Networking teams had repeatedly challenged the approach to much of the technology work, based on their experience and the cultural environment and history of the organization. The tight project schedule discouraged change, creating an authoritative climate and discouraging communication that challenged the project plan. The project team members, realizing their input was discouraged, stopped providing constructive input and did no more than their assigned tasks. Technically, their work was efficient; they were performing work on time and budget, but knowing the work was being done the wrong way fundamentally changed the attitude of the team members. In previous projects, team members understood their value to the project: small problems would be solved organically at the lowest level, but in this project team members who saw they were no longer vested in the project only responded to problems addressed in a formal work order. Although I was able to re-establish some trust and we worked together to complete the project, there was irreparable damage done to the relationship between team members and the project management team. The trust, shared understanding and collaborative nature required for executing successful projects had been replaced by a culture of self-preservation.
The refusal to communicate and effectively use Organizational Process Assets resulted in a measurably negative impact on Enterprise Environmental Factors. The organization and future projects would pay the costs of rebuilding communications, trust and changing the culture and environmental factors. Had the team members been encouraged to be part of the project process, it is more likely that the project would have been completed without issue and the projects contribution to the Organizational Process Assets and Enterprise Environmental Factors would have been of more value.
Summary: Revisiting assumptions has a cost, failure to do so can have a far greater cost
“People need to be reminded more often than they need to be instructed.”
― Samuel Johnson
How different would our world have been if there was a Sir Joseph Banks in the early 16th century that insisted his Captain challenge assumptions by listening to the Polynesians?
How much better would my project have proceeded if team members had a more active voice in the process?
As project managers, we understand the importance of periodically reviewing assumptions in a project. Resource constraints force us to choose the scope of the review and how we proceed.
An effective approach toward assumption review almost always combines both objective and collaborative approaches to mitigate risks
Objectively, the project manager uses project information and reports to determine critical assumptions.
Collaboratively, the project manager creates a project climate that encourages and supports project team members to provide input on assumptions in their area of work or expertise.
Together, these two approaches create a near-optimum way to mitigate risk: the objective approach allows the project manager to manage known assumptions and the collaborative approach effectively addresses unknown or ill-defined conditions that may impact assumptions. Outside of the project, the collaborative approach communicates the value of project team members, creating a positive influence on Enterprise Environmental Factors and for the organization as a whole.
In closing, it is of critical importance to challenge assumptions during a project, and it is best approached in a collaborative environment.