It’s lonely at the front of the room.
And it’s quiet. Very quiet. The moment between my introduction, and my short walk to the centre of the stage seems to take minutes, not the mere seconds that have actually elapsed. The very moment I make my mark and utter my first word, I flip the switch from self-conscious, partially-deluded, nobody…to CTO, fast-talking, fully-deluded “expert” of whatever content happens to be on the screen behind me.
I’m not saying it’s an act, I’m saying it’s a significant and dramatic situational personality change, and I’m not really sure I can completely control it. After many years of demonstrating software to literally thousands of people I don’t remember, I’ve evolved this real-time Dr. Paul and Mr. Lewis personality change. My level of objectivity may be skewed, it’s possible that it’s all in my head. Fortunately that’s where all the magic happens anyway.
Over time I have learned a few things about public speaking:
- Saying “and the logical conclusion is” doesn’t make my statement logical or conclusive: I’ve had enough “I beg to differ” audience questions that have corrected that behaviour
- The bigger the audience, the more important the front row becomes. Bigger stages mean more, hotter lights pointed directly at you, and therefore the only people you can see are directly in front of you. Make eye contact with a few of these people to keep the audience included in your interesting monologue
- The smaller the audience, the more of an expectation of dialogue. 5 people requires a sit down conversation, 1000 people requires a 45 minute monologue without questions
- Use misdirection liberally: Put the audience at ease with well-placed visual humour or context specific funny stories. It will grab attention and put everyone at ease throughout the presentation
- Don’t worry, it will end soon: Not all gigs will be homeruns. Be comfortable with singles and doubles, but try to avoid the strikeouts by knowing the content. Presentations don’t last long, and you will get many more chances.
As a technology executive, CIO’s/CTO’s and the like, our ability to communicate effectively extends well beyond public (not internal) speaking. We communicate to motivate and inspire a team to grow and evolve. We communicate to make critical short and long term decisions. We communicate to achieve team consensus, and we communicate to get approval…approval to make significant organizational change, and approval to spend heaps of organizational money. In fact, communicating to spend very limited available cash might be the pivotal capability of a successful technology executive.
It tends to boil down to the least inspiring central figure of project financial decision making…the business case. They exist in varying forms, but tend to boil down to a multi tabbed spreadsheet created by finance, for the purpose of fiduciary compliance, and formatted perfectly for the CFO to compare all projects against a pre-set list of financial metrics. If you are lucky, they provide optional cells to input creative language to justify why your project doesn’t meet the corporate KPAs and why it should be considered by a committee of your peers.
Simply created, but limited creatively, you need to add content and context related to: assumptions (the varying dimensions you based the decisions upon, and “what must be true”); the detailed costs (related to implementing the project including people and technology, upfront and ongoing); the detailed offset (sometimes documented as revenue, or cost savings, or cost avoidance); the calculated project metrics as compared to the corporate thresholds (think IRR, ROI, NPV, etc).
In fairness, the document is the least of your concerns. The presentation to the “Project Steering Committee” (or the like) is where the communication mastery comes into play.
Over time I have learned a few things about publicly defending a business case:
- Saying “and the logical conclusion is” doesn’t make my statement logical or conclusive: Opinion is your enemy in the room (everyone has one, and the potential that they don’t agree with you is high). Be prepared with double-click facts, externally verified and justified by independent and trusted sources. Reference all experts and quote clients, especially ones that are willing to buy. Within a technology business case, the expense line and detail are rarely discussed. As far an everyone is concerned, you know your discipline best, and not likely to under-estimate the effort to implement the project. The revenue (or conversely the potential savings) offset however, will be HIGHLY contentious. Be prepared to be MUCH more conservative relative to what intuitively seems reasonable. By far the most difficult business case to get approved is one without an expense offset. Items like KTLO (keep the lights on) and maintenance (currency projects) will ALWAYS be argued for postponement or cut to bare bones expense. Your best bet is to quantify the RISK impact to the business if they don’t get implemented. Describe in detail what WILL happen if you don’t replace an aging storage platform, especially to the number of clients impacted and the number of staff unable to do their work for an extended period of time.
- The bigger the audience, the more important the front row becomes: More specifically, the more people in the room, the more likely the highest ranking audience members with have the most important opinion. All other members will want to impress the few Sr. Executives (CEO, COO, CFO) with eloquent speeches and grandiose perspectives but will change their “passionate” opinion when the senior executives express their own….so you need to also share that habit. Focus on and convince the key decision makers, thus convincing the room.
- The smaller the audience, the more of an expectation of dialogue: The smaller the committee, the more likely they will have equal power and share in the decision. You best bet is to be prepared with pre-decisions well before the meeting. Review the business case with each member individually prior to the meeting to address concerns, modify for acceptance, and get conditional and informal consensus. The meeting will suddenly become a checkmark 15 minute chat about your love of skipper patter on the Jungle Cruise.
- Use misdirection liberally: The potential is high that even when confronted with facts, some decision makers will disagree with the business case assumptions. They key is misdirection, meaning changing the focus to other assumptions that have a more “impactful” contribution to the PLUS side of a business case and away from that one controversial assumption that “figuratively” have very little impact.
- Don’t worry, it will end soon: Not all business bases will be approved, so only fight for the top 3-5 you REALLY want to implement. Have a few on hand that are “throw away”, or that you are less passionate about implementing. Be comfortable with singles and doubles, but try to avoid the strikeouts by knowing the content.
Your ability to get strategic business cases approved will be the pivotal step on implementing your IT strategy as a whole. Of course the logical conclusion is to ask for help. That’s where we come in.
What are your thoughts on the subject? Feel free to share your perspectives in the “Comment” section.