Skip to content

Moving beyond projects (part one)

April 14, 2010

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.

One Comment leave one →
  1. April 17, 2010 5:57 am

    This definitely applies, I think, to the multiple projects we are constantly undertaking in an academic environment. One team is working on a report to an accreditation agency, every department is working on its own outcomes assessment processes, a third is working on strategic planning, a fourth on a project to assess and ameliorate workloads, or three different committees are working on a particular policy question. Individual faculty are producing annual reports of their activities, and another committee is designing a survey (that will have to be distributed, filled out, and analyzed) to collect data on faculty activities. Financial aid and admissions and the registrar are all next door to each other, but nobody has access to all of the data that would answer sophisticated questions about enrollment and retention (e.g. “what percent of applicants with 3.0 or greater high school GPAs remain enrolled after 4 semesters, and how does retention of this group correlate with financial aid awards?”). Reams of data are being produced, nobody has access to any of it, and all the answers to anyone’s question are out there, but you have to fill out the same information on five different forms to satisfy the inquiries of five different projects.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s