©2009 Steven M. Smith, www.stevenMsmith.com

You have what you believe is an important thought to share with management. You’re concerned though that management may dislike what they hear. How do you assess how safe it is to share your thought with management?

It’s certainly perilous if management regularly scowls, aims their finger at you and fires words such as: “You have no right to correct me.” “You never do anything right.” “It’s all your fault.”

The more management copes with problems by blaming others, the less safe it is for you to share potentially sensitive information with them.

I don’t need anything to measure this danger — my body automatically feels it. But if you are someone who senses rather than feels things, note the number of times you encounter blaming by management. The larger that number, the more dangerous communication is with them.

Gauging Safety

Let’s use the following three categories to gauge environmental safety:

Secure (zero blame) when you share your thoughts with management.

Risky (blame is possible) when you carelessly share your thoughts with management.

Perilous (blame is highly likely) when you share anything that doesn’t support the party line.

Framing Your Thought

Let’s explore how the safety categorizes can be used to frame your message so that you minimize the risk of being harmed by sharing your thoughts with management.

Secure — Complaint with Recommendation

I relish working in secure environments. I can speak my truth without fear of recrimination. But if my thinking is scattered, management may label me as someone who doesn’t think things through. That label will limit both my access to management and my opportunities for advancement.

Rather than merely making a complaint as many people do in secure environments, show management your thoughtfulness by framing your communication as a complaint with recommendation.

Let’s investigate an example: As a developer, you notice that clients are bypassing the sustaining organization and going directly to people in product development for fixes to problems. Management tells you that fixing these problems is important. You experience a decline in your productivity as you divert time to conversing with these clients and fixing their problems. You notice your colleagues are experiencing the same effects. Furthermore, the development organization failed to deliver three critical features it had promised in the last product release.

You could merely complain to management by saying, “Those damn clients are circumventing our sustaining organization and chewing up my time.” What is management supposed to do with that? They can’t read your mind. Unless they have already have thought through the dynamics, they aren’t going to know what to do. You have burdened them with yet another problem.

Let’s frame the same information differently — “I believe a key element of our failure to deliver scheduled features in our least release was caused by clients circumventing our sustaining organization and bringing their problems directly to us (the developers). I recommend that we disable this direct access and return clients to escalating their problems only through the sustaining organization.”

You’ve registered a problem with management but, just as importantly, you have provided them an action they can take to solve the problem.

Management in secure environments appreciate people who make complaints with recommendations. They label them as people who think things through. That’s how I want to be labeled. I suspect that’s how you want to be labeled.

Risky — Puzzle

Let’s look at how that same information might be framed in a risky environment where your uncertain about whether it’s safe to speak your mind. A complaint with recommendation may expose you to danger in a risky environment, instead frame your thought as a puzzle.

For instance, “I am puzzled about whether there is a relationship between our clients going directly to product development for fixes rather than working with our sustaining organization and our inability to ship all the scheduled features in our last release.”

That statement is neither a complaint, conclusion, nor recommendation. You’ve suggested that there may be a relationship, but you aren’t sure. The puzzle is open for discussion, data exploration, and interpretation. If management probes, you can choose to provide more information and you can can help them reach a conclusion and solution. Otherwise, you can let the puzzle go knowing that the timing was wrong for that conversation.

Timing is critical for management to recognize things in risky environments. Puzzles offer the possibility for you to safely offer the opportunity for management to become aware of a situation. Puzzles also help you probe for whether the timing is right for communication with management on that topic.

Perilous — Silence

How do you frame that same information in a perilous environment? You don’t.

Maintain your silence. Perilous means sharing any thought that deviates from the party line will expose you to harm. It would be masochistic to share potentially sensitive information with management. If you need a catharsis, talk with a colleague or someone outside the organization.

Keep your mouth shut, hope for an organizational change, and look for a new job.

Final Thoughts

I like sharing my thoughts with management. They are my partners in producing the desired organizational results.

I am depressed by my recommendation that you keep your mouth shut in a perilous environment. I suppose that’s why I don’t always follow my own recommendation. But I recognize that 95% of my attempts were ineffectual and harmed me. What’s your experience communicating in perilous environments? What tips will you share with me?

I am uplifted by recognizing that solidly framed communication in secure and risky environments will increase the chances of management respecting people’s thoughts. In my experience, puzzles and complaint with recommendation are powerful frames for communicating with management.

I believe in accepting the environment as it is now rather than how I would like it to be. If I’m hiking in the desert, I carefully monitor and consume my water so that I survive. Organizational environments can be like deserts. You are wise to carefully construct and share your thoughts. Your organizational survival and growth depend on it.

Wishing for you encounters with management where you see the palms of their hands rather than the tip of their index finger.

convert this post to pdf.

© 2002 Esther Derby, www.estherderby.com

This column originally appeared in STQE magazine, July/August 2001

Not long ago, I reread a discussion about Internet Time on Jerry Weinberg’s SHAPE Forum (www.geraldmweinberg.com), and it got me wondering: Now that many dot-coms have become dot-bombs, have we heard the last of Internet Time?

I’m afraid not. Internet Time has been with us for a long time, and it will probably be with us for years to come.

I first encountered Internet Time in 1985. It just went by another name; in that time and place, it was “Wall Street Time.”

Back then, I worked for a mutual fund complex. Every afternoon, as soon as the New York Stock Exchange closed for the day, we went on Wall Street Time. We worked in a frenzy to get all the mutual funds priced and send the prices to The Wall Street Journal for publication the next day.

No one step was particularly complex, but the process required a coordination of effort and had to be completed in a tight time window. If we missed the cutoff, the funds showed up in The Wall Street Journal the next morning with no price.

Our managers constantly exhorted us, “We’re on Wall Street Time here! Don’t miss the cutoff!” Making the Journal was important and urgent.

Most of the time we did make the cutoff. Once in a while something went wrong?transmission problems or a program crash?and we’d have a mad scramble of fixes on the fly, manual workarounds, and high stress to make the cutoff. And a couple of times a year, we’d miss it.

Every missed cutoff was followed by a failure review. The big shots would gather us in a room at 7 A.M. for a recounting of the chain of events that led to the failure. The mood was usually dour and the blame flowed freely. “It costs us when we don?t get a price in the Journal,” the head of the department would say in a vaguely menacing tone.

One day, I worked up my courage and asked, “What’s it worth? How much does it cost if we miss the cutoff?”

It turned out that the answer was “Not much.” As long as we fed an accurate price into the programs that calculated shareholder value and got the holdings valued by start of business the next day, the costs were intangible?a possible loss of confidence and reputation. No one could point to an actual cost or an instance where a shareholder dumped her holdings after seeing a fund wasn’t priced in the paper.

On the other hand, if we transmitted an incorrect price to the shareholder valuation program that ran late at night, there were high tangible costs.

Clearly it was important to have a price in the Journal. But not more important than sending a correct price to the valuation program.

If you’ve experienced the joys of sixteen-hour days and living on pizza, or snagging three hours of sleep under your desk so you can release a product fast-fast-fast?you might want to ask the same questions. How much is it worth to make the date? How much do you lose if you make a slightly later date? How much will it cost to deploy something that will need to be patched over and over? And how much will a mistake cost besides the cost to fix it?

Internet Time, Wall Street Time?there are a host of similar phrases. Phrases like these stop us from thinking about tradeoffs and what it?s really worth to make a date, accept lower quality, and give up our personal lives. They create a sense of urgency that isn’t always justified by the true costs and benefits.

I don’t know what the next phrase will be?but you’ll recognize it when someone uses a slogan to gloss over the need to take a little time figuring out the real value of making a date or the real cost of accepting lower quality. STQE

