What do you mean by “communicate?”

Project management tools are amazing. Not only can they tell you the status of your project, but they also produce numerous spiffy charts and colorful graphs that you can paste into the PowerPoint report you are preparing for that senior user management presentation you need to give. You are sure you will dazzle them with your RACI matrix (responsibility assignment matrix) and knock them off their feet with your Pareto Diagram (look it up). 

Imagine your surprise when senior managers are not impressed. Hours spent color coding the work-breakdown structure wasted on an audience that does not appreciate the nuances of project management. To be fair, you might be bored at one of their presentations on RAROC (risk-adjusted return on capital), DSCR (debt service coverage ratio), or EBITDA (earnings before interest, taxes, depreciation, and amortization).

The reality is that each specialty has its own language, methods, and measurements that are often understandable only to the properly initiated. It makes sense, you would not trust your favorite Japanese chef to fly your plane or the pilot to prepare your fugu dinner. 

Worse, you might think that hearing all of that unintelligible-to-senior-user-management-geeky-jargon would make them realize that true IT experts are running their project. Not the case. You would probably be more effective reporting project progress through interpretative dance. Many senior managers consider jargon (at least not their jargon) a smokescreen hiding something you do not want them to know.

To effectively communicate, project managers need to see IT and the systems development process from the perspective of the user. Many users, including corporate senior management, do not understand what IT staff do and why they do what they do. They have a decent understanding of hardware—you need to buy it, you need to maintain it, you need to replace it. However, software and networks are seemingly unfathomable mysteries. You can see a computer; you can touch it; it has a physical presence, it is real. Software? It is intangible—who has ever seen it or touched it? It is not physical, so why do you need to fix something that is not physical—how can the non-physical break? Why does IT have people who dress like hippies (honest, who wears sandals in the winter?), smell like the homeless, (this is them talking, not me!), keep bizarre hours, and talk in a language unknown to anyone on this side of the Shire? And the costs! Why does something not real cost so much and take so long to develop?

They have a good point (except for the smell thing). They are competent and accomplished senior managers who know how to run their business. They might be experts in their respective fields, quoted in the Wall Street Journal or interviewed on CNBC. For them, IT is a very costly wizard shop of very expensive staff doing…who knows what. This uncertainty leads to many unanswered questions. Are the company’s IT people “the good ones” or are they the dregs of the profession? Are they working hard or treating the job like summer vacation? Are all those dollars spent on things the company really needs, and what is the deal with the pizza delivery bills? They simply don’t know.

It must be very uncomfortable for people who pride themselves of knowing exactly what is going on in their business to need IT to run critical parts of that business, to have it cost so much, to be overseen by such strange people, and to know so little about it. 

Yet, the need is mutual and symbiotic. IT needs the business just as much, if not more, than the business needs IT. Organizations have survived without IT, but no IT shop can survive without an organization behind it and willing to write all those checks. Therefore, it is incumbent on IT staff to adequately explain to business executives exactly why they are doing what they are doing, why it takes so long, and why it costs so much. IT staff who fail to learn this lesson might find themselves facing the Big-O (outsourcing), replacing them with consulting staff trained in business speak.

If you, the project manager, can’t present that RACI matrix and don’t know what RAROC is, then you have to do something else. You have to ask yourself, what does senior management want to learn from a meeting with the development team? What is it that will make them come away feeling that those in charge of their project know what they are doing and are working in the best interests of the company?

Hundreds of projects, thousands of project status meetings, and more than enough experience doing the wrong things, has taught successful project managers that, when all the dust has settled, management wants to know three things.

1. Is the project on schedule? Will the project end when is supposed to end?
2. Is the project on budget? Will the project cost what it was projected to cost?
3. Will it work? Will the system do what it was promised to do—features and quality?

Anything else is either gilding the lily or obfuscation. 

The challenge for the project manager is to adequately answer these three questions.

Less is More. Have you ever been to a really good PowerPoint presentation? Have you ever been to a really bad one? Content aside, one of the big differences between the good and the bad is the slide-to-minute ratio. 

Bad presentations contain a large number of slides in a short period of time. If your 30-minute presentation contains thirty slides (slide-to-minute ratio of 1:1) then the odds are high that few people will come away with a good picture of the project and/or a good impression of the presenter. The truly good presenters have a higher than 1:5 slide-to-minute ratio. Why? Because bad presenters get it backwards. They think that the presentation is the slides while their comments are the background. The truth is just the opposite. The primary means of communication at the meeting is the presenter speaking. The slides just underscore some of what is said. The successful presenter, and the successful project manager, must hobble together, not a series of charts and graphs, but a story—a story of how the project is doing. People remember stories—nobody remembers graphs. There is no greater take-away from this section than…

Project Management Review Rule One: A good presentation contains a good story that the audience can take with them when they leave. 

With this is mind, let’s look at the three senior management questions.

Is the Project on Schedule? Schedules are tricky. For senior management, some projects schedules are very important, while for others they are the least important answer to the three senior management questions (cost, time, and functionality). The difference is when the system is needed and the impact it has on the organization. For example, The Hershey Company, the chocolate manufacturer, required that IT have its new business-critical systems installed before the busy Halloween and Christmas seasons (when most orders are placed). Project schedule slippage (read the sidebar) caused mountains of unfilled orders and put the very existence of the company is jeopardy.

The best advice for any meeting with senior management is to know before you go. If schedules are non-critical to the user, then the project manager of a late project will probably get a pass. If, on the other hand, they are critical to the business, then considerable pre-presentation preparation, including possibly replanning, is needed. If the project manager doesn’t already know the importance of schedules to the user, the project champion (See “Projects, Politics, and Champions,” SD Times, March 2022) probably does. 

