Mismanaging Time: How Not to Manage Projects, Part 2
This is the second article in a series about mismanaging projects. In other words, if you can avoid doing the stuff here, you’ll be on the road to managing projects effectively.
There are five aspects you have to manage to move projects forward effectively:
- The project itself, discussed in the previous column.
- Time.
- Money.
- The client.
- The team.
Let’s talk about mismanaging time. This topic is complex, and I’ll break it into two sections, concluding in my next column.
The Matrix of Project Times
The table below flags time-related issues on three different scales for various aspects of a project or team, the first of which is the project itself.
Let’s take a brief look at each of these, in turn.Project Time
Minutes and Hours: Most legal-project tasks have – or should have – durations measured in days, as we’ll see below. However, a significant amount of time on a project is lost to “friction,” non-goal-related activities. The legal professional and the project manager rarely build these minutes into the schedule – and often fail to acknowledge their impact until prompted – but they add up quickly. Friction is one major reason so many projects, in fields from law to banking to IT, take longer than expected.
In other words, you can fail quite nicely by ignoring the effects of friction. Those impacts are real, and they add up quickly.
The simplest form of friction is brief off-task activity – e.g., bio breaks, checking email, drop-ins and interruptions, and so on. We’ll look at these below in the context of the project manager’s time, but of course similar friction affects all workers on the project, and thus the project itself.
A second form of friction stems from interpersonal or office dynamics. We’re not robots. (And AI-powered robots aren’t doing our jobs. Yet.) If an office environment is uncomfortable, physically or emotionally, work will take longer, and/or be done less well. Too many team meetings – as well as too few – will also slow down work, the former for obvious reasons, the latter because team members will lack information they need to make the best decisions quickly.
As a project manager, aim to handle friction in two ways: First, minimize it, to the extent you can. Second, build it into your schedule. If a research task will take two hours in an ideal world, then it’s likely to take two-and-a-half hours in the world we actually inhabit. Note that some tasks with throughput set by empirical evidence, such as e-discovery page rates, have this kind of frictional time already built into them, but for most legal tasks, you need to recognize, minimize, and allow for a certain amount of friction.
Task Length: Setting a bunch of very short (one- or two-hour) tasks is a good way to screw up a project by adding massive frictional overhead. Agreeing to a task length measured in months will also increase the likelihood of failure, both because you won’t know what’s going on inside the task and because of Parkinson’s Law.
Most of all, allotting either too much time or too little will hurt a project. Too little, and either tasks are rushed (or done poorly), or they take longer than your plan allows and thus destroy your carefully worked out schedule. Too much time, and you deliver work with little marginal value, wherein the last 20% didn’t really add much that the client cares about – and is happy to pay for.
I’ve written elsewhere, in SLAW and in my books, about how to set task lengths, and why most tasks should be broken into chunks of about eight to eighty hours (one day to two weeks, called “human scale”). But let’s look at another way task length affects project time.
In 1955, historian C. Northcote Parkinson formulated what’s come to be known as Parkinson’s Law: Work expands to fill the time allotted for it. (His book – which I highly recommend – is brief, funny, and filled with humorous drawings. Don’t let that fool you into thinking his work wasn’t serious.) If you allow too much time for a given task – or don’t set a target at all – that task will take the full amount of time. In fact, it will likely slop over and take even more time, because project tasks simply tend to do that. Thus well-managed projects set reasonable expected lengths for each task, and good project managers urge their teams to be thoughtful about trying to keep the work within those lengths.
Note that task length is not the same as a deadline. Most of us do multiple tasks over the course of a couple of weeks, across multiple projects. That’s neither good nor bad, per se. It’s just the way the legal world works for most of us. It’s a nice luxury to sometimes focus on a single project for an extended period. (See Slow-Motion Multitasking, below.)
Dependencies: Ignoring how one task is dependent on another – especially when different people are doing the various tasks – is a good way for a project to shoot itself in the foot.
Consider the following brief task list:
In theory, we have 15 hours of work, spread over perhaps four days.
Let’s say you’re responsible for the document, you finish on time, and your document hits the partner’s inbox at 4:58 p.m. Tuesday.
The partner, however, has been called away on another item and can’t review the work until late Wednesday. Okay, we’ve lost half a day. Maybe we can make it up.
Except you’ve been sucked onto another project Wednesday afternoon, so you revise the document Thursday morning and get it off to the client, with apologies.
And you get the client’s out-of-office message. She’s in the Bahamas for the weekend. (It’s a legal conference. Really. At any rate, she’s not reviewing anything she can’t two-thumb on her iPhone.)
She sends you her changes Monday mid-morning and you jump on them right away, but… you’re still two days late. Note that the amount of work hasn’t changed, only the endpoint. Worse, if other tasks depend on completing this one, they, too, will now be late.
This is a common reason that even well-estimated projects to deliver significantly late. Small slips in making deadlines rapidly cascade into significant breakdowns.
The solution – and it’s only a partial solution – lies in understanding these dependencies, and making sure everyone in the dependency chain, including the client, is aware of them. Then you need to find the balance between staying on top of delays and creating additional friction by getting in your team’s hair, micromanaging, etc. That’s a balance that comes with experience, and it’s not the same for all team members.
Your Time
Interruptions: I’ve written about this many times, and indeed have a book on the subject, The Off Switch. Let me summarize:
Interruptions kill productivity.
It’s a slow death, and you don’t even notice it until productivity is gone.
So keep on letting yourself be interrupted. Give in to the temptation to check your email for the fifteenth time this hour. Try to do two things at once. Go ahead, damage your project.
Common interrupters include email popups, checking email spontaneously, people dropping by your office, social media, and rapid task switching rather than focusing for at least twenty minutes on a single task. All of these are productivity killers.
They add up, and you don’t even notice. Things take longer than they should, and you go home late, tired, stressed, and wondering where the time went.
Get rid of as many of these as you can, as much as you can, in your own work and your team’s. Set aside specific blocks of time to handle them.
As a project manager, you do need your door to be open to your teams (interruptions), but you can avoid interrupting your team unless absolutely both urgent and necessary. You can take control of the rest, including email.
Micromanagement is not only un-fun for your team, it saps productivity. So micromanage your team only if you want your projects to fail. (And micromanagement lets you pass the blame, too. The trouble with passing the blame – other than the morality of the thing – is that if your project had succeeded, there’d be no blame to pass.)
Be a manager, not a supervisor. Better yet, be a leader rather than a manager, but at a minimum, stop focusing on “how” and concentrate on “what.” Set clear goals. Then guide your team members to achieving and exceeding them (and do not be stinting with praise when they do).
Remember that the synonym for “my way” isn’t “the right way.” It’s “a right way.” Yes, there are a small number of low-level tasks, such as formatting briefs for a court, that have very tight constraints. Don’t treat the rest of the work like that. You won’t get your team’s best efforts, and you’ll make work for yourself.
I know how hard it is for many people to accept this. I had trouble with this problem early in my career as well. But if you’ve hired good people, you can point them in the right direction, give them feedback and encouragement, and get out of their way.
(If you haven’t hired good people, that’s a different problem. You can fix that. Hire people who scare you, who want your job, who are the very best people you can find. And give them visible credit for the work they do. You’ll be amazed at how much more your team gets done… and how much of that credit reflects back on you anyway!)
Slow-Motion Multitasking is the art of working on multiple divergent projects at one time – not on a scale of minutes or hours or even days, but over weeks and months. I recommend you invest seventeen minutes in watching Tim Harford’s TED Talk on the subject.
Our subconscious is a powerful tool, but we need to give it room and opportunity to operate. If you’re working on multiple projects that aren’t tumbling all over themselves or running against the same deadlines, you’ll discover that you return to projects refreshed after you’ve been working on something else for a few days. Not minutes, but days. Or weeks.
Slow-motion multitasking works best if the projects are diverse. For example, you might be project-managing the early phase of one project, shepherding another through client delivery, doing some long-term research that may help your career, taking courses (even CLE, as long as it’s more than just collecting the hours), receiving mentorship, and mentoring someone else. Try to fit these all into a morning, and you’ll build up a ton of stress while working rather inefficiently. Spend serious time on each of these in the course of a month, and the whole will become more than the sum of its parts.
Coming Attractions
Next time, the other two rows of this matrix, team time and client time. And in the following months, I’ll discuss how to fail at each of the other three aspects of total project management: managing money, managing the client, and managing the team.
Comments are closed.