Anticipating Stakeholder Needs

Over my 40+ year career in IT project delivery, I observed a significant shortcoming in most Project Managers; that is, an inability to anticipate the needs of their project stakeholders. I also noted that Project Managers who had developed this trait set themselves apart from their peers.

Like many other of the “soft skills” that Project Managers must learn, the ability to anticipate – and even act upon – their stakeholders’ needs and wants is paramount. People have disagreed with me on this point. They believe that this characteristic is a product of one’s innate intuitive capabilities, and therefore one either has it or does not.

That has not been my experience. In fact, I have seen that as Project Managers mature in their careers, they focus on people rather than just schedules and budgets. They begin to anticipate and creatively meet the stakeholders’ goals and objectives. Their deep experience informs them. Their ability to read human behavior alerts them. And their wanting to delight their customer propels them to act.

The following vignettes come from my own project experiences and illustrate this trait to a certain degree. Some vignettes show what can happen when Project Managers are oblivious to stakeholders’ needs, even when those needs are obvious. Others illustrate the positive outcomes that stem from purposefully and proactively anticipating their needs.

• Ambitious bid. It was my first proposal at my new firm. The RFP requested major enhancements to its core system in keeping with new legislation. I had worked on that system several years earlier with my former firm and assured my leadership that we could bid lean and still be successful.

  We won the bid. In our kick-off meeting, the client’s primary stakeholder shared with me that our bid was aggressive in comparison to our competitor. She was concerned. The new functionality we were required to implement, while based on current legislation, would also require significant changes in response to a recent client advocacy complaint.

  I will admit I blanched. I scrambled to re-read the RFP requirements and my notes from our pre-bid meetings with the stakeholder. There it was in black and white. As I stared at the advocate’s requested changes, I realized they would require significant modification that went to the core of the system’s database structure. I had failed to anticipate the stakeholder’s commitment to satisfy the advocate’s requests.

  Result: We augmented our team and delivered on time, but left much profit on the table. I vowed to never again make such hurried assumptions, and to better read my stakeholders’ intent.

• Vendor animosity. Our PMO had performed a stellar job in guiding the client organization and the IT provider in completing a large, complex project on time and well within budget. A success all around.

  Weeks later I learned that I was not accepted for the project management position for a similar organization’s IT project. Apparently. I had received a negative reference from the technology stakeholder from the previous project. I contacted my partners from the PMO. They had received similar negative references.

  How could this be? By all accounts, including this stakeholder’s own account, we had guided the delivery of the most successful IT project his organization had ever undertaken.

  I thought back over the project lifecycle. There were clues, and I had missed them. This was not an issue of performance. Rather it was the age-old issue of corporate IT’s resentment of having contractors on their turf. I had not anticipated that whatever ill will he might feel would result in negative references.

  Result: I soon landed another contract position. Of course, I did not use him as a reference. And on future projects I was careful to manage all stakeholder relationships to avoid a repeat of this experience.

• Competing stakeholders. I contracted with an organization for post-implementation support for its mission-critical system. Following implementation, there was a period of “settling in”. End-users were familiarizing themselves with the rich functionality of their new system. The IT provider was fixing software defects that had slipped through the User Acceptance Test.

  Anticipating the pent-up demand to immediately add new functionality to their new system, I compiled all known enhancement requests that had built up over time. I prioritized these according to several factors based on my knowledge of the organization and its stakeholders.

  I then requested the primary stakeholder organize a meeting of all stakeholders, who were largely the department heads. We began working through the long list of enhancement requests. We validated priorities from a corporate standpoint, negotiated compromises, culled lower priority items, and assigned ownership to each enhancement.

  Result: We formed a permanent committee of stakeholder representatives to continue the process of prioritizing enhancements for each new software release. Each stakeholder felt heard and was able to support enhancements that benefited the entire organization, not just their areas of responsibility.

• Dishonest Project Manager. The project was in trouble. I was requested by my boss to perform a project review and determine how best to move forward. At the same time, the client Project Manager appealed to her management for executive support.

  The executive stakeholder requested a meeting with project management. This included his organization’s Project Manager, his IT manager, myself, and our firm’s on-site Project Manager.

  Having observed the client’s Project Manager for several weeks, I knew that she would not cooperate. Having made several inquiries about her boss, I felt that he would probably side with her, but also learned that he was fair-minded.

  I needed an attention-getting gambit to shake him out of any complacency he might have and to show her we were serious about getting the problem solved. I warned our firm’s Project Manager. “She’s going to set us up. If you see me close my portfolio and get up, you do the same. We’re walking out.”

  Ten minutes into the meeting she showed her true colors. And she lied. I closed my portfolio, and the two of us walked out.

  Result: About an hour later the executive stakeholder called me to meet privately. He felt her story was too one-sided. Shortly after that, she was removed as Project Manager and processes were put in place to bring the project back on track.

• Unprepared client. The project was running a little behind, but we were not concerned. Until … until I looked ahead on the project schedule. I quickly became concerned. User Acceptance Testing (UAT) was only eight months away and I had seen no preparation by client staff to be ready to test.

  I re-read the contract to remind myself that the client was fully responsible for UAT. That is, the client staff on the project needed to develop test case scenarios, write the test scripts, review the requirements traceability matrix for complete coverage, learn how to report defects, learn how to execute system functionality, and learn how to use the testing tools. All in eight months.

  I met with the primary stakeholder to determine if her team had begun preparing for this most critical responsibility. As I had anticipated, she and her team were not even aware of what UAT entailed. After all, their only qualifying experience was in testing enhancements to the legacy system. Whenever they tested a new enhancement, they would bang on a few keys, show the programmers what they had found, and then trust that all would work. No big deal.

  I explained why “seat-of-the-pants” testing would not work for their new system. I offered to lead her team for the next year in preparation for, and execution of, UAT.

  Result: It took the entire eight months to prepare. The team wrote several thousand test scripts and dutifully executed each one. The thoroughness that they exhibited uncovered thousands of defects that were fixed before implementation.

I have many such examples, fortunately almost all good. Interestingly, however, when I’ve shared some of these real-world experiences with colleagues I’ve often received pushback in the form of, “How is that showing anticipation of stakeholder needs? That’s simply good project management.” To which I reply, “Then why did no one else see it coming or act on it?”

Anticipating the needs of our stakeholders is just another facet of our ability to apply the people aspects of project management to successful project delivery.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.