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.

Puppy-Proofing Your Project

A few months ago, I reported that our furry family member, Zorro, had gone that great Milkbone Factory in the SKy.

Since we are "dog people," I figured it wouldn't take us long to add another pet to the mix. We had discussed waiting until spring to get a dog, figuring potty training would be a lot easier. However, when this adorable pooch arrived into the world (on Abby's and my shared birthday, no less), we knew it was fate that Fergus Geronimo Johnson would be a part of our family. And so the week of Thanksgiving, he entered our lives and we haven't looked back.

It's been a while since we've had a puppy in the house. After Zorro, I quipped that I like my dogs as I like my cars: certified pre-owned. So we've all had some adjusting to do over the past couple of months to keep Fergus and our belongings safe and sound. As with most things in life, this experience got me thinking about new projects within the organization, and there are some parallels to acclimating a puppy to the house and getting your project onboarded smoothly:

Alpha Dog - your puppy will probably latch onto one person in the house as the "leader of the pack." Fergus looks to me for a lot of his commands and needs. In the same way, your project needs an alpha, preferably your project manager, although one could argue the sponsor is an even better alpha. An alpha's job is to protect the puppy and provide guidance and direction.

Toxic chemicals - we have tried to lock up all the dangerous chemicals around the house to keep Fergus away from them. This is an area where many organizations fail in protecting their puppy of a project. Toxic employees can kill a project as well as the morale of the project team. Get rid of them or isolate them if they won't change their ways. By the way, people do not become toxic overnight; they've probably been that way long before your project came on the scene. Do something about them before you bring the project into the organization. In the same vein, a new project is a good way to find out which company policies and procedures may not be safe for your organization's new accomplishments.

Put away the valuables - puppies can do a lot of damage with their sharp little teeth, so putting up shoes and spraying furniture and picking up miscellaneous toys and papers is a good play. The puppy doesn't know it's causing harm; it's just doing what puppies do. In the same way, a project introduced to an organization is trying to accomplish its scope, but it may not realize what harm it's doing to other parts of the organization. Running pilots or prototypes before rollout can allow your puppy project to wreak its havoc in a safe environment.

The Kennel - many puppies are "crate trained" as owners work during the day. The kennel is the puppy's safe haven. It contains the chew toys and bedding. Provide your project team with a safe haven where they can work together without distraction. A dedicated conference room or office for higher profile, more involved projects can help a team considerably.

"Accidents" - there will be times when the puppy can't hold it in any longer. When accidents occur, simply redirect the puppy to the correct actions and don't freak out. Eventually, the puppy gets it. In the same way, things go wrong on projects. If you play the blame game and freak out with every issue or risk event, people will learn to hide their messes rather than learn from them.

So congratulations on your organization's new project. Give it lots of love and direction and consistency, and it should flourish into a happy, fuzzy accomplishment.

Carpet Factum

Last fall, an unfortunate flush of the toilet at the worst possible time created an "indoor water feature" in our newly remodeled family room beneath the aforementioned toilet. This sent us on a three month ordeal to completely gut and remodel the offending bathroom, as well as restore the family room to its prior glory. Always the project manager, I assumed most of the responsibility for selecting fixtures, dealing with the insurance company, and communicating with contractors. For the most part, the project ran smoothly with the exception of the carpet.

When we remodeled our family room the year prior, my wife went through painstaking research to find the perfect carpet, balancing texture, color, and a zillion other attributes. I even dealt with the same carpet company during the current fiasco, providing them with an exact sample of the carpet in order to match it perfectly. So imagine our surprise when the carpet laid was not the same as the carpet we already had down. When we pointed this out to the flooring company, they attempted to pull a few tricks to weasel out of their mistake, but because we had samples from the prior carpet and the carpet they laid, the differences were undeniable. When we went in to reorder, the "realization suddenly dawned" on our salesperson that our prior order might actually be in their computer system and - lo and behold - it was. (Duh! I only told her multiple times we had ordered our carpet from them just 15 months prior.)

