Not Everything is a Project

Most project leaders believe that a project is a temporary endeavor with a defined beginning and end that produces a unique deliverable, or another similar definition[1]. The problem with this definition is that it really does not exclude any effort from being declared as a "project." "Uniqueness" is a very vague concept that can be applied rather indiscriminately. Using the above definition, employees filling out their weekly timesheets could conceivably be executing a timesheet project, whose duration is 10 minutes, with the unique deliverable being the timesheet for that specific week. This extremely trivial example does point out that PMO leaders need more guidance than the standard definition provides.

And it gets worse: Once the "project" label is applied, project management process, governance, reporting and roles often follow. Although these practices have merit, if the effort isn't truly a project, they will hurt more than help. In today's environment, speed of execution counts, resources are scarce and costs need to be minimized. Project management and PMO involvement takes time, people and money. Therefore, applying these practices and oversight to the wrong efforts — that is, where they are not really needed — slows down benefits delivery and makes the effort cost more than what is necessary.

For example, an application development organization defined any effort that required more than 50 hours as a project, and applied project management and PMO oversight to these efforts, fostered by a very aggressive PMO organization external to the application development group. Very quickly, the organization found that it could accomplish much less than it needed to and at a much slower rate than the business expected. Sadly, the organization decided to outsource large portions of its development as a way of getting out from under its own PMO!

I have also heard of project review teams that were so bored with being asked to sit through meetings to review and scrutinize long lists of projects that contained items such as server upgrades, quarterly application releases, and other efforts that generally ran well and were completed to expectations that there was no mental energy left to fully engage with the really complex, risky efforts PMO leaders need to recognize when common wisdom is wrong and stop following it. Like the cowboy entertainer Will Rogers said, "When you find yourself in a hole, stop digging."

If you’re not really worried about It, its not a Project

The first step is to determine what really a project is so that the right level of rigor and management discipline can be applied. The key is to ensure that the effort has enough inherent execution risk that the cost of project management, reporting and governance is worth it to ensure improved execution. Anecdotally, that cost can range from 5% to 20% of the overall project budget. It does not come free.

A project is an effort that carries significant execution risk. If the organization is not really worried about deriving specific value from an effort or is not injured significantly by its lack of success, than it's not a project — it's just work. This description also implies that the definition of what a project is varies by organization. An organization with a mature release management process may find that quarterly releases look more like work than a project. However, another organization first establishing release management may find the first year or two of quarterly releases feels more like projects.

Work that requires a team, a plan and management is not always a Project

Many efforts need management — just not "project management". An effort that is large enough to warrant a team, and complicated enough to need a plan and someone to watch over it, looks and feels a lot like a project. However, if the effort is largely well understood, with little uncertainty and lower overall risk, it should not be considered a project. I call this kind of effort "managed work." Efforts ranging from infrastructure upgrades of many similar components, software installation on desktops to application and product releases, to the 500th opening of a fast-food chain restaurant can fall into this category.

One of the defining characteristics of managed work is often that it is a repeatable activity. The effort is done more than once (additional restaurant franchises, each one a copy of the others; multiple identical servers being upgraded; new product versions being released periodically; and so on). These efforts move from project to managed work because each repetition allows the execution to be optimized over time, thus lowering the attendant risk.

Carrying through with the franchise restaurant analogy as an example, the 500th restaurant being constructed and opened in North America might have components of the effort that feels like managed work to an experienced restaurant construction team, such as installing "cookie cutter" internal furnishings. However, that same team opening the first restaurant of the franchise in a new region might find that the effort requires true project principles across all components to mitigate the associated risks of unknowns in the new environment.

Environmental stability drives Project approach

A best practice that is inherent in traditional project management is to fully define the requirements (needs), have the requirements drive the scope, have the scope drive the plan and then execute the plan (hopefully on time and on budget)[2]. The logical flaw in this argument for more of the projects we encounter is that there is low certainty around the entire requirements set, and that working on them harder or longer does not help. The unknowns in the environment in which the project resides do not get resolved or become known on command. Often, execution must proceed within uncertain assumptions and incomplete requirements. This is the driver for agile, iterative and adaptive approaches[3].

Build a spectrum of effort types for your organization

To develop a set of approaches beyond work and projects, use Figure 1 and adjust it for your organization. First, decide what projects look like — the efforts that carry enough execution risk that they have the need and can bear the cost of project management process, roles and artifacts.

Second, decide whether a traditional or agile approach is required, based on the certainty of the overall requirements. Third, resource the people appropriately, arm them with the tools and guidance needed, and do not over engineer beyond what is required to deliver the expected outcomes.?

Recommendations

• Define a spectrum of effort types applicable to your organization that optimizes throughput, the ability to execute, and value based on the risk and uncertainty of requirements.
• Design a "decision tree" to identify each effort type with specific processes, roles, approaches and resource models.
• In all cases, make sure that overhead is minimized and all work is executed as "locally" — that is, close to the skills, knowledge and users — as possible

[1] Sources of project definition are from the Project Management Institute (PMI), and the Association for Project Management (APM) and others

[1] Project Management Institute. (March 2012). "2012 Pulse of the Profession." Retrieved from www.pmi.org/~/media/PDF/Research/2012_Pulse_of_the_profession.ashx.

[2] Rothman Consulting Group. (1 January 2008). "What Lifecycle? Selecting the Right Model for Your Project." Retrievable from https://www.jrothman.com/2008/01/what-lifecycle-selecting-the-right-model-for-your-project