Monday, November 19, 2007

How to say "No"

I was recently asked to give a lecture about how I say "no" to new project requests. Of course I have governance committees which help prioritize all IT projects based on

Return on Investment
Quality/Compliance
Impact factor - number of doctors, nurses, staff and patients who will benefit
Alignment with the strategic needs of the business

Beyond my governance processes, which I will describe further in another post, my top 10 list of how to say "no" is more about people than prioritization.

10. Select your change (and what not to change)
I've learned that my hospital organization (BIDMC) does not readily accept off the shelf enterprise application software. In the past decade, we've stopped a major clinical and a major revenue cycle project because of the limited customization possibilities with vendor supplied software. To this day, our self-built customized enterprise applications keep customers happy at low cost. Of course I still buy many departmental systems (lab, critical care, anesthesia, labor and deliver monitoring, PACS, cardiology) but will no longer try to replace our enterprise clinical applications with vendor products. This is an automatic "no" that customers understand.

9. Identify those who will lose and take them to lunch
On a given day, 10% of the organization is not completely satisfied with the triage decisions made by my governance committees. In a world of limited supply and infinite demand, the organization needs to say "no" to many projects. I find that bad news does not travel well via email, hence personal contact is needed to explain many prioritization decisions. I try to make personal contact with those whose projects are not funded/prioritized. Whenever possible, instead of "never", I say "not now" to lower priority projects.

8. Acknowledge the loss
Many people will accept change if the process is transparent, they are involved in the decision, and their losses are acknowledged. Telling folks that you understand the impact of negative decisions and expressing a willingness to work together in the future goes a long way.

7. Over Communicate
Rumors are often worse than the truth. Every Friday I send out a broadcast email to the entire organization explaining issues, good news, bad news, and future plans.

6. Be Honest and Consistent
I work hard to tell all stakeholders the same message. If everyone hears the good and bad news consistently, the credibility of IT is enhanced.

5. Consensus is not essential
A vote of 500 to 1 is not a tie. If governance works objectively, even politically powerful stakeholders cannot veto prioritization decisions which are in the best interest of the organization.

4. Embrace conflict
Sometimes the right decisions are the hard or politically challenging ones. By expecting conflict every day, the CIO can make decisions more dispassionately. My training as an emergency physician prepared me to approach every situation with balanced emotions. Eliminating caffeine 5 years ago helped too.

3. Focus on your detractors
Sometimes organizations can be 1000 points of veto. By focusing on those who oppose projects instead of those which support them, I can use my time most effectively. I'd rather meet with my friends, but my day is optimized when I spend the day with my detractors. Sometimes detractors become friends, but at least all detractors understand the rationale for "no" decisions.

2. The last two minutes of the meeting are the most important
It's very common for politically challenging meetings to end with differing opinions as to what was discussed. Using the last two minutes of the meeting to review all the decisions made and next steps, then memorializing that conversation in written minutes, enhances the communication of "no"

1. You cannot please everyone
I accept that the good of the many outweighs the needs of the few, even if I have to be the "no" guy.

4 comments:

Unknown said...

Great post!

Saying no is often the hardest thing to do. Undoubtedly you have tons of requests, vendors knocking at your door, Physicians requesting specialized software or products, so on and so on.

I'm surprised you use an in house developed solution like that. What's it based on? What database, SQL?

I keep wanting to type out all my dealings with some vendors and software people. I've told them no, I've gotten what I wanted, the looks on their face when I ditched their contract and cited their inability to be even the least bit flexible.

Telling all those fun stories would take too long and I've got work to be doing.

Again, Great post!

John Halamka said...

Our clinical applications are written in Intersystems Cache, a hierarchical database. For decision support with we use clustered SQL2005 databases. For ERP we use Oracle 10g.

Anonymous said...

Phew, so far, he hasn't taken me out to lunch . . .

:))

Amudha said...

Nice article....