Customer Feedback Received

True involvement of end users, clients or their representatives (product managers) throughout the entire project dramatically increases the project's chance for success. This well-known truism is definitely easier to state than to apply. Finding the right balance of user involvement to ensure a smooth acceptance without allowing them to run the project (ever heard of scope creep?) is one of the most difficult tasks facing a project manager.

A recent gantthead article by Luc K. Richard titled Customer Feedback Wanted describes a very interesting example, which unfortunately is not uncommon on the software development landscape. The sample project depicted creates a perfect setting for a discussion of what we can do as project managers to get the needed feedback, despite all kind of obstacles.

For full details, please see the article But the short version is: Zack is a project manager that was handed down an SRS by the product manager for the next iteration of a software product. The product manager takes a week vacation, and then leaves for three more weeks to chase new sales in Europe. Zack is left without the product manager's support—and as the clients' representative--when crunched between budget constraints and an over-inflated scope of work. By the time the product manger returns to provide feedback, Zack's project is already late and over budget.

The article concludes (absolutely correct) that customer feedback is required not only to create the SRS, but during the entire project as well. Especially during scope scrubbing, but also throughout the entire project to respond to questions regarding customers' requirements, the involvement of the product manager as representative of the users community is essential to achieve business alignment.

While the events unfold, a question grows more and more: What could Zack have done to resolve the issue? Yes, the product manager has a part of the blame as suggested in the mentioned article, but the project manager was supposed to expect and mitigate such issues. Moreover, Zack's ability to act depends on the organizational environment, the project manager's authority within the company, the executive's level of involvement and so on, but the project manager could and should have taken steps to resolve the problem before derailing the project.

This action might not have been available if the charter was already finalized before Zack was even notified about his assignment (defined already in the charter). However, the cases where the project manager has no knowledge or input about his/her assignment as stated in the charter are quite rare. So, even if the executive or sponsor--who created the charter--forgot about the product manager as a key stakeholder representing the user community, the project manager must suggest to be included as such. By doing so, Zack would have ensured a clear basis for stakeholders' analysis and consideration into all future planning activities.

With a single product manager for the product, this should be a standard risk to account for. The product manager's time is split between conflicting duties toward the customers and toward internal support and development teams. Moreover, what if he/she becomes ill or otherwise unavailable? Identifying this risk in front of the executives will ensure that it is accepted, mitigated or avoided as appropriate. Zack's project would have been protected either by executive's acceptance of potential impact, by committing a certain percent of product manager's time to the development project and/or identification of a backup person that can fulfill the role, to name a few potential options.

Both communications to the product manager (status reports, questions, etc.) as well as expected responses should have been defined in the communications management plan or corresponding section in the project management plan. Defining clear information needs, timing and delivery channels would have set clear expectations and established commitments. If the product manager would have been notified in advance about the information needs of the project team, it is conceivable that he would have established a permanent communication link with Zack, the project manager. From e-mail to cell phone, from checking office voicemail to pre-scheduled conference calls, there are a variety of communication channels available to overcome physical distances.

When the SRS was handed over to the project manager, Zack should have asked for a prioritization of the included features. A good practice in itself to focus the resources toward the "must have" items, this was even more important as it was known that the product manager often spends time at customers' sites. In fact, the product manager just spent three months meeting with existing and potential clients, so it was to be expected that time away from office will continue. Having the desired features in a priority order would have eliminated the need to guess later in the project.

This could be an item included in the communication plan action (No. 3), but its importance warrants a separate discussion. It is a common best practice for the development teams to respond to user requirements with a design document. It could be called functional design, high-level architecture, design specification and so on, but the underlying idea is to describe the development team's understanding of the user requirements and how they plan to address them. Requiring the product manager's review and sign-off would have ensured not only a correct understanding of required features--resulting in business alignment--but would have also put pressure on the product manager to include the review and feedback in his/her schedule. During this design activity, the effort and duration estimates would have been refined and only budgeted features included, so the product manager's acceptance would have explicitly provided Zack with the required trimmed-down scope of work.

