The Tailoring Rule

"Professionalism is knowing how to do it, when to do it, and doing it.”

                                                                                                - Frank Tyger

When people choose to complain about project management, one frequent refrain is the burden and overhead of all that process.  (I believe this is often a red herring, used by detractors who are concerned that project management best practices will expose their delivery weaknesses, but today’s discussion is to address the valid concerns for appropriate levels of process.)

A typical organization does many different types of projects of different sizes, styles and complexity.  For example, an IT department might have projects for:

• Infrastructure
• New software development
• Enhancement and maintenance
• Product selection, acquisition and installation

Since all projects, regardless of size, style or complexity have many common elements necessary for success, does that mean that the organization only needs one methodology?  Well, yes.  And no.

If the organization has one bloated methodology dictating that all projects must produce all deliverables from identical templates, then those people who complain about too much process have a (partially) legitimate complaint.  It’s legitimate because for most projects there will be too much process, but they are complaining about the wrong thing.

However, there are so many common and essential elements for project success that no organization wants to manage multiple (many?  dozens?) of different, but similar processes.  How to resolve this contradiction?

Both SEI’s CMMI and PMI’s PMBOK® Guide provide for Tailoring.  Tailoring is an important but rarely formally practiced principle.  In fact, in all of my years of consulting across a broad range of companies, I’ve encountered numerous cases where formal practices are ignored or circumvented because they are too onerous or just irrelevant, but in only one case have I worked at an organization that formalized process tailoring.

Even the description in PMBoK does little to suggest that the organization should establish tailoring in the formal processes:  Initiation and Planning includes “guidelines and criteria for tailoring the organization’s set of standard processes and procedures to satisfy the specific needs of the project” (27).  This description makes it sound like tailoring should be done inside the project to customize the organization’s standards rather than that the organization’s standards should specify the tailoring appropriate to different projects.

For example, an IT software development project, an IT software implementation project, an IT infrastructure project and a business process redesign project all have many similarities on how they should be run (they should all have charters, business cases, status meetings, risk logs, change management, etc.), but also significant differences (a new software development project won’t need the RFP activities in the implementation project and the BPR project will need a host of training and documentation activities that will not be needed for a back-office infrastructure project that has no end-user visibility).

Further, for a sufficiently small project, the charter could be fully contained within an email and the change approval process will need to be sufficiently streamlined, since long decision timeframes would jeopardize the delivery of the project.  In contrast, a long, complex, risky project wouldn’t want to make change decisions too informally or too quickly.

The process burden needs to be appropriate to benefit the project – designating those best practices that best assure project success – while addressing project risk without over burdening the project.  A requirements document for a small project might be a few pages, whereas the requirements document for a large, complex project could be a tome, with sections and subsections for business requirements, functional requirements, technical requirements, non-functional requirements, etc.

One size does fit all in project management, as long as that one size addresses the principles of successful project management.  (Is that a tautology?)  Organizations with best practices are clear about what processes are required and how those processes are customized based on type of project, complexity, size, risk.

The mistake often implied by those that complain about excessive process is that the situation would be better if there were no process.  But processes evolved because lack of process (chaos) could not be relied on to consistently deliver successful projects, whereas the use of the processes improved the project success rate.  The solution to excessive process burden (or bad process, for that matter) is not eliminating process.  Rather, the solution is to fix the process through lessons learned and continuous process improvement.

Of course, organizations are even worse at lessons learned and process improvement than they are at projects.  Look for my eventual series on lessons learned to address just this subject.

© 2014 Chuck Morton.  All Rights Reserved.

Change Management – The Process (Part 2)

“If you do not change direction, you may end up where you are heading.”
                                                                                                                                - Lao Tzu

This post concludes the series on change management that started with a discussion about what’s so confusing and is a continuation of my previous post on the process of project change management.  That post described the conceptual activities in project change management and why there are not explicit change management processes in the PMBoK.  Now it is appropriate to review what is in PMBoK and how it aligns with the conceptual activities.

The following PMBoK processes relate to project change management:
·         Develop project management plan
·         Plan [Knowledge Area] management
·         Direct and manage project work
·         Monitor & Control project work
·         Perform integrated change control

“Develop project management plan” and “Plan [Knowledge Area] management go hand-in-hand.  The project management plan includes each of the knowledge area management plans.  Each knowledge area plan (scope, time, cost, etc.) needs to include how change to that component will be managed.  In addition, the project management plan should describe how change requests are submitted, processed, reviewed and decided.

One thing I haven’t yet discussed is the two types of change.  There are, for example, changes to the product or service that is produced in “Direct and manage project work” and variance and compliance changes that are recognized in “Monitor and Control project work.”  We encountered both of these in a previous post on the philosophical dilemma of project change.  The project plans should,, of course, address how this dilemma is recognized and resolved in the “direct and manage” and “monitor and control” processes.

