Managing Project “Weather” with Constant, Credible, and Visible Monitoring of Project Teamwork
Part 2: Penthouse, Poorhouse, or Courthouse: Where Will Your Project Take You?
ALL PROJECTS are prone to bad weather: the mists of poor scope, the winds of deadline pressures, the thunder of executive oversight, and the rains of team disharmony. And while traditional project management methods go a long way towards mitigating these conditions, the terrible record of rampant project failure described in part 1 of this series still remains.
In part 1 of this three-part article: A Legacy of Failure: The Dramatic, Traumatic, and Enduring Disappointments of IT Software Projects, I described the depths, the costs, and the causes of chronic project failure, but it must be recognized that there are degrees of failure and we cannot hold all projects to a single standard. However, we can address the most neglected aspects of all projects: a lack of teamwork between service providers and their clients.
The proper formation and management of efficient and (here’s the rub) harmonious project teams, comprised of both client and service provider members, will have a greater influence on project success or failure than the relative talent level of the project team members.
And while project success can be variously defined (from the low-brow “on-time, on-budget” to the sublime “business benefit measured at the KPI level”) a collaborative project progression that is visible to outside stakeholders is generally found to be the source of that success because collaboration and openness provide the most effective protection from bad project “weather”.
Here are just some of the conditions that arise:
Methodology Heat Wave: Slavish devotion to a methodology can be worse than no methodology at all. If the service provider lacks the agility to respond to changing project conditions by sticking too closely to method, the project will suffer.
Methodology Ice Storm: Conversely, if the service provider and the client fail to follow the methodology, they will get lost in the tall grass very quickly.
Client: “Consultant’s ‘cookie cutter’ approach led to a lack of business benefits”
Service Provider: “Client staff didn’t follow project method. Every day was like starting over.”
Foggy Knowledge Transfer: Does the service provider deliver it? Does the client come to receive it? I have witnessed variations of this scenario:
Client: “We didn’t get sufficient knowledge transfer!”
Service Provider: “Your people never showed up for the scheduled sessions.”
Client: “We’re not getting sufficient knowledge transfer!”
Service Provider: “If we take the time to show you how to do it, we’ll be late and over budget.”
Wind in Our Face and not at our Backs (Lack of Client Management Commitment): Client’s senior management sees the project as IT-centric and fails to follow or adequately support its progress.
Service Provider: “We need you to talk up the project to your employees and let them know how you support them in their efforts.”
Client: “We’re $15 million dollars committed.”
These are but four “weather” conditions that are not covered in weekly status reports or even the monthly executive steering committee meetings. Instead they are ongoing sub-rosa arguments that chafe at team harmony and, untreated, undermine success.
Here is a brief tour of the three basic project outcomes in which project weather is mostly sunny, cloudy and rainy, or full-blown hurricane:
In “Penthouse” projects, client and service provider senior management have clear visibility of project progress, maintain awareness of inter-team issues, and are able to exert executive influence to assure that project team members are aware of their commitment.
At the same time, both client and service provider project members are constantly aware of their required roles and what project behaviors are expected of them. Such awareness leads to collaboration and a joint adherence to project methodology.
“Penthouse” projects also tend to have measurable goals, a high level of client ownership, and a project plan that is heavily invested in organizational change management and post-implementation planning (the latter of which does not appear in any of the leading systems integrator project methodologies and is thus driven by clients rather than their service providers).
“Poorhouse” projects are sad affairs that test the patience and good will of all team members while creating havoc with career paths both among client and service provider project staff as well as client stakeholders.
Such projects usually begin with sloppy plans that are 50% expertise-based and 50% optimism as clients have the distinct tendency to under-budget and service providers have a matching tendency to knuckle under rather than lose a potential client. Thus, by the end of the first few project weeks, it is already over budget and late and will remain so to the very, often bitter, end.
In such projects, scope is elastic and elusive and a constant source of friction between clients and service providers. There are myriad meetings to re-set planning, clarify scope, re-align project responsibilities, and, in many cases, to craft a “project recovery plan”. In such an environment, especially when the “project recovery plan, version 7.4” is issued, client and service provider collaboration is sorely tested and the nervous systems of project members are frayed.
“Poorhouse” projects do not always totally fail to the point of abandonment. The majority are completed, even if completion results in client disappointment over project benefits that were not realized and/or a time lag and price tag far in excess of original plans, not to mention the erosion of client morale.
What moves a project from the “Poorhouse” category to the “Courthouse” is a critical lack of project visibility for both client and service provider senior management.
George Bernard Shaw sums it up thusly:
“The single biggest problem in communication is the illusion that it has taken place.”
When a project is going badly, all project members, individually and collectively are highly aware of what is amiss. In many cases, project managers harbor dim hopes that, as the project deadline nears, things will fall into place, conflicts will be resolved, and the sun, just this once, will rise in the west.
One of the saddest aspects of the work of an expert witness for a failed IT software project is reading tales of woe in various depositions and realizing how so much heartache and wasted money could have been avoided if only people had spoken up about the reasons for the rift between the client team and the service provider team.
The short answer as to why this does not take place:
1. Project members, both from the client side and the service provider side are given wrong or incomplete criteria to report.
2. Project participants who are not part of project management have no channel available to communicate project problems.
3. Project management tends to defensively deflect the dissemination of troubling project news. This is often accompanied by the illusion that somehow they will make up for (check any that apply):
the project is running late
the project is running over budget
the software is over-customized
testing reveals seven million three hundred thousand errors
user acceptance testing = users are throwing tomatoes
the one person who understands the blueprint just quit
the client team hates the service provider team
the service provider team hates the client team
the project manager has another job offer and is thinking of jumping to it
Outside of that error count and, yeah, the tomatoes, every one of these situations has come up multiple times in my project quality assurance exercises, project audits, and expert witness experiences and the key takeaway is that:
• In every instance, no one outside of the project team circle had any clear understanding that any such project impediments existed or were as serious as they proved to be
• In every instance, project stakeholders (CEO, CIO, CFO, SVP at the client; Consulting Director, Consulting Partner, Managing Partner at the service provider) state that “if I had known about that, we would have done something to fix it”.
Thus, a project that ends up in litigation cannot be solely blamed upon project team members. Project sponsors, steering committee members, and other more peripheral players must share in the blame. But to what degree are the latter to blame when no viable or credible project visibility was provided? Further, no matter how disciplined and refined a project status reporting process may be, we have long observed that the content of project status reports fails to accurately characterize true project status.
When reading legal depositions, we “experts” tend to find that seemingly minor issues, left untreated, bloomed into full-blown project crises months after they first appeared.
A number of conclusions can be drawn:
• The information provided to steering committees is limited to what the project managers want them to see.
• Executive oversight is seriously hampered by a lack of project visibility by project stakeholders, either through a lack of channel with project management or the Sargent Schulz alibi.
While we can’t do anything about the latter, we can provide a solution that will help you say goodbye to the heartache, the financial bruises, the bad nerves, and drama of abject project failure.
Stay Tuned for Part 3: Mastering your “Project Weather”: the ProQ Solution