The Contrarian Project Manager, and Other PM Lessons Learned

There are many project management “methodologies” – I use the term loosely, since there are different methods addressing multiple issues. But most boil down to good common sense – including the addition of a Steering Committee that acts as a change-champion, addresses issues that impact budget and schedule, and provides some depth of experience and input to the Project Manager.

To that end – a sampling of past Steering Committee discussions, illustrating a few of my favorite methods and patterns. The lessons learned here are applicable to many types of projects (and certainly not limited to technology efforts!) …

Challenge: One-on-one, I asked what the issues were, and the PM said “something about Type Codes, nothing else really”. But I was there with the rest of the group at the Monthly Review – there was an undertone during this bit of the presentation, a sense that these Type Codes were important, but the decisions being made were … contentious. The review of the issues was just too easy, too lightweight, and we weren’t getting into any details – the Steering Committee was just rubber-stamping the deck, while thinking about our Other Priorities.

PM Tactic – The Contrarian: I urged the PM to be a bit more contrarian, especially if the Steering Committee is feeling somewhat positive. And – if they are being positive, should be a little bit negative. Remember, the primary goal of a Project Manager is to Manage Expectations – which often requires that the PM actively and mindfully prevents people from falling into their own detached and comfortable mental place. If the crowd is being too positive, roll them back in with tales of What Bad Things Might Happen. Conversely, if folks are getting too negative, and despairing of success – roll them back from that depressive state with Positive Feelings of Success.

Challenge: The organization was looking at a two-phase project – the first phase covered some basic modules and processes across the distributed user community in a small acquisition, but the second was a more comprehensive rollout for a larger, more complex operating unit, including a Fundamentally New Process for a critical, Run-The-Business activity. The PM and the Steering Committee were bypassing discussion of phase 1, and interested only in the Big Hairy Audacious Change of phase 2.

PM Tactic – The Dry Run: I noted to the PM that there were important parts of the Phase 1 effort that would be repeated for Phase 2 – most notably, the communication and change management process for the distributed, highly independent, anti-standard-work user community. In addition, she had a project team that had done this many times before – but that was over five years ago, and key parts of that original team were no longer with the company. The opportunity here is to view Phase 1 as a dry-run for the more complicated, higher-risk phase 2. How do we roll out a process change to these distributed organizations? What worked, and (more important) what did not work, when rolling out the “benign” Phase 1?

These “dry runs” of communication, issue tracking, go-live incident management, etc. are golden opportunities to learn how to maintain that “heartbeat”, so problems do not get out of control. For hairy / scary process changes, it’s difficult to do a test run – so take advantage of the Phased approach to practice for The Big One.

Challenge: Another project, another Status Review meeting – and this time, the team was going into great detail about the features that should or should not be on a Monthly Billing Statement for our end customers. The project team – including programmers, consultants, etc. – were doling out opinions based on their personal experience with their own monthly electric or heating bills. Ach du lieber – this is absolutely not something the project team should be worrying about – how about all of those interfaces that haven’t been written? Or the detailed training plan? Opinions are like … well, opinions are cheap, so leave those discussions to the domain experts – preferably, people who have the direct relationships with end customers!

PM Tactic – Get Focus: The effective PM must differentiate between “design and development” – the work of the project – and “communication and coordination” – the work of the Project Manager. For small and medium-sized projects, this can be a bit of an art form – but the experienced PM knows how to balance creative experimentation with a focus on results.

Does this mean the project team should not weigh in on usability? No, it means the project team should weigh in on those areas that have to do with their particular piece of the project; UI designers can weigh in on usability, the interface team should weigh in on technical architecture, and management should weigh in on communications and change management. (But only if their opinion is valued by the folks ultimately responsible for the deliverable …)

The PM Book of Knowledge is an interesting concept; like swordmaking and SQL query tuning, effective Project Management is something of a black art, informed primarily by the PMs mistakes and the mistakes of others. I’m still learning about the multiple ways to Manage Expectations …