“Perform integrated change control” is the key to having project change work effectively.  It is here that change requests are received and processed.  As I mentioned in the previous post, this process is like initiating a complete mini-project for each request.  That’s why I have a dissonant response to Table 3-1 on page 60 of the PMBoK every time I pay attention to the location of 4.5 Perform Integrated Change Control, in the Monitoring and Controlling Process Group column.  Realistically, this step spans all five columns, from Initiating to Closing.  Not only does this span all process groups, but because a change to one functional group will trigger cascading changes in other functional groups, this activity also spans all functions (scope, time, cost, etc.), which is why it is integrated change control.

As I now bring this series to a close, the most important point to emphasize is that change will occur on your project, it will happen, and it must be planned for, you must prepare to have change, and you must have the processes and practices in place to effectively include, manage and control change in your project.

So now that you know everything I know about project change, what tips do you have for other PMs?

© 2013 Chuck Morton.  All Rights Reserved.

Change Management – The Process (Part 1)

“What you have become is the price you paid to get what you used to want.”

                                                               - Mignon McLaughlin, The Neurotic's Notebook, 1960

Continuing my series on Project Change Management, it is now time to drill into the change management process.  As I explained in my previous post in this series, the change management process is unlike other project management processes because it is not neatly contained, either by PMBoK knowledge area nor, except for one Monitoring and Controlling process, by PMBoK process group.  This post will attempt to demystify change management by examining what is in place, how it works, and what it could look like.

In the PMBoK (5^th ed), other than “Perform integrated change control” in the Monitoring and Controlling Process Group, the remaining change management activities are spread across and buried within the Knowledge Areas and Process Group activities.  So there’s a “perform” process, but how do you know what to “perform” if you don’t plan for it?  How can you “perform” an activity if you don’t recognize it?

Let’s start with an understanding of what, conceptually, project change is.  In a project, if you could alter the plan indiscriminately, there would be no need for a change management process.  The change process would be “do whatever you want, whenever you want” and, thus, the project would equally be “do whatever you want, whenever you want.”  Similarly, if there’s no plan, then there’s nothing to change.  So, project change is the formal approach for replacing an agreed-to plan with an amended agreed-to plan.  Since the plan establishes stakeholder expectations, change management is the structured approach for resetting expectations.

The word we usually use for “agreed-to plan” is baseline.

Let’s step through this from the beginning of a project:  The project is initiated, chartered and planned.  A project plan (time, cost, procurement, HR, scope, change, etc.) is produced, agreed to by the appropriate authorities (baselined) and published to stakeholders.  At this point, all stakeholders should be operating on the same expectations and you, the PM, should be reporting status, progress and variance based on the plan.  Now, someone comes along with a request to add a new feature (or get it done quicker, or cheaper, or without a key resource, or ….).  At that point, the project change management process is used.

The requestor submits the request according to the approved change management process.  The interesting thing here is that, regardless of how it’s described, the change activity is like a mini-project with all of the steps.  The change request is equivalent to a Charter.  The project team evaluates the request, estimating how the current project activities will be altered (new tasks, changed tasks, eliminated tasks, etc.) and creating a revised project plan, which must then be reviewed and approved (at which time it becomes the new baseline plan) or rejected (and the current plan remains effective).

So, if a stakeholder can submit a request to change the schedule, why isn’t there an “Evaluate schedule change request” or “Perform schedule change,” and likewise for all of the process groups?  As you – an experienced project manager – well know, all the project parts are connected:  you can’t tweak one area without somehow changing some other area.  Therefore, there is no time (or scope or cost or HR or procurement, etc.) change activity:  there is, reasonably, “Perform integrated change control.”

So I want to pause here:  I will continue this subject in my next post on this, where I will discuss how the current PMBoK activities relate to change management.

Does your organization have an effective and manageable project change management process?  How does it work?

© 2013 Chuck Morton.  All Rights Reserved.

Project Change Management – Process Overview

"Change is inevitable - except from a vending machine.”
                                                                                                - Robert C. Gallagher

Now that we have the confusions and dilemmas of change management behind us, it’s time to drill into the change management process. 

The one thing you can count on to stay the same when running a project is that there will be change.  Yet, the PMBoK (5^th ed, p60) identifies nine knowledge areas and change is not in the name of any.  And change is not in the name of the five process groups.  There is no process that says “Plan Change Management.”  If change is so prevalent, what is the process and where is it documented?

Some examples of change include:
·         We need to complete the project sooner.
·         We need to reduce the project budget.
·         We need to add this feature to the project scope.
·         This person has resigned, but we still need to complete the project.

In fact, there are eight broad areas where change can occur:  Scope, Time, Cost, Quality, HR, Communications, Risk, Procurement and Stakeholders.  This list, no coincidence, corresponds to eight of the PMI knowledge areas (PMBoK 5^th ed, p60).  But there is no “Deal with scope change” or “Handle HR disruption.”

