Did you ever stay up late watching infomercials on TV? Remember the salesman selling that stainless-steel turnip slicer-yogurt steamer, “And if you act now….” He must have been talking more than 200 words a minute. Three A.M., a crummy set behind him, a questionable item that might fall apart faster than its overnight delivery, and it most likely made him a fortune. Why? Because, corny as it sounds, he was probably a good salesman.
Now imagine your best systems programmer in the same job. You might have the one programmer who would do well, but many coders would have difficulty selling ice in the desert. What’s worse, they would probably be miserable doing it. The fact is most IT people have neither great selling skills nor the inclination to acquire them.
That’s not the bad news. Here is the bad news. All managers—business, IT, and project—if they are to be successful—are salespeople. If you are a project manager, then one of your jobs is to sell your project. The initial proposal meeting—it’s a selling situation. The kickoff meeting—it’s a selling situation. The progress review—it’s a selling situation.
So, what’s a reserved project manager to do? The successful salesperson needs to know a lot about his/her client, which, it turns out, is the first of five tasks the project manager/salesperson needs to perform.
ONE: UNDERSTAND THE CLIENT. To successfully sell the project, managers need to know their client and what that client is likely to buy.
Identify the Clients and Stakeholders. For the average project, IT’s clients are certainly business user management and IT management, although clients, sometimes called stakeholders, can also include others such as employees (for a payroll system), the government (tax systems), and external customers (customer service).
Who Are the Project Stakeholders? There is an old tale about the pet supply company that introduced a new premium dog food. Despite its upscale image, sales were miserable, so the company hired a topnotch marketing consultant to help them. The company executives explained to the consultant that they conducted an extensive advertising campaign, ran nationwide store promotions, and even went as far as to gain celebrity endorsements, but the dog food still did not sell. The consultant then asked a single question, “But do the dogs like it?” The stunned executives looked at one another for anyone who had an answer. None did.
Not all stakeholders have a seat at the management table (for example, customer service reps), but they may have proxies (such as an employee union) whose interests need to be represented and understood.
Understand Client and Stakeholder Goals. Why is the user willing to spend good money on this project? Does the project need to be completed before a certain date (Christmas selling period or next tax year, for example)? There are issues that might not be publicly known but that the project manager needs to know.
Know What Clients and Stakeholders Expect From Project Management. What do users and IT management expect from the project and the project manager? You would think this would be obvious, but you will be surprised to learn that user management, even IT management, can harbor diverse expectations. Even though they all want a functional system, on time, and on budget, they might not all share the same priorities. User management might be more concerned with cost and least concerned with schedules, while IT management, mindful of its project backlog, is more concerned with schedules. Understanding clients’ priorities can be complicated and tricky, but it is essential for a successful project.
TWO: PRE-SELL ALL MAJOR IDEAS. In a fair world, the project manager would be showered with accolades for successes and flogged for failures. Unfortunately, sometimes the clients get it backward. The complexity of the project plan, arcane technology, and bizarre terminology can lead even the most fair-minded business executive to the wrong conclusion. Whether a project manager is to be praised or eviscerated at a review is not always obvious ahead of time. Sometimes a small incident or misunderstood progress is enough to land a project manager in hot water.
Pre-selling is having one or more informal one-on-one meetings with critical executives to discuss the meeting’s topics before the formal review session. The purpose is threefold. First, the project manager wants to inform senior management of the issues to be discussed, ensure that they are understood, and correct any misconceptions before the formal meeting.
Second, the pre-selling meeting can be used to gauge senior management’s reaction to the meeting issues. This gives the project manager a heads-up on whether executives are likely to be amiable, displeased, or even hostile to issues that are scheduled to be raised at the meeting. The project manager can then prepare a presentation targeted to the expected response.
A third advantage of pre-selling is the opportunity for the project manager to correct or mitigate issues upsetting to user management before the review meeting. Sometimes a quick fix can change a career-limiting situation into advancement.
THREE: BE PREPARED. It is amazing how many project managers go into senior review meetings unprepared.
Formal Presentations. The formal project review is the primary venue for selling the project. Many project managers go into a meeting thinking that the presentation is the slides and that they only provide background and commentary. They have it backward. The primary means of communication is the presenter speaking. The slides only provide background information and underscore some of what is said. The successful presentation is not defined by a series of charts and graphs, but rather by the story the presenter tells. The story includes what has been completed, what remains to be done, and any issues or implications going forward. It should be an informative sales pitch— not fluff, not feathers—but hard facts that are relevant to the audience. The best stories include a message that everyone present takes away with them.
Informal Meetings. Every project manager should meet informally with every important stakeholder. For some stakeholders, one or two meetings during the entire project are sufficient. Others might want the project manager to meet more frequently. Each stakeholder has his or her own interests and concerns and might even be disinterested in other project issues to the point of rudeness (talk bits and bauds to the CFO, and the meeting might turn hostile).
Many project managers have less success with informal stakeholder meetings than with formal ones. The reason: lack of structure. Most formal meetings follow a formula: reserve a conference room, provide coffee and donuts, present a few PowerPoint slides, ask for questions, muddle through some answers, take the remaining donuts back for the support staff.
Informal meetings can be a minefield of misunderstood protocols, subtexts, and missed opportunities. However, following a few simple rules can help you to avoid being thrown out of executive row.
Prepare to take the lead. A business unit president once complained that the project manager for an important project showed up at her office and apparently thought they were going to chat. The project manager was told not to come back until he had something specific and relevant to talk about.
The solution is to never show up empty handed. One project manager always prepared three PowerPoint pages of project issues that he kept in his briefcase. If the stakeholder had some project issues she wanted to discuss, then the pages never left the briefcase. If the stakeholder had no project issues on her mind, then the project manager brought out the three pages.
Follow the top three/bottom three rule. Projects are often large, and the interests of stakeholders can be arcane. It is easy for a project manager to get stuck with little to say on an important topic. You cannot prepare for everything, you cannot know everything, but you can cheat—well not cheat but rather improve your odds of not looking like an idiot.
Formal meetings tend to focus on facts: accomplishments to date, budget status, issues going forward. Informal meetings tend to be more question and concern focused, with the client or stakeholder asking questions, sometimes at the prodding of the project manager. Questions might be about why the project manager is comfortable with progress or whether he or she needs more resources. Many executives want to ensure that their staff, the business experts associated with the project, are providing what the team needs.
Being prepared for the un-preparable is possible if the project manager limits the subject to the top three/bottom three facts about the three questions management wants to know most about a project.
Question 1. Is the project on schedule? Will the project end when is it supposed to end? The project manager should know or have in her briefcase the top three things that need to happen for the project to finish on time and the bottom three (most probable) reasons it might not.
Question 2. Is the project on budget? Will the project cost what it was projected to cost? The manager should have information on the top three examples of strict budget management as well as the (bottom three) cases of (real or potential) budget overrun.
Question 3. Will it work? Will the system do what it was promised to do—features and quality? The project manager should be able to show or discuss three examples of functional success (top three) but also three cases (bottom three) of (real or potential) functional concerns.
Why should the project manager have examples of project failures in her briefcase ready to share with stakeholders? First, the client might already know. It is a common management technique to ask questions of a subordinate when the superior already knows the answers to test the honesty of the subordinate—a powerful barometer of credibility and trust.
Second, it is better to get the bad news out in the open in a one-on-one meeting, where emotions can flair with minimal consequence, rather than in a more public venue. Both stakeholder and project manager have a more private setting to work out differences and resolve problems.
Why limit examples to the top three and bottom three? Would not the top five or bottom ten be better? The truth is the average project manager’s mind can only hold so much. Knowing three facts shows that the project manager has some mastery of the subject. Knowing six would add little to the meeting while doubling the project manager’s preparation work. And let’s face it; absorbing more than three of anything is beyond the span of attention of many senior executives.
FOUR: USE THE PROJECT CHAMPION OR YOUR MENTOR. A project champion is a senior executive who feels some ownership of a project. The champion might hold an official position with name and job description in the project plan or charter or could be serving based on an informal arrangement solidified behind closed doors. The champion often has the power to influence, if not modify, budgets and project plans and commit organizational resources. The project champion can function both as a project-friendly customer for the project manager and as an excellent salesperson for the project.
Every project manager should have one or more mentors (official or unofficial) who can help him or her navigate senior executive waters. While senior executive mentors might be uninformed on the latest systems development techniques, they are probably pros on selling ideas to business managers and corporate executives.
Use both the champion and the mentor to ensure your message to management is targeted (at what you want to achieve by the meeting), concise, cordial, and frank (the truth). Hone your message by running your presentation past them in a safe and supportive environment.
FIVE: MANAGE EXPECTATIONS. This fifth task—manage expectations—is the most important of the five and the one that comes the closest to encapsulating the other four.
An expectation is an anticipation or mental image of something that will happen sometime in the future. In systems development, users have an expectation of what the application they are paying for will do when installed. Of the three project planning variables (cost, time, and functionality), the one that most commonly involves expectation problems is functionality or features. The user believes that the system will do X, but instead it does Y. When systems development expectations get out of whack, it is usually not the person with the strange expectations who suffers the consequences, but IT.
Expectations commonly go awry for one of two reasons:
The user is unsure or unaware of the details. Confusion often exists about what the system will actually do (its functionality) when complete.
Expectations stray over time and can grow between their first inception and their reality. Like the guy who buys a Ford Focus, but by delivery time expects a BMW, there are senior executives who want to limit costs and development time during the project funding cycle but, forget their frugality by project end. They are amazed to find that features, discarded as too costly during planning, are missing from the final system.
What’s so insidious about expectation disease is that users are absolutely positive they are right. They firmly believe they told IT exactly what they wanted, and IT, owing to its tradition of underserving or its devious nature, has purposely ignored their requests and sabotaged the system.
If you have not experienced this response, then you might find it hard to believe, but it is a real problem. Ask around. You will find someone in your organization who has experienced this horror show first hand.
There is a solution to this problem that is also the poster child for this article—manage expectations. Managing expectations means providing near continual, honest, and unvarnished feedback to the user. Three simple rules apply.
First, be clear about what the system will do. (1) During project planning, create a small summary document (one page would be ideal) specifying what the system WILL and, more important, what it WILL NOT do. Make sure the user signs off on this document. (2) Keep this document in your briefcase and bring it to ALL meetings with a user, but only use it if you have to.
Second, focus on the progress IT has made in building the system. (1) Make sure that progress reviews are user friendly and geared to the three issues that concern users (cost, time, and functionality). (2) Be honest—you’re probably not a good enough liar to snow senior executives.
Third, state exactly what IT and users need to do to successfully complete the project. (1) Lay out exactly what you will be doing between now and the next user meeting and any issues you think may arise. (2) If you need anything from the user (staff, cooperation, funds, etc.), this is the time to ask for it.
The takeaways for being a great project manager are simple:
- Recognize that all managers—business, IT, and project—if they are to be successful, are salespeople.
- The project manager needs to know who his or her clients are and what they expect from the project team.
- The key to selling success is constant, honest, and informative communication with the user and managing their expectations. Without constant feedback, expectations can go awry.
George Tillmann is a retired programmer, analyst, systems and programming manager. This article is excerpted from his book ‘Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes‘ (Stockbridge Press, 2019).
