pmStudent

The concept of a Project Management Plan has been defined and implemented in various ways.

For example, I've heard project managers refer to their MS Project file as their "Project Management Plan".  (I'm not even going to go there....if I start on that, I'll go on a rant about how that's so bad, it's not even wrong.)

I have also seen it implemented in such a way that it attempts to capture all of the scope, cost, and schedule and other related artifacts.

It turned out to be a huge pile of paperwork, with lots of effort to compile it, only to never be seen again.

It was useless.  Why?

It Didn't Add Value

The only reason for a document to exist on your project is to add value.  If it's not dynamic enough to be modified quickly by a lean change management process, it's going to die and go to artifact heaven (or hell).

One of the best ways to ensure something doesn't add value is to make it a redundant copy of something else that already exists.  In this case, there were already all of the artifacts outside of this "Project Management Plan" that were the REAL documentation, the real baseline for the project.

So What Should a Project Management Plan Be Then?

I'm glad you asked.

A Project Management Plan should be the defining document for HOW the project will be managed.  No more, no less.

It's the documentation of your project management methodology.  You can hand it to a stakeholder or customer and they will be able to read it and understand how the project is run.  When processes need to change, they should be updated in the plan.  A new employee joins the project?  Reading the Project Mangement Plan will orient them to "how things work around here."  Not WHAT we're doing, but HOW we are going about it.

Here are some critical areas to be sure your Project Management Plan covers:

• How are Changes managed?
• How is Scope planned and managed?
• How is Cost estimated and how are Budgets set?
• How is Schedule set, managed, and reported?
• How are Staffing considerations handled?
• How will Communication be effectively facilitated?
• How will Risks be identified and managed?
• How are Procurements to be handled?

You'll notice these line up pretty well with the PMBOK Knowledge Areas.  I tend to call out change/configuration management as it's own knowledge area, because it's so important and so poorly done on many projects.

So, that's my experience of what a Project Management Plan should be in order to add value to your projects.  I found this article here on Gantthead which agrees with my take on the plan.  Some of you may disagree with my approach.  I'd love to hear your arguments for alternative approaches in the comments.

I was recently interviewed by Cesar from pmforthemasses.com about getting started in project management.  I hope you find my responses helpful!

Can you tell us how you got started in Project Management?

In early 2004 I had been laid off from my role as an Operations Manager.  My wife was pregnant with our first child too, and for the first time I decided to really get strategic about my career. I asked myself "what parts of my previous roles have I really enjoyed doing?" The list was fairly long, but here is an example of the items on it:

• figuring out what the business needed
• working on something brand new
• leading people

During my research into going back to school and what companies were hiring for, I found out about something called project management. It was a discipline, with organizations and standards, etc. As I was learning more about it, I was like "Hey, I do that!" quite a bit.  I was shocked and overjoyed!

I had found my calling. I knew this is what I was meant to focus my career on. There were parts I loved and hated about my previous work....nearly all of what I loved was actually this crazy thing called project management that I had been doing all along, but never knew existed as a distinct discipline.

From that point, I looked for organizations who knew about and valued formal project management as a discipline.  I landed a job working on projects in a department where I could easily learn and grow.  Although it was a hefty pay cut from what I was used to, it was worth it.  Shortly afterward, I started going to night school for a degree in Project Management.  

What advice can you give to those planning to start a career in Project Management?

That is a huge question, and I've written hundreds of articles and developed many hours of online training about it.  In general though, I would say the following are key points:

• Take stock of your starting point and career goals first.  Then you can formulate a plan.
• A 4-year degree is required for most project manager positions
• Experience trumps graduate education in most cases for a project management role
• Certifications can be useful, but usually only once you have some experience to back them up.  Otherwise, view them as a learning tool, not a job marketing tool.
• Target organizations first, jobs second.  The organization you work for is more important than a job title at any organization.
• Networking is critical.  The majority of jobs are never posted.  You want to be a referral from someone who knows and trusts you.
• Volunteering internally within your current organization and externally is also critical.  Expect that you should prove by demonstration you can do a job before you earn it. 

