• Authors

  • Calendar of Posts

    October 2017
    M T W T F S S
    « Dec    
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    3031  
  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 7 other followers

Planning the plan

First, an apology about not posting often enough. It’s been the holidays, much of my spare time has been eaten up. So, I haven’t posted much. Sorry.

Second, I am officially registered to start the PMP exam prep course offered through the PMI chapter in Baltimore beginning on 1/7/12. I suspect that the first session or two will recover everywhere that this blog has been so far, so I should have more notes on how to refine my understanding.

Third, I’ve been trying to write this blog entry for a couple of weeks now. 2 weeks ago, we launched a change to our IT systems at work, which required me to oversee testing on the weekend. I was kept just busy enough that I was able to read a couple of pages of Rita, but not write my notes about it. So here goes.

We’ve been looking at the Integration Management area of knowledge over the past few weeks, which encompasses virtually all of the the Initiating process group, some of the critical steps of the Planning process group, and a little of the Executing and M&C groups, and resurfaces with much of closing. In the last post, we looked at how Integration Management is integral to Initiating.

In the table that Rita provided with the elements of the process groups associated with Integration Management, she identified planning the plans as the first Integration Management piece within the Planning process group (Mulcahy 98). So, every project has management plans (duh!). “Management plans are the strategy for managing the project and the processes in each knowledge area (Mulchay 112).”

More specifically, management plans  answer the question of “how will I define, plan, manage, and control scope, schedule, cost, quality, HR, etc (Mulcahy 112)?” Because of the work we’ve already done in understanding the business case, the company’s culture, resources, and procedures, we have an idea of how these plans will be modified to accommodate this specific project. No 2 sets of plans are identical, and even which plans are used varies depending on need.

Of course, the organizational assets dictate how the plans are created; for instance, if there is an existing change control procedure within the company, then the change management plan will mirror that (PMBOK 80).

Each of the Management knowledge groups has plans specific for it. Integration Management is focused on: Change management, configuration management, requirements management and process improvement (Mulcahy 113).

The project management plan integrates all of the other plans into a unified whole. It includes the baselines for the project. It also includes the project management tools that will be used on the project (for instance, which additional plans are being used); a requirements management plan; a change management plan (yes, it really includes this!!); a configuration management plan and a process improvement plan (remember, improving the process is a critical piece of the M&C process group) (Mulchay 113).

The development of the project plan mostly occurs through the use of expert judgement (PMBOK 81). This is when you circle the project team, and start working with them to define how to tailor the process to the project need, determine resources you have available and make sure their skills meet the needs.

Baselines: The project management plan includes baselines for the work that is going to be done. It includes the scope baseline (project scope, work breakdown structure and WBS dictionary- covered later in Scope Management), schedule baseline (scheduled start and end times for milestones), and cost baseline (time-phased budget) (Mulcahy 114). Why are baselines critical? Without baselines, it’s impossible to tell what is being accomplished on track. The project manager needs to track these baselines to identify deviations. When the work is deviating and the project cannot be adjusted to meet the baselines, then the change management process kicks in (Mulcahy 114). Most critically, deviations to the baselines usually stem from inadequate risk assessment, since it’s a risk that the baselines are changing.

Requirements management plan: We’ll discuss this more indepth as part of scope management.

Change Management plan: I like Rita’s statement: “…you need to stand as a barrier to prevent unnecessary changes and to plan the project in a way that minimizes the need for changes…Changes should not be undertaken lightly (Mulchay 114).” I think this summarizes what a change management plan is. How can you prevent unnecessary change (while acknowledging that projects will always change). The plan should contain the change control procedures; what the approval levels for changes are; the creation of the change control board; the plan outlining how changes will be managed; and the organizational tools used to track change (Mulcahy 115).

Configuration Management plan: I have to admit, this plan is new to me. The configuration plan “defines how you will manage changes to the deliverables and the resulting documentation, including which organizational tools you will use (Mulcahy 115).” Got that? This is the convoluted way of saying, ‘have a plan for version control of the documents, and the deliverables’. I think it’s a great idea.

