Do What I Do; Not What I Say. Rethinking the Advice We Give New PMs
How many of you have given this advice to a new PM? I know I have. I remember vividly explaining to a fellow consultant the mistakes she made in failing to determine exactly what the client wanted when she started the project and then offering a few techniques that I felt would help her in the future. The only problem is that the advice I gave her, while sound was completely wrong for the situation she had found herself in. What’s worse was, that my advice didn’t reflect the very things she’d seen me do when I came over to help the project get back on track.
Just like the quote above from another PPM blog, my advice focused on talking to the customer to get the requirements and indirectly implied that every client should know exactly what they wanted so that the PM could go away and execute. The only problem was sometimes the client absolutely doesn’t know what they wanted because it had never been done before and it’s the PMs job to work with them to help them find out what they needed.
Unlike the PM I was advising I recognized that the only way the project could be successful was to take an approach that supported Rapid Application Development (the precursor to agile) so when the VP asked me to take a look at his prize project which was tanking badly, I walked over and knew what to do. I got the team talking to the users, shifted over to a plan for six 30 day release cycles and then got down to work iterating ever closer to what was going to get them to done. If I reflect back on the situation the major skill I brought to the party was the fact that I wasn’t upset or concerned that the users didn’t know what they wanted. I had a 4 GL tool for rapid development (a proprietary piece of software that was unmaintainable in the long term but well suited for the short term) and a good team of people who were committed to results.
Looking back on it, I hope the new PM I was talking to watched what I did and paid less attention to what I said. Yes, projects most often fail when no one know where they are going. And yes, we (as PPM Leaders) do need to spend time making sure our PMs know how to help the client define “What done looks like”. But if the client can’t really paint the picture and there isn’t a choice to delay the project to a later date when things are clearer, we need to ensure that our PMs know to to put on their hiking boots and to plan for a few extra twists and turns on their way to a destination that someone will recognize when they see it.
Projects are inherently uncertain activities. Obviously some projects are more uncertain than others, but in the final analysis being prepared and comfortable doing something the hard way probably ensures that the easy stuff gets done more reliably as well.
