• 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

Integration Management and Charter

“If you were asked, ‘what is a project manager’s main role?’, what would you say? The answer is to perform integration management – to put all the pieces of a project together into a cohesive whole.” Rita Mulcahy, pg 97

So, we’ve made it through the summary of each of the process groups. We’ve seen what PMI is saying are the key process groups for the exam, and what Mulcahy lists as the core tasks under each process group. Now, we’ll get into the meat of the studying, and we’ll do that by moving out of the silos of each of the process groups, and looking at the knowledge groups that make up project management. So, the first is integration management- combining all of the work into “one cohesive whole that gets the project done faster, cheaper, and with fewer resources, while meeting the project objectives” (Mulcahy 97)

Integration management is the high level work that a project manager does. Some examples provided here are “to complete a cost estimate, for example, risk reserves, the number of resources on a project, the scope being estimated, etc., should be taken into account (Mulcahy 97).”

Mulcahy goes on to provide a diagram of which knowledge areas fall into each of the process groups. Integration management is the only one that falls into all 5, and includes such activities as developing the charter, creating the Project Management plan, working the plan, performing integrated change control and closing the project (Mulcahy 98-99). What’s interesting to note here is that, over the next few chapters, discussing the knowledge areas, she identifies which activities in each process group roll up under one of the knowledge areas. For Integration management, she identifies nearly all of the initiating and closing activities here. Initiating and Closing are therefore linked together, in both the fact that what is determined in the Initiating process is signed off on in the Closing, wrapping the project up into an integrated whole, and being the section that most people skip over when they look at a project.

Because we start with the Initiating group, the first deliverable portion of the Integration management is developing the project charter. The charter lays out the Statement of Work, business case for the project, the constraints limiting the project (budget, time, resources), the assumptions of the project, and a high-level view of the risks. Also included are descriptions of the project manager’s role and authority, who the stakeholders are and the requirements they’ve set for the project, the project’s objectives, and the project’s approval requirements (Mulcahy 100-101). Remember back to the Initiating group, when we identified the project charter as one of the last things to complete in the group, after reviewing the history and culture, the business case, the initial requirements and creating the measurable objectives? We gather all of this information to include it in the charter.

But, we can go one better, and pull in the PMBOK definitions. The charter established a partnership between the performing organization and the requesting organization. The approved project charter formally initiates the project (PMBOK 73). So, of course the elements above are in the charter: if the charter is the contract between the project team (the performers) and the sponsors (the requesters) then of course it will specify what needs to be done, why it needs to be done, who is driving and how much control they have, what the limitations are, and what constitutes success.

For the project manager, the charter dictates what is expected of you, how you can do it, and how you know you’re done. Also, since it names the project manager, it gives the PM authority to spend money and assign resources. And, finally, it links the project to the ongoing work of the organization (Mulcahy 102). The charter ends up being one of the most critical documents for the project, possibly even the most critical. If, during the course of the project, substantial changes need to be made to the charter, then a serious rethink of the project itself needs to take place. Can you really hit the target if the target has just changed size, the colors inverted and it moved behind you?




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?

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.

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: