Jason Martin wrote an excellent article about a debate I had with MyPMExpert on Twitter (moderated by TheGreenPM). In it I was contending that the further the PM is away from his or her comfort zone in terms of subject matter domain, the greater the risk to both the project and the PM.
After reading it, I started thinking about the article, and why I take the position I do. I thought I’d share a little bit.
I’ve run all kinds of projects through the years from simple to mind-scramblingly complex. I came from the trading floor where not only did we have some very hairy projects involving legacy systems integration with enterprise-wide applications, but we had to do it with some horrible, horrible stakeholders. Traders have gotten a lot better over the years of humbling market crashes, but the stereotype of trader as money-making / money-spending arrogant monster hasn’t gone away entirely.
Through it all I had a great rapport with my teams, and my stakeholders and I all had a common understanding. Don’t piss in my cornflakes, and I won’t piss in yours. And beers are on me after. I became about as arrogant as my clients–there was nothing I couldn’t do.
Then one day I joined a consulting firm and was put on a chequing program. I knew nothing about chequing. But how hard can it be, right?
Well, it turns out, plenty. I wasn’t the program manager…I was given one piece of the program to manage, the front loading portion called “cheque capture”. I had to plan out a series of nine different releases to span four years, many of which would run concurrently. In the first week I rallied the troops, and hammered out a gorgeous, detailed project plan of about 1000 lines, inputs and outputs to other plans, and anticipated risks (all written in sexy colours). I set everything up and away we went.
Then the problems started happening. Mechanical failures. Sorting problems. Rejects. People put gum and staples on their cheques which buggered up the hardware. Consumers wrote cheques in pink marker that the scanners couldn’t read…on mylar cheques that reflected glare back at the camera. Sorters were configured perfectly and still wouldn’t work.
Day after day, the issues compounded; issues my people didn’t anticipate, and some issues it turned out they did anticipate but I didn’t ask the right questions (and they didn’t volunteer). This was a multi-vendor program, so some vendors were more than happy to “accidentally withhold” information if it meant they could take revenue away from their competition (“oh, gee, that’s too bad they didn’t catch it…we certainly would have if only we’d been there”).
And everything we did still had to integrate with the other teams’ work. They were facing similar issues. We raised an endless string of change requests because if our team slid because of the problems we were facing, the other teams who depended on us had to slide. And vice versa.
In program review meetings, we watched expenditures balloon as we flew more experts in to deal with issues. Because of the parallel nature of the program (and the delays), skilled resources got spread too thin, further slowing work. The program manager’s response was to add more layers of management. Functional meetings bloomed out of control because by this time there were hundreds of people working on this thing…I couldn’t get a parking space that didn’t involve at least a two block walk, and more than half the resources were sharing desks across two buildings.
When my doctor refused to give me any more Xanax I knew it was time to reassess things. LOL I committed to stay through the first release, and the second release until integration testing, at which point they’d need to replace me. We kept things moving, I met my deliverables and went on my way. Before I did, I advocated strongly they find someone with chequing experience.
Why was I so stressed? It was a project, and I’m a project manager (and a damn good one). But I was on very insecure footing, in a domain I had to learn on the fly. As project managers, our job is to take teams off into the unknown, define the destination, and plot the journey. If we have a reasonable sense of the journey, we can be confident that we can face the challenges that lie ahead. That will inspire our teams and instill confidence in our stakeholders. When we take up the mantle of responsibility on a job where we’re doubly blind, the unseen risks proliferate. It wears you down.
CAN a project manager guide any project to the finish line using the tools as their disposal? I would say yes, I believe so. There are processes for changing scope, and managing expectations, thereby eliminating budget or schedule concerns.
SHOULD a project manager try to take a project they know nothing about to the finish line?
I’ll let you decide that one, but I know my position.
