Welcome!

Professor of Project Management General ,

The Project Management Institute (PMI) encourages its members to advance the profession. One of  the ways to do this is by helping others increase their project management skills. The target audiences for this blog are professional PM’s early in their careers as well as those who manage projects but are not PM’s by title or trade. I will be posting every week or so, offering practical tips and tools on the full range of project management topics. I hope you will find this useful and help you advance your career.

PMprocess

The Project Management Plan – Schedule Management

Professor of Project Management Uncategorized
Planning

Before I dive into Schedule Management I want to note the difference between the schedule and what many refer to as “the project plan”. You will often hear the Microsoft Project artifact referred to as “the project plan”. In reality, it is only the project schedule. The Project Plan is the combination of the Project Management Plan (being discussed in this series of posts),  the Project Activity Plan (or Work Breakdown), which will be discussed in future posts, and the Project Schedule. I encourage you to use this terminology correctly.

The Schedule Management Plan addresses the following:

• Indicates how the project schedule will be created (who will be the sources of start/end dates and effort), when it will be base lined and lists any scheduling constraints

• Describes the implementation approach (phased, iterative, pilot, etc)

• Defines what level of the schedule will be subject to change management (typically these are the high level milestones and major phase start/end; all other changes can be informally negotiated)

• Defines how schedule performance is monitored and reported (e.g., variance analysis)

• Defines the project schedule software to be used

• Includes a plan for change management: How a schedule change is requested, authorized, and documented

• Reference the Project Charter for the priority of Schedule in the triple constraints

Schedule Management is a critical part of project management and communication. In future posts I will show how to construct the schedule and monitor performance.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!

The Project Management Plan – Scope Management

Professor of Project Management Project Planning ,
Planning

The Project Management Plan defines how the project is executed, monitored, controlled and closed. The first component of the Project Management Plan is the Scope Management Plan.

The Scope Management Plan addresses the following:

• Defines how the Scope of Work will be created. This includes a roles/responsibilities matrix (who will create the scope, who will contribute to the scope, who will approve the scope)

• Defines what the Scope of Work will contain (Scope exclusions, process and physical scope, organizational scope, application scope, deliverables, Work Breakdown Structure aka WBS)

• Defines what constitutes the baseline Scope for change management purposes. This is not the actual Scope, it is the sources of Scope (e.g. “The deliverables as listed in section x of document z and the approved WBS”)

• Includes a plan for change management: How change is requested, authorized, and documented

• Describes the process for getting approval for completed deliverables

• References the Project Charter for the priority of Scope in the triple constraints

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!

The Project Management Plan – Overview

Professor of Project Management Project Planning ,
Planning

There are two main types of high level planning for a project: (1) The Project Management Plan; (2) The Project Activity Plan (aka The Project Plan). The Project Management Plan describes the approach and processes for managing the project. The Project Activity Plan describes the work to be done to achieve the project objectives. This series of posts address the Project Management Plan.

The Project Management Plan defines how the project is executed, monitored, controlled and closed. It addresses the management of scope, schedule, cost, quality, staffing, communications, risk, and procurement. Whenever matters of project procedure are in question, this document shall be the first source consulted.

This is a dynamic document and reflects the current thinking regarding the project approach based on what is known at this time. It is expected to be updated with new information as the project unfolds. Original and revised versions should be distributed to the entire project team.

The components of the Project Management Plan are:

  • Scope Management
  • Schedule Management
  • Budget Management
  • Staff Management
  • Communications Management
  • Risk Management
  • Procurement Management
  • Project Close Definition
  • Post-Project Audit Plan

In subsequent posts I will elaborate on each of these sections.

For large projects I highly recommend creating a Project Management Plan and sharing it with your sponsor and key stakeholders. This plan describes the “rules of engagement” for the project and will minimize assumptions and misunderstandings regarding project process. I have also found this to be very helpful if you are new to an organization. It is a way to document your understanding of the project management practices of that organization.

There is a good reason the Project Management Institute (PMI) includes these plans in their best practices. Once I obtained my Project Management Professional (PMP) certification, I included a formal Project Management Plan on all of my large projects.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!

The Project Charter – Sign Off

Professor of Project Management Project Initiation
Initiation

The Project Charter can be looked at as a contract between you and your project sponsor or you and your manager. It documents your understanding of the expectations of the sponsor and what you are expected to deliver and when. Like any contract, it should be concluded with a signature indicating agreement.

Why get a real signature? It is amazing how people will pay close attention to what is in a document when they have to sign their name to it! I have seen cases on my own projects as well as those I consulted on where misunderstandings are cleared up prior to charter sign off. This has and will save many hours of effort avoiding taking a project down the wrong path. For these reasons I highly recommend getting a real signature and posting a PDF image of the Project Charter in the project repository.

