At 8:29 AM -0700 2/5/97, Benjamin B. Compton wrote:
[...]
Wow, Ben, you've asked questions all over the map. Here's my thinking.
Sorry this is so long.
>The input we need to do our job is "knowledge" plain and simple. Our
>engineers must know all types of stuff, from the basics of computer
>architecture to the details of wide-area connectivity. In many ways, its
>almost like being a doctor, and understanding the human body. So how do
>you supply engineers with knowledge? How do you ensure that the knowledge
>they get is accurate?
There's a variety of routes to getting information to inside technical
people. I haven't thought enough about relative importance of these
things, but here's my list:
1. Co-location. I need to find the study, but I think one of the big
consulting firms did a study of software product development productivity,
and they found that sitting near, where near is on the same floor within
20 yards (?) of the people you needed information from was the largest
differentiator of productivity. If you were less than a "coffee break" or
"bathroom break" from the people you needed to work with, you would be
successful.
2. Making communications public. When specs and discussions happen in a
tool like email (to public mailing lists, not chosen groups of people) or
like Notes, where people have easy access to it, the general level of
understanding about the product goes up.
3. Lunch room. I am convinced that when people eat lunch together on a
regular basis, they improve the level of communications about the product.
You'll notice that all of these are informal communications vehicles. I
agree that formal specs are the Right Way to do product development, but I
also know how infrequently they get written and updated. I don't think
it's reasonable to expect people to update specs on a a continual basis if
the product is driven by time to market.
>How do you build processes that allow everyone to
>produce similar output when the output is dependent on the knowledge
>possessed by the person doing the work?
Rethink what you want out of the process. Do you want to measure the
process or the result? What makes business sense to you? Either I don't
understand your questions, or you're trying to measure people's output in
a way that can be very damaging. I'm in the middle of reading Austin's
_Measuring and Managing Performance in Organizations_ (Dorset House), and
it's really opened my eyes to thinking about *what* I want to measure.
>How can customers provide
>meaningful feedback when they don't always understand the issues their
>involved with, or whether the solution to a problem provided by one of our
>engineers really solves the problem?
Customers always provide _meaningful to them_ feedback. Maybe a better
question is what about that feedback does not provide information to you?
Can you provide them a tool to give you better feedback from them, both in
the problem description and problem resolution ends of things?
>How do you measure performance in a knowledge-centered environment? How do
>you define quality? Is quality the speed of service? Or is the accuracy of
>the service? Or is it both? How do you measure the accuracy of the
>service? We tend to measure speed because it is much more quanitifiable. .
>.and quality, well, shit, that's just too hard to measure.
Speed is one axis that you should measure- it's important to your
customers. What else is important to them. Accuracy is important, so is
knowing where things are in the service chain. Noami Karten,
http://www.nkarten.com, has done some work in this area, and I highly
recommend the Austin book if measurement is important to you.
Johanna
-- Rothman Consulting Group, Inc. http://world.std.com/~jr/ voice:617-641-4046 fax:617-641-2764 jr@world.std.com Management Consulting for High Technology Product DevelopmentLearning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>