Cap'n Arbyte's

Advertisements


Blogroll


Other sites

Involving Your Stakeholders

As a rule I've avoided writing much about Intel. But in this case I'll make an exception:

In order to address the problems that have cropped up, [Intel CEO Craig] Barrett said in his memo that Intel plans to change its approach to at product design by adding better checks and balances to help enforce better planning and project management.

Intel is "starting to put in place the indicators, reviews and management attention to start to turn these problems around by ensuring good planning, staffing and program management. This will not be a short-lived focus; we have plans to continue to review expectations and performance in the future," he wrote in the memo.

(Read the linked article for a few examples of things that haven't been going well at Intel lately.)

For the past few years employees have been hearing about a need for "operational excellence." There's always been a fair amount of snickering at that phrase, because no one (except perhaps senior management) is too sure what it means. My colleagues and I hear the message as "do your job, only, ya know, better. Somehow."

Real helpful advice, that is.

"Oh! Now I see! I was operating, but not excellently. So all I have to do to improve my performance is to… be excellent!" Bill and Ted would be proud.


I have two anecdotes to share. I can't be too specific about them, but I believe the contrast between them is illustrative of what operational excellence ought to be about, and the sort of concrete advice management should be giving us.

I'm involved in planning some processor debug technologies that have a several-year lead time. The amount of work is significant, and is currently being done by a cross-organizational team of three: one from design, one from presilicon validation, and one from postsilicon validation.

The other case is a group working on tools used by manufacturing and for some debug purposes. The group had reduced the importance of one aspect of the tool without the knowledge of their customers, to whom it was very important. This mismatch was ultimately discovered and was an unpleasant surprise to everyone involved.

What's the contrast? The level of involvement of the stakeholders.

In the first case, postsilicon validation is the primary customer, and is actively involved in architecting the tool. This matters; limitations that presilicon thought were no big deal have been overturned by postsilicon as an unacceptable burden. It had to be done at this stage — it couldn't have been changed later without great difficulty.

The second case is an example of poor communication with stakeholders. If plans had been clearly communicated at the beginning, the customers could have said "that's insufficient" right away, and that group's plans could have been changed at that time. Hopefully, with minimal impact on other groups. As it is, the plans of several groups may be affected until the newly-reemphasized aspect of the tool is delivered. The longer until a problem is discovered, the more costly it is to fix.

Lesson: talk to your stakeholders. Keep them informed of your plans, and especially to changes in your plans. Ask them how proposed changes will affect them. Even better, involve them directly in your planning. It is the individual responsibility of each group to check on the other to ensure requirements are clearly understood and being met. If the other group doesn't talk to you, shame on them — but if you don't reach out to them either, shame on you. It is not acceptable to assume "the other guy" will "do the right thing" without oversight. Trust but verify. If it's important to you, act like it.

Tiny Island