Developing your Project Management Office (PMO)

I have developed many different PMOs over the past two decades. These PMOs have supported various different types of organizations at various levels of maturity responsible for various different aspects of technical development. Each of these PMOs provided different services based on the organization that was being supported. The first PMO that I developed was designed to support a software deployment group. The overall organization was immature (SEI level 1) and I was one of the few people that thought in terms of project management. I too was immature, especially in the area of project management. I was a mere novice having recently discovered PMI and the Project Management Body of Knowledge (PMBOK). Using the PMBOK like a hammer I hit my thumbs many times. This organization had two primary areas that it supported: software delivery (deployment) and problem support for the same software. In my role as project manager I was also the technical face to the customer. You might be wondering how I could call this a PMO. The first key element that made this a PMO was that we were the organization responsible for reporting to the customer on a regular basis. This was for all software releases long before they were in the hands of my organization. We also managed delivery and roll out plans for the software. The last piece that we supported was the tracking and scheduling of problem fixes. The customer interface, release management and problem tracking were the three areas that the larger organization required of us as a PMO and we performed those functions. A few years later of was assigned to perform project management for a large software development project. This project utilized the services of about 180 people. At this point in time we were at a much higher maturity level (SEI level 3) and we were actually using the words “project management.” I became involved in this project shortly before contract signing. We had been asked to provide a schedule to out general manager. Imagine that, us giving the date to him! Our date was three months later than he wanted and as hard as we tried we could not see a way to shorten the schedule. He signed the contract with a deliver date three months earlier than we thought we could deliver. Sound familiar? The difference with this one is that the GM committed to take ownership of the difference in dates and he did. With this very large and diverse group of development engineers my primary tasks where managing deliverables and communications. We were constantly looking for a way to pull in the schedule. Each month the GM would ask if we found a way. Ultimately we met our committed date much to the surprise of our customer who expected us to deliver much later. I attribute our success to our high level of process maturity and our application of sound project management practices. For this particular PMO our primary responsibility was tracking deliveries, connecting the dots and keeping all the stakeholders informed along the way. The last PMO I will discuss was for an architecture team. The hardest part here was trying to determine the product deliverable. We determined that the deliverable was a technical description of this new product. We had pulled senior level technical people from all over the corporation to come together to design the “Next Generation Wireless Telecommunications System.” We intentionally avoided the word “cellular” as we did not want to limit our thinking. By the way, ne’er did we consider satellites ;-) With this diverse group of thinkers we quickly came to

Continue Reading