• Authors

  • Calendar of Posts

    April 2024
    M T W T F S S
    1234567
    891011121314
    15161718192021
    22232425262728
    2930  

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 7 other subscribers

All posts tagged PMP Handbook

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…

 

Leave a comment
by dgrimm100 on December 27, 2011  •  Permalink
Posted in Notes
Tagged , , , ,

Posted by dgrimm100 on December 27, 2011

https://danspmblog.wordpress.com/2011/12/27/planning-the-plan/

Monitoring and Controlling Process Group

To start off the fourth of what are becoming 5 increasingly difficult posts to write, I wanted to document my new-found understanding of the difference between Monitoring and Executing. Last week, when I was working on the Executing process group, I noticed that Quality Control was listed under Executing. Right next to it on the chart was Quality Assurance, listed under the M&C group. Since I was a very inexperienced novice when I worked in Quality and Data Management, and was working with amorphous deliverables like home visits, and documentation quality, I had always used these two concepts interchangeably. So, if they’re interchangeable, why would one be in Executing and one be in M&C (BTW, M&C will be my shorthand here, and in most posts for this Process Group, because Monitoring and Controlling is freaking long).

Stumped, I posted the question to a couple of PM groups on LinkedIn. 35 similar responses later, I know have a very good understanding of what QA is, and how it differs from QC (see note 1). QA is the little slip paper in your jeans pocket when you buy a new pair (you know, the ‘this article was inspected by #47 slip), while QC is the reviewing the process to make sure that the jeans manufacturing team is adhering to the controls of the project to keep the deliverable under cost for the client. QA is running spell check before the thesis paper goes to the printer. QC is handing the thesis paper to your advisor to make sure the line of argument is cogent throughout and addresses what you actually researched.

That’s what we’re looking at here. M&C concerns itself not directly with the product itself, but the process of obtaining that executed outcome. A PM friend of mine talks about widgets to highlight the unit-ness of things, even if they don’t seem like units (test cases, for examples). In this case, were she to describe M&C, she would say it’s role is to monitor and control the project-as-widget. In the end, a PM leads a production team. Their team is producing a finished product: the project-as-widget. M&C is making sure the project-as-widget is meeting the requirements specified in the Planning process group.

Is the project team meeting it’s performance goals, based on the baselines and performance metrics set in Planning (Mulcahey, PMP Exam Prep, 6th Edition, 43)? If it isn’t, why? If those whys are critical, do you need to change something in the project? Right, aren’t you glad you created that change control process back in Planning? Because now you get to use it. And, when you were in Planning, your change control process should have basically been a) request changes, b) perform integrated change control, c) approve changes, d) notify stakeholders of changes (directly drawn from Mulcahy, though she lists these as steps in M&C, when they are really spelled out in the change control plan, but why split hairs?).

During this phase, you also perform QC and risk audits. What are risk audits? Potentially another question for the LinkedIn masses…

Note 1: If you also followed the LinkedIn conversation on the Project Manager Community site, you would notice that about 50% of people swapped QA and QC. Everyone agreed on the concept that one controls the actual product and the other controls the process. Since Mulcahey uses QA in Executing and QC in M&C, I went with that here. Since Executing is always listed before M&C, a helpful mnemonic would be that QA has ‘a’ which is before the ‘c’ in QC, right?

Leave a comment
by dgrimm100 on November 16, 2011  •  Permalink
Posted in Uncategorized
Tagged , , ,

Posted by dgrimm100 on November 16, 2011

https://danspmblog.wordpress.com/2011/11/16/monitoring-and-controlling-process-group/

Executing Process Group

It’s late on a Sunday night, and I’m looking over the list of activities for the Executing Process Group (Mulcahy’s PMP Exam Prep 6th Edition, 43). Unlike with the Initiating and Planning process groups, there is no clear line of logic with these steps. Maybe because it’s late, or maybe because every project is different, and the execution takes a different path every time.

I have to say, I love the first task: ‘execute the work according to the PM plan’ (Mulcahy 43). Great. Thanks for that clarifying statement. Or the regular refrain from the guy who lead my first PM course, 2 years ago: “Plan the work, then work the plan!”

Like the rest of the groups, it’s fairly clear that the activities are lumped into categories. Actually, the categories coincide with the upcoming chapters. The first section is integration management, which entails integrating the work of the whole team into an outcome. This includes ‘executing the work according to the PM plan’. It also includes staying within the defined project scope.

The second section is quality management. Yes, some of this will come back to haunt us in the Monitoring and Controlling process group, but quality management needs to take place at the time of executing. Quality audits can occur. Processes can be performed, and improved. This will make the monitoring piece go a whole lot smoother.

Third is Human Resource management. People are doing the executing, so managing the worker-bees falls under the Executing stage. Evaluting their performance, praising them for a job welldone and incentivizing them to work harder. Working with them to identify issues and tracking them to avoid risks.

