In a recent post on Thinking Faster, Phillips expresses concern about the apparent propensity for project sponsors to skim over the details and jump to quick answers. He’s talking about [what I believe is] a peer relationship, when external expertise is brought in to develop the solution that they (the sponsors) are responsible for “owning” (vision, design, execution, and ongoing support). I’ve seen the same sort of thing in multiple organizations, especially when talking with executives about projects and initiatives that they are championing. It’s a slightly different scenario than described in Jeffery’s post – reporting status “up the chain” versus “to the customer” – but multiple nuances of “don’t bother me with the details” come into play just the same. My only suggestion to Jeffery would be to exercise a little empathy and adjust the message. Management needs to understand the details in spite of their objections or shortcuts; the trick is to understand what’s behind this drive for the quick answer, and adjust the communication accordingly.
Fractal Attention Span
Challenge: People typically work on 7-10 major items at any one time; that’s about as many as the brain can comfortably prioritize for chunks of their attention. Unfortunately, these to-do items / projects are fractal in nature, easily decomposed into multiple tasks and subtasks. Our prototype CEO needs to deliver increased revenue (3 key accounts in play), reduced costs (2 cost cutting and 3 productivity-enhancing initiatives), while driving down inventory (S&OP, SKU reduction, and supply network optimization projects). Oh yes, there is also a pending lawsuit, product R&D reviews, and the board presentation to develop. The VP of Sales has five territory managers working on different aspects of the three key accounts, and two project managers working on the cost-cutting – in addition to ongoing promotional planning and customer service issues. Sally, the lead project manager on the first cost-cutting project, is working towards a launch date of 15 July, and has 10 open issues with varying degrees of severity.
If I’m the CEO, and I have two hours to complete an Operations Review for the entire company, I have maybe five minutes to listen to Sally tell me about her piece of the VPs piece of one of my 10 hot items; do I really have time to hear about usability issues or the challenges of scheduling acceptance testing? All I really need to hear is the specific objective of the project, current status, maybe the next milestone date, and our current expectations for meeting the stated objective (vs. budget and/or need-by date). Anything else and my eyes will glaze over, because I’ve got 20 other people to get through, backlogs in voicemail and e-mail, two more meetings before the end of the day – and I’d like to get home before midnight.
Mitigation: This environment is hostile to knowledge retention (ie. you risk the CEO spacing out), so you need to focus on the critical information. I (the CEO) need to hear a clear objective, a plan to get there, and an active monitoring process. I don’t care about the options available or the decision process for task 4.2.6.a on your plan – I just need to know you are planning the work and working the plan.
“I don’t believe you” might mean “I don’t understand you”
Challenge: Phillips’ post captures his frustration when project sponsors ignore input on usability and data access. Features and functionality are stressed over the intended audience’s capability and willingness to use what is being built. Experience in creating and implementing software-enabled processes teaches you the impact of a poorly laid out web page, but this is experience that your project sponsor doesn’t have. They assume all software is built consistently (look at Microsoft Word and Excel!), and that Google, Amazon.com, and YouTube are “user-friendly” solely because they’re on the web (web = friendly and easy, right?).
Regardless, your [sample] project sponsor is very aware of one fact; their integrated demand forecasting system, driven from a single database for security, consistency, and speed, does not exist. I want to see project milestones that deliver what doesn’t exist!
Mitigation: First and foremost they are correct. This new system we’re building doesn’t exist – that’s why we’re building it. So if you’re talking to me about work that doesn’t directly deliver the list of requirements, I don’t understand why we are wasting our breath.
Here’s the trick; to save your personal sanity and preserve your credibility, assume good intent. They aren’t saying I don’t believe you – they are saying I don’t understand how this topic relates to my requirements. Of course, you must connect the dots between the need for usability [in this case] and the eventual delivery of the expected benefits. The system is only as good as the quality of the data going in.
This is important – when talking about issues, decisions, or work that needs to be completed, you most always tie back to stated benefits.
Nature Abhors a Vacuum
Challenge: Blithely ignoring the fact that the executive team has many other things on their plate (see above) our intrepid project manager lays out five major issues and three options for each one. I, as CEO, got to where I am by Being Decisive and Making the Call – so if you’re giving me the options, I’m going to start telling you what to do because 1) you’re asking and 2) I need to move on to the next agenda item.
Mitigation: Heed that classic management one-liner – don’t come to me with problems, bring me solutions. We all get paid plenty of money to solve problems, and it really drives execs nuts when all we do is define tough problems – and look to them for guidance. Believe me, most organizations will massively empower you to show some leadership and make your own decisions!
Not to worry – there are many control mechanisms in place to guard against bad decisions, but you need to control the message and flow. When presenting to the execs, don’t lay out options followed by your preferred choice – it sounds too much like you’re asking for their choice, that the project is dead in the water without their decision. A better method is to present your choice as the only way to proceed (this makes sense based on X and Y and Z). At this point, you can do a few quick bullets on the options, subtly giving the executive team an opportunity to ask probing questions and suggest alternatives. Trust me – if they have any issues, they will drill into these options and dissect your rationale. But when they don’t … progress!
The Myth of Executive Omnipotence
Challenge: In many companies, the executive team holds a magical sway. The staff adheres to their every whim; reworking this project “because the CFO said we should”, reprioritizing that project down the list “because the CEO wants it that way”. I love asking the “stupid” questions … like Why does this need rework? What exactly does the CEO want to see as a deliverable from this team?. If you find yourself pondering (hmmm, I’m not sure exactly what he asked for, but he was pretty adamant – so we better deliver)
Mitigation: If your neighbor stops by to borrow a ladder or chat up the Fire game this weekend, you might have no idea that they are a COO or Vice President; she’s just a regular person like you and me. So why would you grant them magical status in a workplace environment? Look, if you don’t understand what they want, just ask for some clarification. You can make the [very safe] assumption that they are good men of business, and will react predictably to a business-based conversation. We had two options; here are the costs, benefits, and risks, and here’s why were going to pick option one. If your assumptions differ from theirs, why can’t you have an open conversation to challenge those assumptions?
Sometimes I think people are too self-conscious; no one wants to appear stupid and ask the General Manager to elaborate on what they’re saying, because they aren’t being very specific or they’re making a logical or factual mistake. This is entirely possible, even probable – they may not understand the implications of what they’re asking for, but since you the project manager, are defining problems not solutions, and since I’ve got 16 other things to do between now and quittin’ time, I’ll just start making decisions. I’ve seen plenty of projects get blown out of proportion and swerve down strange side routes because the executive said something, the team took it to be the One True Way To Go.
- Update them on what they are expecting to hear about
- Keep it to the relevant level of detail
- present solutions to any problems that pop up
- Anticipate some questions …… but don’t offer up the details until asked
- If you failed to write down what they asked for, follow up ASAP… and figure out how to listen better next time!
This Post Has One Comment
[…] This post was mentioned on Twitter by John Tropea and Rich Newbold, Brian Tullis. Brian Tullis said: RT @johnt: Can you, should you, bother Executives with The Details? http://icio.us/o1gg0e […]