Well, you are building a PMO, so you’ll be expected to come up with some Project Management procedures. There are a plethora of great procedure sets out there that cover everything you can imagine about Project Management, they usually come with their own documentation and form sets. Your company probably already has some standards or processes that you will want or need to include in anything. Again, below are my ideas and thoughts, suggestions only, I know many of you have had different experiences, please share them.
This is pretty generic and universal advice, so I’ll go quickly. Whether you are starting from scratch or have some existing material, start small. Most of you know this one already. Don’t try to impress by inundating your organization with rules and forms, they’ll rebel. For the first time around, I would use very light processes and forms – maybe a charter, schedule, action items/issues list, and meeting minutes. Have your PM do all these so that no burden is on the sponsor or other team members. You’ve got good PMs, just trust in that, they’ll get the job done, and that is what counts.
What to do with Existing PM Standards?
This can be a real problem. Management may be looking to you to implement these standards, or to enforce them. Personally, I did not get into this to “enforce” anything, so I would begin negotiations with the objective of starting small and controlled and building on. In all likelihood, the package or set of standards you start with will not fit the way business is being done. Use this to encourage a process by which you start with a subset and add on as needed.
One company I worked for had purchased a very comprehensive set of Project Management and software development standards and procedures. There must have been 200 or more forms. The product was available on the intranet, and the project manager was expected to go and select the methodology they were going to use and then use the forms and procedures associated with that methodology. The methodologies were all based on software, and they were pretty specific – web based, mainframe, client-server, purchase, etc. I am sure that you can guess what happened. Since there was no PMO or procedure for using the tool, PMs just picked out what they wanted, used that and then copied the documentation from one project to the next. Everyone was “using” the tool, but the only similarities ended up being the fonts and the title pages. IMHO, that was because it was too complex. That is one reason why I advocate people, processes and then tools.
So, take whatever you have, boil it down to the essentials, then take half of that and start. You should not have any problem convincing people to use less, except maybe those who are invested in the tool or process. Find them, and get their help and buy-in, make them a part of this. Be careful that you are not perceived as wanting to slay a sacred cow, if all of this is new, then you can use that as a starting point. Things like “I need to start small so I understand everything” will go a long way here.
Next time, I’ll talk a little about build or buy options and how to move from processes to tools.
Mr. Derry Simmel, PMP, MBA, FLMI
Derry Simmel has been in IT and project management for over 15 years. He has started 3 PMOs in the last 6 years, the latest of which is with a large project for the State of South Carolina. Derry has an MBA from University of Phoenix and a Bachelor of Science degree in Computer Science from the University of South Carolina. He currently serves as the Vice-Chairman of Membership for PMI’s Project Management Office Special Interest Group and as the VP of Programs for the PMI Midlands Chapter. Derry maintains All about Project Management Offices, a professional blog covering all aspects of PMO.