3 practices every rookie project manager should follow
Summary
If you’re a rookie project manager, maintaining a calm and productive team environment should be one of your primary goals. I recommend three important practices that’ll help you in that quest.
Limit your work-in-progress
Be a scope dragon
Work in short cyclers
Have you just started a job as a project manager? If so, you know the basics, such as throwing up a task board on a tool like Jira. Maybe you’ve learned a bit of the agile stuff, too! But being a team manager is far more than asking a bunch of people to complete a bunch of tasks by a specific time.
I recently came across this graphic by Liz Fosslien that explains the role of an effective manager. Your job is to shield teams from:
unnecessary meetings;
ridiculous requests;
unclear priorities;
last-minute panic;
and uncertainty.
A great manager wards off pressures and maintains a calm team enviroment
“People don’t leave jobs; they leave managers,” goes the cliche. I believe the converse is true as well. People don’t stay with companies; they remain in healthy teams with effective managers. So, in today’s post, I want to share three practices that’ll help you maintain a calm but productive work environment in your team.
Limit work-in-progress (WIP)
Too often, we’re “involved” in many activities and not committed to anything specific. Your team then ends up with several parallel work-in-progress streams. The more workstreams a team has to handle, the more they context-switch. And context-switching is productivity kryptonite. Indeed, the more WIP, the less likely you’ll complete work in a reasonable timeframe.
Think about it this way. The number of tasks you can handle in parallel depends on the number of people in your team. So why take on more work than the bottleneck can handle? The agile and lean movement advocates the following principle.
“Stop starting. Start finishing.”
It’s simple to implement. If you’ve defined work stages, then work with your team to identify a reasonable work-in-progress limit for that work stage. Let’s understand this with a couple of examples.
If you only have a product owner and an analyst who scope requirements for the developers, your scoping stage should begin with a WIP limit of two and no more.
Similarly, if four developers work in pairs, you can’t handle more than two coding tasks simultaneously. So, your “in development” stage can start with a WIP limit of two.
Of course, you can tweak these WIP limits based on the throughput you observe. For example, the QAs may be able to test stories at twice the speed it takes for developers to code. Or perhaps your developers have to wait for feedback on their pull requests, and they’d like to pick up coding tasks to fill in at that time. In such cases, you may either tweak your existing WIP limits or add additional holding lanes, such as “ready for dev” or “ready for QA”, to buffer your WIP limits. Of course, you shouldn’t build up a massive inventory of “ready” tasks, but that’s a topic for a deeper discussion.
Be a scope dragon
While agile teams should accommodate new scope to address changing business needs, unbridled scope change can derail teams. Assuming that you don’t have any budget constraints to how much scope you handle, here are a few simple techniques to manage scope effectively.
Respect WIP. Unless it’s important and urgent, don’t context switch your team from the work they’re already doing. Let them finish their WIP before they pick up anything new. You can always prioritise your queue of “ready” tasks to nudge your team to pick the most important tasks first.
Keep your tasks small. Cultivate the skill to scope tasks effectively. Small tasks are less ambiguous, so it’s less likely that you’ll discover hidden complexity while the task is in progress. An efficient tasking approach helps you complete work at a predictable pace. No task should take longer to complete than the duration of one work cycle (a.k.a sprint or iteration). For example, if you work in weekly cycles, you must scope your tasks in a way that it takes less than a week to complete any of them. Ideally, the smaller, the better. Aim to size all tasks similarly, if possible. That’ll make it easier to calculate your team’s throughput (i.e. tasks per cycle). Small tasks will also make it easier for you to respect WIP. Someone will finish their WIP soon and be ready to pick up the next important piece of work.
Compromise scope, not deadlines. Perfection is often the enemy of good enough. There’s never a fixed notion of scope. Scope always increases over the lifetime of a product as the business context changes, as we get feedback from the market and develop new ideas. Scope change is a good thing, and this is precisely what agile accommodates when it says it values “responding to change, over following a plan”. Releasing early gets value out faster and feedback quicker. So you’re better off releasing a smaller scope on time than waiting for the mythical notion of “delivering all the scope”. Do the simplest thing that works. There’s always another iteration to do more.
Work in short cycles
You can’t limit WIP, be a scope dragon, and take forever to respond to your stakeholders’ needs. Most stakeholders are happy to wait as long as they know you’ll attend to them in a reasonable timeframe. In agile software development, we often advise our clients not to disrupt a team in the middle of a sprint. Instead, let the team complete their work at hand, and then in the next cycle, they can pick up whatever work a client prioritises.
Traditionally, software development teams have worked in month-long or fortnight-long sprints. There’s no law against a shorter work cycle, though. Especially if you aren’t building software, you can work in even shorter cycles - I suggest a week.
The shorter cycle makes everything easier.
Scope your work so tasks take at most a week. Most people know what they can achieve in that time frame.
If you realise midway that a task will take longer than a week, split it and deliver what you can within the week—compromise scope, not the deadline.
When working with stakeholders, you can always tell them that your team will pick up the next most important task by next week at the latest.
When you combine WIP limits with meticulous scoping and short work cycles, you’ll see how much easier it is to maintain a calmer team environment than with a laissez-faire management approach. I encourage you to give these practices an honest crack!
A colleague recently called me a “perfectionist”. They didn’t mean it badly, but I silently took offence to that characterisation. But I also understand where that impression comes from. I’m big on “doing things right” and not so much on “getting it right”. You see, “doing things right” is within our control, but “getting it right” isn’t.
Take my wildlife photography, for example. I could do all the right things in the bush—get to a wildlife-rich place, follow the tracks, listen to the sounds, and wait patiently—but I may still not get the shot I’m after. Does that mean I should stop doing things right? Not really, right?
Doing things right pays off in the long term. There’ll be days when luck and circumstances conspire against a thoughtful approach. When you zoom out, you’ll notice that an efficient approach pays off in the long run.
Effective management is about doing things right. Be boring. Boring is efficient. Follow a good process, and the discipline will pay off. It’s only a matter of time!