(Apologies for the shortness this week - life and work keep interfering )
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.
Start Small.
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
Subscribe to:
Post Comments (Atom)
4 comments:
Not all the projects will visit every stage as projects can be terminated before they reach completion. Some projects do not follow a structured planning and/or monitoring stages. Some projects will go through steps 2, 3 and 4 multiple times.
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.
Too much software can become an impediment. The point of Agile is to collaborate, not use different tools. Software tools can (and do) enforce a style of work that may not be very collaborative.
Project is designed to primarily assist PMs in developing plans, assigning resources to tasks, tracking progress, managing budgets and analyzing workloads of different resources.
Post a Comment