Notifying the product manager by e-mail regarding excluded features is a passive communication method. By Week 3, when the product manager returned from his vacation, the project impact was already visible because the estimates were greater than the approved budget. Zack should have taken an active approach and initiated a meeting with the product manager to resolve the issue of reducing project scope. Either by phone or even marching down into the product manager's office, Zack should have secured a "live" discussion to explain the issue and define appropriate mitigation actions. "We cannot deliver all features" would have grabbed the entire product manager's attention and ensured his cooperation.

Even if communication expectations were not set in advance, when problems were identified requiring the product manager's input he/she should have been contacted. It is quite unlikely that nobody in the office knew how to contact the product manager. Even assuming that the product manager did not carry a cell phone compatible with European networks and could not check the office e-mail, the administrative office most likely knew his hotel bookings. Yes, Zack would have had to call at odd hours (in North America) to find the product manager in his hotel room, but sometimes it is expected for the project manager to go the extra mile to save the project.

If Zack could not find a way to contact the product manager directly, it is most likely that the product manager's boss could. Travelling representatives are usually required to provide status reports after customer meetings, and it is quite probable that his/her boss would have ensured that there is a way to contact the product manager at any time. Otherwise, who can be sure that the product manager was actually at a client's site and not sunbathing on the French Riviera?

When the project was clearly and severely impacted by the inability to receive feedback from the product manager, Zack should have highlighted it on the regular status report and/or directly to the project sponsor or executive. As far as the sponsor (usually a top person in the company) has all interests to ensure the project's success, he/she would have found a way to contact the product manager or even directly the corresponding clients regarding the features described in the SRS.

The larger visible issue is lack of formal procedures for Scope Change Management: Should it have been defined, the project manager would not have had to decide by himself on scope reductions--only to include the eliminated features back in the plan at a later stage. But even if the formal processes were not defined, Zack should have secured the approval for the scope change from the sponsor or executive. Not only that this is their prerogative, but they could have also found alternate ways to deal with the issue, such as increasing the budget and/or extending the timelines. Once changes were agreed to as executive level, the onus would have been moved to the product manager to justify the need to re-include those features. The executives can decide if "it was promised to the client" is good enough or not to spend the additional money in delivering the desired features.

The above are not by any means an exhaustive list of actions that Zack could have performed to mitigate the product manager's unavailability to provide input for scope reduction. However, the underlying principle of it all is that the project manager must take an active role in resolving the problems. Waiting for the return of the key customer representative, trying to guess by himself what can be eliminated and asking for help around instead of upward reflect a passive attitude when confronted with a significant issue.

A successful project manager must initiate the contact and ensure that all project stakeholders do their job. This includes sponsors, executives and users (or their representative--product manager), not only the subordinated team members. Yes, some rude persons might scream at the project manager when "bothered" with project issues that require their action, but when the project is successfully delivered, all this will be forgotten. However, a failed project will be remembered for a long, long time.

George Jucan , MSc,PMP,OCP,SSGB is the founder and acting CEO of Open Data Systems Inc., an IT consulting services company based in Toronto, Ontario. He has almost 14 years of progressive technical and management experience, specialized in project and software development methodologies, as well as process and organizational (re)engineering. A regular author of technical and methodological articles, George Jucan can be contacted through the Open Data Systems website or directly at gjucan@opendatasys.com.

"Selecting the Right Requirements Management Tool – Or Maybe None Whatsoever" – Get your free copy of this independent report by Forrester Research, compliments of MKS.

Ever tried to explain what you do to your Mom? It's not always easy…and "not easy," is not good. So, for those out there struggling to explain Quality Management, here's a quick 3 minute video to make life, well, a little easier. View Now!

Need to gain control of evolving business requirements? Want to drive clarity and context across the software delivery lifecycle? Watch this brief video discussing "Creating Value through Requirements Definitions." Find out about challenges that plague organizations and techniques, processes and tools to use to visually define, elaborate, collaboratively validate, and effectively manage your requirements.

Learn how to develop a measurement program to track project management performance and the impact it has on your organization with PM College's latest white paper, Mastering Performance Measurement!