As any practitioner of project management quickly learns, everything is connected to everything else and nothing happens in isolation.  It’s like there’s a seven dimensional pyramid (eight nodes), where there are 28 connections between the nodes.  (This concept also applies in communications management and communications planning related to the project team size.)  This means that if, for example, you need to complete the project sooner, that has a potential impact on all seven of the other knowledge areas that needs to be evaluated (and each impact to one of those has a potential impact on the other seven, etc.).  So, a “Deal with scope change” process cannot be done in isolation from time, cost, quality,….

Thus, we have, in the wisdom and experience of the PMI, the ninth knowledge area:  Project Integration Management with the process Perform Integrated Change Control.  This is the only practical technique for addressing project change – holistically across all areas.  But “perform” omits “plan” and “evaluate.”  It’s still not complete.

In the next installment of this series, I’ll drill deeper into the change process and how it works.

Has it occurred to you before that change management and communication management have this mathematical relationship?  What consequences can you foresee from this?

© 2013 Chuck Morton.  All Rights Reserved.

Change Management – What’s so Confusing?

"I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”
                                                                                                - Robert McCloskey

With this post, I begin a series on change management.  Today I’ll make the effort to clarify what change management we’re discussing.  Next I’ll discuss a challenging philosophical dilemma posed by the choices of how change management is implemented.  Then I can settle in with actually discussing the “hows” of change management best practices.

When change management comes up on my projects, I always ask what “change management” the person is referring to.  I know of three different change managements that are commonly encountered on projects and there is invariably confusion because different project team members have different contexts where their specific change management label makes sense, but they often don’t realize that other groups use the same label, change management, to refer to something completely different.

In the HR and process worlds, change management refers to Organizational Change Management, the methods for transitioning people, teams and processes from a current state to a new future state.  This can involve realigning people, changing roles and duties, training, adding people, eliminating positions, streamlining job functions, etc.

In software engineering, change management refers to Systems Change Management, the practices necessary to successfully implement new software or update the installed software with new features.  This is better referred to as release management, but is frequently called change management by the practitioners.

When the PMBoK refers to change management, it means Project Change Management, which involves documenting and updating changes to the approved baseline project plan.  Project Change Management is neither difficult nor complex, but few organizations practice it effectively.

Note that an organizational change may involve a project and/or a software release.  A project can involve making organizational changes.  A project can involve implementing a software release.  A software release may be run as a project.  As I opened, it is not unusual at all to encounter all three of these change managements on a project and have different team members using the same terms and meaning completely different things.  Oh, the confusion you can sow.

For the remainder of my series on change management, I will be exclusively discussing project change management.  In my next post, I’ll take up one of the challenging philosophical questions about implementing project change management.

Are there any other change managements out there that I’ve missed?  Have you encountered confusion on projects when referring to change management?  How did you resolve the confusion?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Manager’s Cycle – Review Risks & Mitigation Actions

“Jack, we’ve allocated five days in the plan for you to review each of the major deliverables,” Alice, the Sr Project Manager, explained to the Executive VP (HR), during the schedule review.  “If you can complete those reviews and provide signoff within three days, we have the opportunity to knock two weeks off the schedule.  However, if you take longer, that will push out the Go Live date.”

With this post, we reach the midpoint of The Project Manager’s Cycle where this action and the next few actions are deceptively easy to describe, but are considerably more complex to practice.  As a reminder, this series describes the Monitor and Control activities that the project manager repeats each project reporting cycle.

Project Risk Management is, of course, a process documented in A Guide to the Project Management Body of Knowledge (PMBoK) and includes the Monitor and Control Risks activity.  The activity I’m describing in this post is similar to the PMBoK equivalent.  At its simplest, this activity assumes risk identific-ation, quantific-ation, prioritize-ation, and mitigatin-ation have been done and all you do is “process” the risk mitigations assigned to you on the risk register and follow up with others to make sure they are “processing” the risk mitigations assigned to them.

But as someone I admire would say, that’s not “the way of the project manager.”  It’s certainly not all that is required for a best practice.  For example, as you review the risk mitigation actions assigned to you and you get others to review the actions assigned to them, you naturally reassess the risk itself and the risk response;  if anything has changed (assumptions, probability, or impact, for example), then you transition into risk analysis or risk response planning.  Further, processing the risk response actions works best as a team exercise, and a superior project manager will involve all appropriate stakeholders in the activity.

If risk response is required, take appropriate action.  For a seasoned project manager, this means delegating any product work.  Also follow up with everyone else who has a risk response action assigned to them.  Verify their action plan, determine status and issues affecting their risk response, and gently nudge them if necessary.

 If there is an effect on the project, then consider use of contingency reserves (risk buffers), escalation, or project change management.