Once you have a signed-off charter, you now have one of the deliverables subject to formal Change Management. Any request that would change any component of the charter should have a formal change benefit/impact statement signed off and the Project Charter should be changed to a new version and signed off again.

In my next post we will move to the Planning Phase and begin a multi-part discussion on the Project Management Plan.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!

Kick The Field Goal! What American Football Can Teach Us About Project Management

Professor of Project Management General

With the NFL season about to begin I thought I would share a project management lesson I learned many years ago from, oddly enough, watching an NFL telecast. The color analyst was the legendary John Madden.

Team A was trailing Team B 21-0 but it was still early (mid second quarter). They were confronted with a 4th down and goal to go situation from the 5 yard line. Fans of Team A, concerned with the large deficit, were no doubt screaming for their team to go for the touchdown. This is when Madden made the point that resonated with me from a project management perspective:

“I would kick the field goal here. The longer you are at 0 points, the harder it becomes to move off of 0. Once you have points you have something to build on.”

There are those in the modern sports analytics field who might argue this but that is not the point of this post. Madden’s comment made me realize that the longer a project goes without delivering business value (known as the “Business Objectives” of the project), the harder it gets to deliver them. Some of the main reasons for this are:

  1. Business or IT Management and Stakeholders continue to propose grand ideas which significantly increase the scope without going through formal Scope Change Management.
  2. The Project lacks a Charter or Definition with sufficient detail, making “scope creep” hard to define.
  3. The Project is trying to deliver the Project Objectives all at once instead of a phased approach which can deliver some business value earlier.

I recommend having well defined Business and Project Objectives. Manage Scope jealously. Deliver at least some of the Business Value as early as possible and in phases.

The longer a project drags on without delivering something, the harder it gets to deliver anything. So”Kick the Field Goal”. Get off of “zero” as soon as possible. Your business and project (and your career) will be the better for it.

A reminder that my Kindle book “Project Management For The Real World” is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!

The Project Charter – Constraints

Professor of Project Management Project Initiation ,
Initiation

Constraints are any limitations to solution options that have been imposed on a project. It is important to know these early on so time is not wasted pursuing these options. Here are some examples:

  • The solution must work with Microsoft Edge as that is the company standard
  • The solution must be an Oracle product for seamless integration with our other Enterprise systems
  • The new department we are adding as a result of this project must fit into this 30′ x 50′ area

When project constraints are uncovered, be sure to understand the reason why. It is possible some constraints could be removed. I was involved with a project where the service provider was already selected but without looking at the competition. I convinced my business partners to conduct formal “Request for Proposal’s” with the leading competition and the result was a different provider was selected.

Constraints are included in the Project Charter so that the Sponsor and Core Project Team understand and agree.

My Kindle Book, “Project Management For The Real World”, is available at

http://www.amazon.com/do/b089krddvn

Now available in paperback!

The Project Charter – Issues

Professor of Project Management Project Initiation ,
Initiation

Issues are any event or known problem that will negatively impact your project’s schedule, scope, budget or quality. Issues differ from Risks in that Issues are 100% will or has happened whereas Risks may or may not happen with a probability less than 100% and greater than 0%. Risks that are not actively managed are more likely to become Issues.

At Project Charter time, you want to highlight the most severe impacting issues. Look specifically for the impacts in the following areas:

  • Schedule – issues that will delay your project start, or impact key milestones and the target completion date.
  • Scope – Issues that can prevent you from delivering the defined project scope
  • Budget – Issues that can cause the project to go over the allowed budget
  • Quality – Issues that will affect the quality of the delivered solution

In a future post I will address Issue Management in detail.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!

The Project Charter – Risks & Assumptions

Professor of Project Management Project Initiation
Initiation

In upcoming posts I will discuss Risk Identification and Management in detail. For now, you just need to know that a risk is an uncertain future event that can have a negative impact on your project’s schedule, scope, budget or quality. The event has a probability of occurring less than 100% and greater than 0%. If the probability is 100%, then you have an issue, not a risk. Some risks can have a positive impact but we will not discuss that here.

You state the risk as follows:

  • If <risk event> occurs, then <state the outcome that affects your project> causing the project  to be impacted in the following specific ways <scope, schedule, budget, quality>.

At the Project Charter level, you are interested in identifying only the highest impact risks so that your risk management strategies can be accounted for in the scope and schedule.

Some Project Charters will list “Assumptions” in its own section. I have eliminated assumptions from my own charter template as I feel if you have assumptions that can impact your project, then that is just another form of risk. I now include any assumptions in my risk section.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!