The difference between projects and operations

I don't see a need to determine if an initiative or activity is a "project" or an "operation". Maybe it can be both. The intent is to find the best way to manage what it is that we are trying to achieve. One should look at all available management tools and select what will best achieve the objective. Once you have labelled something - say "a project" - then you feel constrained to apply project management thinking. Yet there may be advantages to operational thinking.

Some will argue that a project is defined as a unique (non repeatable) initiative/deliverable with a beginning and an end. My response is that pretty well everything we do has a beginning and an end and that nothing is 100% unique (lucky if its 10% unique).. Project management has a very high component of repeatability - not only within itself but with earlier projects..

Bottom line: don't worry about labelling the initiative, put energy in finding the best way to deliver.

Despite the labeling aspect, Operations vs. Projects can make a significant difference in terms of what might be called Organizational Intelligence which I find can be very important to a PM. It speaks to the culture of the organization, and navigating that culture is very important in our job roles.

Businesses focused on operations want to limit change and disruption. Projects by nature cause disruption, albeit in a positive and carefully controlled way. PMs are essentially agents of constructive disruption.

I got into PM as one of the few people in a largely "operationalized" organization, willing to take on the new challenges while most people want a very predictable day where they work mostly independently at their own computer terminal. Understanding that culture is key to navigating the organization. There are some people who are responsive and comfortable with change, but the majority look at the PM as the pebble in their shoe that they would rather do without. Understanding the operations vs. project culture helps me understand how to deal with the people assigned to my project. The people who avoid change aren't going to react the same way as the people who enjoy change.

Similarly, when I'm changing jobs, I want to make sure it's a good fit for me, so I need to understand the organization. An operations focused org is generally more a functional org chart rather than a projectized one. Having a discussion prior to hiring about operations vs. project oriented environment, may be very important in figuring out whether or not I'm a good fit for the job opening, while speaking a common language. A PM in an operations environment is the one generally adding chaos to the established order. A PM in a product development environment is generally trying to create order out of chaos. Of course we try to find the best way to do the job, but I find it helpful to understand the organization before deciding on the "best" way to achieve the goals.

Despite the labeling aspect, Operations vs. Projects can make a significant difference in terms of what might be called Organizational Intelligence which I find can be very important to a PM. It speaks to the culture of the organization, and navigating that culture is very important in our job roles.

Businesses focused on operations want to limit change and disruption. Projects by nature cause disruption, albeit in a positive and carefully controlled way. PMs are essentially agents of constructive disruption.

I got into PM as one of the few people in a largely "operationalized" organization, willing to take on the new challenges while most people want a very predictable day where they work mostly independently at their own computer terminal. Understanding that culture is key to navigating the organization. There are some people who are responsive and comfortable with change, but the majority look at the PM as the pebble in their shoe that they would rather do without. Understanding the operations vs. project culture helps me understand how to deal with the people assigned to my project. The people who avoid change aren't going to react the same way as the people who enjoy change.

Similarly, when I'm changing jobs, I want to make sure it's a good fit for me, so I need to understand the organization. An operations focused org is generally more a functional org chart rather than a projectized one. Having a discussion prior to hiring about operations vs. project oriented environment, may be very important in figuring out whether or not I'm a good fit for the job opening, while speaking a common language. A PM in an operations environment is the one generally adding chaos to the established order. A PM in a product development environment is generally trying to create order out of chaos. Of course we try to find the best way to do the job, but I find it helpful to understand the organization before deciding on the "best" way to achieve the goals.

Hi Keith,

You said:
"Businesses focused on operations want to limit change and disruption"

That's an interesting hypothesis but I don't think it's true. In my experience there are digital businesses for example who are agile enough that innovation and continuous improvement are part of expected BAU activity for all business units. The idea that you need to start something called a "project" in order to effect disruptive change would seem very alien and counter-productive to many people in my field.

Projects are usually understood to apply limitations on the scope of change. An empowered team who focus on creating new product and enhancing value every day, who are accountable for results and costs but not restricted by any particular fixed scope are, I would suggest, not executing projects and have no need of one.

I don't disagree. All I want to stress is that the situation should dictate the methodology. The situation being the specific initiative, the organisation and the people involved. Some may believe that a solution to a problem is to label the problem. A company having challenges with their operational management approach may feel that converting to project management is the answer without doing a proper analysis - all they may be doing is uploading other problems.

Back a few years companies in difficulty would decide to computerise the administration functions (because someone told them that computers were the way of the future) rather than identify the real causes of poor performance. If anything, computerising enhanced the underlying problems.

My bottom line is to use the management methods and processes that most effectively delivers the solution or objective.

I completely agree. I'm merely stating that as a PM, how you choose to address a situation may be strongly influenced by the organizational culture. If you're working with people who mostly want to do the same thing every day of their careers and your role is an outsider assigned to implement changes, you will usually encounter resistance and probably need to tailor your approaches differently than when you're in an environment where change is the norm.

Not only are the business processes often different, but also basic psychological issues are at play like people's comfort level with change. In some environments you can move through the Storming and Forming stages quickly, while others require a lot more patience and hand holding before the team reaches the Norming stage.

I understand what you're saying, and I think the disagreement comes from what you consider "operations" and "disruption".

Operations are active or ongoing processes and/or functions. Incremental changes occur frequently in well run operations, however they are limited in nature compared to the repeating cycle of mostly regular activities.

If you were to draw a diagram of your existing processes, and you are changing both the content and the order of most of the steps constantly, that really can't be described as operationalized processes. It would be better characterized as process development. In order to leverage repeatability and reproducibility, there is often a longer term goal to stabilize the processes, i.e. move from development to operations.

Process changes require disruption by definition, because they alter an existing way of working. Although disruption is often viewed as negative, it is also required to make improvements. Since operations seek to continuously produce value through generally repeatable activities, pausing/disrupting continuous processes to enact changes interrupts the production of value and often cash flow until the processes may resume. For that reason, limiting disruption by making incremental changes in an operations environment is often preferable to stopping everything to completely overhaul the existing standardized processes.

That is what I mean when I say that businesses focused on operations (ongoing value creation following regular processes) wish to limit the disruption. There is only so much disruption to cash flow that can be absorbed while still running a healthy core business.