All Posts in Leadership

|In: Career Management|Last Updated:

I’m mad at Bob Metcalfe.

But first … IS Survivalist Roger Crawford points out one of Microsoft’s business practices that’s even more unfair than its antitrust shenanigans, namely, how it describes new products or product plans: “We are developing product X that does functions a, b and c and we expect these types of people to use it.”

Its competitors, who say things like, “We intend to leverage our strengths in the buzzword arena to provide our customers with the tools they need,” are handicapped, because it’s never quite clear what they’re planning to produce, nor for whom.

For fairness’s sake, the courts should prohibit Microsoft from clearly explaining its plans ever again. Based on what I’ve read so far about Microsoft.NET, it appears the Redmond contingent is already complying, because just what the heck are they mumbling about, anyway?

As soon as I read about Microsoft.NET, I thought, “This is Microsoft’s SAA!” I figured I’d write about it eventually. Metcalfe had the same insight, though, so there goes my claim to originality. Nuts.

If you don’t remember SAA, it stands for “Systems Application Architecture”. IBM, in the early days of its implosion, developed it to do for applications what its Systems Network Architecture (SNA) had done for networking: Provide a standard architecture IBM could control. SAA wasn’t a product. It was a framework within which IBM’s future products would, in theory, fit.

IBM’s core strategy was to control architecture. Even when companies bought non-IBM components, everything fit the IBM model for functional elements, specifications, and interfaces. The strategy worked because you could buy every component from IBM if you wanted to. SAA failed because the only thing IBM had was intentions.

Sound familiar?

Microsoft.NET is a non-starter. Ignore it. If, miraculously, it succeeds, you’ll pay little penalty for waiting. You have absolutely no reason to be an early adopter (and of what? There’s no product!), and lots of reasons to wait and see what happens.

But this column isn’t about Microsoft, nor IBM, nor, for that matter, about Metcalfe’s beating me to the punch. It’s about you and your IT organization.

Take a look at your mission statement, vision statement, strategic intent, program charter, or whatever defines what you’re trying to accomplish these days. While you’re at it, read some of your recent communications. Does it all look like Microsoft.NET, or does it mean something?

Meaningless visions like Microsoft.NET are punishments for the sins of our forefathers. American industry, paralyzed by a generation of bottom-line managers who couldn’t see past financial statements, awoke one day to the need for vision. Ever since, every self-styled leader in business has made sure to start at least one sentence per day by saying, “My vision for this is …”

Don’t do that. Let others decide whether you’re a visionary or not. Your job is to paint a compelling vision for the future. While it’s tempting to be an artist, painting blurry abstract swirls others can interpret as they choose, abstract artistry isn’t leadership. It isn’t vision. It’s Microsoft.NET.

Grand visions are wonderful things. But if nobody can figure out that you’re developing product X, with functions a, b and c, you aren’t a visionary.

You’re just daydreaming.

Comments

|In: Leadership|Last Updated:

The Standish Group, in its annual Chaos Study of project completion rates, has been quoting from Tom Clancy’s The Sum of All Fears: “The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labor to perform the same task.”

At the risk of quibbling with Mr. Clancy, some of those Roman bridges are still standing a millennium later, while some of our more efficient ones have tumbled into the bay [Corrected from “a half millennium later – Bob]. Adherence to budgets and schedules is our preeminent ethic. One suspects Rome held different values.

But I come, not to praise Caesar, but to bury him: An IT department’s credibility depends on its ability to get projects done. And if we believe the Standish Group, getting them done is the exception, since about half finish late and over budget and nearly a third are put out of their misery altogether.

If you’ve read anything about this subject, you’ll find an unfortunate focus on process and methodology. Supposedly, the key to success is following the right steps in the right order, whether you’re building bridges or writing software.

The experts, I’m afraid, are wrong. Or, rather, they’re insufficiently right: Following good project management practices — the right steps in the right order — is a darned good idea. It’s insufficient, though: effective project management isn’t a cookbook exercise. You can’t just follow the recipe and be sure the cookies will come out tasty.

The most important factor in project success isn’t having a repeatable process or sophisticated methodology, nor is it, for that matter, the project management software. It’s having a strong, experienced project manager to lead the project. Seem obvious? Of course.

So why do so many companies actively prevent project success by ensuring they have no experienced project managers? The career ladder is the problem: Project management is used as a bridge position – not in the Roman sense of solidity and durability, but in the American sense of being something to cross as quickly as possible.

Project management is the bridge between staff and management.

It’s a test to see whether you deserve a department of your own. Do well and you’re promoted out of project management. Faced with the additional salary and prestige of a management position, how many good project managers will say, “No thanks. I want to keep managing projects, because I like working longer hours for less money and respect.”?

Here’s a novel thought: Create a project management career path. The entry point is apprenticing with an experienced project manager, the progression moves from managing small projects through large programs, and the end-point is leading your company’s program management office (PMO). Managers of small projects should be parallel in compensation and prestige to workgroup supervisors; the head of the PMO should have as much influence and prestige as the CTO.

Want your technology projects to succeed? Stop worrying about employing project management methodologies and start worrying about employing strong project managers.

They’ll take care of the methodologies.

Comments