All Posts in Leadership

|In: Leadership|Last Updated:

I’m told Proctor and Gamble does an amazing job of measuring its innovation assets. Its chart of accounts, for example, can track the cost and revenue of every fragrance the company develops. Oddly, though, there’s no equivalent way to track the profitability of flavors.

That’s right, there’s no accounting for tastes.

Speaking of partial solutions, last week’s column advised that alignment of goals is more powerful and reliable than specification of responsibilities. Decades of experience on both sides of delegation affirm the value of this perspective.

But it’s incomplete. Decades of experience also tell me that you can’t manage a project unless everyone on the project team knows what tasks they should be working on each and every week, when each task should finish, and what “finished” means. And that the project manager has to verify, each and every week, that the tasks that should have completed did, in fact, finish. Sounds like specification of responsibilities.

So what’s the deal? Is project management so different from other leadership situations that the same rules don’t apply?

The answer is the difference between leadership and management. In leadership situations, goals are broadly stated and success can come in many forms. They’re organic. Project situations are, in many respects, more similar to processes, where schedules interlock, specifications are the goal, and deliverables have to mesh. They’re mechanistic. And as Admiral Grace Hopper put it, you lead people, but have to manage processes.

If you’re the CEO of a large corporation, you might establish strategic goals for the business such as increasing sales by 10%, achieving a more uniform public perception of the company’s brands, improving margins by 2%, and building the organizational capability to release ten new and successful products to the marketplace every year. The Senior VP of Sales recognizes a personal accountability to: Increase sales by 10%; do so without violating brand image; train the sales force in how to sell new products, and structure commissions so as to avoid cutting into margins.

As CEO you’ve established common goals, and the responsibilities of Sales Management, Supply Chain, Manufacturing and so on in achieving them. If you have to establish week-by-week plans for each area and personally oversee them, you’ve hired the wrong executives. If they can’t work independently when appropriate while working together whenever necessary, you’ve still hired the wrong executives.

Now imagine you’re managing a software integration project. You can’t simply establish four broad project goals, align the project team members to them, and expect anything useful to happen. Each team member depends on the others to deliver work products that fit together according to a precise design, and to deliver them when they’re needed.

This doesn’t invalidate the principle of aligning project team members to goals — it means you have to apply it differently.

If project managers were exempt from the principle of delegating goals and aligning everyone to them, they would define all tasks and the overall schedule themselves — a terrific way to give every project team member a perfect excuse for missing deadlines.

With goals in alignment, the team members responsible for each assignment develop the work plans for their achievement — work breakdown structures and timelines they can commit to. As project manager you assemble them, connect the interdependencies, and fine-tune the schedule with the whole team so everyone agrees the entire project is feasible.

Alignment to a common goal is also a big part of making sure work products fit together instead of simply meeting the letter of the specifications. Since it’s a team, its members compare notes instead of working in vacuums. When managing a project, establishing a common goal and aligning everyone to it is what makes the project team a team instead of a committee.

But even with goals in perfect alignment, project managers have to review everyone’s progress every week. With the best of intentions and the hardest and smartest work, risks do turn into reality, the unexpected turns into the inevitable, and, sadly, some project team members turn out to be unreliable.

That’s a fact, and when facts and great ideas collide, the great ideas don’t stand a chance. The tight coupling of activities within a project means projects have to be managed as well as led.

In a way, that’s too bad. Because while leadership requires more courage than management, management is harder work.

Comments

|In: Leadership|Last Updated:

You can’t make this stuff up. Ray Todd Stevens tells us:

I am working on a recovery project for a company that outsourced the coding for a major application on which the company depends. They did this to an offshore company. Someone at some point realized that the code had no comments, and so insisted on the code being commented. So comments appeared and nobody apparently looked at them other than to ensure that they are there. The project was accepted and the offshore vendor was paid.

Now we are dealing with some bugs, and have found that yes there are comments. The ones that are in English refer to process and procedure documents that were apparently internal to the vendor. My client certainly does not have them. The rest of the comments are not in English. The variables are named after Indian Gods. So far the comments that we have determined the language for are in eight different languages. Most of these refer to things that we can’t even figure out, and don’t appear to relate to the code they are tied to.

The external documentation is about as bad although it is in English.

I guess you get what you pay for.

If you’re looking for anecdotal ammunition to argue against offshore outsourcing, look no further. But that would be wrong. Once more, with feeling: Anecdotes illustrate points, they don’t prove them. The question is, what point does this anecdote illustrate? Surely not that all offshore outsourcers provide comments only under duress, and then in inaccessible languages. An anecdote this tasty has to illustrate something more profound than that.

For example, this: Alignment of goals is more powerful and reliable than specification of responsibilities.

This point plays itself out in all sorts of situations. When you delegate tasks instead of goals, for example, you have to inspect the results with far greater care, because the assignee’s work is finished when it meets the written specifications. Whether it does anything useful is Someone Else’s Problem — not the case when you delegate the goal.

When you contract with a vendor, relying on specifications almost guarantees you’ll pay more for less. Never mind offshore IT services. It’s just as true when dealing with ad agencies: Plenty develop campaigns designed to win them awards and new clients and not to make your cash register go ka-ching.

It’s the same when you don’t rely on a vendor. If you want to make sure IT delivers software that does nothing useful for the business, define your Systems Development Lifecycle so that business analysts work with business departments to determine their requirements and create written specifications that programmers use to design and build applications. If you’d prefer to accomplish something, have business analysts facilitate conversations between business departments and developers, using written specifications to remind everyone of what they decided in the face-to-face conversation. The former is reliance on specifications; the latter gives everyone the opportunity to align their goals.

Then there’s the ever-popular dress code — the subject that wouldn’t die. Companies that try to define and enforce proper dress mostly achieve resentment and a cadre of jailhouse lawyers adept at malicious obedience — at adhering to the letter, but not the spirit of the code. Companies that encourage employees to use their good judgment, dressing professionally and appropriately for their work seem to get better results.

Alignment of goals is more powerful and reliable than specification of responsibilities for a reason well-known to computer scientists: When in doubt, add more processors. When you rely on specifications you rely solely on your own brain to figure things out. When you rely on alignment of goals, you get to take advantage of everyone’s brainpower. More processors.

Which leaves just one small challenge to be addressed: How, exactly, do you align everyone’s goals?

The short answer is, that’s what leadership is about. A slightly longer answer is that it isn’t all that hard, because most people, most of the time, prefer things that way — they want to belong to a group that has a purpose they can buy into and contribute to. For some reason, likely related to a personal need for control, many managers give every appearance of working very hard to prevent this very common and natural human tendency from operating.

There are few situations in IT, or anywhere else in a modern business, where specifications are enough. Usually, good judgment matters. The only way employees can apply good judgment is if their goals and yours line up.

Making that happen is up to you, not them.

Comments