Skipping Shortcuts: Convincing Clients to Take the Better Path

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.