• Authors

  • Calendar of Posts

    August 2017
    M T W T F S S
    « Dec    
     123456
    78910111213
    14151617181920
    21222324252627
    28293031  
  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 7 other followers

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.

 

Planning Process Group

Last week, I started narratives for the process groups, based on the Rita Mulcahy chart of process group steps, by beginning with Initiating a project. The next process group is planning.

For this process group, Mulcahy insists that there is a set order to these steps. Down the line, I’m sure I’ll figure out the logic to why these are in a set order.

So, after the project is initiated, one begins planning, and in a totally cyclical fashion, one begins Planning by planning how to plan. Seriously. Once the plan for planning is in place, you can finalize the requirements and begin creating the project scope statement (Mulcahy 43).

I would like to take a moment to express my surprise that the project scope statement is here in planning and not in initiating. While the project charter document discusses what the project will be including and not including, I suppose you can’t finalize the scope statement until the requirements are finalized, which happens in planning. I could see strong arguments made for the scope being in the Initiating phase, but oh well.

Following the completion of the scope, and I would suppose, building off of the analysis of the existing systems from initiation, you determine what will need to be purchased. Since making the determination to purchase some aspects trims those pieces out of the in-house work, after you decide what’s being bought, you can determine who is on the team, in-house. If you’re outsourcing the weaving, then the staff weavers don’t need to be part of the project team, nor do the loom-setup staff.

Now that you have staff, you can plan what work to assign them, in the WBS (Work Breakdown Structure) (Mulcahy 43). The WBS is everyone’s favorite part, at least if you work in my company, since it’s the most readily accessible portion of MS Project. More (much, much more) on this later.

So, tasks broken out in the WBS, you can create an activities list, and string them along into a network diagram. With the work diagrammed out, you can estimate the resource requirements to assign to the work, estimate the time needed to complete the tasks, and with time linked to tasks, you can see which tasks take longer and which define the critical path (the series of interrelated steps that define the total timespan of the project). If you take the critical path of 25 weeks, add it to a start date of tomorrow, you get a completion date, which means you have a schedule! Schedule x overhead= estimated expenses=budget.

So, now we have a network diagram, a schedule, and a budget, we have to plan to stick to this set of guidelines, so we build some quality metrics and processes to measure them. I like to think that this part should be easy, but it seems to be easy to skip, in my opinion.

Looking through these steps of the planning Process Group, I can kinda see phases going on here. Phase 1: Planning the Planning (the anal-retentive part of this). Phase 2: Building the execution plan (WBS, activities list, schedule, budget) (the concrete part of this). Phase 3: The Monitoring of the plan. Phase 4: Documenting the planning. We’re in Phase 3 at this point.

Notice how these 4 phases mirror the Project Lifecycle? It’s like a crazy project fractal.

Anyway, on to phase 3 of this: so, we have the quality metrics portion of this down. Now, if we don’t adhere to the quality metrics, we need a process improvement plan. Then, knowing how we are going to measure things, and what activities we want to complete, we can assign roles and responsibilities. This must be, logically, more than just “Bob, you’re responsible for overseeing the loom pattern development” but also, “Bob, you are responsible for submitting the weekly loom pattern development audit checklist that was documented in the quality metrics plan.” Responsibilities are more than just concrete tasks to get done.

Now that Bob needs to get the audit checklist to the project group, we need to plan the method of communicating that. So, communication plan (to monitor the quality metrics which monitors the work). Makes sense, right?

And with a communication plan, a quality plan with process improvements, a schedule, a budget, an activities list, a critical path, a network diagram, a WBS, and a list of things that needs to be purchased, what could possibly go wrong? Everything on the risk list that you can now develop and start planning for, too.

And, as we plan for risks, we need to tweak the WBS to account for Bob’s potential quality audit findings that could delay loom setup, which could delay prototype production, etc, so we have to repeat some of the above steps. Until we’re happy, we need to repeat phases 1-3.

Now, for phase 4, which is really the same as the Project Closing process group, as we’ll see later: we finalize the plans (including procurement documents), gather all the documents together, and get signoff from the stakeholders, and we’re done. Oh, no, wait, we’re done planning. Now, finally, we can kick off the project and get underway.

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.

 

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.

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.
%d bloggers like this: