Project execution: efficiency versus learning
Most projects are subject to tight constraints. As a consequence, project teams are conditioned to focus on efficiency of project execution – i.e. to get things done within the least possible time, effort and expense. In this post I explore another approach; one that emphasises learning over efficiency. Now I know this sounds somewhat paradoxical: we all know learning takes time – and time’s the one commodity that’s universally in short supply on projects. However, please read on – I hope to convince you that an emphasis on learning may actually improve efficiency. My discussion is based on a recent Harvard Business Review article entitled, The Competitive Imperative of Learning, in which the author, Professor Amy Edmondson, presents two perspectives on organisational execution, which she defines as “the efficient, timely, consistent production and delivery of goods or services.” The two perspectives are: “execution as efficiency” and “execution as learning.” The former emphasises getting the job done, whereas the latter underscores the importance of finding better ways to get the job done. Projects are organisations too – albeit temporary ones – so the two views of execution discussed in the article may be relevant to project environments. This post discusses execution as efficiency vs. execution as learning in the context of project management.
Professor Edmondson compares and contrasts the two views of execution as follows:
|Execution as efficiency||Execution as learning|
|Leaders provide answers.||Leaders set direction and articulate mission.|
|Employees follow directions.||Employees discover the way.|
|Optimal work processes are designed and set up in advance.||Tentative work processes are set up as a starting point.|
|New work processes are developed infrequently.||Work processes are ever evolving and improving.|
|Feedback is one way (manager to team).||Two way feedback is common.|
|Employees rarely exercise judgement and make decisions.||Employees continually make important judgement-based decisions.|
The reader will notice that the efficiency approach is rigid and very “top-down” whereas the learning approach is flexible and if not quite “bottom-up”, at least open to change. The remainder of this note discusses the latter might work in a project environment.
In projects the focus is on getting the job done in time and on budget. This sometimes (often?) leads to micro-management of project execution to the extent that team members are given detailed directions on how they should do their tasks. This corresponds to the efficiency approach. In contrast, the execution as learning way recommends that project managers set the overall objectives and leave team members to find their own way to achieve them (within parameters of scope, time and budget).
On a similar note, as I have written in a post on motivation, the best way to ensure that people remain engaged in their work is to give them autonomy – i.e. empower them to make decisions pertaining to their work. This is true both in (permanent) organisations and projects. Many project managers are reluctant to delegate responsibility to team members – and here I mean proper delegation, where team members are given responsibility and decision rights over all issues that come up in their work. Granted, on some projects it may not be possible to delegate these rights entirely. Nevertheless, even in such cases it should still be possible to make decisions in a collaborative manner, with input from all affected parties.
In another post I pointed out that project management methodologies are sometime implemented wholesale, without any regard to their appropriateness for a particular project. This corresponds to an execution as efficiency approach where directions are followed without question. In contrast, an execution as learning approach is one in which processes are adopted and adapted as required. This is better because it uses only those processes that contribute to achieving a project’s objectives; anything more is recognised as bureaucratic overhead – good only for generating pointless documentation and wasting time. This applies to not only to project management processes, but also to processes used in the creation of deliverables. This bit of common sense can be codified into a “principle of minimal process” which may be stated as follows: one should not increase, beyond what is necessary, the number of processes to achieve a particular end. This principle is akin to the principle of parsimony or Occam’s Razor in the sciences. Furthermore, in an execution as efficiency approach, processes, once established, rarely change. However, a project’s environment is always subject to change. In response to this, execution as learning recommends that processes be continually reviewed and tweaked, or even overhauled, as needed. What works well today may not work so well tomorrow. Bottom line: process is good as long as it contributes to getting the project done, anything that doesn’t should be discarded or fixed (i.e. improved).
An execution as efficiency approach downplays the need for communication because it is assumed that all processes are already running as efficiently as they possibly can. Communication in these environments tends to be one-way: from top to bottom. In contrast, in learning-oriented environments communication is a two way process: those doing the work suggest process improvements to management and management, in turn, provides feedback. Two-way communication is therefore an important element of execution as learning in organisations. I’d argue this is especially the case for projects because – as all project managers know – change (in scope, timeline, budget or whatever) is inevitable.
To conclude: projects are organisations, albeit temporary ones. Therefore, principles and learnings from research on permanent organisations should be checked for potential applicability to project environments. With this in mind, it may be more productive to approach project execution with a learning mindset rather than a focus on efficiency. Of course, this is not new – proponents of agile techniques have long advocated such an approach; learning is at the heart of the the agile manifesto. That said, I’d love to hear what you think; I look forward to your comments.