Finally, there is vendor management. Hey, if you have to manage the internal worker bees, you have to manage the folks at the outsourcing company who are managing their worker bees, right? Having just wrapped up a project that was 6 weeks late, in part because the vendor didn’t finish all of their work on time, I can attest that the vendor can be as critical as the internal staff.

Also, sprinkled throughout the list of steps are communications. Meetings, emails, status reports, risk assessments from weekly team meetings.

The short summary of this phase, which is proving incredibly hard to summarize, is that if a task involves producing anything that was already on the project plan, it’s in the execution process group. If it’s making sure the project is on time, on scope and on budget, it’s in the next process group: monitoring and controlling.

 

Leave a comment
by dgrimm100 on November 13, 2011  •  Permalink
Posted in Notes
Tagged , , , ,

Posted by dgrimm100 on November 13, 2011

https://danspmblog.wordpress.com/2011/11/13/executing-process-group/

Lessons learned notes

Lessons learned are a collection of things that went right, things that went wrong, and things that should be done differently. They can be collected at the end of each phase, and at the end of the project. (Mulcahy 32)

Lessons learned should include technical aspects of the project, tying them to reality. They should look at project management, including planning and risk prevention. And they should look at management, including communication. (Mulcahy 32) The documentation looks at the causes of the issues, the reasoning behind the corrective action (PMBOK 261).

Lessons learned should be shared throughout the organization, probably through a PMO, or whatever the existing structure for sharing this information is.

During the initiating phase, lessons learned from other projects should be reviewed as part of identifying risks. They should be certified during the Closing phase of the project, and stored.

I had identified back a few weeks ago that I would be conducting a lessons learned exercise for a CRM project I was working on. That exercise is finally scheduled for next week.  More to come.

Leave a comment
by dgrimm100 on November 4, 2011  •  Permalink
Posted in Applied PM theory, Notes
Tagged , ,

Posted by dgrimm100 on November 4, 2011

https://danspmblog.wordpress.com/2011/11/04/lessons-learned-notes/

Initiation process group

Happy International Project Managers Day! In honor of it, and because I’ve been very burned out at work, I took the day off. I made some progress reading into Chapter 3 of Mulcahy’s PMP Exam Prep, 6th edition.

The focus of this chapter is to review the project process groups and the activities in each one. The process groups are Initiating, Planning, Executing, Controlling and Monitoring, and Closing. In the book, she provides a table of all of the process groups, and the activities. I’m working on memorizing, or at least working out the overarching narrative of the project, for each one.

I’m writing out the steps in a spreadsheet that I can reach back to when necessary. I’m not going to post that here, because it’s fairly well copy-writed. What I will do is try to describe the process group’s narrative flow, so I can internalize it better.

Before a project gets into the initiating phase, the organization has already determined it’s strategies for what it wants to accomplish. It identifies a goal, and decides that to reach that goal, a project needs to be performed. A business case is developed for reaching the goal and documenting how that goal will further the organizational strategy.

Once the business case is finished, the project initiation can begin. The first step is to hiring a project manager. The project manager needs to first understand the culture of the organization and its structure, to determine how the project will be ultimately shaped. This goes back to the post about organizational structure (functional, matrixed, projectized). Coupled with this phase is also determining what the organization’s processes for projects are, and the history with similar projects  (Mulcahy 43).

Knowing this background information, the project manager can dig into the business case, viewing it from within the context of the organization. Sensing the scale of the business case, the project manager can also determine if the project will need to be divided into phases. When reading the business case, you can determine the initial requirements for the project and potential risks  (Mulcahy 43).

It’s important to note, that these requirements are still within the context of the organization’s strategies. So, instead of just focusing on ‘completing this system’, there are larger questions at stake, about other pieces of the strategy, including vendor selection, long-range plans that this system are a part of, etc. (Mulcahy 44).

From the requirements, measurable objectives become clear. These are the hows and whens of the project. No longer are we interested in ‘growing market share’, but in ‘growing market share by 20% through streamling Customer Relations’.

With measurable objectives come, a sense of the requirements, and an overview of the risks, a project charter can be built (Mulcahy 43). From the charter documents I’ve drafted, I can identify that the history of both this business case, and the company’s history with projects of this nature are included, as are 30,000 foot overviews of timelines and budgets. The business case may have identified these already. But, this charter is the first of the project documents.

And finally, there is the question of stakeholders. Mulcahy lists the identification of stakeholders, and developing a stakeholder management plan at the end of the phase, though she does identify that these steps don’t need to be in order (42-43). I disagree with keeping these at the end. Stakeholder identification is often included in the charter, based on the business case, and the initial requirements. Stakeholder buy-in can be critical for getting approval for the project charter, and for ensuring the project is properly supported and resourced. I would opt to include identifying stakeholders before completing the charter.

While she doesn’t identify it here, I would suggest that approval of the charter indicates the end to this phase.

Finally, this phase appears to be the most cut-and-dry, and the one that most seldom is returned to. I could be proven wrong, though.

 

