• Authors

  • Calendar of Posts

    May 2018
    M T W T F S S
    « Dec    
  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 7 other followers

  • Advertisements

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.


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.

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 Organization

Continuing with Mulcahy’s Chap 2.

Project Management Office:

Centralizes the management of projects. May do one (or more) of the following:

  • Provide the background structure for projects within a company (policies, methodology, templates) (Mulcahy 23)
  • Provides support and guidance to others in managing projects, provides training and tools for project management (Mulcahy 23)
  • Runs some or all projects (Mulcahy 23)
  • Also, coordinating communication across projects (PMBOK 11)
Differences between PMO and Project Manager:
  • PM focuses on project objectives, PMO focuses on program scopes and aligning projects for strategic benefits
  • PM controls project resources, while the PMO coordinates resources across projects
  • PM manages constraints, PMO manages methodologies and standards at the enterprise level (PMBOK 12)
Project Objectives
We need to assume we manage to objectives. This requires establishing concrete and unambiguous objectives, reviewing progress toward them throughout the project and implementing corrective action on the ones that won’t be met, and terminating the unrealistic ones. (Mulcahy 24)
Features of a project, including cost, time, risk, scope, quality, and resources. This are established in the charter, and are prioritized as to importance (Mulcahy 25). To successfully complete the project, we need to hit the objectives, within the constraints. Or, to use a sports analogy (which is highly unusual for me): get the ball through the goal, without going outside the boundaries and before the buzzer goes off, while only using the teammates currently on the field.
“People or organizations whose interests may be positively or negatively impacted by the project (Mulcahy 25). For the exam, they are recommending we think of them as assistant team members, who’s desires, goals and inputs are sought out throughout the project. Contributions for stakeholders are not necessarily constant or equal, and can include occassional input, constant input, and sponsor level support (PMBOK 24). Stakeholders obviously have differing goals, occassionally which conflict with each other, that need to be managed (PMBOK 24).
Stakeholder identification is critical at the outset, to make sure that needs are being met up front and aren’t addressed after the fact (PMBOK 24). Thinking back to my lessons learned about change management, part of the issue was that when Compliance and Quality Assurance started complaining, it was out of the blue, since neither group was included as stakeholders from the beginning of the project.
Organizational Structure
The company’s internal culture and organizational structure impacts the project. Mulcahy identifies 3 styles of organization: functional, projectized, and matrixed. While most of us probably work in a functional environment, she recommends assuming a matrix environment unless specified differently (Mulcahy 26).
  • Functional: Most common form of organizations. Siloed functionality, projects generally occur within each silo. If work is needed from a different department, the request occurs between department heads. Team Members perform project work in addition to daily work. Functional manager is the most powerful (Mulcahy 26). Project Manager has little authority, little resource availability, perhaps part-time project admin staff, role in the project is part-time (PMBOK 28)
  • Projectized: All work is organized around projects. Staff answer to project managers. When the project is over, staff are assigned to the next project or leave. (Mulcahy 27). I would imagine this is most similar to a consulting firm.
  • Matrix: A blend of functional and projectized, where the PM has more power than in a functional environment, but the staff still answer to functional managers. Communications go between staff and both the project manager and the functional manager.
  1. Weak matrix: PM has limited authority or resource control, is usually part time, and the Functional manager controls the budget
  2. Strong matrix: PM has high amounts of authority and resource control, controls the budget and is full-time engaged in the project.
  3. Balanced matrix: PM has medium amount of authority, some budget control and may be full or part time. (PMBOK 28)
Life Cycle: Project life cycle is generally sequential and occasionally overlapy set of phases. THe phases, duration and names are determined by management needs , the nature of the project, and the area of application. The lifecycle provides the basic framework (PMBOK 15).
Project Life cycle: Can be simplified into: starting, planning, working, finishing. During the beginning of these phases, the cost of the project is low, the stakeholder influence and risk is high, but the cost of making changes is very low. As the project progresses, the stakeholder influence and risk reduces, while the cost of the project and the cost of changes increases. (PMBOK 17). The project life cycle is occassionally refered to as the organization’s methodology for projects. The five phases for Project and Product Life Cycle are: Conception, Growth, Maturity, Decline, and Withdrawl (Mulcahy 29)
Product Live Cycle: The complete lifecycle of a product from conceptualization to create to development to release to upgrades to withdrawal. This can span many projects. (Mulcahy 29). Efficiencies may be gained by managing all the projects under one product together. (PMBOK 16).
Project Management Process: There are 5 Process Groups in the Project Management Process
  • Initiating
  • Planning
  • Executing
  • Monitoring and Controlling
  • Closing
