Projects and Operations: An Amicable Separation
Introduction Projects and Operations are quite distinct sets of
activities that, when mixed, can cause unnecessary havoc with
the management of each. They have different resourcing
requirements, require different management styles and have
different objectives. Projects are time-constrained and initiate
change. Operations are ongoing and suffer change, sometimes
unwillingly...
This short paper is a brief overview of the definitions,
descriptions and characteristics of each set of activities. And
concludes with some recommendations for avoiding the worst of
"projerations"...
Definitions
Projects Most project management approaches define a project
using terms such as: * a series of interrelated activities, *
with a specific goal or end result, and * having specific start
and finish dates.
Operations So we can broadly say that anything else is
operations; upkeep activities or incremental improvement. Three
key indicators that show when a set of activities is not a
project (ie. is operations) are: * if there is no commitment to
move ahead, or * if the set of activities doesn't have an end
date, or * if the set of activities does not have a measurable
goal.
Descriptions
Operations Operations can be described in terms of business
functions or activities and business processes. Business
functions are those groups of competence that are needed for the
healthy functioning of the organisation. They can be decomposed
into business activities that are usually, but not always,
encapsulated by an organisational unit. For example, human
resource management, the activity, is partly encapsulated by the
Human Resources Department.
Business processes, on the other hand, describe how the
organisation adds value. They are triggered from outside the
organisation and finish with the organisation delivering
something of value.
The two most common diagrams for these views are the org-chart
and process maps.
Projects Projects are described by their scope, the requirements
they are expected to meet and the resources required to meet
them. They have a deadline, milestones, stakeholders, steering
groups, a budget, and change and communication plans.
They are initiated, planned, executed and completed. They add
value for the stakeholders, who may or may not be outside the
organisation.
The most common diagrams to help describe projects are: a GANTT
chart for resource allocation, and PERT chart for critical path
analysis.
Characteristics of Projects and Operations Activities grouped to
form Projects or Operations are easily identifiable as each has
its own set of characteristics. Generally speaking they are
mutually exclusive though this is not always the case. The table
below outlines these in a comparative manner so that, in the
first instance, the distinction can be made.
Operations * Repetitive * Continuous * Deals with the Present *
Evolutionary change * Equilibrium * Suffer change * Pre-defined
objectives * Stable resources * Stability * Efficiency * Roles *
Security and Predictability
Projects * Unique * Finite * Deals with the Future *
Revolutionary change * Disequilibrium * Initiate change *
Objective to be defined * Transient resources * Flexibility *
Effectiveness * Goals * Risk and Uncertainty
>From the lists above, if a project is not actively seeking to
initiate change in operations, then it is, in effect, a set of
operational activities; improving the situation incrementally.
Operational activities do not, in general, cause disequilibrium.
It is the operational activities that are destabilised. By the
project. Not the other way round. Though there are plenty of
examples of operations destabilising projects... But this is a
resistance to change rather than the initiation of change.
There is, however, a link between the two. And successful
projects need to have this made explicit. To take the example of
change. Projects are change efforts. But managing change is part
of an operational manager's responsibility. Projects identify
the change required to move operations into the future.
Operational managers then manage the introduction of those
changes into their domains so that the new operational practices
are different from those before the project.
Conclusion
Problems with mixing Projects and Operations: If a project
begins to have characteristics that resemble those of
operations, it is probably a good idea to bring it to an end.
And ensure the handover in a timely and professional manner.
Equally, if a project has within its plan elements that involve
operations, it is probably better to take them out. Otherwise
there is a risk that operational management falls to the project
manager.
So we need to be wary of "projects" that are: * Uniquely
repetitive, * Continuously finite, * Projecting the present into
the future, * Evolutionary rather than revolutionary, * Are
stable, efficient and role based, and * Secure.
None of these bear the characteristics of a project. Rather they
are a mixture of both. They become "projerations", and are
generally unsatisfying for everyone working on them.
Overcoming the Mixing: One way to overcome the mixing of
projects and operations is to ensure that operational activities
are properly resourced. The absence of correct operational
resourcing often leads to projects being "loaded-up" with
operational tasks such as report generation, cube building,
process mapping, etc.
The people working on the projects know this and react, causing
tension with their operational activities.
The solution? Ensure that operational activities are correctly
resourced. And don't, as far as possible, move unresourced
operational activities into projects.