• Authors

  • Calendar of Posts

    June 2017
    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

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.

Closing Process Group

Finally, finally, we’ve gotten to the fifth process group of the 5. Closing. This is the shortest list of steps. This is the one no one likes. This is the one that gets the short shrift (and you thought Planning was undervalued!).

We close the project now. We verify the work was done, and done to the original requirements. We close the procurements, and sign off on those. We sit down with our customers and make sure they agree with us that the original requirements were met, and that the changes were implemented as approved. We DOCUMENT that they sign off on this. We store all of the documents and lessons learned in a single location, so that when you start the next, similar project you have some historical process to refer back to in the  Initiation process group.

Then, we wipe our hands of it. Operations takes over the running of the unique, shiny new thing that was built with the project, and we send our project team back into the wilds from whence they came (Mulcahey, PMP Exam Prep, 6th Edition, 43).

I think it’s this last 2 portions that I most dislike about the Closing process group. I always feel that the deliverable widgets don’t look all shiny and new, or like they’re half-formed, and giving them to Operations, they are going to not appreciate them.

Then, with the releasing of the team, it means that the PM (me) gets released too. Then, you are left with this impression that Ops didn’t like your results, and no one will ever¬†assign you to a project again. And then Monday rolls around…

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?

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.

%d bloggers like this: