When Facts Are Not Enough – 10 Tips for Communicating to a Non-Technical Audience

Project managers and technologists (geeks) are detail-oriented folks with a precise way of describing things, especially when those “things” are requirements or product descriptions. However, other people may be less interested in absolute truth and more interested in generally correct information. When a project manager talks with customers, potential customers, executives or project stakeholders, finding the right level of detail and “representation schema” (mental model) can be challenging.

As I was thinking about this partial failure to communicate that reflects different world-views, I thought way back to the U.S. Justice Department hearing with Bill Gates talking about Internet Explorer. Yes, some of us watched this while we used our Netscape browsers.  Now, I know these were adversarial proceedings, but I think the example of crossed communication wires is a good one. If you want to read the entire transcript – although I can’t imagine why – the Washington Post has it archived. Here is an excerpt with line numbers and some text removed:

Q. … tell me if you think there is anything in here (the definition of Microsoft’s web browser) that is inaccurate. The full entry of Internet Explorer reads as follows:  “Microsoft’s Web browser introduced in October, 1995….”
A. Well, certainly the product we shipped that was before October, 1995 was Windows 95. The browsing functionality we had in it we’ve updated quite a bit several times. And so defining Internet Explorer to be what we shipped just on one particular date can’t be considered accurate. You have to say that many times we’ve taken the browsing functionality in Windows, which we refer to as Internet Explorer, and we’ve updated that functionality. So you can’t really pin the definition to a particular date. It’s really a brand name we use for those technologies.
Q. Was this definition accurate in 1997 when Microsoft’s computer dictionary was sold to the public?
A. I already told you that reference to October 1995 certainly makes the definition inaccurate.
Q. Apart from that, is it accurate?
A. It’s not accurate to say that Internet Explorer is defined at a single point in time, that it’s one set of bits because it’s a brand that we have used for a set of technologies that have evolved over time. And in that sense I would take exception…

To say this communication was not going to end well is an understatement. Do you have conversations like this?  In the words of Dianna Booher, “ You need communication, not just information.”

When your job as project manager requires answering questions, providing understandable information and persuading listeners to make decisions certain ways, what can you do to help your case?

  1. Define your terms in the beginning. This includes explaining technical words and parts of the solution space e.g., “When I say ‘user’, I mean the person entering data into the software interface. When I use the term ‘customer’, I mean those using the software to get information about products.”
  2. Use examples in addition to data. Here is part of a product description for Albireo™ High Performance Data Optimization Software that tells the audience that it, “delivers ingest performance of 5.9 GB/sec/core with linear performance scale-out as additional CPUs.” You would probably lose some folks with this product benefit statement. Instead, tell the audience what impact a feature makes to them and their experience with your product.   
  3. Tell stories or use testimonials. People form opinions and make decisions for many reasons, not all of which are rational. Decisions can be influenced significantly by what they know like themselves have done before. If you do not believe me, check out Dan Ariely’s interesting book, Predictably Irrational, Revised and Expanded Edition: The Hidden Forces That Shape Our Decisions.
  4. Have someone not directly involved in your project sit through a dry run of your presentation. Ask them what they think you said.
  5. Answer why questions without requiring them to be asked. Tell your audience the reason that a piece of data or decision is important in terms of cost, performance or ease of use.
  6. Give a little education about issues and prior decisions before beginning your presentation. Make your audience feel smarter about the problem and the solution.
  7. When customers, users or clients ask questions, make sure you understand the context or meaning the answer has for them.
  8. Do not provide too much detail. Many people lose the point if it is buried beneath a shower of numbers. However, have the data as backup, if you receive questions about your conclusions or recommendations.
  9. Sound bites are not all bad.  Even though politicians have given this phrase a bad name – the technique is designed to make a memory or impression in the listener’s mind.
  10. Practice humility. Do not try to come off as a “better than you are because I know this stuff” person.

If you have some effective techniques for communicating technical information to a non-technical audience, please share.

Tips for engaging and keeping the interest of project sponsors

The project manager’s job of selling a concept or product does not end with the kick-off party. Throughout the life of a project, it is essential to keep the flames of interest and commitment burning in the minds project sponsors. And, that’s a challenge.

Software, in its development stage, is ethereal and vague.  Hours of work are performed to create designs, write code, and build use cases. However, much of that effort is not tangible. The sponsor cannot see or touch the software and must take it on faith that something worthwhile is being done with his money. Building that trust is the job of the project manager.

In the current technology and software industry there are several new “methodologies” that have been introduced to help with the “buy-in” from sponsors and clients.  You should have heard of agile, extreme and Scrum techniques and if you have been around for a while (like certain unnamed people), you have utilized spiral engineering, rapid prototyping, and rapid application development (RAD).  All of these methods and techniques have a common goal of either reducing the scope and/or the timeframe for the individual project or cycle.  While these approaches have proven to make it easier to get the sponsor/ client to participate, they will not do the job all by themselves.  There are still basic techniques and tactics that should be employed by the PM to assure sponsor, stakeholder, or client commitment and buy-in.

So to ensure project sponsors remain interested and committed the project manager needs to do more than provide weekly or monthly progress reports. They need to keep the end result—the vision—alive. Here are a few of the techniques I have found to be helpful in maintaining sponsor’s interest:

  • Context: in status meetings and progress reports show how accomplishments tie back to a function or capability required of the end product. For example don’t just say, “We completed the algorithm for buffer allocation”.  Explain that buffering impacts how quickly processing moves through the system, what trade-offs needed to be made to optimize buffering, and the advantages to the client of the approach taken.
  • Involvement: offer opportunities and encourage participation in team meetings. Give the client or his representative the experience of watching the team wrestle with options and make decisions.  If the sponsor’s representative is technically knowledgeable, ask for their feedback and encourage their participation.
  • Acknowledge expertise: the client or his/her representative has expertise about the effect of the end product on their business. Solicit that feedback and then show how the input from the customer is reflected in the resulting design and product. “You requested the ability to edit the output before it is incorporated into the report, here is how we are providing that capability.”
  • No surprises: there are many good reasons that as the detailed design emerges from top level design, there are changes. You may add a feature, delay a capability, or implement the movement of data in a different way. A task may take longer to complete than initially estimated or the world itself changes. The golden rule for keeping sponsors from losing interest or “going ballistic” is No Surprises! Tell the client as changes are being considered and why. Do not force the customer to find it out for themselves.
  • Communicate often: you do not have to wait for the weekly or monthly report to communicate with the customer. Use informal conversations or email to share (briefly) relevant information about the project or the team.
  • Show – don’t just tell: there are enormous advantages to showing the customer or sponsor the project as it matures. Design your schedule and your modules so that there are many opportunities to demonstrate— such as showing the user interface in pictures, prototypes or use cases; providing example or test cases using input and output of various modules, or showing the integration of the output of one function into the processing of another.

Gaining and maintaining sponsor interest and buy-in is essential to a successful project – no matter which software development method or life cycle is used. I have seen projects that corporate management was ready to slash until the sponsor came in to support the effort. I have also worked with follow-on projects that resulted because the sponsor / customer felt like part of the team and was personally invested in the outcome. And, I have seen projects die a slow and painful death because the sponsor lost interest and everyone involved was going through the motions of fulfilling the minimal contract requirements with no joy or anticipation of the resulting software.

So what is your experience?  Are you now being asked to use agile or Scrum in order to get better sponsor / client engagement?  Is that all it takes? Or do you think the PM needs to do some of thebasic techniques I have described in addition to one of these new methods?

Please leave your comments….

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts


Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another WordPress.com site