• Authors

  • Calendar of Posts

    June 2017
    M T W T F S S
    « Dec    
     1234
    567891011
    12131415161718
    19202122232425
    2627282930  
  • 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…

 

Business Case selection

Over the weekend, the local PMI chapter announced their Winter 2012 courses. Included with them is a 6 session PMP Exam Prep course. I spoke to my manager at work, and while I need to front the $850, I got the commitment that the company will reimburse me, so it looks like I’ll be taking the class throughout the month of January and into February.

We’re continuing on about Integration management. We’ve already looked into what goes into a project charter, which is part of integrating activities into the unified whole of the project. One of the inputs to integration management is the statement of work (PMBOK 75). Essentially, this is the narrative description of products or services to be delivered by the project. This includes the business need, the product scope description and the strategic plan.

The second critical input to the charter is, a a rather circular manner, the business case (PMBOK 75). It’s in a circular manner in that the SOW includes the business need description, which is identified in the business case. So, the business case is required because it’s required for the SOW. It seems a little repetitive, but I’m finding that there are times that PMBOK documentation is like that.

Anyway, the business case! It “provides the necessary information from a business standpoint to determine whether or not the project is worth the required investment (PMBOK 75).” The business need and the cost/benefit analysis are included here. The business case argues for the project, and could have ramifications on the project implementation.

Rita Mulcahy goes on to describe methods of selecting projects, by breaking them down into ‘benefit measurement methods (comparative methods)’ and ‘constrained optimization methods (mathematical methods)’ (Mulcahy 106). She provides a lot of detail about economic models, which are categorized under comparative methods, but then indicates that all you need to know is the difference between benefit measurement and constrained optimization methods. So, I won’t go into worrying too much about the Present Value and Net Present Value calculations.

Finally, the last two inputs for the project charter are essentially the same thing: the working environment. We saw these in the initiating process group: 1) Determine company culture and existing systems and 2) Collect processes, procedures and historical information (Mulcahy 43). These, which are listed here as enterprise environmental factors and organizational process assets, are directly linked to 1) and 2), above (Mulcahy 111). The modify how the charter is drafted, and even how the business case was selected.

Thank goodness this post was about the Initiating phase. If it was about the Planning phase, I would be screwed. Why? Because I had intended the post to be about project selection methods. Instead, I wobbled to a number of different topics, because I didn’t plan how I was going to write it, or how I was going to have the time to finish it. Sorry.

%d bloggers like this: