Not too long ago, it seemed that you couldn't read two articles on project management without one of them citing the purported failure rate of projects. Was it 50 percent? 80?! Some sort of "objective criteria" defined the failures in these studies — a certain number of days past deadline or a percentage over budget, for example.
You don't see those doomsday leads as often these days, and their validity was always a matter of debate. Definitions of success or failure aren't so neatly tied to simple metrics that don't take into account the many ways an initiative can deliver value. Of course, that's where self-appointed experts, consultants and vendors make a good living, offering their solution to your project management problem.
But forget failure rates and packaged solutions for a minute. You know, the world's best baseball players walk back to the dugout having failed almost 70 percent of the time. And they don't throw away their equipment or change their technique each time. They've accepted the reality of their enterprise: small, spinning objects traveling more than 90 miles per hour are very difficult to hit.
To continue the analogy, project teams get thrown a lot of curves, from before the project even starts (unrealistic estimates) through the heat of battle (missing-in-action sponsors, conflicting directives, competing resources) to an often-hazy closeout (if they get there). Under these conditions, homeruns are hard to come by. A few bad-hop singles might even be deserving of celebration — and certainly not evidence of complete failure.
My point, of course, is not to say that late or over-budget projects should be accepted as inevitable by organizations. But it is more constructive to re-focus the failure conversation. No methodology or technology solution can wish project success into reality — unless it begins with people.
I've never interviewed a process. However, I have chatted with thousands of project leaders and team members over the years. And many of them confirm that their organizations are striking out on a consistent basis.
But the root cause of these failures does not necessarily map out directly to the particular method or tools their organizations employ. No, the problem is more often the dangerous disconnect between the organization's strategic goals and how those goals are — or aren't — translated into action.
The project teams know it and hate it, but they don't feel like they can do much about it. The customers sense it, and they're ready to do something about it, sooner or later. The senior managers know it, and they're doing everything they can to deflect it. And what of the top-level executives — the leadership? Well, too often, they're still waiting to be told about it, so they can hire an outside consultant, who may or may not get around to talking to the project team, to fix it.
If that sounds like sour grapes, or cynicism from the trenches, so be it. Perception becomes reality. And the truth bears repeating, again and again, until someone at the top hears it and believes it:
Processes don't perform projects; people do. Until people drive the processes, and not the other way around, there will continue to be unrest in the trenches — along with "experts" who make a good living citing the project failure rate, whatever it is.
Though it is a well-worn cliché, many technologists probably are less people savvy, while great communicators must rub the glaze from their eyes at the site of code. And business vision may be better left to the MBAs in the executive suite.
It's unrealistic to expect any one person to excel in all three areas. But ... a successful project must. And that won't happen by osmosis or timecards.
Strategy without the tactics to execute it is nothing more than hot air. Tactics without a strategy to give them purpose is just busy work.
No matter what the project, the business goals and the processes must be on a first-name business, or the results are destined to be a stranger to the original vision.
But is it up to the project manager and team to connect the strategic dots with tactics? If team members are providing the relevant technical expertise, and their leader is staying on top of the project management processes — status reports, budget and schedule, risk assessment — haven't they "covered" their responsibilities? According to the typical job descriptions, yes. But according to the reality of projects, there must be another obligation — or success is unlikely.
The unwritten obligation of all team members is to see beyond their individual pieces of the project puzzle, to understand the importance of their roles in the larger scheme, to care about the results off in the fuzzy distance. That, after all, is what gives work — any work — meaning.
And the obligation to care is not unrealistic to expect. In fact, it is more often the desire of skilled people, whether or not they are adept at communicating it. Perhaps that is why employees universally resist timecards. And why wouldn't they? Who wants to have his or her role reduced, in large part, to the monitoring of a clock? Doesn't that, in essence, reduce their contribution to just another quantitative metric instead of qualitative value?
Of course, timecards are important to understanding resource allocation. And performance, hopefully, is judged by many other measures, tangible and intangible. The point is, organizations won't get well-run, customer-focused, value-driven projects if those initiatives fail to address both the technical and business objectives.
So if project managers and team members are expected to deliver the tactical execution in the name of the strategic vision, then they also should be included, supported and rewarded in pursuit of that all-important connection. Are you?