• 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

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…


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: