Moving beyond projects (part one)

It’s not uncommon for organizations to be heavily project focused, i.e., to align business activities and outputs with the projects that enable, create, or modify them. From budgeting, forecasting, and portfolio management, to cost and time accounting, staffing, and day-to-day operations, most of my clients, regardless of industry or size, exhibit this project-centric approach to work in critical functional areas (such as IT), but a good number of them exhibit this project focus across nearly the entire organization.

There are benefits to a project focus, of course, and to some extent it’s unavoidable, particularly in industries like construction, oil and gas, mining, aerospace, defense, and the like. But there are significant downsides to the project-centric approach, even for clients in these project-intensive industries.

In the rest of this post, we’ll take a look at some of the most common negative effects I see resulting from a strong project orientation and explore some of the alternative (and complementary) methods I typically recommend to help organizations structure their business activities and outputs more effectively.

Knowledge Management

The most pervasive negative effect of a project focus I see is in terms of knowledge management (KM). To some extent, I think everyone’s experienced some variety of this issue: during a project, the team collects a tremendous amount of new and existing knowledge (through stakeholder interviews and analysis of systems, processes, and so on), much of which is memorialized in project documentation such as design docs, specifications, interview notes, meeting minutes, issue lists, and lessons learned. And because the project team is living and breathing all this information during the project, KM is often not an issue for them: all this information—memorialized or not—is normally top of mind for the team and therefore readily accessible.

For those outside the project team, however, this information is much less readily accessible during the project and all but inaccessible after it’s complete for at least two reasons. First, information is usually organized differently project to project (or at least department to department), which makes it difficult for outsiders to find what they’re looking for. Second, particularly at large organizations, those outside the project team or the sponsoring department may not be aware of the existence of the project—so outsiders won’t even know to look for the project information that might be of interest to them…particularly once the project’s over and everyone’s moved on to bigger and better things.

Tremendous inefficiency results:

• Document level: folks duplicate work already done (research, design, requirements gathering, vendor evaluations, etc.) because they don’t know it exists
• Project level: important organizational learning (i.e., lessons learned) isn’t captured and made available to future projects—continuous improvement is more difficult and expensive to achieve, same mistakes are made over and over again
• Asset level: assets typically persist longer than the projects that create, maintain, and change them, and so critical information (design changes, as-built drawings, maintenance records, incident reports, bug fixes, and so on) is often organized according to the project that created it rather than with other documents related to the asset, making asset management more difficult and less effective than it otherwise would be

Let’s take a look at a real world example of how a project focus can hinder KM and the negative impact this can have on the company’s bottom line: mining operations.

During the first phase of development for a mine site, the engineering department builds an asset, e.g., a crusher. The site has production targets, and engineering designed the crusher to operate at a level that will support those production targets. After the phase one project ends, engineering hands over the operation of the site to mining operations.

During the first year of extraction and processing, operations determines that the crusher built as part of the phase one project is not performing at the level it needs to in order to support production targets—so they modify the shaft used by the crusher, file the as-built drawings in their repository, and performance reaches desired levels. So far so good.

When phase two rolls around five years later and the engineering department designs the expansion of the mine site, they build another crusher using the specifications from phase one, which do not include the as-built drawings in operations’ repository because they were created after that project was closed out. After the project to complete phase two ends, engineering hands over the operation of the expansion of the site to mining operations.

During the first year of extraction and processing on the expanded site, operations determines that the second crusher is not performing at the level it needs to in order to support production targets—so they modify the shaft used by the crusher, file the as-built drawings in their repository, and performance reaches the desired levels…and so on.

The result is significant waste (making the same mistakes again and again) and lost revenue (missing production targets that easily could have been achieved).

One way to remedy these kind of problems is to augment the project focus of the typical engineering department with a focus on assets, so that whatever happens, whether during a project or day-to-day operations, the impact on specific assets is captured and made readily accessible on an asset basis within a shared repository. In this case, when I’m getting ready to do maintenance on an asset (like a crusher), rather than having to find all the projects that may have affected the asset in order to do my work effectively, I can simply search for all information about that asset and be done. Similarly, when we’re looking to build another version of an asset in production, we can do so in full confidence that we understand the asset not only as designed, but as built, because all the relevant engineering and operational documents for this asset are in one place.

In the next post, we’ll look at how a heavy project orientation negatively impacts portfolio management and explore some ways to overcome it by shifting focus.