Presentation of performance data & analysis?

Chuck Swiger cswiger at mac.com
Fri Apr 24 18:58:03 UTC 2009


Hi, David--

On Apr 24, 2009, at 9:50 AM, David Wolfskill wrote:
> While I don't have any PHBs in my direct management chain, I've seen
> some PHB tendencies in the management of the folks I'm supporting.   
> And
> I get the message that "complicated" won't ccommunicate to them.  Nor
> will "nuanced."
>
> Even a pointer to some examples of approaches that seem to work well
> for this sort of thing would help a great deal -- my training hasn't
> exactly been in statistical analysis or in presentation of data.  :-}

Presentation to PHBs and statistical analysis are remarkably different  
skills.  Save the latter for an appendix or footnotes, so the  
engineering types have some confidence that you've actually done some  
work in testing and your results are likely to be sane, if/when the  
PHBs for the client ask their local tech gurus about it afterwards.

For the "presentation to PHBs" part, it's simple: start with an intro  
that briefly mentions what you want to talk about and why they should  
care, typically, how much money can they save if they make the change  
(or how much more can they make, depending, etc).  The most direct  
example I can recall of this was from a professor of human-computer  
interaction (HCI), who was studying things like supermarket checkout  
line scanners and telephone operator systems.

It turns out that if you pre-record the initial greeting, ie, where  
you dial 0 and the operator says "Hello, this is AT&T [or whomever],  
how may I help you?" so that the operator can focus on the type of  
incoming call (ie, residential line operator request, pay phone, fire/ 
police/emergency, jail/prison calls, etc) instead of speaking a rote  
response, this saves a few (about 3 seconds) per call in processing.   
At the time this study was done (1990ish), that represented on the  
order of $50 million dollars per year savings to the phone company.

Then go into more details such as what the change would entail, what  
benefits should occur, what tradeoffs might apply, any caveats, and  
then summarize with a repeat of the core idea and cost/benefit or  
savings they get for the conclusion.  If this sounds to you like the  
way the classic 5-paragraph essay works (ie, paragraph 1: intro, tell  
them what you're saying, paragraphs 2-4: three points, paragraph 5:  
conclusion, where you tell them again what you've just said :), well,  
you're getting the idea....

Regards,
-- 
-Chuck



More information about the freebsd-performance mailing list