Top Ten Reasons Why Projects Fail – Reason #4

I had originally intended each post in my “Why projects fail” series to be one page. But I wanted to tell this particular story which speaks so well to bad stakeholder management that it will be in two posts. So, still overall a ten-part series on what makes projects fail. But maybe more than ten posts.

So here’s the story:  Back in 2003, a short while after I started my company, an ex-co-worker got in touch with me. She told me that she had gotten a contract position as a project manager with an investment bank in New York. She was part of a small team of PM’s whose job it was to upgrade 17,000 or so computers to Windows XP. They needed another PM, she thought of me and wondered if I’d want to interview for the position. The only catch was that the job was 9-5 in NY and I lived in the Greater Boston area. But I needed work and so, off I went to NY.

I won’t go into all the details of exactly why they needed me. Suffice it to say that I was replacing a guy who was not a PM but who was, in fact, a chemical engineer or something like that. His counterpart on the business side was a young woman fresh out of college with not much more project management experience than he. So into this environment I came. What I didn’t know when I came on board was that this project was already well overdue and my new boss was getting tremendous pressure from his bosses on Wall Street to get “numbers.” So, the mantra was to upgrade as many PC’s as you can as fast as possible. (Never mind that a lot of them were on the trading floor and we were dealing with some very reluctant bankers).

I found out that my first assignment was to take over the upgrade of about 30 or so PC’s in a back office operation in New Jersey. So the guy I was replacing, let’s call him Joe, took me over to Jersey to meet the involved people. And at that meeting we met the site manager and his subordinate, Tom. Now we explained to them what we were doing, when and why. Since this was the middle of the summer (I had started in July) the manager advised us that he would not be around but that Tom would take care of us.

So armed with that knowledge – and the fact that we had two weeks to get this done – we engaged the vendor, planned our attack and decided to do the upgrade on a Friday night two weeks hence. (The vendor was there to do the actual technical work under my supervision. So the upgrade (including applications) would be copied down from a central server to each affected machine). I will save you all the backstory about what it took to prepare for that Friday night. Suffice it to say that we (the business PM, me and the vendor) showed up Friday at 5pm as planned. Awaiting us was Tom, the technician. After some discussion about what we were going to do (or thought we were going to do), and after inventorying all the machines, we suddenly realized a thing that made us all feel very uncomfortable. Namely, Tom had gone ahead and done the upgrade himself! Without benefit of the server-loaded upgrade, without benefit of knowledge of the various applications needed, etc.

Why had he done this we wondered? What he told us was that he had had some free time and he thought he should just go ahead and do it himself. That’s what he told us. The reality was something quite different which we found out later and which I’ll tell you now. The reality was that Tom feared for his job. He was threatened by us (even though we represented no real long-term threat) and wanted to establish his turf by doing the job himself.  He was what we might call, for want of a better term, a hostile stakeholder. And if that were the only way he manifested it, then this would be the end of the story. But it’s not.

(Stay tuned for the rest of Stakeholder Management, real soon)

Comments are closed.