Running successful projects – some lessons from strategy execution

In a recent Harvard Business Review article entitled The Secrets to Successful Strategy Execution, Gary Neilson, Karla Martin and Elizabeth Powers identify reasons why many companies fail in translating strategy to reality. Their research is based on surveys from over 100,000 employees in more than 1000 organisations worldwide. The article also lists the top five traits of organisations that are effective in executing strategy. When reading these, it occurred to me that the same characteristics are also crucial for successful project execution. Judge for yourself: the attributes, rephrased in project management terms,  are listed and discussed below.

1. Everyone has a good idea of the decisions and actions for which he or she is responsible: The project manager shouldn’t be the sole decision maker on the team. Many decisions (and follow-on actions) are best made by individual team members, especially when these pertain to their expertise. A smart project manager realises this and delegates specific decision rights and action responsibilities to appropriate persons on the team. Empowering the team in this way removes decision bottlenecks and keeps the project running smoothly. Moreover, delegating real responsibility  demonstrates trust and improves team morale. 
2. Important information about the project and its environment gets to the project manager quickly:  A project and its environment are dynamic – things change, sometimes from day to day. When changes that affect the project occur, it is important that the project manager is made aware of these as soon as possible.  As an example, a developer realises that an approach he intended to use isn’t going to work. Rather than taking unilateral action  – say, by shoe-horning his efforts into the time allotted – it’s better to let the project manager know  so that both the developer and project manager can come up with a mutually agreed approach.  This is critical because the project manager may be aware of certain things  (like reserve time or resources, for example) that the developer isn’t. If project-related information doesn’t get to the manager quickly, it is inevitable that sub-optimal decisions will be made –  either by the project manager or the team.
3. Once made, decisions are rarely second guessed: If the project manager has delegated decision rights (as per the first point above), it is imperative that decisions made by team members aren’t second guessed.  Too many project teams spend time reviewing decisions ad nauseum. Don’t do it – once a decision is made, get on with it. Decisions should be revisited only in exceptional circumstances, and only with very good reasons.
4. Information flows freely across all project interfaces: This is all about communication. Many projects suffer from a lack of open communication between various stakeholders (see my post on obstacles to project communication for more on this).  One of the important functions of a project manager is to ensure smooth communication, both within a team (internal interfaces) and between a team and other stakeholders (external interfaces). Most project managers are conditioned to ensure good communication across external interfaces, especially when the external party is a sponsor! But they often neglect to facilitate  communication between team members. Dysfunctional communication within a team can kill a project, so project managers should continually  watch for signs of intra-team communication problems. Communication, or information flow, is a good segue into the next point which is…
5. Team members usually have the information they need to understand the impact of their day-to-day choices: Team members are at the coalface of the project. They’re the ones who,  through their day-to-day work,  are making it happen. Seemingly inconsequential decisions made by them can have a large knock on effect on the project. Given this, they should be fully aware of the impact that their choices (and actions thereof) can have on a project. This can happen only if they have all relevant information regarding the project. What’s relevant? That’s up to the project manager to figure out, and communicate to every team member.

Perhaps you’re asking, “Why should traits relevant to effective strategy implementation have anything to do with running projects?” Well, a strategy can be regarded as a set of time-bound objectives together with a plan for implementing them. This makes it a project. So it’s no surprise that traits which improve an organisation’s effectiveness in implementing strategy also make project teams better at executing projects.

Empowered or not – A litmus test of organisational culture

In a recent lecture on leadership in software development, Mary Poppendieck relates the well-known parable of the three stone cutters. The story, in short, is as follows. Three stone cutters are asked what they’re doing by a passer-by. The first one answers, “I’m cutting stones”; the second, “I’m earning a living”; and the third, “I’m building a cathedral.” A variant of this tale is related in Ricardo Semler’s best-selling book, Maverick, in which he details how he turned his company, Semco, from a traditional, hierarchical organisation to one in which workers were empowered to make decisions that affected them. In effect, he turned an organisation of stone cutters into one of cathedral builders.

When asked, most senior managers claim that their organisations, like Semler’s, have more cathedral constructors than stone slicers. However, this is their subjective impression which, quite obviously, should be taken with a sprinkle of sodium chloride. What’s needed is an objective test of employee empowerment in organisations. In her lecture, Mary Poppendieck proposes such a test. Here it is:

Question:
What do people in your organisation do when they are annoyed by some aspect of their job?

Possible Answers:
a) They complain about it.
b) They ignore it.
c) They fix it.

(a) corresponds to the stone cutter, (b) the wage earner and (c) the cathedral builder. Poppendieck’s point is that when people are empowered to change aspects of their job that they feel need to be fixed, then it is clear the organisation has pushed decision making down to lowest possible level. This situation is desirable for two reasons:

1. Decisions get made at the level at which work gets done.
2. Everyone in the organisation is able to fulfil their full potential

So, now that you’ve taken the test, do people in your organisation (or team) cut stones, earn a living or build cathedrals?

SOA what? A clarification for CIOs in five limericks.

CIOs struggling to keep a lid
on expenses not budgeted,
should have no fear
for help is here –
through designs, service-oriented.

A consulting giant claims
cost cuts and many more gains
will come one’s way
when SOA
unshackles technology’s chains.

“The Next Revolution in Productivity.”
Hype’s alive and well – so we see.
But implementing software
that’s not business aware
will cause much pain and grief.

The slick salespersons who sell
SOA software won’t tell
the truth, it’s tragic
that it ain’t no magic,
but a true integration hell.

So, don’t be sold snake-oil.
For you will be in for much toil.
With nothing to show
for all your spent dough,
but an organisation in turmoil.