Archive for the ‘Project Management’ Category
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.
- 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.
- 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.
- 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.
- 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…
- 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:
- Decisions get made at the level at which work gets done.
- 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?
Half a project manager, one project
A while ago I wrote a post entitled, Two project managers, one project, in which I offered some suggestions to those who share project management responsibilities with one or more colleagues. In the present post I’d like to discuss the opposite situation – one where a project is managed by someone who has to juggle project management responsibilities with their regular job. It’s pretty obvious that this is a recipe for failure (of the project), burnout (of the project manager) or both. Nonetheless, this situation isn’t uncommon and, given the ever-increasing resource constraints that organisations are subject to, I suspect it will only become more common. Hence the motivation for this post in which I offer the part-time project manager some tips on dealing with this predicament.
My first tip is to refuse to do it. Having said that, I realise that in most cases refusal isn’t an option, and may even be a career-limiting move. So, here are some other suggestions that may help deal with the issue head-on:
- Get someone to help with your regular job: Look into the possibility of off-loading some of your regular job duties to your co-workers. The first step is to get your co-worker’s consent. One way to get buy-in is to ensure that the work you’re handing over is meaningful for the other person. Consider giving away something that will be interesting and perhaps also useful from skill / knowledge development perspective. Next, you’ll need to get approval from management. When speaking higher-ups, be sure to emphasise the importance of freeing up your time to focus on the project. Some say one should speak to management first – I disagree. It is important to get buy-in from the “off-loadee” before approaching management about doing any off-loading.
- Find another part-timer to share project management duties with: If you can’t find anyone to do your regular job (or a part of it), you may have more luck getting someone to share project management duties with you. Here too, you would want to get the person’s OK before talking to management. Obviously it will also be necessary to get buy-in from management, but that shouldn’t be too hard if your project is important from the organisation’s perspective.
- Smart multitasking: OK, if you fail to get help – either with your regular job or with managing the project – you’re stuck with doing the project on your own. In this case, it is inevitable that you will have to multitask. Check out this post for some tips on how to multitask effectively.
- Know your limits: Despite your best efforts, it may become apparent that the project is suffering from the lack of a full-time project manager. In this case it is important to appraise management of the situation as soon as possible. You’re not doing anyone any favours by indulging in heroic efforts that may lead to burnout, so be sure that management understands the problems you’re having. The decision on whether to help or not is up to the folks upstairs, but they must know the full story to make an informed decision. If they decide not to help, at least it isn’t because they didn’t know.
After reading the above, you’re probably thinking that the suggestions I’ve made are pretty lame – they’re either impractical or won’t help much at all. You’re absolutely right! The truth is, a half-a-project-manager scenario is a bad one for both the project and the project manager. The best way to deal with it is not to sign up in the first place. So I return to my first tip – when asked to do it, just say no.
Eight to Late 