One of the key functions of an effective project manager is to ensure the free flow of information about the project and to use that flow to help manage expectations. Project Management Institute (PMI) defines expectation management as “the process of communicating and working with stakeholders to meet their needs and addressing issues as they occur.”1 With the widespread adoption of Agile and other iterative methodologies, this is an often overlooked discipline. Regardless of the methodology used, before a project goes live it is always prudent to hold a go/no-go session. There are a series of key questions that are pertinent to ask at that session. But for the purpose of this article, I want to focus on one: Is the receiving organization ready to accept the product?
As technology projects are challenged to deliver more, faster, and with fewer resources, it is bringing the issue of expectation management to the fore. Project managers tend naturally to focus their communications on the project team and their sponsor. This makes perfect sense if you realize that the project manager gets most of their day to day input from the team and the majority of their outbound communication is aimed at the sponsor or the PMO. However, once we move into the execution phases, we need to intentionally involve two receiving organizations that very frequently are left out of the communication loop: the support teams and the end users. The support teams are going to have to know about the changes coming down the pike and the types of issues they are likely to face after the go-live event. Their needs for documentation and understanding can typically best be met by involving a representative team member from the level one and level two support teams either late in the Planning phase or early in the Execution phase. But engaging the end user is another matter entirely.
Managing the expectations of end users presents a particular challenge for project managers. We want to minimize the “expectation gap”2 between their expected value and their perceived value of what we deliver. But we do not typically have a clear picture of what is going on in their worlds. We are usually working with generalized personas that represent our end users’ needs, but not real people with real jobs and sometimes with real conflicts. Over the past 25 years of my experience one of the most effective ways I have found to handle this aspect of communication management is to leverage the Sales and Marketing teams. There are two particular points where they can add the most value.
First is when prioritizing the requirements for delivery. They know first-hand what things they hear the most about from their ongoing conversations with the clients. They can also provide invaluable insights about things that will add the most value from the point of view of the people who are actually paying the bills. Their input in this phase does need to be tempered a bit as they will never prioritize a requirement that the end user never sees such as improvements in the back end architecture that enhance the supportability of the product. But they do have insights that no one else on the team has that need to be taken into account. Sometimes seemingly trivial enhancements that the development team might overlook can have tremendous value to the end users providing a large ROI from a value perspective.
Second, I like to see the Sales and Marketing groups involved in the Execution phase. As decisions are made that determine what is in and out of scope for the project. To determine when to engage them, a balance needs to be struck between the cost of their engagement versus the value they bring. As a project manager, you can leverage them in the Communications plan by letting them work on how best to frame the message to the end-user community thus taking some of the burden off the project manager. At a minimum, they need to be engaged once the final in and out list is determined and with sufficient time before go-live to effectively communicate with the client base before a go/no-go meeting. Let’s go back to the question in my opening paragraph: Is the receiving organization ready to accept the product?
Just because the development work is done and tested does not necessarily mean that we are ready to push the project live. There can be myriad reasons not to push a set of enhancements into your live production environment that have nothing to do with the readiness of the software itself. That final go/no-go meeting MUST take these reasons into account. As project managers, if we fail to do so, then we fail to meet the needs of a vitally important stakeholder group who largely fund our professional existence. We fail in one of the key areas of our responsibility. We can spend our time and energy engaging the right teams and effectively managing expectations, or we can focus solely on a delivery date and spend our time and energy smoothing all the feathers we ruffled by pushing out things our customers weren’t ready to receive. The choice really is ours as project managers. My experience has been that the former is much more satisfying and leads to much better results in the long run.
Endnotes
1. A Guide to the Project Management Body of Knowledge, Fourth Edition – Project Management Institute, 2008
2. http://consultingacademy.com/a08.shtm – Consulting Academy, Brazos Consulting, 1999-2009