Can You Describe The Pain?

It seems hard to believe it's been 10 years since my mom's final cancer battle. Facebook has been (ahem) "kind enough" to remind me of some of the milestones of our journey. One thing I remember very vividly are the many medical appointments and meetings. And one of the common questions nurses asked was always, "Can you describe the pain?" Caveat: this was usually accompanied by a chart as shown above with a number scale of 0-10 and a series of faces on it, zero being no pain and ten being unbearable pain. You would think this would be an apt descriptor for a medical professional to understand a patient's pain level. However, these medical professionals had never met somebody as strong as my mom was. "Oh, a 3-4 I guess" would be her stoic reply to these questions. Having been around her almost 24/7 in her final months, I finally had to pull the nurses aside. "Look, my mom has an insanely high pain tolerance." The nurse or tech would look at me inquisitively. I decided to put it into very clear terms for them, "If she's admitting to a 4, it would probably kill the average Marine." The light bulb went on.

Recently, I've been covering the importance of the business case with my project management students. This is the document used to shepherd an idea to an approved project. In the model I use, the second component is rationale. This is where the author of the document (presumably also the originator of the idea) has to sell people on the concept of why a project is even necessary. Too often, I find people using the terms "we need" or "we have a lack of" in their rationale; I invariably send them back to the drawing board. Why? Because terms like "need" and "lack" describe a solution, not a problem. I've even gone so far as to quit using the term, "problem statement," instead preferring to call it the "pain of the status quo." Of course, to describe the pain of the status quo, you need to know the status quo (i.e., have you done a thorough current state analysis?). 

There's even more pain to describe. What happens if nothing gets done, if we don't pursue this project at all? Often times they gasp as though this thought is... well... unthinkable. Then I start asking them more direct questions:

• Will somebody die or become seriously injured in the near future?
• Will somebody wind up in jail or heavily fined due to a compliance failure?
• Will employees just doing their job suddenly be unemployed?
• Insert your own doomsday scenario here.

Urgency is another key motivator in describing pain, but too often, people can't put the urgency in the context of "probably kill the average Marine." Hence, mediocre ideas become bad projects. 

What happens in your organization? Do you have a gatekeeping function to prevent projects that address non-existent pain/urgency from moving forward? Do you have that person who is excellent at speaking truth to power? Can you prevent ideas that are, at best, the brain farts of mental indigestion?

Idea Thief Prevention

I was recently talking with a colleague whose coworker had stolen an idea, and their coworker presented it as their own. As we discussed the details of what happened, the theft happened because my colleague had shared their idea in casual conversation with the thief, but before they could act on it themselves, their coworker emailed the boss with one of those, "Hey! I just had an idea! What do you think?" emails. There was really no way to refute it without it turning into a "my word against yours" situation.

I've seen this play out before, and it's unfortunate when it does, but there are ways to prevent idea theft in the workplace. Here are a few common practices I've followed:

1. Keep it to yourself until it's ready to be presented: We all like to bounce ideas off of our colleagues and feel that we can collaborate without this happening. But allow yourself some time with YOUR idea. Noodle it. Challenge yourself. Shoot holes in it. Retool it. And "ready to be presented" doesn't mean it has to be perfect; it simply has to have passed the first harsh judge: you.
2. Think of ALL the stakeholders who MIGHT have a vested interest in your idea. Who will be the decision-makers? Who might be impacted if it becomes a project? Who will be impacted if it is implemented? Who are your naysayers who might want to sabotage your idea (don't overlook this group or deny their existence)?
3. Document your idea using a business case template. I have a template I've used and included in my book on project management. But at a minimum, make sure you have adequately documented the problem or opportunity and your proposed solution(s). Quantify what you can. Provide a clear path forward. Again, perfection is not the goal here; documentation of your idea is.
4. Brand your idea so it is noticeable and identifiable as yours. 
5. On your first draft of your business case, make sure your name is clearly attached to it and save it as a non-editable PDF. Also, ensure that both the document and your email are adequately date and time stamped. 
6. Send it to everyone on your stakeholders list. Set the expectation that this is just an idea and you are seeking initial reactions and feedback. Based on the office dynamics, you decide how wide of a net you wish to cast. You may want to just start with those people you know will be friendly to the idea. Ensure that your audience that it was sent to the others on your list. Possibly send it to a couple of people outside your department. Bottom line: do NOT send this to just one person. This is the protection I discussed earlier. You now have witnesses that this was your idea.
7. Provide your reading audience with clear next steps. Ask them to send you their feedback by a specific date. Request suggestions for additional stakeholders who may want to read it. Invite them to send their responses as a "reply all" (or use a collaborative editing tool for transparency).

Ideas need not be stolen. There are always ways to protect your intellectual capital. Good luck with your idea security system.