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.

PM Journal – Risk in Complex Projects

Thamhain, Hans.  "Managing Risks in Complex Projects," Project ManagementJournal, April 2013 (Vol 44 #2), pp 20-35.

From discussions and networking with my peers and colleagues, I don’t think there are very many that read PM Journal.  I won’t suggest that’s a mistake because the applicability of the content varies – some articles are so academic and esoteric they are only of interest to the author’s mother, some are only applicable in narrow contexts, and some are a challenge to decipher.

In contrast, Hans Thamhain has written a very approachable and relevant article that I recommend to my readers (Yes, both of you).  He reports on the result of research on managing risk in complex projects (hence the title of his article).  Thamhain’s discussion of the current state of research and knowledge of risk in enterprise projects is both enlightening and disheartening:  “Predicting and controlling such [unknown] risks appears impossible with the existing organizational systems and management processes in place” (21) and “there is no framework currently available for handling risks that are either unknown or too dynamic to fit conventional management models” (22).  “…Many of the organizational tools and techniques that support early risk detection and management … readily exist in many organizations ….  Project managers, while actually using these project management tools and techniques extensively … do not give much credit to these operational systems for helping to deal with risks” (29).

The model he provides on pages 22-24 describing the three-dimensional relationship of risk characteristics (Uncertainty, Complexity and Impact) is easy to grasp and is probably valuable to introduce in your risk log for classifying risks.

Thamhain covers a variety of topics beneficial to PMs and, as the article’s title indicates, the focus is on the outsized consequences of risk effects that are not effectively managed.

I did find that since Thamhain shifts between discussing risks (a possible future event) and looking back after-the-fact to discuss the consequences, his terminology is sometimes confusing.  It’s like reading an article written by someone a few years in the future about something that for them happened a few months earlier.  They’re talking about something in their past that is still in my future.  I’ll offer a bit of guidance for readers of this article.  The word “contingency” appears throughout the article.  Late in the article he provides a couple of contextual definitions, undesirable events (29) and risk situations (30), which don’t help clarity.  However, from the article context it appears that he uses “risk” to refer to a future event and “contingency” to refer to a past event that was formerly a “risk.”  I would have used the term “risk event” to describe these, but I understand his difficulty.  The other confusion is the use of “issue.”  PM purists will no doubt object to Thamhain’s use of “risk issue,” but in context it translates to “the project issue that results from the occurrence of a risk event.”  I caution newbies to have a firm grasp on the distinctions between “risk” and “issue” before tackling this article.

One specific takeaway from the article that I want to share is worth noting by both PMs and managers.  PMs “blame project performance problems and failures predominantly on contingencies that originate outside their sphere of control … while senior management points directly at [PMs] for not managing effectively” (30).  Thamhain’s further commentary on this topic in the article should be read by both PMs and executives.  It probably deserves reworking for broader distribution, such as an article in PM Network.

For reference, my previous posts on project risk management:

·         The Project Manager’s Cycle – Review Risks & Mitigation Actions [Published:  03/06/2011]
·         The Schedule – Risk Buffers [Published:  12/28/2012]
·         Where to Find Risks  [Published:  03/20/2013]
·         Estimates, Schedules, Assumptions and Risks  [Published:  04/03/2013]

© 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.

PM Network – 6 Rookie Mistakes

"You only get one rookie season.  So, I hate that we lost, but this was one of the best games I’ve ever played in.”
                                                                                                - Chris Paul

I’ve been reading the April issues of PM Network and PM Journal, two key PMI publications available to all PMI members.  I’m going to interrupt my regularly scheduling programming to comment on a couple of articles that I found noteworthy.

The first, “6 Rookie Mistakes,” is by Ashley G. Richardson and is in the April issue of PM Network starting on page 44.  (I’ll cover the other article in a subsequent post.)  PM Network is not exactly the reference for scholarly or deep content, but Richardson identifies a half-dozen truly devastating mistakes that can derail any project.  While she labels her list as rookie mistakes, I don’t believe any of these are limited to rookies, but any PM who makes one of these mistakes should be truly embarrassed.

I’ll tease you with a couple of quotes, but urge you to read the whole article.  “Sometimes managing the team’s personalities can be more challenging than dealing with the tasks – especially if a member unwilling to pull his or her own weight is dragging everyone else down.” (46)  “If your organization lacks a set of standards around risk, seek out others who have done similar projects within the organization or find a more seasoned professional willing to provide guidance.” (48)

The nature of my blog is such that it has been much more focused on the “hard” or “technical” side of PM skills rather than the “soft” skills (something that will eventually transition).  There are a lot of PM bloggers out there who provide good advice on soft skills;  I saw an opportunity to add content where there wasn’t as much commentary.   But the soft skills are generally much more visible, harder to master and weakness is more severely penalized, so every PM needs to master both types of skills.

One thing I would like to know, though I wouldn’t expect to find this in a PM Network article, is how Ms. Richardson arrived at this specific list of six mistakes, especially if there is research backing the importance of these in particular.

I won’t ask you to embarrass yourself by posting a comment of your own rookie mistake, so I’ll instead ask what rookie mistakes you’ve observed and what happened?

© 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.

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

“How are you fitting in?”  Tom, the Account Manager, was conducting the three-month review with Eric, PM trainee.  “I can handle the technical aspects of the job OK,” Eric answered, “but the culture is very different.”  Eric had jumped ship from one of the clients and had joined the consulting firm for the opportunity to travel.  “My old job was all about fixing the applications.  You focus on the numbers more than we ever did.”

This is the middle of a three-part series taking an uncommon perspective on the Project Management environment.  The first entry discussed the characteristics of the Product & Service Delivery PM environment.  This entry discusses the Consultancy PM and the next entry concludes the series by reviewing the impact and significance of this subject.

The Consultancy PM is usually found in the big consulting houses:  PWC, Deloitte, Accenture, E&Y, KPMG, Tata Consultancy, etc.  The core competency of the Consultancy PM is project delivery, independent of domain, product, or service.  Whereas the P&SD environment will apply lessons learned to improve the product or service, the Consultancy PM applies lessons learned to improve project delivery.  The Consultancy PM focuses on stakeholder management, risk management, change management, and acceptance management.  Metrics concentrate on cost management and Earned Value Management (EVM) is common in Consultancy PM.  Product or service metrics are rare.

The Consultancy PM will be more attuned to deliverables rather than milestones, cost is prioritized over schedule or scope, resources are valued for their skill producing deliverables, and resources are generally exclusive to a project for the duration of their assignment.

Consultancy PMs could also be called Assembly Line PMs.  This shows the continuing evolution of the PM function, from journeyman PM, to craftsman, then to manufacturer.  In this case, the Consultancy PM aspires to complete projects like a company runs an assembly line.  In this case, however, the product or service – the target of the project – is a black box to the Consultancy PM.  Think of it like cans coming off an assembly line.  Except for the label, each can should be identical on the outside, but the content of each can could be different.

PMI’s Organizational Project Management Maturity Model (OPM3) aligns best with the Consultancy PM.

Small consulting firms offer an interesting mix across these descriptions.  Some, for example, specialize in a particular product or service, operating in the P&SD model;  others are immature, competing on price, mostly clueless about the needs for PM maturity, thus operating as journeymen;  then there are the second-tier consulting firms – they aspire to join the big leagues, but don’t yet have the volume and lessons learned loop so that their assembly line is not yet operating with the smooth efficiency of the top-tier players.  For those interested, this series of articles will help identify which model describes a particular consultancy you might engage.

Are you familiar with P&SD and Consultancy PM environments?  What other characteristics describe and differentiate them?  Can you use these models to improve negotiations with consulting firms?

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).