More about these later

Project Hour Tracking Tool

As part of my preparation for the PMP application, I went in search of a tool for tracking Project Management experience hours.

In response to a question I posted to the Project Management group on LinkedIn, I received a tool from Geraldine M. that she had used when applying for the PMP certification.  I thought I would post the tool here for others to find and use.

Project Management experience tracker

From Geraldine:

“That part of the application is a real challenge (nightmare). I was in the same boat where tracking the details per project was very difficult. I created a spreadsheet that was organized the same way the application is, with a column for each project and rows for the different project tasks. I created formulas to spread the project hours across the tasks in a way that felt realistic for the kind of work I’ve done, and then manually tweaked…”

One of the inspirations for this blog

Being referred as a resource for information can certainly be an ego-booster.

About 2 months ago, a co-worker sent me an email from a friend who was enrolled in a college IT management course. The friend was assigned a class project to create a project proposal to act as a consultant to advise an agency who had been burned in a poorly managed software development contract. The class project asked for a report on the proposal to use a PM to bring the project back on track, and to develop a budget and Gantt chart.

My co-worker didn’t know anything about formal project management, but she knew I did, so she sent the information to me. I spent two hours or so creating a framework of a plan for how to tackle the assignment, and provided advice to the student.

Two weeks ago, the student reached back out to me with a bunch more questions about the class assignment, which was due at the end of that week. Over the course of the day, with emails back and forth, she was able to sort out a direction to head with building the proposal.

On Friday, last week, I got an email from her, informing me that she had gotten an ‘A’ on the project. I just reviewed it, and while it’s a little light on specifics, owing to the nature of the class project, it’s more coherent than a lot of the proposals I’ve seen floated around the office.

Working on the advice definitely solidified my belief that I actually know something about project management, and is driving me on to getting the PMP in the Spring.

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.

Lessons learned about change control

Two weeks ago, I posted that I was planning a lessons learned meeting for the project I’m leading currently. That meeting hasn’t happened, the project has not ended, and we’re all still chugging along. And that in itself represents a lesson learned.

I work in health insurance. We are in a highly regulated environment, and that includes deadlines for when we can and cannot accept applications for new enrollments. 10/1 was one of those deadlines. The project I am working on was to allow us to accept telephonic enrollments through a custom built CRM into our enrollment systems. The project was delayed when the key developer walked off the job after leading us on for over 2 weeks. This pushed us extremely close to the 10/1 deadline. The core work for phase 1 was complete a week before 10/1, and the work for phase 2 is delayed, and may be launched by 11/1, if we’re lucky.

On 9/30, coincidentally a Friday, the department we were partnering with, who uses a different CRM system for a different set of members, suddenly annouces that their CRM is also not set up for the 10/1 deadline. So, they want us to scramble all weekend to add functionality to our system to accommodate their business. Should I mention it’s 2pm? We say, “sure!”

Fast forward two weeks. Our CRM is set up to accept our members and the other department’s members. IT has gotten the file feed to talk to the enrollment system (after 10 days). Then, I get a call from Compliance, howling about the number of applications that were captured and not entered in the 7 day time frame, because IT took 10 days. Next day, quality assurance calls to complain that they have no visibility into the raw data. Then enrollment calls to complain.

What went wrong? No change management plan. We accepted the expansion of work at face value. We had the resources in IT who could crash the development. We had the testers available to work on it. The external vendor was ready. But, we didn’t take the time to see a) what compliance needs surrounded the request, b) what necessary timeframes were, c) what the needs of the end users where, and d) what this cost overrun meant to the overall project.

There is the lesson here: when you read the case studies in the PMI materials, they talk about these added features that get tacked onto projects, and I always assumed they were talking about those out-in-left-field add-ons (the “flip flops with a bottle opener in the heel” type add-ons). But, scope creep can show up at the 11th hour, and looks like you’re just salvaging another department’s work, instead.

Mental note: enforce the change management plan, even if it looks like the worse option!

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.

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: