“If a project planner must at least satisfy the client’s needs for a project to be successful, then the planner needs to know what’s necessary, but how do we determine the client’s wants over their needs in a project?”
As we all know, what a customer wants and needs are often two very different things. It is nothing less of an art form in many different professions to be able to discern what is more important, or in the very least, pick a side in Marshall Field’s motto “the customer is always right.”
In project management, when assigned a project, it is never good enough to leave it at face value and create only what was asked of you. Doing that won’t get you long-term praise, a solid foundation for growth, or even notoriety. To be better, you must determine if the customer wants the wrong deliverable, and then from there, gently lead them in the direction that would better satisfy their constraint. We do this through gathering information on current operations, success factors, core values, and the competitive landscape from the eyes of the customer.
This is easy to say, hard to do, because projects come from a myriad of sources. Projects can originate from daily task lists, strategic planning sessions, enterprise roadmaps, or simply a project request, but no matter the source, the first step is always the same. We need to determine the principle purpose, a list of major objectives/deliverables, standard phases, a timeline expressing due dates, and a project sponsor. It is in this first step of developing the project purpose that the true needs of the customer or the user should be separated from the desires.
To get the conversation underway and start gathering the necessary information, a project manager needs to organize meetings, first with the sponsor, and then with the client. The objective of these meetings is to listen. These are opportunities to refine our understanding of the current situation and the problem that the final deliverable is meant to solve. A strong leader strategically listens for the competitive landscape, core values, success factors, as well as current conditions. This is the information that you need to make the best project plan possible.
This delicate dance can be accomplished by presenting your initial understanding of the principle purpose and objectives. The project objectives are derived from the principle purpose as two to eight key components that the project must deliver or effect to be called a success. Each objective is a category for strategically delivering or achieving the project purpose, and therefore, the final deliverable.
The first meeting with the sponsor is designed to create a consensus before further refinement with the customer. You should present your understanding and then listen to what the sponsor and client says in response. In these meetings, ask questions designated to elicit information as well as repeat the information you have gleaned through the questioning. The deliverable of a project is not change itself, but always ushers in some sort of change to the organization. Obtaining the true project purpose is important, but delicate. Take care not to push too hard.
Any member of a project should want to answer the question, what is necessary to satisfy client’s need for the project? Why do your customers need you? Every organization needs a reason for their customers to buy from them, or use them, and not their competitors. Understanding this reality means that you can tailor your project to better match their needs rather than just their wants, so start digging for the truth.
First of all, thanks for the post. In an IT organization, talking about a customer can be confusing, and talking about competition even more so. But when you're talking about a project, every project has at least one competitor; the choice of not starting, or terminating the project once started. This type of competitor is sometimes called the "Do nothing" project choice and is a real 'competitor' to your project. I think more should be said about this "Do Nothing" competitor.
Of course most of the time, the business unit is our ‘Client,' but there are internal projects sponsored by the IS Director or IT Steering Committee. In this case, it's odd to consider your boss the client, but your post even rings truer while thinking like that.