Leave a comment
by dgrimm100 on November 3, 2011  •  Permalink
Posted in Notes
Tagged , , ,

Posted by dgrimm100 on November 3, 2011

https://danspmblog.wordpress.com/2011/11/03/initiation-process-group/

The PMI Code of Ethics

I’m keeping this as a separate entry from the PMP Handbook entry for a couple of reasons:

  1. I want to be able to come back to reference this.
  2. I know that the Code of Ethics is on the test. The price of the exam is not.
  3. It’s probably important.
So, as part of being a PM, you have to adhere to a code of ethics. Not the end of the world. Looking it over, it’s actually kind of the standard stuff you would expect.
The purpose of [the] Code is to instill confidence in the project management profession and to help an individual become a better practitioner. We do this by establishing a profession-wide understanding of appropriate behavior. We believe that the credibility and reputation of the project management profession is shaped by the collective conduct of individual practitioners.
The code applies to PMI members [so me, for instance]. It also applies to applicants for PMI certification [theoretically not me, until I actually apply], PMI certification-holders [me soon], and PMI volunteers.
The core values: responsibility, respect, fairness and honesty
  • Responsibility
Aspire to take actions in best interest of society, public safety and the environment
and accept only assignment consistent with your background, experience, skills and qualifications.
     [The comment on these aspirations indicates we should notify project sponsors when the completion of a project requires us to exceed our qualifications. Notice how these are the aspirations?]
Aspire to fulfill commitments that we make; take ownership of errors and omissions to correct them promptly. We accept responsibility and consequences of errors and omissions.
Must uphold policies, rules, regulations and laws that govern our work activities. We must report unethical or illegal conduct to appropriate management. We bring violations of the code to the appropriate body.
  • Respect
We listen to other points of view. We approach people we disagree with. We conduct ourselves professionally. We negotiate in good faith. We do not exercise power of our position for personal gain. We are not abusive.
     [This seems to be the easier of the two to maintain so far.]
  • Fairness
Demonstrate transparency in our decision making process. Reexamine our impartiality. Provide equal access to information when allowed. We disclose potential conflicts of interest. We don’t participate in favoritism, nepotism or bribery.
    [Later, there is a discussion of the need for these codes to level the playing field across cultures. I suppose that’s reflected here.]
  • Honesty
Seek to understand the truth. Are truthful in our communications. Provide accurate information in a timely manner. Make commitments in good faith.
   [Maybe it’s just my upbringing, but this entire core value is embodied in the ‘Respect’ value. I suppose they felt it necessary to carve this out specifically. Remember that. It’ll be on the test.]
One last note on the Code of Conduct. In August of this year, the test was changed. There used to be a Code of Conduct section of the exam. Now, the Code of Conduct is embedded in all of the other sections. Guess I’ll need to pay attention to these things, then.
Leave a comment
by dgrimm100 on October 18, 2011  •  Permalink
Posted in Notes, PMI
Tagged , ,

Posted by dgrimm100 on October 18, 2011

https://danspmblog.wordpress.com/2011/10/18/the-pmi-code-of-ethics/

The PMP Handbook

In one of the earlier posts, I talked about the first step being to figure out timelines for this process. Tonight, I downloaded the PMP Handbook and reviewed the entire thing. While the book doesn’t give me much insight into what a PM does or is, it did enlighten me on the PMP Certification process.

PMP Handbook notes

Eligibility Requirements:

  • Tertiary degree
  • 36 months of non-overlapping work leading and directing project tasks since 2003 (past 8 years)
  • 4,500 hours of work leading and directing project tasks since 2003 (past 8 years)
  • 35 hours of training
Currently, I have 24 hours of training, at least 23 months of work and the degree. I have to count the rest of the hours and months.
Gather all the documentation BEFORE you begin the application. You have 90 days to finish what you start with the application. Plus, you have 90 days after the application if you are in the approximately 10% who is audited. So, I need to make sure to get copies of everything up front!
The application takes 5 days to process. But, scheduling the exam could take 3-6 weeks. So, to meet my 1/15/12 deadline, I would need to apply by 11/29. Hmm….
It’ll cost me $405 to take the exam. Hello, Christmas present.
The rules about the exam are straightforward. I’ve taken the SATs and AP exams. I can figure out the rules. Plus, I’m sure they’ll remind me again. Though, no calculators. I have to use theirs…
After I pass, I have to deal with PDUs. 60 PDUs in 3 years. But, 15 PDUs per year can be from working professionally as a PM for 6 months, minimum. So, stay working as a PM, you only need 15 PDUs every 3 years. Cool
Then, there is the code of ethics. I’ll do another entry on that.
Leave a comment
by dgrimm100 on October 17, 2011  •  Permalink
Posted in Planning, PMI
Tagged , , ,

Posted by dgrimm100 on October 17, 2011

https://danspmblog.wordpress.com/2011/10/17/the-pmp-handbook/