May, 2007 Archives

8
May

Scale and Consistency

by Meri in Management, Productivity

One of the things that becomes a problem as your company (or product or service) expands is how to ensure a consistent experience across the board. Whether it’s that you’re operating in multiple countries or just spread across multiple servers, quality of experience can start to vary, not just for your customers but also for your employees.

This is why in huge companies, “procedure” can come to dominate. You want to make sure that all your employees get equal access to career progression, training, personal development. So you mandate that all your people managers follow certain procedures — annual reviews, work plans, etc etc. You want to make sure that anyone who calls customer service receives pleasant, friendly and above all useful service. In an attempt to standardise quality, you give people scripts, mandate that phones must be answered within a certain number of rings, and so on.

Many of us have felt the impact of these kind of procedures — the call centre guy who can’t wait to get you off the phone, because a “successful” call must be finished in less than 3 minutes; the manager who sits you down for a stale, scripted “career discussion” that makes you feel more like leaving the company than going for that next job or promotion.

My theory? These procedures are written in with the best will in the world. The need to write them down is the problem however — the “spirit” gets lost. People become slaves to the letter of the rules.

Have you seen this happen? Ever seen it combated in an effective way?

2
May

Using the Best Plan Format

by Meri in Leadership, Project Management

The most frequent mistake I see in Project Planning is what I call “premature Gantting” — going straight to creating a huge Gantt chart (often in MS Project).

Why is this a mistake? Because a huge Gantt chart, with many lines of tasks, all precisely allocated to specific dates looks very authoritative. It gives the impression that you’ve spent hours working out the exact dependencies, estimating the length of tasks and precisely scheduling all the work that needs to be done and who needs to do it.

If you truly have done all that work, then perhaps you’re fine. But the reality is that most of us have ACTUALLY spent half an hour scribbling on the back of an envelope, or at best on a flip-chart, to get some rough stages and some key dates. All the detail was then made up when the Gantt chart was created, primarily because the software demanded it.

What’s the solution? Let the format of your plan reflect the stage of development that it is at. Internally, I will frequently go into a meeting and DRAW the plan stages on the whiteboard. For communication with the customers/stakeholders, I’ll create a simple plan (sometimes even a flowchart) that reflects the reality of the situation.

So far, everyone involved has appreciated the honesty — and it’s prevented projects going wrong at a very early stage in the game.