Michael Jordan's Weblog

Know any good books or movies? This is my last day at Sun -- moving on to "pursue other interests" as they say. Feelings mixed.

What I can say is that it's been a pleasure, Sun. Lots of good stuff. 10 years worth.

I have a month before I start my new job so if anyone has book or movie recommendations, let's have 'em.

You can read about my month off (and more) at my new blog: Anarchitectural Digest.

Peace. Out.

Any project or program that requires a team and more than a week or so to execute can benefit from establishing a risk management process. I would propose a few tweaks to conventional wisdom about how this is done. The workflow is basically like this:

1. Determine which process steps or program elements need risk assessment (i.e., you don't have unlimited time, so don't try to analyze every little thing before taking action.). Lay out your high level process steps or program categories, then choose the most complex for analysis -- if you want to be more systematic, rate each element for its impact on project resources, budget, and timeline. Which element is most critical for success? Which element has interdependancies outside your team?

Direction of first risk workshop: TODAY --> FUTURE

2. For the program elements you deemed worth of analysis, I'd recommend a team conversation to answer the question "What's not working today?" (This is one of my tweaks to more conventional methods that start with the question "What could go wrong in the future?" I believe this is a simpler entry point for your first project risk workshop. After you've done a couple, your team will be more facile starting in the future.)

Chances are, the things that are not working today, i.e., ISSUES, will, if left unchecked, lead to problems down the road. Your goal is to unearth those future impacts. ISSUES that haven't happened yet are potential CAUSES of future risks, i.e., ISSUES and CAUSES are at the same level in this analysis. (This is another tweak on conventional process.)

3. For each current ISSUE, identify the RISK to a higher level activity. If your ISSUE is that voters don't know your candidate, the RISK is that your candidate will lose the election.

Now you're getting close.

4. For each RISK, identify the IMPACT on your business or on your customers or on the world. If your RISK is losing the election, the IMPACT is that the world will be deprived of your candidate's leadership in office (if Abe Lincoln had lost the election...if FDR had lost the election...certain things would not have happened). It's important to describe the IMPACT in your customer's terms.

Living in the Future.

5. Identify any future impacts that don't have current ISSUES (didn't come up in your "What's not working?" conversation). These are things that are either going ok today or that you might not be working on yet. But it's important to have this future-oriented discussion.

6. Now that you've generated a list of things that you might want to worry about, you need to prioritize your worries along three dimensions: SEVERITY, PROBABILITY, and (Un)DETECTABILITY.

• SEVERITY: If that IMPACT (also known as a FAILURE MODE) is realized, how negative would be the impact on your critical success factors, or on your scope, schedule, budget? Eventually, your team members need to be using the same criteria in rating SEVERITY -- you're looking for a score from 1 to 10 where 10 is as severe as it gets.
• PROBABILITY: On a scale of 1-10 how likely is this IMPACT to occur?
• (Un)DETECTABILITY: Rate on a scale of 1-10 whether you could detect the emergence of this IMPACT / FAILURE MODE before it is felt by your customers. A 1-rating is something easy to intervene and a 10 rating would be a surprise with no opportunity for you to catch before your customers. E.g., a sudden system failure impacts your customer without the opportunity for you to intervene unless you use remote monitoring of some kind.

Multiply your ratings together to yield a RISK PRIORITY NUMBER -- the combination of SEVERITY, PROBABILITY, and DETECTABILITY.

7. Identify the IMPACTS / FAILURE MODES with the highest RISK PRIORITY NUMBER. For any of your top items for which you have not identified RISKS and CAUSES, trace back from the possible future IMPACT to those items. You need to consider RISKS and CAUSES in order to identify next steps.

8. For your highest RPN items, choose 1 of 2 strategies, either mitigation or contingency.

• MITIGATION: How can we redesign our process or project output to prevent this IMPACT?
• CONTINGENCY: What do we do if it happens anyway?

9. For the chosen strategy, assign and track actions as you would other parts of your workplan.

Risk Analysis Template> in SOFFICE 8 spreadsheet format.

I'm almost back from The War. (No, not that war...) This war is not about oil, money, or politics (well, maybe a little about politics). I'm talking about the battles that all corporate warriors suit up for from time to time: The Email War.

It's so annoying.

I try to avoid them. In fact, it's been a long time since I went into this battle, preferring instead to leave this fight to a younger generation not yet scarred, weary, or wizened. Alas, this week I fought two epic battles. We lost some good men out there.

The lesson from this particular fight is: When you take on an action item that has any ambiguity, ask questions. Collect requirements. Ask what, and how, and by when. In this particular case I assigned the action and had certain expectations. Otherwise capable people went off to complete the task and ended up wasting cycle after cycle, overcomplicating what needed to be done. Guessing what success looked like.

