Managing Project “Weather” with Constant, Credible, and Visible Monitoring of Project Teamwork
Part 1: A Legacy of Failure: The Dramatic, Traumatic, and Enduring Disappointments of IT Software Projects
PROJECT FAILURE, most especially in the realm of enterprise applications, has been more the rule than the exception for more than a quarter century. And with continually advancing technologies, combined with increased software complexity and what appears to be a dwindling sense of client responsibility across the spectrum of IT service providers, the situation is not improving, it is degrading.
I am an enterprise applications consultant with background in both implementation and post-implementation strategies. Over the past fifteen years, I have participated in dozens of research projects regarding the best practices for project success. I have counseled both clients and systems integrators. I am a veteran of dozens of mid and large-scale projects and yet, based upon my books and my experience, I find I have been called upon to be an expert witness in enterprise application project litigation for the seventh time in twelve years.
Clients engaging service providers and then ignoring them throughout the project. “Leaving it to the experts.” Service providers spend as much time selling more services to a client than delivering the already-contracted services. Clients fail to provide the project resource they have promised. Service providers deliver minimal knowledge transfer. Projects go from the penthouse to the poorhouses to the courthouse. How did we get to this point?
Estimates of the costs of failed projects vary wildly in accordance with various definitions of failure but even the low-end estimates are not close to acceptable. The very lowest estimates fall into the $300B-$500B lost range for the U.S. alone and the highest is pegged at a global $3 trillion.
The blame for project failure gets pretty evenly spread between client and their service providers. Software vendors are largely off the hook as software failures are not seen as fatal to projects and are too rare to make the blame board.
A partial list of clients sins in this regard:
1. Failure to provide sufficient management commitment. Commitment word that one can find in a statement of word is far too often forgotten once the service providers have arrived to start the project.
2. A failure of senior management to become educated to their expected role in a project. When senior management “leaves it to the experts”, the client populous loses confidence very quickly.
3. Under-budgeting, which is usually the effect of short-term thinking in which cutting corners on project work (especially around organizational change management and training) results in a predictable failure of the project to yield any measurable business benefit.
4. Failure to assign quality staff to the project team and instead taking “whoever is available” because of an unwillingness to back-fill key positions for the duration of the project.
5. Presuming that the core activity of the project is information technology and, by consequence, failing to properly assign project responsibilities to business leaders.
A partial list of service provider sins in this regard:
1. A lack of agility characterized by an over-reliance upon project methodology at the cost of listening to the client.
2. On the flip side, a failure to follow base disciplines included in the chosen methodology and instead to “go cowboy” in improvising activities from week to week.
3. A failure to provide anticipated knowledge transfer to client management, project team members, and/or end users, thus leaving the client unable to maintain its software after go-live.
4. Unwarranted attention to “selling on” via scope growth, additional services, or additional resource.
And while I have thus far mentioned that “software vendors are largely off the hook”, this observation applies to litigation but not to brand damages. One prominent example is SAP, the largest provider of enterprise software in the world. Both business and IT news outlets are regularly littered with headlines about failed projects that include “SAP” in them when, in fact, those project failures proved to be the responsibility of an SAP implementation partner such as IBM, Deloitte, Accenture, et al. and not SAP itself which merely licensed the software.
A partial list of project sins co-committed by both the client and the service provider:
1. While project team members are aware of project over-runs for time & budget, there is a collective silence as they delude themselves into believing that they will somehow catch up.
2. As relations between service providers and clients begin to fray, rifts are not reported to relevant executive committees or quality assurance groups until they have reached a crisis stage.
3. Usually, via pressure from the client to keep project costs down, the Statement of Work and consequent project plans will describe a project that is accelerated in an exaggerated fashion that results in enormous risk and a project that, in all reality, commences both late and over budget.
In instances 1 and 2 above we find a serious lack of project visibility which is why, in all of the litigation I have observed or participated in, we find that project sponsors, stakeholders, and senior management from both sides of the aisle are taken by surprise by a situation that is already past remediation.
One might think that with all the improvements we have seen over the years in regard to project methodology and project management that failure would be decreasing instead of increasing at a gallop. But in the IT industry, it is nearly impossible to find anyone who doesn’t have a multiplicity of horror stories to recount from a diversity of lived-through project failure.
To paraphrase Thomas Edison, “We have not failed, we have just found 10,000 ways that won’t work.” And these 10,000 ways seem to have been boiled down into the project methodologies and the classical project management techniques that we have followed over the years. Hundreds of books have been published on the subjects of project leadership, project management, project disciplines and methods and tips, not to mention the thousands of blog posts, white papers, and the like that litter the Internet like oceans of spam.
And still the projects fail. And still project managers pound their heads into their desks. And still a senior vice president wants updated project status but really means “how late are we and how far over budget?”. And with each failure we dig deeper into these methodologies, these tips, these blog posts. Without relief.
While there are myriad variations on the “weekly status report”, they are still distressingly alike and uniformly uninformative. For example, those that deploy red, yellow, and green lights as a shorthand way of reporting upon the status of various project aspects tend to short-change readers by being a) unsophisticated and simplistic and b) without sufficient mention of “cause” or, even better, “mitigation plan”.
Increasingly “weekly status reports” are generated on PowerPoint and deploy bullet-points rather than full sentences and, worse, do not include content that can serve as a foundation for project improvement. Here are the common subject headings included in these reports:
• Adherence to time
• Adherence to cost
• Updated project plan
• Scope discussions
• Technical issues
• Resource planning
What I and other veterans of such projects have long observed is that there usually comes a time when members of the service provider team meet up for dinner or drinks and find themselves collectively complaining about the client team. They are not adhering to the project methodology or they have not provided the resource they promised in the contract. Maybe the client management isn’t showing the commitment that was expected. Maybe project scope is not being respected.
Quite often these complaints lead to bitterness. And what these disgruntled service providers may not know is that in another restaurant or bar just down the street members of the client team have gathered to complain about them. The service provider is not giving enough knowledge transfer or they are not providing effective organizational change management. Maybe the service provider is not being flexible when it comes to project planning.
On occasion, the two project managers will meet in an attempt to smooth things over but in the majority of cases, such attempts are fleeting and inevitably unsuccessful. In such instances, the project weather goes from rainy to a hurricane. Worse, that hurricane is not readily visible or reported upward to the people who are paying for the project (CEO, CIO, et al) or to service provider senior management who want a contented client and crave an excellent client reference and the promise of add-on or repeat business.
Given these obvious failures over the years, I have frequently surveyed the marketplace in an effort to get to the bottom of project failure. Among the elements I have succeeding in isolating are the project performance attributes that each side (client and service provider) expect of each other. I have also served as an expert witness in seven ERP project litigations (sometimes on behalf of clients suing their service providers and other times on behalf of service providers being sued by their clients). This experience, buttressed from the reading of thousands of pages of depositions from all project roles, has helped me to confirm the survey findings. Collaboration, good will, active listening, a group spirit, teamwork are nearly non-existent. And the whole time both the client and the service provider were staring at the project plan, the budget, the issues list, the weekly status report…all while studiously avoiding each other.
Project methodologies, which first came to the fore in the mid 1970’s, are intended to apply disciplines, standards, a clarity of roles, insight into process, and, at the center, a systematic plan that will encourage collaboration but which relies upon active teamwork to succeed…
…thus leading us back to that original quote- “Everyone Complains About the Weather but Nobody Does Anything About It“ which, until now, has not been credited, as it should be to Charles Dudley Warner, a friend of Mark Twain’s (and so of course Mark Twain gets the writing credit. Twain could, in absentia, apply the Yogi Berra quote “I didn’t say everything I said.”)
The bottom line is that projects fail largely because too little attention is paid to project weather (i.e. teamwork) while perpetuating and protecting a low level of stakeholder visibility.
“If the Service provider and the client aren’t working as a team, cancel the project and save yourself a ton of time, money and angst“
So, knowing what we know through the aforementioned research and experience, let’s tweak Twain a twinge and say “Everyone complains about project teamwork but no one ever found a way to measure it.”
Stay Tuned for Part 2: Penthouse, Poorhouse, or Courthouse: Where Will Your Project Take You?
If you are attending SAPPHIRE/ASUG this year in Orlando, come see my presentation of the same name:
A5189 Penthouse, Poorhouse, or Courthouse: Where Will Your Project Take You?
Tues: May 17 11:0 AM – 12:00 PM ASUG HUB (Show Floor) – Education Theater Orlando Convention Center