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.

Conflict

"All polishing is done by friction.  The music of the violin we get by friction.  We left the savage style when we discovered fire by friction.  We talk of the friction of mind on mind as a good thing.”
                                                                                                - Mary Parker Follett

“Conflict is as inevitable in a project environment as change seems to be” (Vijay K. Verma, The Human Aspects of Project Management: Human Resource Skills for the Project Manager, Volume Two, PMI 1996).  So begins chapter 3 on Understanding Conflict.  (I have a hardcopy of the book around here somewhere, but for my refresher for this post, I re-read chapters three and four from PMI’s eReads member benefit.)

I completed my five-part series on governance in the project context and project conflict seemed the natural successor to that series.  After all, putting a governance system in place establishes a state of conflict that is beneficial to the project.  A good project manager and a good PMO will understand the different types of conflict and know when and how to use them for the project’s benefit.

I’ve worked with many managers and project managers that are conflict averse.  When I bring it up with them and point out what they are doing, they often readily acknowledge what they are doing and are still hesitant to change.  This style is consistent with the earliest management and project management practices, which was to avoid or reduce conflict.

Eventually, accepted practice was to allow natural occurrences of conflict to develop, the behavioral view.  The latest practice, the interactionist view, is to encourage appropriate conflict, much as implementing project governance creates a conflict between the governance team and the project delivery team, that, when done properly, benefits the organization and the project.  Verma goes much further into these three views.

The whole notion of stimulating conflict is difficult to accept because conflict traditionally has a negative connotation. However, the interactionist view encourages conflict. There is evidence that, in some situations, an increase in conflict actually improves performance (Verma, ibid, chapter 4).  However, too much of anything is detrimental.  They key is finding the proper balance (foreshadowing for a future post), as shown in this table from Verma’s book:

Table 3.1: The Value of Conflict
Positive Aspects	Negative Aspects
Diffuses more serious conflicts	Can lead to more hostility and aggression
Fosters change and creativity as new options are explored	Desire to "win" blocks exploration of new opportunities
Enhances communication if both parties are committed to mutual gain	Inhibits communication; relevant information never shared
Increases performance, energy, and group cohesion	Causes stress; creates in unproductive atmosphere
Balances power and influence if collaborative problem solving techniques are emphasized.	May cause loss of status or position power when both parties take it as a contest of wills and strive for a win-lose outcome.
Clarifies issues and goals Negative Aspects	Real issues overlooked as positions become confused with personalities

 So what is the best practice?  Expect conflict.  Find the proper balance between avoiding conflict and stimulating conflict.  This means both averaging toward the center of the spectrum, but also having a high deviation.  This way, conflict management becomes another tool available for you to apply appropriately as conditions warrant.

So are you a conflict traditionalist (conflict is bad), a behavioralist (conflict is natural) or an interactionist (conflict should be encouraged)?  How about the management and leadership (these, of course, are two different groups) of your company?  Does that explain your company’s performance?

© 2014 Chuck Morton.  All Rights Reserved.

Measuring Software Productivity

Enhancing the Efficiency and Effectiveness of Application Development.  Michael Huskins, James Kaplan, and Krish Krishnakantham.  August 2013.  (registration required)

I just read this recent article from McKinsey and Company that extols the virtues of software productivity metrics, compares several alternative methods, and offers their recommendation.

I find it amazing that in the several years I have been publishing this blog, I have never discussed software productivity metrics – but after a review today, that is exactly what I found.  As an avid advocate and proponent of metrics, the topic has certainly been on the list for discussion.

Had I written the article before today, I would’ve advocated Function Points.  Function Points have several advantages, including being the most consistent, accurate and reliable of the various methods and the one most appropriate for evaluating and measuring vendor software.  In particular, if you are comparing building a package versus buying a commercial (COTS) package for the same capability, then FPs offer an objective measure for comparing both features and cost to determine the appropriate path.  Likewise, it is similarly appropriate when comparing products from multiple vendors.

As the McKinsey article explains, though, FPs are expensive and challenging to introduce.  For organizations that rely primarily on software development (rather than purchasing vendor offerings), the McKinsey authors introduce a new (to me) method called Use Case Points, compare this to Lines of Code, Story Points, and FPs, and describe how to introduce UCPs into the organization.  Further, the article notes that UCPs are comparable across applications and teams.  And UCPs can be used with both agile and waterfall development methodologies.

