| Date: | September 5, 2007 / year-entry #330 |
| Tags: | non-computer |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070905-00/?p=25263 |
| Comments: | 36 |
| Summary: | Whenever there is a coordination problem, somebody says, "Hey, let's create a process." Now you have two coordination problems. I see this over and over, and paradoxically the people who create a process for managing a coordinating problem come off looking like proactive problem-solvers who get ahead of the problem. They're the go-getters, the people... |
Whenever there is a coordination problem, somebody says, "Hey, let's create a process." Now you have two coordination problems. I see this over and over, and paradoxically the people who create a process for managing a coordinating problem come off looking like proactive problem-solvers who get ahead of the problem. They're the go-getters, the people who look at each problem as an opportunity for continuous improvement. All that great management buzzword stuff. It doesn't matter whether or not the process actually works, because failure is an orphan, and besides, nobody follows up a year later to see whether your process actually improved things or whether it was abandoned six weeks after roll-out. You get the credit for proposing the process in the first place. Consider this problem at a hypothetical toy company: Some rumors have started that one of their toy cars is dangerous because of a wiring flaw that can result in excessive heat and possible fire. (It doesn't matter what the crisis is. I just made up something vaguely plausible.) Employees all over the company are getting email from their relatives asking about the toys, but the employees don't know what the story is either. Presumably, the safety department is investigating the problem and providing guidance to the PR and marketing departments so they can prepare a public response, and if there really is a problem, they're working with the product recall team to organize how the recall will be carried out, and they're working with the product engineering team to figure out what changes need to be made to the product to avoid the problem. In other words, the safety department is up to their ears in crisis. A employee from the dolls department, whose brother asked him about this toy car problem, can't find any information on the status of this issue and sends email to the "Employee Issues" alias, and a dozen people chime in with "Yes, please, we would like this information, I want to know what I can tell my brother and everybody else who is asking me about it. I might even post it on my blog so I can try to counteract some of the out-of-control rumors that are out there." A half hour later, somebody from the safety department responds, "Yes, we know about this, we're working on it. Please don't say anything publicly since we're still investigating." Somebody watching the saga unfold proposes a process by which employees can be kept up to date on the status of these types of emergent crises.
This is the wrong solution to the problem. The reason why this is the wrong solution is that it suffers from the classic "Create work for somebody else" problem. The people who benefit from this site are not the same people who would make the site useful. This doesn't give the people who make the site useful much incentive to do so. They're busy dealing with the emergency. They don't want to waste the time of one of their valuable investigators to do "internal PR". This scenario repeats itself on a less dramatic scale with various types of inter-group coordination problems. One group wants to be kept advised of the progress of another group for whatever reason. But if the second group doesn't need the first group for anything, they have no incentive to keep the first group informed. For example, suppose the first team provides an interface that the second team uses, and the first team decides that they need to redesign the interface for whatever reason. During the transition, the first team provides both interfaces so that the second team can transition from the old to the new, with the request that the second team let them know when they have finished transitioning to the new interface so they can remove support for the old one. Unless the first team keeps on top of things, the second team will probably forget to tell the first team when they have completed the transition, or they may even forget to transition to the new interface at all! After all, the old interface still works. In this case, the traditional way of making the second team care is to file a bug against them saying, "Stop using the old interface." That way, it shows up in their bug statistics as a reminder, and when they actually do the work, they can resolve the bug back to the first team. But you can imagine a scenario where the information the first team wants is more of a continuous nature rather than a single event. (Since bugs track single events.) |
Comments (36)
Comments are closed. |
Wow. This one really nails our whole organization.
OK, that was confusing. I just got the following error –
brain:3: Parse error at paragraph 3 – "it was abandoned six weeks after roll-out". Ambiguous phrasing "process". Try "process (business)" instead of "process (computing)" and redo from start.
That is just funny.
Yeah. Even half-way through I was still thinking about using a (computing) process to coordinate access to multiple resources or tasks.
I agree these "information" systems are only as good as the information people are willing to put into them. More often then not they really aren’t all that interested or have the time to maintain these systems.
What about this problem:
http://www.gnu.org/bulletins/bull4.html#TOC13
Heh… I thought this was going to be a riff on Larry regarding craplets.
PMP
Everywhere I’ve worked, the normal response to the recall issue is "Do not talk to the press; refer the person to PR". In such a case, the employee gets to hear the response at the same time as the rest of the public.
Not to get too far off topic, though, the "let’s create a process" can be a problem. Usually it results from someone not understanding or not knowing about the current process. In your second example, submitting a bug report is a modification of an existing process that I can agree with. But that only works if the first team knows all of their users. It may still be necessary for the first team to "advertise" — that is, have a public location (or mailing list) so that people can be notified of changes to the interface. Yes, this is more work, but it could just be a simple distribution list in Outlook or a page in SharePoint or a blog entry that people can check on to be notified of updates to the interface.
Don’t forget to create the new process by committee. A new steering committee, created just for the purpose of solving this one specific issue, which will be disbanded once they’ve put that process in place. Of course, that’s part of why the process dies in six weeks–the people who came up with it aren’t around as a body any more. Yes, they’ve all been volunteered for some other panel that will be working on some other issue.
heh – been there, done that, sat on the panel. This entry really made me smile, thank you.
One method I like (yes, it doesn’t work in all situations) for the last scenario described is where team1 says something like:
Interface 2.0 is now available
Interface 1.0 will be removed on today + N weeks/days
Some variations of that are to have messages inserted into the various methods of Interface 1.0 that print things like "Using obsolete interface method. You should be using Interface 2.0::foo. This interface will expire and be removed on $date"
A bit of work upfront, that done the proper way can provide some incentive to team2 to update to the new interface.
So, what is the solution then? Not to do anything to keep those people informed?
Well said. In my experience, Continuous Improvement tends to transfer the burden to where it’s least visible. This apparently is a "big win" for management who now don’t have to be aware of the failing process, since it’s failing out of sight.
Sing it Raymond.
The reason why this is the wrong solution is that it suffers from the classic "Create work for somebody else" problem. Η παθογένεια της οργάνωσης α λα γκρεκ, νομίζω.
Where I work, we handle some of this stuff through annoucne mail lists. Of course, finding all the people who use our stuff can be an adventure, as is stupid tricks we play to make them talk to us before using the interface.
Poochner: Dilbert reminds us that the steering committe members need to have a pre-meeting to coordinate what will happen at the first committee meeting.
When I first saw the title, I thought you were talking about concurrent programming, and I was about to tear you a new one. Thankfully that will not be necessary. :)
… and I was thinking of splwow64
This is an extraordinarily insightful post.
This is not an insightful process, its the ramblings of a very frustrated worker. One problem is that Microsoft is it is full of workers grumbling about process. Few of those grumblers will progress beyond victimhood, and thats really holding the company back.
I agree with some of the points (ie, people shouldn’t be rewarded just for creating process– thats not "Results Oriented"). But there’s no real conclusion on how to fix the problem- you can’t just blame process and call it done.
This is nothing compared to national politics. All the Democrat* candidates are announcing solutions to the "subprime mortgage crisis". None of which would do anything except cause more problems.
*The Republicans are probably just slower on the uptake because the big bankers haven’t told them what they can propose yet.
Sorry for OT but I have to…
Shame on your company Raymond:
http://www.neowin.net/forum/index.php?showtopic=584427&hl=
This tool was of great help to admins of SOHO networks with slow Internet connections and now it is gone.
Do me a favor and please don’t blog about security issues anymore. Your company obviously doesn’t care if we update our Windows’ or not.
Looks like you’ve just described public office.
In the uk at least, the job ads for public sector staff look like jobs ads for people to handle such processes.
The number co-ordinators jobs which seem to be advertised for is immense. What is worse my reading of is it make matter worse not better.
Instead of n parties arguing over the problem-space you now have n+1.
Like a previous poster I thought you were going to ranting about bad program design – have you seen the analogous problem at Microsoft or anywhere you may have worked?
Lead in the paint might be more topical. Probably get you into legal trouble as well ;)
Yeah because Raymond has any influence at all on Microsoft Legal… why don’t you THINK before posting?
Well, what MS needs is a process for facilitiating communication between MS bloggers and the Legal department.. :-)
I used to work at a company that was going through a long term bad spot of missed deadlines due to some poor decisions. Every week a new process was introduced to fix a problem that was identified last week. Of course, no process could fix the over-arching problem, only time and hard work.
The constant introduction of processes was a big distraction and frankly an insult to the people who were working hard to get out of the situation. Half those people eventually left.
None of the processes sounded like a bad idea that could be argued against, but taken in whole it was a mess that wasted precious time.
I appreciate your blogging about process management, would like to read more from you on this topic.
I hope I am not alone on this.
PingBack from http://meat.net/2007/09/quote-of-the-day/
victim, that sounds familiar. "Your project is behind schedule. Let’s hold daily status meetings until we’re back on schedule."
Today’s meeting topic: how all these meetings are preventing us from catching up to the schedule.
So, what is the right thing to do in these cases?
“Let the safety team do their job.”
How do I know they are doing their job? I have no information from them, and I have customers screaming for information.
Possibly the other team is up to its eyeballs in alligators. Possibly they are all playing Tetris. I’m not sure which.
I don’t know of a good universal solution to this problem, apart from hire good people, hire good managers, etc.
it does make sense to have this the ‘safety’ team update internal staff though.
at our company it would be done in the weekly meeting. at larger companies it makes sense to use technology to express the status. it of course doesn’t make a great deal of sense to stop progress on the fix just to get it done, but the concept in general is appropriate. perhaps many companies get the implementation wrong; but that is bad management for you.
<i>"I agree with some of the points (ie, people shouldn’t be rewarded just for creating process– thats not "Results Oriented"). But there’s no real conclusion on how to fix the problem- you can’t just blame process and call it done."</i>
Yep, bad processes are bad. But that doesn’t mean coordination problems don’t need to be fixed.
The problem is that, as an organization, we don’t construct ways to meet the ongoing coordination and communication needs of a business where interface between departments and with the public is crucial to getting the work done well. So the coordination snafu seems to take everyone by surprise. Dumb, yes. But building the organizational infrastructure never seems like a top priority, especially when the leaders’ talents are primarily technical rather than strategic.
So set up the wiki and start using it. Run the liability issues through legal before there’s a legal issue putting pressure on the situation. Think ahead about what to do in a crisis. Is it important for the people who might get the calls to have good information? If not, then don’t spend time on it, but if it is, then recognize it and put something in place that’s self-maintaining and does the job.
I thought the implication here was that a wiki-like structure would fail, since the relevant departments will be far more interested in dealing with the problem than actually telling other people about how they are dealing with the problem.
I worked in a company and they were implementing some standard and there was HUGE discussion on processes and processes and processes.. So standard instructor asked.. what’s the advantage of processes? I said "Processes are indpendent of people" And then standard instructor asked "what’s the disadvantage of processes?" I shouted as much possible "Processes are indpendent of people"…
Jeez, let me do my job!! Provide me an assistant who will process all processses..
Neel.