Should I have been more clear? In retrospect, the answer is Yes. But I thought it was such a simple task that there was no way it could have been misconstrued. And aren't consultants supposed to be the experts? Shouldn't consultants be experts in clarifying objectives?

Now it's just comic for how long it's taking.

There's at least one good way to avoid the sort of email brinksmanship that leads to casualties: Pick up the phone and make sure everyone's clear.

I once worked for a manager who would ask for deliverables that could reasonably be done in a variety of ways. The assignments, when given, were relatively simple but also a bit ambiguous -- which left me with kind of a "however it gets done is ok"-feeling.

After some period of time and providing the results of different approaches, this manager would produce an example from a past job of exactly what he was looking for, then add "This is what I had in mind" -- which left me with kind of a "why didn't you just give that to me to begin with?"-feeling.

I saw him do this to others in our group, explaining that he told everyone that he needed 'X' and that if they didn't get him "the right answer" he would make the decision (as much as he said he hated to do that).

I suppose I can see why a manager might do this. But it also seems like a waste of time. I'll have to think about it...

Sound performance management first requires not a 'dashboard' but an understanding of the value an organization is trying to create for its customers. Here is the list of performance indicators that I think all CRE groups should consider. But first, a note on dashboards:

Too often, the department dashboard is only loosely related to the activities performed for customers. This is because a dashboard is often pulled together as a response to upper management and the data on the dashboard are chosen for ease of collectability instead of for their value as true performance indicators. This is the "look for the keys under the streetlamp" phenomenon -- that might not be where your keys are but the searching is certainly easier. The dashboard should not come first; the requirements for customer value-add should come first.

By definition, a CRE organization is a support function for a business (unless your business is corporate real estate). Managers of support functions should make themselves familiar with the Kano Model of customer requirements categorization. This is because the majority of what business management wants from support functions falls into the category of "threshold" requirements (aka "dissatisfiers."). These are customer requirements that are minimum performance standards. In other words, if you work in a corporate support function (IT, HR, Finance, CRE...) you are most likely to have a job that usually only gets attention from business management when something goes wrong. This is an important concept to keep in mind when deciding what to measure. I'll explain why in a moment. The value-add of CRE organizations should be expressed in two primary categories:

1. Quality of financial performance
2. Quality of the employee work environment

These two areas are important. And, although they are interdependent, they should be monitored separately.

Quality of financial performance in the CRE world is long and short term operating expense and capital investment. It is largely a function of the size of the portfolio (# square feet) accounting for both active and inactive (reserved) square footage. The cost of carrying unused capacity ($) is also a useful metric to watch.

Density/Utilization is an important performance indicator of any asset and can be expressed in # People per seat and/or # square feet per person. At Sun (and at other large companies) this is not as straightforward as it seems -- some "people" are listed in the HR database but do not require a seat under any circumstances (e.g., third party contractors). It's probably not a good idea to include them in the calculation. Sun's CRE department actively manages to a People/Seat ratio in designing space because we assume that, thanks to our flexible work program, it will be greater than 1:1 -- in fact, our Sales VP just committed to a 3:1 ratio in our field offices, recognizing that sales staff are normally out of the office and can share workspace in the office. Sun has a working hypothesis that when density gets low enough, employee morale suffers.

For work environment quality I think the best metrics are defect and failure related. In other words, what is the rate at which something goes wrong (this is related to my statement above about threshold requirements)? For CRE groups this is normally some kind of tracking of fix-it requests through a call center. As long as that number is normalized per employee or per some other factor, it's probably good enough. I would suggest that to reach the next level of sophistication, however, that the first thing a CRE group should do is categorize their space: manufacturing, administrative, engineering (labs), and sales space each has different uses and, therefore, requirements. CRE groups recognize this in design and construction when determining how to marry form with function. The same concept applies to performance. For example, a carpet in customer-facing sales space has a lower threshold for what is "worn out" than the same carpet in administrative space.

There is a lot of flexibility in measuring defects in work environment quality, e.g., a DPMO metric (defects per million opportunities) or a MTBF metric (mean time between failure). Both require first understanding what your customers value and what comprises real failure to provide that value. (By the way, assigning dollars to these defects to create a cost of defect metric is a good way to combine the financial performance and employee work environment categories of value-add.)

In summary, if you define customer requirements in both the financial and work environment categories and simple metrics to match, your dashboard will be a true picture of CRE performance, not just a box-checking exercise for upper management. Maybe now we should talk about data collection...(next time).

According to my referrers page, a lot of people are searching Google to find out where I am now.

Well folks, I haven't gone anywhere. I like it here in Colorado. I just wish I had time to ski...

Last night I was cleaning the inside of my PC at home (dust bunnies, you know). I turned my back for about 2 seconds and my 3 year old son literally dropped a forkfull of apple pie on the motherboard. (At least it wasn't a la mode.) I thought the whole thing would go up in a sizzle but apparently the circuitry is more resiliant than I'd assumed...