Project 2010 as an Enabling Tool for Project Managers : When to Use Project

As organizations perform work, it can be characterized into two major categories: operations and projects. Although these work categories share many common traits, they differ in some key ways. Consider a project as defined in PMBOK: "A project is a temporary endeavor undertaken to create a unique produce, service, or result."

Three key characteristics define a project and differentiate projects from operations. See if you can fill in the blanks with these differentiating characteristics:

If you chose unique, temporary, and result (or deliverable), you're on the right path. In contrast, operations focus on ongoing, repetitive activities, geared toward optimizing the value and utilization of existing assets. Projects focus on the creation of new value or unique deliverables in the form of tangible or intangible results. Based on the PMBOK definition, projects come from all levels in an organization and from any function, department, or group. Project management is no longer limited to traditional engineering, IT, or big research-and-development type projects, but now extends across most industries, departments, and functions.

Look at the first keyword in the definition of a project. Zero in on that word: temporary. Every project has a well-defined beginning and a well-defined end. In other words, there is no such thing as an ongoing project (see Figure 1).

Figure 1. No Such Thing as an Ongoing Project

1. Projects Are Supposed to End—Really

If you're working on a project and the end is unclear, stop and take the time to define the finishing point. Too often, confusion exists about when a project stops being a project and becomes part of operations or ongoing support. Even if you do a good job developing the result of a project, if there is confusion during hand-off or putting the result of the project into production, there may the misplaced perception of a poorly managed project. Your project may even be considered a failure. This isn't a good situation to be in, especially after working hard on a project.

PMBOK does a wonderful job differentiating not only between projects and operations but also between project life cycles and product life cycles. It states that every project has a beginning, a middle, and an end, with a cycle time that can be represented by some version of the curve shown in Figure 2.

Figure 2. Project life cycle bell curve

As the project moves through the initial stages, they're often broken down into phases. PMBOK directs us to organize and structure these phases by deliverables, or what I refer to as interim deliverables, which together will constitute the completion of the project and delivery of the final deliverables (the result).

As you move through the project life cycle and project phases, the impact of change on time, cost, and scope becomes increasingly worse and is sometimes catastrophic. If you don't have good initiating and planning processes, supported with the right tools—including Project—then the cost of rework, false starts, do-overs, and canceled or failed projects will be far greater to your organization (and your career) than the cost of the relatively small amount of time it takes to initiate and plan well.

2. Projects vs. Product Life Cycles

Keeping in mind that projects have defined life cycles, we need to clearly distinguish those life cycles from the life cycle of the product, service, or result that is being created from the project. Projects are unique undertakings that come with some level of uncertainty. As a result of that uniqueness, they eventually move into production or to the operations side of an organization, to be maintained in a non-unique or routine manner. As I mentioned, PMBOK differentiates project versus product life cycles, to help you know when to apply project-management techniques and tools. Consider Figure 3.

Figure 3. Product vs. project life cycles

The figure clearly illustrates that product life cycles contain project life cycles and that products may constitute multiple projects, such as new versions or improvements. Often this is referred to as life cycle management (LCM). It's easy to draw a parallel to when it's appropriate to use a tool such as Project. During the project life cycle, you should apply project-management techniques and tools. This is where Project becomes an enabling tool.

Figure 4 illustrates that for Project to be used in the right way, for its primary intention, it should be applied to the project-activity side of work, leaving other systems and processes to support ongoing, operational activities. It's also becoming more important to pay attention to the need for integration of systems in overlapping areas of operations and projects, such as enterprise resource planning (ERP), financial, and customer relationship management (CRM) systems. Knowing when to use Project and recognizing that it's an enabling tool when used for the right type of activities will go a long way toward enhancing organizational success.

3. Consider the Impact

Often, we're given tasks that seem to meet the definition of a project but don't appear to warrant the creation of a detailed or even high-level plan in Project. The size of the project does become a differentiating factor for determining when and how to use a tool like Project, but it's important to combine common sense with guidelines.

Figure 4. Operations vs. projects

I've worked with many project management offices (PMOs) that use criteria such as the number of person hours (effort or work hours) to determine whether an activity warrants the creation of a plan in Project. Other considerations may include duration or the number of tasks involved. It isn't uncommon to see a mixed set of these criteria used to determine not only whether the activity warrants a separate project plan but also whether an appointed project manager is needed.

Keeping your categorization process simple will help ensure your success in implementing a policy around what makes a project a project and when to employ a tool like Project 2010. Always consider the impact that implementing the project will have on the organization.

Real World Scenario: Person Hours as a Guideline

Working with a PMO for an organization that develops custom software solutions, we set up a custom enterprise project-management system using Microsoft Project Professional and Project Server. To facilitate project planning, we created many enterprise templates.

To determine whether a project was to be planned out in detail, we first put the project through a fairly rigorous initiation process. This evaluation determined whether the project was to be deemed a strategic or long-term project or considered a tactical or short-term project.

Project templates were only used to plan strategic or long-term projects that consumed more than 120 person hours. Short-term or tactical projects were also planned in Project but were tracked only as individual line items in a consolidated master plan. This allowed the organization to keep track of all work related to projects.

Another large financial institution used 40 person hours as the discerning factor for whether an activity was large enough to warrant a plan in Microsoft Project.