I encourage you to take a look at this article for your application development environment.  Metrics add a valuable tool to your toolbox.  And metrics are an absolute, foundational necessity for continuous improvement.

Have you worked in an organization that uses software productivity metrics?  What benefits did you find?  What problems did you encounter?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Status Report – The Bad News

"It not knowing what to do, it's doing what you know.”

                                                                                                - Tony Robbins

Over the last couple of posts, I’ve discussed the “what” of the project status report (i.e., the content).  In this post, the conclusion of this three part series, I discuss the “why” of the PSR, but focusing on some of the less obvious benefits.

Everyone understands the theoretical or conceptual need for the project status report.  The client expects it, it may be obligated by the contract, and it may be in the standard process.  But it’s a burden to put together every week, to come up with newly creative ways to say you’re still behind on the project and you don’t have any tangible accomplishments to report.  We want a reason to do this activity – week in and week out – some reason larger than obligation to process;  some reason that overcomes the urge to make anything else we can be doing a higher priority than the Project Status Report.  We want something that gives this activity purpose and meaning.

There are a few good reasons for producing the weekly Project Status Report.  For example, a well-written PSR – succinct, factual, comprehensive – launches good discussions in the client project meeting.  It documents the action items and effects of non-compliance and non-responsiveness from the stakeholders.  It is an archive of the project trail.  But, there’s more.

On the LinkedIn discussion boards for Project Management that I follow, the question “What’s the best way to deliver bad news?” appears regularly.  This is a question I struggle with answering because the question those LinkedIn questioners are asking is not really “How to deliver bad news” but rather “How to deliver surprising bad news.”

The bad news I deliver to my project stakeholders is rarely a surprise to them because I publish the project status report religiously every week and I pack it with factual information about the project – the good and the bad.  I document the issues we are experiencing and the risks that present threats and opportunities.  I show where we have variances.  Sure, this is hard.  But it is a professional and ethical responsibility.  And if you don’t do this (think good risk management here), you are going to be struggling with the question of how to deliver surprising bad news to your stakeholders.

I can’t think of a better reason or a higher purpose than this.

Producing the project status report every cycle is a Project Management Best Practice.  What problems have you experienced when you ignored this practice?  What problems have you avoided by publishing it even when it didn’t seem like a healthy choice?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Status Report – Content That Matters

"Thinking is more interesting than knowing, but less interesting than looking.”

                                                                                                - Johann Wolfgang von Goethe

This is the second post in the series on The Project Status Report.  In this post, I get specific about the appropriate content of a PSR.  But first, while it is called a Project Status Report, it typically includes status (snapshot), trending, progress (accomplishments) and exception (variance) content.  Second, the PSR should not be confused with a person’s (individual) status report (ISR), which everyone on the team should be completing.  Further, the PSR is not a roll-up from the ISRs.  Finally, the PSR, when done properly, is aligned with and contributes to the overall Management by Objectives (MBO) approach.

This last point deserves emphasis.  The PSR does not and should not say what is going on.  I know this seems totally off base, but to ignore this point devalues the PM contribution.  Rather, the project has a plan and the PSR documents the consistency with or variance from the plan.  So rather than saying “what is going on,” the PSR should say what is going on relative to the plan, which is a key distinction.

I’ve found that the following sections are useful to have in the PSR:
·         Current snapshot
·         Dashboard
·         Performance to plan
·         Accomplishments
·         Planned for next period
·         Issues/ Variances
·         Acceptances
·         Change activity
·         Risk summary
·         Downtime

Not all organizations use all sections and not all sections are appropriate for all organizations.  Let me discuss each section.

Current snapshot

This optional section is status content and is the executive summary of the PSR.  It should be a very brief (no more than a few sentences) narrative.  Of particular significance is to use this section to emphasize areas where stakeholder intervention is required, such as resolving third-party bureaucratic or administrative interference, stakeholder non-compliance (failure to approve a deliverable or change request), failure of a risk or issue owner to act, or when intervention is needed to address a “red light.”

Dashboard