If the project manager is unsure of the business users’ tolerance for project lateness, then some pre-presentation homework is needed. The project manager should schedule interviews with a senior business manager or two to learn their allowance for lateness. Work on one or more possible solutions to the scheduling problem before the meeting—don’t show up without some options for remediating the problem. However, don’t postpone a meeting to avoid giving bad news. If there is bad news, it needs to come from the project manager and the sooner the better. Having management learn about it elsewhere can turn a bad situation into a disaster.

Project Management Review Rule Two: Do not present a problem without an accompanying well thought out solution.

This is a good place to learn a lesson from lawyers—no really. Every lawyer will tell you that they never ask a question of a witness in court when they do not already know the answer. They want no courtroom surprises. Likewise, a project manager should strive to have no surprises at a senior management presentation. Vet everything possible before the big event.

Is the Project on Budget? Budgets can generate the most noise but are often the least critical of the three management questions. Budgets are what senior managers understand the best; after all, they have spent careers crafting them, enforcing them, and learning how to get around them. They can manipulate a budget faster than a politician can change positions. Their adherence to a budget can be fanatical while, at the same time, they can be eminently practical. If the project is needed for the business, e.g., if it will “kill more than it eats” (business speak for “generate more revenue than it costs”), then spending more than anticipated will be approved. Oh, there might be some public castigation of the project manager, but most of that will be for show. If the project is needed, then it will be funded. The project manager just has to utter some public mea culpas, and all will be right.

If the project is considered anywhere between unneeded and frivolous, then the situation is entirely different. An overbudget report is often the catalyst to kill the unwanted or undervalued. This is not an entirely bad situation. Cancelling unneeded projects frees up scarce resources for more valuable work. It can, however, be a blot on the project manager’s career, though some perceptive and resourceful project managers have turned the tables to their advantage by being the one who recommends that, “for the good of the company,” the project should be cancelled.

An awkward budget meeting can point out one important reality of senior management thinking. Both project management tools and project managers themselves tend to focus on actuals (schedule actuals, actual spend, tasks completed), while senior managers are more interested in projections (what will happen when and what will it cost?). Spend more resources and time on when things will happen rather than when things did happen, what costs are ahead rather than what was spent, and what features are being developed rather than what was developed. For example, if you are a nickel overbudget then you need to be prepared to explain the impact it will have on projected costs.

Project Management Review Rule Three: Traditionally, project management reviews focus on the past (work accomplished, milestones achieved, spend so far), but what management really wants to know is the future (when will it finish?, what will it cost?, what am I getting when all is done?). 

Just ensure that focusing on the future is not perceived by senior managers as masking past failures.

Will it Work? This is by far the most important of the three senior management questions but often the least discussed at project review meetings (where the focus tends to be on numerical issued such as schedules and budgets) and the most difficult to answer for two reasons. First, there are so many questions to answer. Functional failure can be caused by a lack of analysis, or programing that does not adequately do what is needed, or the architecture cannot support the production environment (platform, data volume, transaction volume, etc.). The list goes on and on. When reporting on budget and schedule progress, the project manager has many numerical and presumably objective measures; however, there are few mathematical crutches when reporting on feature progress. Progress on the functionality landscape is highly subjective. 

This is where iterative and incremental (I-I) development approaches, such as rapid application development, prototyping, extreme programming, and agile development, etc. come into play. By having user staff intimately involved in the project, providing insight and reviewing work accomplished, senior business management has the input of their own staff regarding the progress and quality of the system so far. There is an added benefit. If user staff assigned to the project are excluded from the preparation and presentation of the project review, then they might take on a more adversarial position, searching for project flaws rather than extolling its virtues. On the other hand, if user staff are charged with reviewing and presenting functional progress at the management meeting, then their inclinations will be more toward supporting the project rather than criticizing it. Many a project manager has suffered a self-inflicted wound by minimizing the role of user project staff. The wise project manager uses business staff assigned to the project as ambassadors to the user community.

Lastly, do not stand up at a senior management meeting and toss a project management hand grenade—giving senior managers bad news cold. Short of announcing at a senior management project review that you won the lottery and are quitting your job immediately, surprises are not a good idea. Moderate less than good news is OK, but senior executives hearing for the first time that the project will not deliver 50 percent of its promised functionality is not. Bad news, particularly about functionality, needs to be pre-sold, ideally with one-on-one meetings with selected senior managers. This is also the time to use your project champion to pour oil on the troubled waters. But do not dawdle. Bad news is like dead fish—it does not get better with age. Too many project managers procrastinate about giving bad news, but as awkward as it is for senior managers to hear about problems from the project manager, it is far worse if they hear about them first from someone else. Any credibility you had will be lost.

Project Management Review Rule Four: Never wait for a formal management meeting to present bad news. Always pre-sell bad news to the project champion or at least one or two senior managers before the meeting. No surprises.

Salty old project managers are awash with tales of presenting terrible news at a senior management meeting and getting no reaction, while getting skewered on something the project managers considered trivial. You never know what will pass without a sigh and what will cause a brouhaha. When in doubt, pre-sell.

Managing the Managers. Like it or not, a project manager needs to manage up as well as down. The project manager techniques that are so successful in managing subordinates are rarely the same techniques needed to manager superiors. Techniques and styles that work so well with programmers might be the absolute wrong thing to apply to user supervisors. The successful project manager has a separate tool kit for each constituency and the number one tool in the manage-up kit is communication (See “Half of Managing is Selling,” SD Times, November 2020). A good project manager uses every opportunity in front of senior staff to sell their project, its benefits, its team, and its project manager. Anything else is shortchanging the project and the user.