Mentor's Corner
The Importance of Defining Stakeholders on Your Project
by Jim Stewart, Project Management Consultant and Trainer of JP Stewart Associates
Stakeholder management is defined by the Project Management Institute as “managing communications to satisfy the needs of, and resolve issues with, stakeholders.”
1 Stakeholder analysis, likewise, is defined as, “identifying the influence and interests of the various stakeholders and documenting their needs, wants and expectations.”
2 In those small, bloodless phrases are contained enormous nuggets of wisdom. I could lecture all day about the necessity of identifying and managing stakeholders but I think that a story from my experience would illustrate it best.
A few years ago, I got a contract as one of several project managers for a major New York City-based investment bank. Apparently, the systems side of the house had committed to upgrading all of the company’s PC’s to WinXP by – if I recall correctly – the end of 2004. My role – as one of five project managers – was to oversee the upgrade of about 3500 computers across several divisions.
When I arrived at, let’s call it MegaCorp. Inc., I soon came to realize that not only was the schedule woefully behind but that there was a distinct lack of formal procedure in place. The modus operandi seemed to be as follows: “Just get them upgraded as soon as possible. We need numbers.” With that as my charter, my first assignment was to upgrade a division of the company in New Jersey. My predecessor – a chemist with no formal project management training - had gotten underway with this project but it wasn’t moving fast enough. His counterpart on the business side was a young woman with no project management or technical experience to speak of. So she was expecting him to lead her to the finish line. By now you would think that my spider sense would have told me to stay away but I really thought (naively, as it turns out) that I could pull this one off.
At the Jersey site, I was introduced to the two stakeholders whom I was told would be the only ones to worry about, namely the site manager, Mr. Johnson and a contractor named Bob who was Johnson’s senior techie. From the get-go, it was apparent that neither Mr. Johnson nor Bob wanted me – us – there. “An intrusion,” they said. “We can do this ourselves,” they further exclaimed. Etcetera. Nevertheless, my job was to upgrade their 200 PC’s and so, they resigned themselves to that fact. Mr. Johnson explained that he was going on vacation but that I should be in good hands with Bob, his right-hand man.
Did I mention that a large part of stakeholder analysis is determining not only who is on your side but also, who is actively against you? Let’s just say that Bob was not on our side. Why? Well, for a variety of reasons I guess, not the least of which is that he felt he could do the job himself. And if we did it, then why did MegaCorp need him? (Lesson – never assume that your motives – which you see as pure and virtuous – cannot be misread by others. Especially those with an agenda of their own).
So, what happened when we went to deploy? Well, when we got there on the appointed night, Bob advised us that he had taken it upon himself to upgrade all the machines! This, despite the fact that I had engaged the services of a third-party contractor whose job it was to actually do the deploy. They had carefully tested and packaged all the applications, which were sitting happily up on the server, ready to be brought down for each specific user. What had Bob wrought? A bunch of upgraded machines with base applications, none of which could log in any longer. But, he proved he could do it. I guess.
That was the good part of the story. It gets worse. I then reported to my manager, a good, selfless guy who got more grief on a day-to-day basis than any ten people I know. He complained to Bob’s next-highest manager who got involved. Turns out Bob knows how to spin a story. “Never told me they were coming,” he said. “Told them I could do it myself.” So Bob, shall we say, dissembled. And was believed. He was a hostile stakeholder and I didn’t pick up on it. Well, I picked up on it but I did not pick up on the level of duplicity he might engage.
The end of the story? The bottom of the well? I wish. Recall that Bob and Mr. Johnson were identified to me as the only stakeholders I need concern myself with. Bob knew better. Within days I heard from the following – the regional manager, the regional district manager, the area regional district manager. Also, some other people whose titles I don’t recall. It turns out that there were a lot more people involved in that site than I had been led to believe. I didn’t know any of them; none of them were identified to me. But Bob sure knew ‘em all. And called every one. “Why didn’t anyone tell me about this?” was the standard question. (That can be printed). Somehow, this fiasco had become all my fault. And hey, maybe it was.
I had gone on faith that A) the stakeholders, on seeing the light, would surely come around and B) all the stakeholders had been identified. But given the lack of controls on any aspect of the project – and given the imperative from “downtown” to get numbers – I fell into the oldest trap you can. I went too fast and I trusted the wrong people. (My boss didn’t know either and got led down the primrose path as well. He stuck up for me though which is about as much as you can ask).
What’s the moral of the story? That you must know all the stakeholders on your project and you must know if they’re for you or against you. Because only then – given the array of all the other forces against you - can you have any chance of succeeding. Your technical skills won’t help you in this instance.
What happened on the project after that? Oh, I survived that particular glitch. Mr. Johnson came back, yelled for a little while (to protect his guy), and then advised me confidentially that he’s had problems like this with Bob before. I did some more rollouts and my boss invited me to stay on an open-ended basis. He knew I was fighting the good fight and would lose battles but win wars. But I left because the weekly New York commute was onerous and – more to the point – I found it impossible to work in an organization with no commitment to ever improve its processes. Which is a story for another day.
1. A Guide to the Project Management Body of Knowledge, Third Edition, p. 235. Project Management Institute.
2. Ibid, p. 110.
Jim Stewart has been an independent project consultant and instructor since early 2003
and has worked in project management for 15 years. He has managed
several multi-million dollar projects for companies such as Lotus
Development and Genuity and currently teaches at both Brandeis
University and Babson College. He can be reached at
jpstewar@rcn.com or view his website at
http://www.jpstewartassociates.com/