This optional section is status content (and is improved with trending indicators).  Despite their popularity, I’m not a big fan of “traffic lights,” those red-yellow-green circles to summarize status, primarily because there often is not a clear understanding by all stakeholders what the traffic lights mean.  Further, a single traffic light summarizes too much to be sufficiently actionable (for example, something I experience regularly is that we will start a project before all of the budget administrivia is complete, knowing that the executives have approved the project and it will go forward.  However, the project shows red because of the budget and, so, everyone ignores the traffic light.  But there may also be other factors that should be recognized that are concealed because of the attention to the budget.)

I’m OK with traffic lights when the following conditions are met:  1) all stakeholders understand what the lights mean (in particular, when their action or intervention is required);  2) that there are multiple lights providing sufficiently discrete information to the stakeholders (e. g., budget, schedule, scope, approvals, issues, risks).  Traffic light value is improved if there are trending indicators (for example, up/ down arrows) to communicate changes.

Performance to plan

This is required status content.  This should include a Gantt chart (showing variance from plan) or, even better, Earned Value (and Earned Schedule) graphs.  This is the meat of the status report.

Accomplishments

This is optional progress content, though it is universally included.  Equally universal is that the wrong information is presented.  This should report accomplishments, not activity.  Avoid muddy verbs, such as:  worked on, met, attended.  Instead, use only concrete verbs, such as completed, published, documented, tested, coded.  The activities associated with these verbs should be tasks or activities in the WBS (and thus on the project schedule).  Finally, include metrics whenever possible (e.g., completed 20 of 30 test cases).

To digress momentarily, be clear about what “completed” means.  I often have developers report they completed an assignment.  “Have you completed the unit testing,” I ask.  “No, I completed the coding.”  OK, but the task is not complete.  These types of grey areas compromise the accuracy and the credibility of your reporting.

Planned for next period

This is optional progress content.  The same rules as listed for Accomplishments apply.

Issues/ Variances

This is required exception content and is usually a table documenting current project issues, the issue owner, activity and plan for resolution.

Acceptances

This is required status and exception content.  This should be a table listing each deliverable that has been submitted but not approved and deliverables that will be submitted in the next few weeks.  Table columns should list the deliverable name, responsible approver, date (to be) submitted, date approval was (or will be) due, and status (Not submitted, Pending approval, Overdue, Approved).  Overdue approvals should be highlighted.  Once an approval is received, this is reported as complete on the next PSR, then it is removed from future PSRs.

Change activity

This is required exception content.  This, too, is a table listing each submitted, but not completed, project change request.  Columns should include PCR number, title, date submitted, date response due, and status (Submitted, Pending approval, Approved/ Denied, Project plan updated).  Once the PCR has been denied or after the project plan is updated following the approval, this is reported on the next PCR, then it is removed from the table.

Risk summary (key risks)

This is required exception content.  This section is formatted similar to the Issues section.  One thing important to add to the section heading is “Date last discussed.”  This should be the date that risks were most recently discussed in the Client Project Meeting with the stakeholders.  I find that these meetings rarely discuss risks because time runs out before we get to this agenda item.  Risks should be discussed at least monthly and, if they haven’t been, this discussion should be moved to the top part of the agenda.

Downtime

This is optional exception content and will rarely be seen except in the status reports of the top echelon consulting firms.  It really isn’t meaningful in a Product & Service Delivery environment, but may mean the difference between profit and loss for a Consultancy PM.  When the client is responsible for the infrastructure on which the project depends, any failure, downtime, or force majeure where they are billed for your services but no work is being performed because of their nonperfomance, should be reported in this section.  It should (hopefully) be rare to have content here, but it is important to report it when appropriate.  I have also seen this section used to report “thumb twiddling” time because a client has not given timely approval to a deliverable.

There are obvious direct benefits from issuing weekly project status reports.  In the next and final post on this series, some key indirect benefits that may not be obvious.

What benefits do you receive or would you expect from publishing a weekly status report with this content?  What project problems can be avoided?  Can you guess what points I’ll bring up?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Status Report

"Oft expectation fails, and most oft where most it promises; and oft it hits where hope is coldest; and despair most sits.”

                                                                               - William Shakespeare (All’s Well That Ends Well)

It has been a few weeks since I last posted.  Not because I don’t have ideas to share, but rather that I have a whole list of “next topics” and I struggle with where to go next.  I mentioned the Project Status Report in a post long ago during my series on The Project Manager’s Cycle, which I encourage you to review to properly understand the context for this expanded discussion on the Project Status Report (PSR).  With this post, I want to revisit the discussion about the PSR, going into depth on both the content (what goes in the PSR) and the rationale for the content.

The PSR is a key component of project communications.  There are the day-to-day communications by the project manager (the activities in the Project Manager’s Cycle where the PM meets with team members to get updates, to encourage, to motivate and meets with stakeholders for behind-the-scenes discussions).  But these build to the three central communication practices of the Project Manager’s Cycle:  the project team meeting, the PSR and the Client Project Meeting.

One of the essential decisions that must be made about the PSR – and this will be documented in the Communications Plan – is whether the PSR is a stand-alone document or whether it is a discussion aid to supplement the Client Project Meeting.  As a stand-alone document, I mean that it has to comprehensively explain information without the need for a discussion.  I don’t operate this way and, as a best practice, I recommend, instead, that the PSR is an aid to facilitate discussion in the Client Project Meeting (and I don’t mean either that the PSR substitutes for the Client Project Meeting agenda).   Thus, the Client Project Meeting – or rather, the minutes from that meeting – is the record of decisions made about the status.

The content of the PSR needs to answer a few basic, but essential questions:  how are we doing relative to the plan;  what is being (or will be) done to restore the project to plan, if necessary;  what threats jeopardize the project;  what actions are needed from the project owners or sponsors.

In the next post, I’ll address common sections of the PSR and the appropriate content for each;  and I’ll follow with a post on some of the tactical benefits of regular, proper status reporting.

What problems have you avoided that were attributable to good status reporting practices?  What problems have you encountered from deficiencies in status reporting?

© 2013 Chuck Morton.  All Rights Reserved.

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

“We’re on schedule for development and plan to start testing next week,” an upbeat Dave updated his manager, John.  John answered, “That’s good, but you’ve pulled developers from support to work OT to make the schedule, our support backlog is climbing, and now no one is available for the scheduled maintenance upgrade this weekend.  We need to take a closer look at how you are deciding the team’s priorities.”

Over the past two blog entries, on P&SD PM and Consultancy PM, I discussed two distinct project management philosophies.  This entry will discuss why this is important to a project manager, to a company hiring a project manager, to a company engaging a vendor of PM services, and to a supplier of PM services.

One area where the distinction is important is academia.  In some circles there are efforts to create a distinct School of Project Management separate from the School of Management.  Existing Management leadership resist this effort, answering that PM is just a variation of Management, not a distinct discipline.  Looking at P&SD PM, one could argue that P&SD PM is, as they argue, just a variation;   after all, it is generally found in organizations where PM is not a core competency, it serves the delivery of the organizations primary function, and general managers manage and utilize the PM services.  Consultancy PM, on the other hand, is a distinct model of management;  it doesn’t support an organization, it is the core competency of the organization.

Another area, closely related, is PM research.  Little of the published research on project management, such as that in Project Management Journal, distinguishes among the types of project management being practiced and the results of the research.  But what can be accurately inferred from the research when comparing such distinct practices as I’ve described in the two previous entries?

More relevant to the practicing project manager, especially one considering a career change, are the styles, cultures, practices, and expectations within organizations with the different PM environments.  I’ve worked in both types and management expectations are crucially different.  Further, the people – your managers and peers – in one are not likely to recognize the differences and prepare you for the changes.

As Peter M. Senge discusses in The Fifth Discipline: The Art & Practice of the Learning Organization (Doubleday, 1994), our mental models can artificially restrict our performance.  Be prepared when moving from a P&SD PM culture to a Consultancy PM culture, or vice versa, to let go of restrictive workplace assumptions.

Finally, the PM Best Practice blog endeavors to advance organizational maturity and continuous improvement.  The concepts explored in the P&SD PM environment and the Consultancy PM environment will be regularly revisited in future columns.  PM best practices are different in these environments and trying to force a set of best practices appropriate for one onto the other is, at best, frustrating.

Do you see other significant ways that the P&SD PM and Consultancy PM environments are relevant to you as a project manager?  If you’ve encountered any of the cultural differences that I describe, how did you adjust to them?