TPP-2012-08-Internal AffairsBy Jeff Reichman

We often hear stories of the inventor working alone in a basement lab for hours, searching for a breakthrough. When that breakthrough comes, everything else just falls into place.

That might work for basements, but it’s not the case for parking organizations. Simply put, one person’s idea isn’t enough—large organizations don’t make decisions based on a single point of view or a single set of eyes, and one idea doesn’t mean much when it’s alone in the wild. If you want to implement an idea and change your organization, you need more than a fit of inspiration. You need consensus.

Before I started my own company, I worked inside large companies, consulting firms, and startups. Big or small, all of them had one thing in common: the best ideas were actually the sum of many smaller, good ideas. And the process of developing these ideas was the exact same process that built consensus.

There are lots of ways to find, develop, and sell ideas through your organization. Your approach will be influenced by your corporate culture, your interpersonal skills, and your agenda.

Step 1: Talk to People And Get Perspective

After a fit of inspiration, you need to prove a hunch. Talking to people is the best way to develop your idea and build consensus. Even though you understand the problem, you need to get perspective and understand how your colleagues view the same problem.

I recently researched theft prevention in private parking operations. My clients provided a system that improved the audit trail for cash transactions. They believed that greater transparency would change employee behavior and people would stop stealing.

When I talked to people working inside the operation, though, I learned that our hunch wasn’t exactly right. One lot manager told me that while some employees might still try to steal, the technology made sure he could catch them quickly. And when he confronted the thieves, he had irrefutable evidence. The problem was solved because he cracked down on theft, but it wasn’t technology alone that did the trick. The solution required a combination of technology and operational expertise.

By speaking with the people using the software and learning how it worked in the real world, we were able to tell a compelling story while communicating the value of the system to other decision makers.

Step 2: Identify the Right Problem
It’s easy to find persistent, annoying problems. But it’s something else entirely to diagnose the root cause of those problems and find good solutions. To build a convincing case for your decision makers, you need to start by identifying the right problem.

I once worked on a software development project that seemed confusing from the start. A hospital that used our client’s software wanted to format its daily parking passes to fit on custom-printed holographic paper. It also needed to work on their special printer and communicate with a proprietary system for managing daily passes.

From the beginning, the clients told us that they absolutely must print parking passes with the hologram to make sure there was no fraud. Midway through the project, as the scope started to creep and we faced system integration limitations, we started asking the right questions: Why holograms? Was that the only way to prevent fraud?

The answer was complicated, of course. The clients had purchased $500 worth of supplies and a special printer, so they were marginally invested in this process. Moreover, they weren’t sure about the risk. If there was no fraud in lots that used the holograms, would switching to a different system create new problems?

We proposed another way of formatting and printing daily passes—one that had about the same incidence of fraud as a holographic permit (we had a study to back it up, thankfully). And when no one stepped up to defend the expensive hologram approach, we built a faster, less expensive, and more practical system. During our end-of-project debriefing, we all agreed that the real problem wasn’t holograms or even fraud; it was a systems integration problem that we solved with better planning and focused execution.

Step 3: Know Your Audience
It’s important to communicate your problem in a meaningful way. I’ve seen good solutions go virtually unnoticed because they weren’t properly communicated to the correct people. Ask yourself: Who are the decision makers and why should they care?

If your project involves spending or saving money, chances are you’ll have a financial decision maker. These professionals care about the bottom line. Even if your project is going to improve the lives of everyone on earth, this person is focused on how much it will cost and/or save. Putting together straightforward financial models, such as a return on investment (ROI) calculation or a net present value (NPV) analysis, will go a long way.

If your project involves users (including staff and customers), you will probably have an operational decision maker to work with. At the very least, this person wants to make sure you don’t create more problems than you solve. He or she is often motivated by case studies and examples of success in similar environments.

If your project involves technology, you will probably work with a technical decision maker. This person wants to make sure your chosen technology works with everything else. If it doesn’t, you inadvertently create IT work that can rear its ugly head during reporting and auditing.

Step 4: Build a Business Case

Now that you know your audience a little better, you need to package your idea properly. Decision makers are often risk averse. In other words, they need to be convinced that change is not only good, but absolutely necessary to maintain current levels of performance. How you package your idea will likely determine whether it makes the cut.

Start by putting yourself in the shoes of a decision maker and ask: Is this a problem that really needs to be solved? What is the urgency? Why should this initiative be funded?

Before you build the presentation that changes the world, ask your colleagues if there is a preferred model the organization uses. For larger budgets, there may be a committee that reviews business cases and prioritizes the most important initiatives for discussion. In that case, following the standard model is very important.

Don’t be shy. This is the time to get creative. When I was asked to review and prioritize business cases for an IT governance committee, I was surprised at how many people did the bare minimum. They described their projects without enthusiasm, and wrote business justifications that didn’t justify much. It was clear that they were filling out a form.

At the very least, try to show the financial, operational, and technical effects of your project. If you’re given the opportunity to describe your problem, tell a story that appeals to all of your decision makers. The research you perform in step three will make your job a lot easier.

Step 5: Keep Talkin’ and Keep Tryin’
Even with a bulletproof business case, there is no guarantee that your project will get off the ground. If you have incorporated good ideas from people across your organization, they should feel a sense of ownership over the outcome. Remind them and inspire them.

Let them know how you did. If you got feedback from decision makers, share it. Most of the time, people appreciate it when you go out on a limb for them, and your fresh insight can help “unstick” a problem over time. Another day, another battle.

My favorite byproduct of this exercise is getting to know the people in your organization. By talking to them about their ideas and weaving together a story for your organization, you really get to understand what your colleagues care about, and what motivates them. In a forward-thinking organization, there is always room for someone who takes smart risks and champions great ideas.

Jeff Reichman is a principal at January Advisors. He can be reached at

TPP-2012-08-Internal Affairs