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.

The Project Manager’s Cycle – Validate Task Status

“Carilyn, your status report says that you completed testing, but the task has four more hours on it?”  “Yes, I ran one more test case this morning,” replied Carilyn.  “But, as of Friday, when you did the status and the time entry, the task was still open?  It’ll finish today, right?”  “Yes, but it was just one more test case.”

Validating the task status within The Project Manager’s Cycle is done concurrently with Validate the Metrics.  For this activity, though, you are reviewing each project team member’s status report (MSR) rather than the metrics that have been reported through tools.  While this series will touch on status reporting in several entries, status reporting itself is a much bigger topic that I’ll eventually address in a future blog series.

The assumption for this PM cycle activity is that team members are submitting status reports.  However, a “status report” can be tailored based on the project context.  I’ve led small efforts – projectlets that are just a few weeks and have 2-3 team members – where I just drop by periodically and get a verbal update.  The point is not the format, but rather the content you need and what you do with it.

First, the content of the MSR and the reported metrics are a “check and balance” against each other.  The reports between them should be consistent;  deviations should be noted and investigated.  For example, if the team member reports on the MSR that they’ve completed a task, but the metrics show forty hours remaining, which is correct?

From the MSR Accomplishments section, note specifically task completions and mark these tasks completed in the schedule.  In the Planned section, note tasks that the team member plans to start and make sure these are assigned to the resource, open, and available for time entry, including that the start date aligns for a near-term start.  These should also be noted for review in the project team meeting (see future post in this series).

Finally, review the schedule the other way.  That is, review open/active tasks for that team member and confirm the MSR documents task accomplishments (e.g., 12 of 15 test cases run successfully).  Also look at tasks in the schedule that are scheduled to start and verify that the team members list them as planned in the MSR.

Any discrepancies need to be investigated, either with a discussion with the team member or during the project team meeting.

Other items to look for in the MSRs include issues (anything that is preventing appropriate progress on a task), risks (anything that may affect a future task), blocked time (environmental problems that prevented the team member from working on any project task), change management (changes to scope, quality, or cost), and deliverable status (is approval tracking appropriately) or milestone status.

Having completed these first two activities of the cycle, you have begun your list of To Dos for the week.  Unexplained variances in the schedule and anything that raises a question or concern from the MSRs goes onto one of your lists:  Issue Log, Risk Log, Commitment Log, Project Team Meeting Agenda, new change request, or your personal checklist of things to follow up on and people to talk to.

Getting good status reports from team members is always a challenge.  Do you have effective techniques for getting them to provide the info?  I’ve listed some content that should be in the MSR.  Do you have additional sections that are useful?