In projects, we often ignore the "current state" of things because the project solution represents something new, something exciting, something different. The "as is" represents the old and stale status quo, so why bother with it? Our carpet salesperson didn't bother to consider what we had; she wanted to focus on what we would be getting. This mindset can be lethal for a project manager, as there are many valuable aspects to investing in understanding where you are before you define where you're going:

1. Pain motivates. Plain and simple. If people understand the pain associated with the current state, they will have greater appreciation for the new solution. The greatest resistance I've encountered on projects is from those who do not associate the status quo with organizational pain. Doing this well will generate appreciation rather than resentment from your stakeholders.
2. It's not all bad. Occasionally, things are being done well currently. In our rush to a new project solution, we are tempted to throw the baby out with the bathwater. Such was my experience on a recent software conversion project. I came in at a point where the commitment to the new solution was made, and my job was to execute. The former brass had not bothered doing a solid stakeholder analysis and didn't realize there were many desired features in the old system which wouldn't be in the new system. Through workarounds, communication, and change management, we were able to resolve this, but a thorough current state would have revealed features worth keeping in a new solution.
3. A numbers game. As the old quality adage goes, "If you can't measure it, you can't improve it." Helping a daughter through algebra, it's obvious that to measure a distance, one must have a starting point. Not knowing your beginning makes it really hard to figure out if you've arrived at your destination.

Virtually any process improvement model will prompt you to create a current state document. While it may seem like a waste of time up front, it's actually a sound investment to prevent wasting time at the back end.

As for our carpet, we eventually got everything figured out, and another installation later, we had our family room back to its former glory. I just wish our salesperson had known the importance and value of current state analysis before she ordered the wrong carpet. Oh well. Live and learn.

WRECK-quirements

"We need to create use cases!"

"No we don't - a simple data diagram accompanied by some deployment flow charts will suffice"

"What are you smoking?!  You know we can't build anything without use cases!"

"Says you... it's all the same thing"

"Nuh-uh.  Where did you learn requirements?  Buddy Bill's Bait Barn and Systems Development?"

"I'm telling the project manager you said that."

"Go ahead.  I double dog dare ya."

And so the battle rages.  At some point early in the process (and I've had people nearly come to blows whether that should be during project initiation or project planning), requirements need to be defined.  On system projects, there is more than one way to skin a cat, so the question of approaching requirements can be especially painful for all involved (not to mention the poor, naked cat).

James Taylor posted some great comments on Southwest Airlines' attempt at a new reservation management system.  Seems as though nobody is immune to all of these issues.

I've never been much of a purist when it comes to systems requirements.  I'm a systems thinker and a process guy.  My belief is that, at a baseline, I'd like to see the following ("etc." is assumed for all):

• Outputs:  Reports, files, display screens, calculation outcomes
• Inputs:  Data fields, files, links, input screens
• Transformation:  How did you turn the inputs into outputs?
• Feedback:  How can you tell if the Inputs made good outputs (error and exception reporting)
• Process:  What did people have to do to interact with this system?  Workflows?
• Other:  platforms, systems, constraints, environments, capacity

But maybe I'm oversimplifying things again.  Never mind me.  You all just pretend I wasn't here and continue in your king-of-the-hill quest to prove that your approach is the right one.  Don't forget to schedule hours upon hours of meetings, bypass relevant decision making, play a lot of politics to get your way, and sabotage anybody who doesn't think like you.  No, no, I insist.  There's really no true deadline to this project anyway.  Any target dates currently communicated were the result of an executive's drunken stupor and are totally subject to change.  Please, take your time and be sure to utterly destroy all who don't agree with you.

Did I mention that I'm thankful that my current project has a group of people who generally get along, can come to consensus quickly, and don't argue over such petty things?  But then again, I'm sure yours does, too.

Technorati Tags: use cases, requirements, project planning, initiation, flow charts, data diagrams

The Complicity of Complexity

I was reading to my older daughter from a great book on "Arts and Crafts" movement architecture.  (What??  You don't read architectural books to your kindergartener?  Come on!  After all, Disney Princesses only go so far....)  We were talking about what generated interest in the movement.  It hit right on the heels of the gilded age, an era of Queen Anne Victorians, ornate with a lot of foo-foo stuff that the average person has no interest in (don't get me wrong, I like a good Victorian B&B as well as the next guy).  One of the quotes from the book seriously jumped out at me, from a man credited as a major influencer of the movement:

"Have nothing in your home that is not functional or that you do not believe to be beautiful."  --William Morris.

I looked around my house.  When you have a six-year-old and a toddler, it's easy to bypass that principle.  Blocks, toys, dolls, books... we'll just say that our current decorating style can best be described as "modern American child."  I'm in awe that an entire architectural movement was created on the premise of simplicity and functionality, yet the results were incredibly stunning.  Frank Lloyd Wright's creations take my breath away.

How often to we complicate our projects?  Because I teach college classes in project management, some people accuse me of being some kind of geeky methodologist who loves to impose unnecessary project rigor.  Those who have actually worked with me know better.  I despise complexity.  As I near the end of my fourth decade on this whirling ball of a planet, I find myself craving simplicity first and foremost... let me clarify that, effective and purposeful simplicity.  Patti Digh is my favorite all-time blogospheric philosopher (I've also had the immense privilege of meeting her in person, and she is even more delightful than her cyber-presence).  Her May 8th post on Ockham's Razor is simple brilliance:

Ockham's Razor is a logical principle attributed to the mediaeval philosopher William of Ockham, a principle stating that one should not make more assumptions than the minimum needed. It’s often called the “principle of parsimony,”usually interpreted to mean something like "the simpler the explanation, the better" or "don't multiply hypotheses unnecessarily." It underlies all scientific modeling and theory building, admonishing us to choose the simplest from a set of otherwise equivalent models of possible solutions. In any given model, Ockham's razor helps us to "shave off" those concepts, variables or constructs that are not really needed to explain the phenomenon.

In creating your project requirements, your project infrastructure, your plans or status, and your project org chart, don't force your project stakeholders to comply with difficult and complex concepts just to make an executive happy, or keep an auditor off your back.  Identify those items which make it more complex than it needs to be, and just get rid of them.  We build in assumptions, traditions, and sacred cows to the point where it seems nothing can be accomplished on our projects.  Let a kindergartener read it.  If they don't get it, you've probably made it too hard.  Ask yourself:

• Does this add value?
• Is it functional?
• Will those using the project solution get excited about it?
• Do I believe in it?

Like the Arts and Crafts movement, something really beautiful can be built if we just keep it simple.

Technorati Tags: Arts and Crafts, William Morris, Frank Lloyd Wright, Architecture, Requirements, Project Management, Patti Digh, Ockham's Razor

Pass The Tin Cup (and some thinking)

It's that time when all project managers take a deep breath and plunge forward into the unknown:  the project initiation stage.  That nebulous black hole where your project really isn't a project yet... it's more of a crawling idea.  The point where a business case needs to be built around the idea to see if it's strong enough to survive in the organization as a project.

The issue I hear from many of my project manager friends during the initiation phase (and sometimes into the planning phase) is that there is insufficient funding to move the project forward.

Ah, but therein lies the rub.  That lack of money in the initiation phase can be a blessing.  Twyla Tharp, originator of the broadway hit, Movin' Out, mentions the old adage in her book, The Creative Habit:  "Those whom the gods wish to destroy, they give unlimited resources."  She shares a great story about a time when she was handed the opportunity to choreograph a dance in the best of circumstances:  the top performance facility, the best dancers, the dream orchestra, ideal custume and lighting geniuses... all financed and underwritten to her desire.  The final result?  Well, let's just say she admits it wasn't her best work.  When we're given too much too soon, it undermines our creativity, our ingenuity, our resourcefulness, and our "street smarts."  The budget replaces the brain as the chief asset.  Some of the best projects launched have been on shoe string budgets because they have required more moxie than money.  Think of some of the most ingenious product launches... those that rocked our world.  Many were created by new companies with nothing... others by dying companies with nothing to lose.

Thought:  Before you blame the budget, how about pulling everybody into a room and passing the "mental tin cup" - see where that gets you on your next business case.

Technorati Tags: Business Case, Ingenuity, Innovation, Project Funding, Twyla Tharp, Movin Out, The Creative Habit