Have I left anything out?  What else is in your cycle of weekly activities for reviewing risks and risk responses?

The Task

“Is the PaRC Coding task complete?” asked Evelyn, the PM.  “Yes,” responded Jeff, one of the best programmers, who then continued “I completed all of the coding yesterday.”  “But what about the unit
testing?” Evelyn followed up.  “No, I’ll get to that tomorrow,” replied Jeff.  “But the task includes coding and unit testing,” Evelyn noted exasperatedly.  “It isn’t done until both are done and it’s ready for turnover to the test group.  You know that.  Why do you tell me it’s done?”

I’m trying to build some of the context for presenting best practices, but PM best practices are difficult to document, in this case, because everything is so integrated.  You can’t really discuss one thing being a “best practice” until you have a context for that practice to be best in.  For example, you can’t comprehensively discuss estimating without also including risk management.  You can’t discuss reporting best practices without addressing stakeholder management.  You can’t address acceptance management without addressing scope management, which also has to involve change management.

So I’m going to start with a fundamental and see if I can build a base sufficient to start expanding into more complex topics.  The Work Breakdown Structure (WBS) is a core project management document and the task is the atomic element of the WBS.

Typically a task should be a single component of work delivered by one person.  This would generally be a best practice.  I have frequently made exceptions to this practice, but that doesn’t prevent this from being a best practice.  And knowing when to make exceptions is part of the pragmatic, flexible responsibility of the good PM.

The task should have clear transitions.  The inputs, outputs, and hand-offs (in- and out-bound) should be clearly understood.  This is one of the main areas where I frequently experience problems, when I assume that team members clearly understand their tasks, including Done.

I’ve developed some techniques to address this problem.  PMBoK v4 references the WBS Dictionary, what used to be called the task dictionary.  The WBS dictionary is without question the appropriate reference for this situation.  But who has the time and budget to include one in the project?  What I’ve found that I can do for key project tasks is sit down with the task owner (Owner A) and the owner of the next (successor) task (Owner B).  In this facilitated discussion with Owner A and Owner B, we discuss what is included in the task, what is expected as inputs and outputs, and what constitutes done.  This often identifies differences in expectations by the owners which, without the conversation, would’ve left  some ball dropped.

The key point I make sure to include in the discussion:  Owner B has to accept the results before the task can be closed for Owner A.  Universally the task owners know more about their jobs than I do, so I don’t have to impose the general task scope, all I have to do is make sure each successive owner is clear about the task boundaries.  It’s amazing how many problems this little discussion has prevented.

Call it a dynamic WBS Dictionary, maybe.

Do you have any experience with a WBS Dictionary, or problems with not having one?

A Philosophy of Projects and Products (Part 1 of 3)

Ron, the IT Director, was meeting with his managers.  “Phil, what is the status of the SAP implementation?”  “The PWC consultants are on schedule and on budget.”  Ron, looking across the table at the manager over the imaging applications, then asked, “Allison, how is the new fax/OCR product?”  “Ron, I wish this Brand X consulting firm we selected was half as good as PWC at schedules and budgets, then it would almost be worth it to continue using them. I’m going to have to continuously monitor their progress, but we should probably plan for a 100% overrun,” she replied.  Finally, to Dave who manages the finance applications, he asked about that status.  “We’re staying ahead of the vultures, but the primary focus is keeping the lights on and responding to the support calls.  We are running about normal on resourcing for maintenance and enhancement requests,” replied Dave.

This begins a three-part blog series on a rarely discussed but rather significant split in the way to look at project management.  The first two entries will take a look at PM from two common perspectives, then the final entry will address the impact and significance of this subject.

The PM environment I’ll discuss in this entry I’ll call Product Delivery (more accurately, Product & Service Delivery).  This is the classic craftsman model where process (and people and tool) maturity is used to enhance and optimize delivery of products and services.  This model is evolved from the journeyman, for whom every new creative effort is a original challenge.  By applying knowledge from lessons learned, best practices and risk management, delivery becomes more consistent, reliable, and predictable.

The core skill of the Product & Service Delivery (P&SD) organization is managing the product or service, their priority is product and service availability, and metrics focus on the product or service (i.e., PM practices are measured to produce more products, faster, for less cost).  Other characteristics of P&SD include a preference for milestones over deliverables, generally prioritizing scope over schedule or cost, resources (including PMs) are valued for their domain knowledge, and resources are generally shared between projects (new development) and maintenance/support.

Most IT organizations, for example, operate with this model and call what they do Project Management;  after all, they use processes and methodology modeled on the Project Management Institute’s (PMI’s) A Guide to the Project Management Body of Knowledge (PMBoK).  They may even have a Project Management Office (PMO) to drive PM best practices. 

The maturity model best aligned with Product and Service Delivery is the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI).