All Posts in Office Politics

|In: Leadership|Last Updated:

Management and leadership are, as has been mentioned once or twice, different. Precisely how they differ is a matter of some controversy, and quite a lot of ink has been spilled arguing what exactly distinguishes the two.

There has been somewhat less discussion of which is the more important, possibly because the answer is so obvious.

It is obvious, isn’t it? Just listen to the two words. Leadership sounds downright inspirational, forward-looking, and important. Management, in contrast, conveys overtones of control, drudgery, and hard, tedious work.

Hmmm. Maybe it isn’t so obvious after all. If we use the Edison Ratio as our metric (1% inspiration : 99% perspiration), perhaps management is the more important of the two. After all, inspiring the troops to battle on for glory and mother country doesn’t do much good if you haven’t first taken the elementary precautions of arming, training, and briefing them.

From a personal perspective the distinction matters only in how you decide to allocate your time. To be effective, you have to be proficient at both — to inspire people to follow your lead, and to make sure they do the job well and deliver results. It’s a reality as true for a chief executive officer as for a first-time supervisor.

Organizationally, the sequence is more clear: Manage first, then lead.

Which is to say, before anyone will take IT seriously as an equal partner, fully engaged in the development of business strategies and tactics, it first has to deliver stable, high-performance systems and networks; it has to complete projects on-time, within the planned budget, and with the original list of deliverables intact; and those deliverables have to help the business change and improve as intended.

Oh, and the Help Desk has to be helpful. Don’t ever underestimate the importance of the Help Desk. It’s impact on IT’s image would be hard to overstate. The Help Desk is the WD-40 of IT, lubricating its relationship with the rest of the business. It’s where the battle for business users’ hearts and minds is won, one resolved problem at a time.

Those stable networks don’t win anyone’s hearts and minds. They do, however, lose them. They’re critical to IT’s success, but only in the way showing up for work is critical to an employee’s career. It isn’t something you get credit for. It’s expected.

Which leaves projects as the battleground for IT’s credibility in the enterprise. IT project completion rates were poor during our industry’s Jurassic period, when file-oriented batch mainframe dinosaurs roamed the enterprise; they continued to be poor after the introduction of database management systems and on-line programming techniques moved us into our Cretaceous period; and they still hadn’t improved as additional waves of technology propelled us through geologic time to the Pleistocene era of object-oriented programming.

IT organizations have finally started to figure it out: Better project completion rates come from better project managers, not better technology. Project completion rates are trending up at last, and that’s a good thing. The only problem is, they’re trending up just in time to be not enough.

Project completion rates are about delivering software to the business that adheres to specifications. Which was enough when IT figured its proper role was to be a supplier and the enterprise was its customer.

The world has changed again, though, and as an industry we’ve caught up just enough to be a step behind the times. Because while we’re finally completing IT projects, the business is figuring out that there is no such thing as an IT project.

We need to take the next step and take it quickly: We and our partners in the business need to stop completing projects and start excelling at change.

Because in the end, taking control of business change is the only goal that matters.

Comments

|In: Leadership|Last Updated:

Pessimists, we’re told, look at a glass containing 50% air and 50% water and see it as half empty. Optimists, in contrast, see it as half full. Engineers, of course, understand the glass is twice as big as it needs to be.

Which explains a major source of friction in IT-related projects: Different umwelts.

Umwelt is a century-old concept introduced to ethology, the study of animal behavior, by Jakob von Uexkull. It’s the recognition that every animal exists in a unique perceptual universe that’s closed to human beings other than through inference: Much of a bee’s world is ultraviolet; a dog’s nose does a lot of what we use our eyes to accomplish. Then there are the electric fish I used to study, which perceive their world through a sense we lack entirely.

Oversimplifying just a bit, IT project teams consist of (at least) one professional optimist, one certified pessimist, and a collection of engineering types. They have to collectively commit to a plan and stick to it, but their umwelts differ.

The optimist is the business sponsor. Corporate executives are supposed to be optimists — they’re supposed to see possibilities as certainties … as real, and motivate everyone around them to envision them as real, too.

It’s hard to be chronically optimistic if your mental habit is exploring the complexities that make even seemingly simple projects difficult. This is one reason it’s very hard for many business executives to understand why IT projects cost so much. “It’s a simple process!” you’re likely to hear a business executive complain. “Why do you IT people have to make it so expletive complicated?”

Engineers — the core staff of your average project — are, for the most part, realists. They understand that the “simple process” really consists of the simple process itself, which takes care of maybe 80% of the situations the project is supposed to address; the most common exception to the process, which takes care of 80% of the rest; and another 327 exceptions, some of which the business really needs to deal with, and the rest of which nobody has had the time to combine with any of the other exceptions to simplify things.

The project manager is, of course, the pessimist. Project managers have to be pessimists, because there’s a short phrase that describes optimistic project managers perfectly: “Chronically over budget.”

Project managers have to be pessimists, because they’re the ones who are held accountable when unanticipated problems, like a key developer being hired away by a competitor, occur. These things happen in every project, of course, so good project managers anticipate them.

Project managers have to be even more pessimistic, because in addition to being held accountable for these anticipated unanticipated problems, they’re also the ones held accountable when harder-to-predict unanticipated problems arise, such as a serious bug in the development toolkit. So the best project managers make allowances for unanticipated unanticipated problems in their plans, too.

Project managers and business sponsors are supposed to meet weekly to review progress and discuss issues that arise as the project progresses. Many of these meetings are entirely dysfunctional. The project manager, who is working from a perfectly reasonable plan, collides with the business sponsor’s entirely predictable expectations. It’s an umwelt thing. The solution is to get the umwelts to converge, which is a matter of creating a corporate culture conducive to good project management.

Project managers can’t succeed unless they work in a project-management-friendly corporate culture. But project managers have projects to manage — they’re too busy to have to influence the corporate culture. That’s where you, as the head of IT, have a role to play. It’s your job. That’s why they pay you the big bucks.

There are three major elements that must be present in a project-management-friendly culture:

  • Appreciation that the overhead added to projects by use of good project management disciplines is worth the effort
  • Understanding of the complexities of software development
  • Recognition by both project managers and business sponsors of each other’s umwelt. Which is to say, they don’t need to understand each other instinctively, but do need to understand that a different umwelt isn’t wrong. It’s just different.

Project managers need strong business sponsors just as much as business sponsors need strong project managers. It’s up to you to make sure the enterprise has an ample supply of both.

Comments