What is the most valuable PM concept/technique one can use in their small business?

Do you bring any Project Management concepts/techniques to your personal life? How do you implement them?

Absolutely.   The discipline of project management can be applied to many places in personal life.  In fact I once recorded a video titled "Project Management in Everyday Life" in which I give a few examples.

What tools or resources can you recommend to the Project Manager wannabe?

"Do you know of any material, studies or other which covers agile project management but with geographically disparate participants. I have a couple of projects where this is difficult - design team in Bay Area, coders in Malaysia, China, India and Pakistan, customers/user reps across dozens of countries and project team in Singapore... timezones are killing me!"

In terms of Agile, I don't know of any training specifically for remote teams. 

I do have some personal experience with it though. I currently manage 2 teams of which some members are remotely located. 

I think Kanban does a lot for this scenario, primarily because it enables some self-organization that I think doesn't necessarily happen easily with something like straight forward scrum. The best thing is that you can use the kanban board even while not doing strict Kanban..and use it with any methodology, such as scrum or even waterfall. 

It allows my team to conduct our daily stand-up and update the kanban board - even when I'm not able to be there. And yet I am able to see what updates were made later and still have a good view of what is going on with each project. 

My recommendation to you would be to first learn about kanban if you don't already know much about it, then look into the many hosted electronic kanban boards for use on your teams. I personally love leankitkanban - but agilezen and others are very good too. 

In this video, Josh encourages you to own your project management career. You are your best advocate, and your questions and answers are going to be individual based on your background, goals, and industry.

Like this? Share it!

Having taken over a project, I find myself in the awesome position of needing to revise requirements with my customers that are pretty obviously in need of some spring cleaning.

Here are some tips for your own situations where you must "scrub the stains" out of a set of requirements, as opposed to dealing with change management on one specific requirement.

Make it Easy

We use DOORS to manage our requirements.  For me, step 1 is to export from DOORS to an excel file.  Getting these requirements into a format people are comfortable with is very important.

Next, I trim away the fields that don't really matter for what I'm trying to do, and then copy/paste the requirements into a blank Word document.  The reason for this will be come clear in a moment.

Track Changes, with Comments

I turn on the "tracking changes" option in Microsoft Word, and go to it.  Whenever a change is made, a comment accompanies it.  I speak to my audience, the customer, so they will easily be able to understand why I am proposing some changes.  In this case, I want to add clarity and also specify some functionality that has become known as a user need over time, but wasn't captured in the original requirements.

Review With The Team

I always like to review any requirement changes with my teams before proposing them to the customer.  This way, I can be sure I'm on the same page as my team members and there aren't any communication gaps about the needed functionality.

Many times, the understanding I've gained about new wants and needs comes directly from my team members, who are interacting with the customer and future users of the system.  It would be very bad if I had a misunderstanding on a particular requirement and ended up making that part of the baseline, when it's really describing the wrong thing.

Meet with Customer

Next I meet with the customer to ensure the changes I'm proposing make sense to them.  The comments I did earlier come in really handy, and the better they were, the easier this process is.  In my environment, I prefer to do this before having it come up at a Change Control Board (CCB) meeting as a change request.  I want the customer to be knowledgeable about the proposed changes and see the value in them before having to make a decision.

Change Control Board

The final step is to "make it official".  If you don't have a change control board in your project environment, you should set one up.  It doesn't have to be complicated, but it does require that everyone on the project understand that changes don't get made to the project baseline unless they are approved by the CCB.  

The customer and sponsor should be voting members, and in my environment the customer is the chair of the CCB.  That means they have the final word on whether a proposal will be approved or not.  If you are in a different contract environment, it may be a CCB internal to your own company/contract you are interacting with.

Like this? Share it!