There is abundant evidence suggesting that the amount of money
and resources used to manage unexpected events in projects is
significant. Therefore, a lot of time and money are invested
to prevent such unexpected events from occurring in the first place.
Of course, some of these events are avoidable. However, sooner or
later, an unforeseen situation will occur that requires the project
team's immediate attention. As in any confrontation, the project team
has two alternatives – fight or flight. Either the project team
apathetically surrenders to the challenge (flight), or, as usually is the case, the
team resolves to put up a fight. This is not a study on what project teams
do to avoid deviations in projects; it is about the fight.
Deviations or unexpected events are especially common and
hard to manage in complex, tightly coupled projects. In such projects,
the margins for error are low and project activities demand a high level
of integration and interdependence among the resources. The context
is typically found in concurrent engineering projects but also in
any other project pursuing operational efficiency. In organizations
where operations are tight, disturbances spread like wildfire, making
the consequences swift and the remedies hard to identify. While a
tightly coupled project demands a rapid response, complex operations
need time to get a thorough understanding of the situation at hand.
My research investigates how project teams deal with this
paradoxical situation, when managing deviations.
Projects traditionally do not fit into any rational planning model.
Too many unexpected events occur, which in turn, demand too
many unplanned responses. However, plans are not the entire story.
Some activities run according to the plan. Examining projects, in
general, and how deviations are managed in particular, through the
loosely coupled systems framework (Weick, 1976), helps explain how
some parts of the project can remain uninfluenced by deviations
(they continue as planned), while other parts are disrupted. Two
concepts are central to the framework—Responsiveness and Distinctiveness.
A loosely coupled system is responsive to events but still
preserves its own identity and some degree of physical or logical
separateness, i.e., responsiveness and
distinctiveness. Activities are tightly coupled, if there is high responsiveness and no distinctiveness.
The implications are that a tightly coupled system relies on standard operating procedures in
its operations. The initial, untested plan is an example of a tightly coupled activity. The loosely
coupled system, on the other hand, requires actions to be adjusted to the specific situation (praxis).
The everyday operations of a project are an example of loose coupling between the plan and its activities. |