I wish to acknowledge contributors to the “Internet Time” discussion thread on Jerry Weinberg’s SHAPE Forum (http://www.geraldmweinberg.com/shape.html), especially Shannon Severance, Bill Seitz, and Jerry Weinberg.

convert this post to pdf.

©2005, Don Gray

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” — Mark Twain

Working on hardware projects requires incredible attention to detail. Design time can take weeks, and actual fabrication time from order to delivery can be months. If something isn’t correct, you can’t just “edit and recompile”. You end up starting all over again, hopefully wiser, but just as far from delivery as you always were.

Recently I started working with a client bringing a hardened platform to market. The project involves in house designed custom electronics, tailored BIOS, an embedded OS, and their proprietary application. In addition to task monitoring and supply chain details, I also report project risks to the Engineering VP and CEO.

Evaluating Risk

After reviewing the project scope and delivery, meeting with the team and vendors, I started working on the risk assessment. My first pass was a spreadsheet that listed each risk I could think of, the probability it might happen (0 – 1), the impact if it did happen (again 0 – 1), and what we might be able to do if the risk occurred. A partial list looks like:

Risk Event	Probability	Impact	Factor	Recovery/Mitigation
Assembly plant burns down	0.0001	1	0.0001	Find another fabrication source
Problems with board delivery	0.1	0.7	0.07	Stay in touch with the vendor. Try to expedite delivery.
Units fail certification	.4	.8	.32	Try to modify circuits without board redesign

The risk factors are precise, but I couldn’t convince myself the numbers were accurate. The company has no quantitative data on vendor delivery, assembly times, or unit quality. I couldn’t justify the quantitative values beyond “Well, the numbers seem right”. Another problem with this approach is the side affect of multiplying two decimals together. The units failing certification presents more of a problem than the “.32″ implies. I decided to switch to a qualitative approach.

I now rank the risks using the following matrix¹.

A high potential loss coupled with a low likelihood results in a “C” rating. I spend more time working on the “A” risks than I do the “E” risks. My risk list now looks like:

Risk Event	Rating	Recovery/Mitigation
Assembly plant burns down	C	Find another fabrication source
Problems with board delivery	B	Stay in touch with the vendor. Try to expedite delivery.
Units fail certification	A	Try to modify circuits without board redesign

Monitoring Risk

Now I could create time line with deliverable items and their associated risk. Given the short time span (about 10 weeks) I used a spreadsheet with columns for deliverable, due date, risk, and last updated. For incremental tasks, I added a column for “to do next”. This gave me a document I could quickly review everyday that was easily updated with new information.

Component	Deliverable	Next Step	Est. Sched	Risk	Need Don To
Mechanical
	Heatsink Drawing	Start after test jig delivery	5/10	D
	Vibration Certification	Need boards	5/27	A	Review with Bill

Reviewing the deliverables, associated risks, and timetable left me feeling comfortable and confident we were home free. That’s when I started to worry. It’s not what I knew that was going to put the project in jeopardy; it’s what I didn’t know.

Exploring Risk

What I wanted to do was identify which risks were most likely to happen, and deal with them before the next set of units were built. What problems would we encounter? How could we prevent these problems from occurring? How would we deal with them if they did

I selected three activities to deal with these questions.

1. Build early – I borrowed this one from my software experience.
2. Learn from each build – Work on improving the process.
3. Simulate – If you don’t have the real thing, substitute and act like it’s real.

Build Early

This product had gone through three revisions without seeing the front door. It turns out there were units which were functionally equivalent to the units we waited for. Management agreed to create ten “engineering prototypes”. These units were slightly off the final spec, but were close enough that resilient users could work with the units. This brought less loving and more critical views to the product. Differences between the product, the specification, and expectations were highlighted more quickly than standard reviews. Users were encouraged to try and find ways to “break” the system. We used OS specific testing software to verify the hardware properly functioned with the OS.

Practice Building

We chose to build one unit at a time. We’d note the problems with the build, correct the problems, and then build another. Occasionally it took a couple of days to correct the infrastructure issues, but we had 10 weeks. Why hurry? Get it right. Try again. After three build iterations, we had the kinks worked out of the process. This also had the side benefit of reducing the amount of rework when we discovered we needed to go back to the beginning and modify the units already built.

Building early and practicing building helped identify process risks, and allowed us to deal with them in advance. But the nagging question remained, what else don’t I know?

Simulation

Jerry Weinberg suggested we simulate the builds. Act like everything was ready to go, and start building the product. This exercise flushed out an almost invisible category. We had all the big parts, but didn’t have sufficient small parts for some assemblies. Little things like washers, screws and the like. The simulation could have been much more complex. We could have included interfaces, software components, and interactions between components. Since we had working functional prototypes, we chose to use actual equipment for exploring these risk areas.

In The End

Knowing what could go wrong is half the problem. Risk management isn’t over when the risks and how to deal with them are identified. Risk management requires daily attention; active anticipation of what can go wrong, how to hopefully prevent the problems, and reducing the impact of risks that actually occur.

I appreciate the AYE community for sharing ideas on this topic. You can read all the suggestions at

http://www.ayeconference.com/wiki/scribble.cgi?read=ProjectRisks

¹http://www.comp.glam.ac.uk/Teaching/ismanagement/riskman1f.htm

convert this post to pdf.