You are on page 1of 3

http://www.brijj.

com/group/project-managers-it-software--link--The-Need-To-Validate-Project-
Assumptions?eid=3774622

The Need to Validate Project Assumptions


66 SHARES
Twitter
Facebook Google+ LinkedIn
Dr. Harold Kerzner
April 14, 2014 Strategy 1

More than a decade ago, I was asked by a group of project managers to consult for their
company. The executives were of the belief that project management was a failure and the
function should be dissolved. Altogether, I was invited into the firm to perform a Root Cause
Analysis and possibly make recommendations. In this particular firm, project management was
being used to create products that could be sold to their clients. And like each project, this one
had a life cycle that includes phases, which are shown in the exhibit below.

The executives were actively involved in the Initiation and Benefit Realization phases; however,
during the middle four phases they were invisible and took very little interest in the project. The
project managers were brought on board at the beginning of the Preliminary Planning Phase;
their job was considered to be completed at the end of the Closure Phase, but when the
executives got actively involved in the project during the Benefit Realization Phase, they were
quite unhappy when the expected benefits and accompanying business value did not meet their
expectations as outlined during the Initiation Phase.

A Root Cause Analysis study was conducted to determine the issues creating the problems.
Almost all of the problems emanated from the assumptions:
• All of the assumptions were made by the executives during the Initiation Phase.
• Not all of the assumptions were fully documented.
• Many of the assumptions were business-related rather than project-specific and impacted
the execution of the project.
• The assumptions were neither prioritized nor explained in writing by the executives.
• The project managers were brought on board the project at the beginning of the
Preliminary Planning Phase and had limited access to the assumptions.
• Most of the project managers were engineers with limited business knowledge.
• The project managers were not allowed to challenge any of the assumptions.
• Some of the assumptions were strategic based upon privileged information held by the
executives and not shared with the project managers.
• During the execution of the project, several of the assumptions had changed.
• Several new assumptions should have been made but were not.
• The project managers had limited knowledge about the assumptions and therefore did not
track whether or not they were still valid.

It was clear what was happening; executives were establishing the assumptions, but the project
was not tracking whether the assumptions were still valid during the execution. The project
managers had expected that the project sponsors (i.e. executives) who established the
assumptions would perform the tracking. The executives had very limited involvement in the
project once preliminary planning began. When the assumptions changed or were no longer valid
during execution, the project manager was not aware of the changes and kept on with the project
until completion. The result was the completion of projects that should have been cancelled
earlier in the project life cycle. Resources were then squandered by allowing the project to
continue because of a poor recognition that the assumptions had changed.

Recommended for YouWebcast: The Art of Building Partnerships

The above story forced me to change some of the ways I teach project management to MBA and
XMBA students. I now have a separate module devoted to the validation of assumptions. In this
module, the class is given a business case and statement of work. They are then broken down
into teams, and each team is given two weeks to prepare a sealed bid for the project, similar to a
competitive bidding environment. Two weeks later, the bids are opened and each team must
stand up in front of the class and defend their assumptions. If the assumptions are correct, then
the financial numbers are probably correct. But if the assumptions are wrong, then it probably
does not matter what the financial numbers are. Each team must convince the class that their
assumptions are correct.

Managing assumptions has many steps. Defending them is just the first. The second, and perhaps
the most important, is that the assumptions must be tracked. When doing so correctly, there are
four possible outcomes:

• The assumption will remain as stated


• The assumption must be updated
• The assumption must be replaced with another assumption
• The assumption must be deleted and not replaced
It is possible for executives to see the tracking of the assumptions with an image on an executive
dashboard. This is shown in the exhibit below.[1]

In this exhibit, it is assumed that only the critical assumptions are being tracked. At the end of
January, there were 10 assumptions, one of which was either new or revised. By looking at the
legend in the exhibit, we can see that the assumption was revised. In February, we had 10
assumptions. From the legend, one assumption was new and another assumption was revised.

It is entirely possible that in the future we will see seminars or courses in Assumptions
Management, but until then, project managers must recognize the importance of the assumptions
made and that they must be carefully tracked.

[1] Adapted from Harold Kerzner, Project Management Metrics, KPIs and Dashboards, John
Wiley and IIL co-publishers, 2013, P.230.

You might also like