- Say again? You WANT to go to the PMO???
A funny thing happened on the way to the PMO. I picked up the Tech Lead, and about 10 other projects I didn’t know existed.
See, when I first got to this position about a year ago, my team (the analysts), and the Tech Leads team (the developers), existed as two separate groups. For months, I knew about projects that the development team was doing, but into which I had no real visibility. All I knew was that my projects would occasionally slow down, as developer resources were stretched by invisible (to me anyway) projects.
But hey – it wasn’t my domain. I am responsible for the analysts, so I just worked to control what I could control. And we had a lot of work to do to get up to industry best standards. I’m proud to say that we have; regularly using BABoK, ITIL, PMBoK and CMMI best practices.
So imagine my surprise when the Tech Lead one day goes ‘ hey, I’d like to come to the PMO and here are the 10 projects we’re working on, and can we figure out how everyone is spread out?’.
What happened? Why the trust all of the sudden? How did one day all of my PMO dreams come true and I was able to see, measure and quantify the full resource allocation of both the analyst and the developer team? Without a fight even?
My Pathway to Trust One of the PMs on my team is reading Steven Covey’s The Speed of Trust. Covey’s premise is that trust, or confidence, has a measurable impact on the speed by which business can move forward. In my situation it took three steps:
• First, I had to trust my team, and what they already had created. That was the first step towards improving process.
• Second, I recognized that I could not control the development team, so I just focused on improving what my team did. As our quality improved, people outside the team gained confidence in us.
• Third, in our interface with the development team, we always explain why. This way, we aren’t forcing process, we are encouraging dialogue about process.
First, Work in the Process Organically by Trusting What Exists Sometimes, all you have to do is just make evident what is already there . When I first joined this team a year ago, the team had struggled to figure out role and responsibility boundaries. They came up with a solution for document ownership that worked for them. It wasn’t perfect, but it was a starting point. I documented the process and then ensured that they followed it. But ultimately, it was their process. That paradigm, of allowing the process to be either based on or informed by what already exists, and to trust the people in the process to determine their own direction, has existed in the group to this day. The idea is based loosely on the Agile principle of self-organizing teams which proposes that the people who do the work, know the best way to do it. In our situation, I needed to provide a layer of management direction with a clear line to industry standards, and oversight of process, but the process itself belonged to the team.
Second, Start With What You Can Control I met a guy at the PMI LIM who runs a PMO in Canada. His advice was to start with what you can control and prove success there. So instead of forcing business units in his organization to use his office, he set up a web interface and asked them to request help on projects via the simple web form. His team would then work those requests into successful projects. Well eventually, those units whose projects were run by the PMO compared notes with those units whose projects were run through the business units and lo and behold, the PMO-run projects were smoother, more successful, on time, on budget, all that jazz. So now, business units want to go through the PMO because he was able to prove success.
Likewise, in my environment, I just sought success in my team and that was noticed by everyone we interfaced with. As our quality improved, their life was made easier – and that was appreciated.
Third, Be Clear About Why One of the things the Tech Lead does is constantly ask ‘why?’. So we spend a lot of time talking about why we need a change management process, why we need a configuration management plan, etc. sometimes it’s frustrating but I understand that while I’ve read the PMBoK, most of the rest of the world hasn’t. So you just acknowledge people where they are without being too snooty and explain, explain, explain. Different people need different messages too. For example, the State of Michigan Department of Information Technology has an awesome website where anyone can clearly understand their process and why it’s important. They’ve even geared thier message towards unique groups: Project Sponsors, Buisness Owners, Project Team Members, Portolio Liasions on thier I Have a Project Page.
Hey! I Have a Project!
Clicking on the Business Owner page starts with a very nice thank you and launches into a great explanation of the process.
Final Thought: Don’t Force it, Prove it I’m sure we’ve moved forward into a deeper level of trust because of proving the power of Project Management, rather than forcing people to follow process.
