• Authors

  • Calendar of Posts

    December 2011
    M T W T F S S
    « Nov    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 7 other followers

Can I be of service?

We’ve been looking at the integration management and how it relates to initiating and planning. With planning out of the way, we can look at Directing and Managing Project Execution, which occurs simultaneously with Monitor and Control Project Work.

Directing and Managing Project Execution is not the same as the executing process group, exactly. The executing process group is getting the work done. Directing and Managing Project Execution is integrating all of the efforts into a finished project. So, Directing and Managing Project Execution is the overview of the entire project (Mulcahy 118).

Mulcahy makes two critical points here: 1) Directing and Managing Project Execution involves managing people, doing the work (and therefore managing people doing the work), and implementing approved changes. And 2) it’s about ‘being of service’ (118).

In my opinion, these really become the two critical pieces of running a project: ensuring a common understanding, and being of service.  I think the picture I posted last week clearly sums up what happens when you don’t ensure a common understanding. As for being of service, look at that post I just linked to. Down there at the bottom, in the game plan: Everyone is your customer. Are we afraid to get our hands dirty to help keep a team member on track? Are we out in front of the risks, trying to remove roadblocks to keep things on track?

Tied with Directing and Managing Project Execution is Monitoring and Controlling Project Work. This is best seen as balancing the demands of the different knowledge areas to control the project (Mulcahy 122). The output is change requests, project plan and document updates .

As we’ve been saying repeatedly, in discussions about planning and discussions about process groups, all projects must be controlled. Controlling a project is about ensuring that the work is proceeding according to plan, and when it is not, creating change to push it back on track. Taking corrective action is, according to Mulcahy, the correct answer for what to do when a task takes longer than expected.

One method of keeping work on schedule is the work authorization system. As we get into more detail about work packages, we’ll be in a better position to discuss this, but essentially, this is signing off that someone should begin work, because the prior dependency is complete. Mulcahy gives the example of building contractors needing to work in the same place, but it also applies to formal sign-off from the developer that QA can proceed in reviewing the IT code (Mulcahy 122).

When you compare the work authorization system with the concept of being of service, it feels, on the surface, almost contradictory. On the one hand, you’re trying to remove roadblocks, and assist the team members. On the other, you’re standing the way of starting on a work package until formal approval is given. But, in the long run, when you have 100+ people working on a project, how much more helpful is it to make sure no one is tripping over each other?

Project Management Best Practices for Production?

So, as I’ve described before, I work in a data processing unit for a health insurance company. But, more specifically, I work on the support team for the data processing group. The support team is made up of a manager, a team of a half-dozen business analysts, led by a senior business analyst, and two project manager. The BAs are responsible for maintaining various aspects of the production work (department communication, file processing, etc), as well as providing support on special initiatives. The implementation of the special initiatives are led by one of the two project managers (of which I am one).

I’ve been in discussions with my manager about how we can streamline work that is being done. One area we are looking at is how can we better utilize Project Management best practices in managing the work that is being done by the business analysts. While much of the work they do is routine, and therefore outside of the strict definition of a project, there are enough changes on a daily basis, and new tasks, that some features of project management would still apply.

If someone were to ask you what is the most valuable best practices from Project Management methodology (PMBOK, PRINCE II, etc), what would it be? Would it be the emphasis on planning? The change management? The need to include Monitoring and Controlling in every project? The invective to celebrate every project at it’s completion with a party?

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…

 

Risk Management presentation

About 2 weeks ago, I attended a lunch put on by the Baltimore chapter of PMI. They run these lunch sessions on a monthly basis. They have a catered business lunch (hoo boy! Wraps!) and have a speaker from the chapter present on a topic.

The December topic was ‘Never cancel a risk meeting when the building is burning’, given by Chris Schaefer, PMP. I think my first question for the session, which of course I didn’t actually ask, was ‘what the hell’s a risk meeting?’. What I was able to glean from the presentation was essentially, ‘I’m probably running my project team meetings wrong.’ When I run a project meeting, I do what everyone does, or at least everyone inexperienced in project management. I focus on status. Where are we today?

What is a risk meeting? ‘Where will we be tomorrow, and what are the road blocks to getting there?’ If I can start to move in that direction, I can start to be more proactive about addressing risks before they blow up.

One area of general risk is the issue of expectation management. I wanted to share this image, since it captures expectation management pretty well (though, allegedly, it’s become a cliche now).

A couple of the other take aways:

  • Approximately 71% of projects fail. Obviously risk management is not an important enough focus on these projects.
    • The Standish Group published the CHAOS report in 2004, and republished it in 2009, looking at project success standards (it seems there are tons of disputes to the CHAOS report finding, so that may be a different blog post) (Also, sadly, the report is not available in the PMI online resource library. Anyone have a copy of it you wouldn’t mind lending me??).
  • One of the recommendations for taking over a project that is already in the red is to have a clear game plan. Mr. Shaefer’s suggestion:
    • Engineer Success
    • Bargain Fairly for time, Scope, and Resources
    • Never Cancel a Risk Meeting
    • Everyone is your customer (and he mean’s EVERYONE!)
    • No surprises- communicate clearly, effectively and often
    • It’s not about you: Seek first to understand, then be understood.
    • Project Management is the Service Business
    • Event+Response= Outcome
    • The world is your oyster
(notes from “Never Cancel a Risk Meeting, Chris Schaefer, PMP. Held In Columbia, MD, 12/5/12).

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.

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?

Right.

 

%d bloggers like this: