"Professionalism
is knowing how to do it, when to do it, and doing it.”
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:
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.