Finally, Process Improvement Plan: exactly what this sounds like. This is the opportunity to discuss what processes will be used for executing the project, and discussing how these processes will be reviewed and improved up0n as the project progresses. This plan helps streamline costs, resources and time constraints, and, if the process is already one that the company uses, it would help improve best practices.

With all of these plans in place, it’s now time to start the project, yes? No! The important piece that PMI sees when it comes to project planning is that the plan must be able to be met. It must be realistic, it must be able to be achieved. Therefore, it needs to take into account conflicting priorities for the team members. It needs to only include scope that can be achieved, and the stakeholders have to be aware of what cannot be achieved. And, most critically, the plan needs to be signed off on by the team. Everyone has to be on board with the plan before the rest of the project can start. This is why the planning process group looks at the iterations of the Plan. The Plan needs to be reworked until its final (Mulcahy 115-117).

This raises a real-life issue about planning, which I’ll raise in another post…

 

Advertisements

Project Management Definitions

To begin studying for the exam, I am beginning with Chap 2, in Mulcahy’s PMP Exam Prep 6th Edition, which focuses on some of the ground concepts. I’ve thrown in additional info from the PMBOK 4th edition (specified below).

Definition of a Project-

  • Temporary
  • Has a beginning and an end
  • “creates a unique product, service or result.” ( pg 21)
  • “The end is reached when the project’s objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists” (PMBOK pg 5)
  • “Can involve a single person, a single organizational unit, or multiple organizational units (PMBOK 5)
Definition of Operational work-
  • Ongoing, no clear beginning and end
  • Follows existing procedures (PMBOK 5)
Example: ‘can you figure out what is wrong with this broken process, and fix it?’ This is 2 projects- 1)figuring out what’s wrong (has a beginning and end) and 2) fixing it (has a beginning and end, but only after project 1 is complete).
34% of projects are successful, so a project needs to be finished on time, on budget, and within scope.
For the exam, questions focus on large projects, with “200 people on the team, last[ing] longer than one year, and [having] a value of $1,000,000” (pg. 22)
What is Project Management?
   5 Process groups:
  • Initiating
  • Planning
  • Executing
  • Monitoring and Controling
  • Closing
   Knowledge Areas (PMBOK 6)
  • Scope
  • Quality
  • Schedule
  • Budget
  • Resources (human and otherwise)
  • Risk
  Knowledge Areas (Mulcahy 22)
  • Project Management Framework
  • Project Management Processes and integration
  • Scope
  • Time
  • Cost
  • Quality
  • Human Resources
  • Communications
  • Risk
  • Procurement
Project Management, Program Management and Portfolios
  A project has a beginning and an end, and creates a unique product.
  A program is a collection or projects that are managed together to create value.
  A portfolio is a collection of programs and projects that are organized around a strategic business goal. (PMBOK 8-9)
An example from my work: the implementation of a new Medicaid plan is a project. The coordination of all new Medicaid expansions is a program. Government-funded insurance initiatives, as a whole (Medicaid, Medicare Advantage, Insurance Exchanges if we get there) make up a Portfolio.

Scope of the blog

Having worked in various interpretations of project management for the past few years, I’ve finally decided to move my career ahead and get a PMP certification. The goal of this blog is to track my thoughts on the process, and to take notes on study materials.

Currently, it’s October 3rd. I would like to have sat for the exam by January 15th.
In the next 3 months and 12 days, I need to:
1) quantify my experiences
2) learn all of the test material
3) obtain at least 16 more classroom hours
4) apply for the exam
5) survive any application audits
6) take the exam

My goals this week:
1) Research application turn-around times
2) Find 3 different class alternatives
3) Read first chapter of study materials
4) Join PMI

Goals next week:
– Download application
– Download experience tracking tool
– More studying

%d bloggers like this: