Your clients may not understand why you follow certain practices as a project professional. They may encourage you to take shortcuts that they believe will save time, money, and difficulty. You know better, but how can you convince them?
Doing things the right way make sense, right?
It's like learning a new piece of software. We may hesitate to watch a YouTube video about a new, unfamiliar software product due to "time constraints." Or, we may avoid the product demo for the same reason or because we don’t want to get into a long question-and-answer session with a sales representative. Or, we may avoid reading software guides because we're smart and can "just figure it out"—sort of like not wanting to stop and ask for directions when you're lost.
Does any of this sound familiar? I have been guilty of all of these things (including not stopping to ask for directions) and, often, I realized only later that they were bad ideas. What seemed to be a shortcut wasn’t really a shortcut at all. It frustrated me, took more of my time than it should have, and left me less prepared and functional than I would have been had I taken the proper amount of time to learn up front. In some cases, the "shortcut" took so much time that I abandoned the new product altogether because I no longer had the time to figure it out.
If any of these situations applies to you as a project professional, then you probably understand where your project clients are coming from if they fail to see value in certain practices you're trying to implement on the projects you’re leading for them. They may not see the value in a detailed status report. They may not understand why it's important to spend three weeks (in their eyes, three expensive weeks) hammering out good, detailed requirements when they can tell you what they want in thirty minutes.
They may not understand your urge to interview subject matter experts (SMEs) and end-users in their organization—again, all of which costs them time and money—when they’ve already come to you with the problem that they believe should tell you everything you need to know. And, the very mention of change requests may have them on the phone trying to contact another delivery organization because they think you’re out to get them. A simple weekly email can replace weekly status calls, right? Um … no.
But, how do you convince the stubborn (and potentially "cheap") project client that these are critical practices that will likely save them money, time, and heartache in the long run? You've been through this before, but maybe they haven't. What’s your approach?
Let's look at a few of these typical client push backs and discuss how to approach each in a way that will help your clients understand the importance of planning, thorough documentation, formal signoff, and frequent and thorough communication.
Thorough Requirements Definition
One of the hardest things to get the client to understand is the need for thorough, up-front—and often extensive and time-consuming—requirements analysis and documentation. Project sponsors often think they’re coming into the engagement fully equipped with detailed (or, at least detailed enough) requirements. They hand these requirements to your team, and you create a solution, right?
The problem is that, at least sometimes, you're really being handed a symptom instead of the real problem. And, you're likely being handed high- to mid-level requirements, not the detailed requirements that relate to real business process and that will truly matter as you’re developing the solution. That's why you must engage more than just the project sponsor. Future system end-users, the organization SMEs, and the business process owners must be engaged in the requirements definition phase so that the issue, problem, or project is fully understood and defined and so that requirements are detailed enough to create a useable end solution from.
How do you convince your project client of this? The best way is to explain what late-project rework can mean in terms of time and money compared to taking an extra two to three weeks now to plan out the scope and requirements of the project and to get a formal agreement on those requirements. Examples of past project issues may help your clients better understand that this is in their best interest.
Status Reporting, Status Calls, and Project-schedule Tracking
What about the clients who aren’t interested in what they consider to be “time-wasting” weekly status calls and the “busy work” of reviewing status reports and weekly project-schedule revisions. These project clients are rare, but they exist. They just don’t want to be bothered, and they may not see the need for paying a project manager to spend so much time on these items.
When this happens, I do two things:
First, I explain that it's critical on my side to perform these tasks so that my team can work efficiently—and, therefore, less expensively—on the clients’ solutions because the team will know the project status and what they’re responsible for, and they’ll assume more ownership of the tasks. Plus, it's best that clients know where things stand so they can hold my team and me accountable. Then, I slip in several tasks that the clients have to be accountable for so they remain engaged and see value in these processes.
Second, I make sure that I only include what is absolutely necessary in the status report, what we discuss on the call, and what I filter out to the clients in a project schedule update. Keeping it simple helps them to better understand what I’m giving them.
Risk Planning
Many clients want nothing to do with risk planning because they think it's a waste of time. Why spend a few sessions discussing things that haven’t happened and may not happen?
To show value to clients, I make sure they're involved in identifying and planning for risks whenever possible. I ask them a lot of questions, because many of the risks will involve business processes in their organizations that can greatly affect the outcome of the project and the functionality of the solution I deliver to them.
Show your clients that by fully understanding the needs and the potential issues in their organizations now, your team can avoid expensive and time-consuming rework later on.
Doing things the right way make sense, right?
It's like learning a new piece of software. We may hesitate to watch a YouTube video about a new, unfamiliar software product due to "time constraints." Or, we may avoid the product demo for the same reason or because we don’t want to get into a long question-and-answer session with a sales representative. Or, we may avoid reading software guides because we're smart and can "just figure it out"—sort of like not wanting to stop and ask for directions when you're lost.
Does any of this sound familiar? I have been guilty of all of these things (including not stopping to ask for directions) and, often, I realized only later that they were bad ideas. What seemed to be a shortcut wasn’t really a shortcut at all. It frustrated me, took more of my time than it should have, and left me less prepared and functional than I would have been had I taken the proper amount of time to learn up front. In some cases, the "shortcut" took so much time that I abandoned the new product altogether because I no longer had the time to figure it out.
If any of these situations applies to you as a project professional, then you probably understand where your project clients are coming from if they fail to see value in certain practices you're trying to implement on the projects you’re leading for them. They may not see the value in a detailed status report. They may not understand why it's important to spend three weeks (in their eyes, three expensive weeks) hammering out good, detailed requirements when they can tell you what they want in thirty minutes.
They may not understand your urge to interview subject matter experts (SMEs) and end-users in their organization—again, all of which costs them time and money—when they’ve already come to you with the problem that they believe should tell you everything you need to know. And, the very mention of change requests may have them on the phone trying to contact another delivery organization because they think you’re out to get them. A simple weekly email can replace weekly status calls, right? Um … no.
But, how do you convince the stubborn (and potentially "cheap") project client that these are critical practices that will likely save them money, time, and heartache in the long run? You've been through this before, but maybe they haven't. What’s your approach?
Let's look at a few of these typical client push backs and discuss how to approach each in a way that will help your clients understand the importance of planning, thorough documentation, formal signoff, and frequent and thorough communication.
Thorough Requirements Definition
One of the hardest things to get the client to understand is the need for thorough, up-front—and often extensive and time-consuming—requirements analysis and documentation. Project sponsors often think they’re coming into the engagement fully equipped with detailed (or, at least detailed enough) requirements. They hand these requirements to your team, and you create a solution, right?
The problem is that, at least sometimes, you're really being handed a symptom instead of the real problem. And, you're likely being handed high- to mid-level requirements, not the detailed requirements that relate to real business process and that will truly matter as you’re developing the solution. That's why you must engage more than just the project sponsor. Future system end-users, the organization SMEs, and the business process owners must be engaged in the requirements definition phase so that the issue, problem, or project is fully understood and defined and so that requirements are detailed enough to create a useable end solution from.
How do you convince your project client of this? The best way is to explain what late-project rework can mean in terms of time and money compared to taking an extra two to three weeks now to plan out the scope and requirements of the project and to get a formal agreement on those requirements. Examples of past project issues may help your clients better understand that this is in their best interest.
Status Reporting, Status Calls, and Project-schedule Tracking
What about the clients who aren’t interested in what they consider to be “time-wasting” weekly status calls and the “busy work” of reviewing status reports and weekly project-schedule revisions. These project clients are rare, but they exist. They just don’t want to be bothered, and they may not see the need for paying a project manager to spend so much time on these items.
When this happens, I do two things:
First, I explain that it's critical on my side to perform these tasks so that my team can work efficiently—and, therefore, less expensively—on the clients’ solutions because the team will know the project status and what they’re responsible for, and they’ll assume more ownership of the tasks. Plus, it's best that clients know where things stand so they can hold my team and me accountable. Then, I slip in several tasks that the clients have to be accountable for so they remain engaged and see value in these processes.
Second, I make sure that I only include what is absolutely necessary in the status report, what we discuss on the call, and what I filter out to the clients in a project schedule update. Keeping it simple helps them to better understand what I’m giving them.
Risk Planning
Many clients want nothing to do with risk planning because they think it's a waste of time. Why spend a few sessions discussing things that haven’t happened and may not happen?
To show value to clients, I make sure they're involved in identifying and planning for risks whenever possible. I ask them a lot of questions, because many of the risks will involve business processes in their organizations that can greatly affect the outcome of the project and the functionality of the solution I deliver to them.
Show your clients that by fully understanding the needs and the potential issues in their organizations now, your team can avoid expensive and time-consuming rework later on.
RSS Feed
