Skip to content

Resource Planning

April 22, 2010

The essence of resource planning is making sure you have the right resources available at the right time to perform the right tasks for your organization. You can do this with varying levels of detail. For instance you can start by laying out tasks, estimating them, identifying dependencies, assigning them, and then prioritizing work (you’ll need to do this eventually, but it does take time). At the other end of the spectrum, you can do quick thumbnail sketches of your projects using start/end dates and rough cuts at effort. If you have the right tools you can be done in about 5 minutes.

Not all resource planning is the same. High level resource planning is strategic. It admits conflicts and inconsistency. Constraints are violated with the understanding that they can be modified in numerous ways if the end result makes sense. It’s best to do high level resource planning with as little effort as possible. Make rough sketches. Use tools to accelerate your exploration. In a way, your goal is to brainstorm ways to reach your organization’s goals first and then figure out if you can make any of them happen.

Frontline resource planning is more about doing the best with what you have. It’s harder to violate constraints. There isn’t time to hire a bunch of people if you decide to take on an additional project or do things in a different way (in any case, adding too many people to a project at the wrong time can have disastrous results). Here, resource planning is all about working within constraints. Can you streamline cross-functional coordination to get work done more efficiently? Can you find ways to execute more consistently or to focus more effort on the non-trivial tasks instead of the routine? Frontline resource planning is about making sure people are in the right place at the right time to hand off and receive work. Frontline resource planning is about making tradeoffs between projects as new things come up. It’s about integrating top level goals with individual tasks so that people always work on the right things at the right time.

Don’t confuse high level resource planning with frontline resource planning. If you take a high level perspective to the frontline, your teams will always be overloaded and running late. If you take a frontline perspective to high level planning, you’ll never have the guts to do anything remarkable.

Advertisements

Some Things are Beyond Comprehension

April 21, 2010

We as managers tend to think that we have a firm grasp of the details. We think we understand all the tasks our teams are working on and how they’re connected. We convince ourselves that we understand project priorities and how they relate to the tasks our people are working on. We don’t.

Things at an organizational scale or even just a team scale can be beyond our comprehension. Consider this. You probably have 10 tasks (at least) on your plate right now. If you’re managing a team of 10 people each with 5 tasks, you have to keep track of 60 tasks at any given time. That doesn’t sound like much, but here’s what 60 tasks look like:

task-list.png

Even if all you had to do was alphabetize these tasks by hand, it would be a chore. In reality it’s much, much worse. There are dependencies between tasks that force a particular sequence. There are dependencies across functional boundaries which you have no control over. For instance, if you think something is very important to an organization, but it depends on something that another manager feels is unimportant, you have a problem (actually, this is a huge problem–we’ll pick this up in a future post). Dependencies like this typically stretch across a range of functions and chains of tasks. It’s not possible to understand how all of these connections interact with different functional priorities on all of your team’s tasks.

That’s why managers hire so many project managers or promote people into these roles. They want someone to shield them from the details. They want someone to give them a one sentence summary of where things are. They want this so much that they believe what these project managers tell them even if the project managers do not fully understand the situation themselves (how can they when their organizational perspective is even more limited than yours?). As long as deadlines are in the distance, it’s easy to feel that everything is under control. However, as projects reach their target dates, reality becomes apparent, and project managers play their other role of taking the heat for missed targets and budget overruns.

In order to effectively manage all of these details and align them vertically with top level goals, you need to automate this. Once anything reaches an organizational scale, it moves beyond individual comprehension. We know our aspect of it very well — as do our counterparts in other functions — but integrating all of this information and keeping it integrated is impossible to do manually. The technology exists for doing this. Stop fooling yourself and use it.

On Managing a New Team – Part 2

April 20, 2010

In our last post, we described the initial conversations you should have with your manager, your peers, and your team when you take on the job of managing a new team. In this post, we’ll talk about how you can use this to start leading change.

When people talk about challenges working with other teams, they’re really pointing out problems with cross-functional workflows (how “work flows” between functional groups to accomplish an organizational task). The first thing you should do is list of all the workflows people described. Can you name them? Who are the players? Did you miss talking with anyone?

For each workflow you’ve identified, list all of the participants by role. Put these roles in the label column of a swimlane chart:

swimlane-example-1.png

Next, figure out who’s responsible for doing the first step in the workflow. Write this task in a box in this role’s swimlane. Who’s responsible for the next step? Write this task in a box in that role’s swimlane and draw a line from the first box to the second. Repeat this until you get to the last task. If there are any decision steps, put these into a diamond with a branch for each decision going to the appropriate steps:

swimlane-example-2.png

Now, go back to your notes and review the problems people cited in working with your team and the problems your team raised working with others. Highlight these in your workflow documents. Do these trouble spots have anything in common? Are the problems in the same area? Are they the same type of work? Are they happening because of a lack of communication? Because of a missing step? Because of inconsistent execution? What you’re trying to do is understand the root problems so you can address classes of issues all at once. Identifying root causes is half the battle.

In your next status meeting, show your team the workflows you’ve sketched out. Ask them for feedback on what you’ve put together. Is anything missing? Does this accurately capture how work is done? Do people agree with the problem spots and your assessment of the root problems? Ask them what they think the most important workflows are and which are the easiest to fix. Your goal here is to get people to recognize the value of change and to get their buy-in to help you fix them. You’ll want to start with the easiest (but still important) workflows first so you can get some quick wins. Every time you get a win, you build both political capital and team momentum.

Identifying and improving workflows is a great first step for leading change. It strengthens cross-functional relationships, it has immediate benefit to the organization, and it helps establish a team culture. The effort you put in here gets you ahead of the curve over time and lays the foundation for all of your future change initiatives.

On Managing a New Team – Part 1

April 19, 2010

Every once in a while, you get to manage a new (but existing) team. There isn’t one right way of approaching this. In order to improve your chances of success, you need to do some homework.

If you can talk to the manager that’s leaving the team, you should. Get their take on what was important to them. Ask what goals were they pursuing and why. Ask them what challenges they were dealing with. If it’s not clear why they’re leaving the team, ask them — depending on the situation, you may not get an entirely truthful response, but you’ll get some response. As you learn more about the organizational landscape you’ll know how to make sense of this later.

Talk to your new manager and understand what their goals are and how your new team fits into that. Were there things that were working? Were there things that never worked? Are there specific things that your manager would like addressed or changed? Jot these things down. After your meeting, see if this make sense to you. Sketch out the high level organizational goals as you understand them and see if you can tie everything together. In order for you to lead your team well, you need to have this clear in your mind.

Sketch out how your new team interacts with other functions in the organization. Figure out who manages these groups. If you don’t know these managers, introduce yourself and ask them about their current challenges. Ask them about specific issues they’ve had with your new team and if there’s anything they’d like changed. Make sure you take notes. Try to understand what’s important to your peers and why. This is crucial in mapping out the political landscape that your team operates in (more on this in an upcoming post). After meeting with your new peers, see if you can sketch out a picture of how things fit together and tie into top level goals. Again, this picture has to make sense to you in order for you to lead effectively.

Finally, devote your first status meeting to asking your team what’s important to them. Ask them what they think the top level organizational goals are. Ask them about their individual and team goals. Ask them about the challenges they’re facing. Ask them which groups they have trouble working with and why. Your first meeting is not about telling your team things — it’s about you asking your team questions and listening. Jot your notes on a whiteboard so everyone can see. Treat this as a pseudo-brainstorming session. Take a pictures of the whiteboard. Make sure to thank your team for sharing their insights, but keep in mind that they may not entirely trust you yet — you have to earn this over time. As you build trust within the team, make sure you revisit this discussion. You will hear different things as people get to know you better and trust you more.

After you’ve talked to everyone, you’ll need to do something with all the information you’ve collected. We’ll pick this up in tomorrow’s post.

Sometimes it’s good to stop for a minute

April 16, 2010

Sometimes it’s good to stop for a minute and appreciate how you’ve gotten to this point. Think back to the beginning of your career. Think of all the good people you’ve met, all the mentors that took the time to teach you something, the managers that gave you a chance to do something great, the managers that gave you the slack to fail and learn from it, the teams that gave you the slack to fail and learn from it.

Each of us has been through a unique set of experiences that make us who we are. Be thankful for this. This is what makes us special. Leverage the heck out of this to do what no one else can — but be sure to stop once in a while and think about how you can give others the chance to do the same.

How to MBWA When No One Trusts You

April 15, 2010

Lots of people treat MBWA (manage by wandering around) as if it’s a silver bullet. It’s not. It can be extremely effective and it’s absolutely necessary if you want to lead your team effectively, but if people don’t trust you, it won’t work.

The difference between MBWA and MMBWA (micro managing by walking around) is trust. When you don’t trust your team, they know. You may not think they know, but they do. If your team doesn’t trust you and you start wandering around, you will unnerve them. People will tense up. You will destroy any flow they’re in. They’ll stop working and start giving you status reports. Instead of motivating your employees, you will have re-invented the age-old productivity buster: RTSBWA (round table status by wandering around).

How to BTBWA (build trust by wandering around)

If people don’t trust you and you feel bad about this and want to change, here are a couple of things you can do to “build trust by walking around”.

First of all, look people in the eye! Don’t scan their desk to see what they’ve been writing. Don’t look at their monitors to see what they’re working on. These are signs that you don’t trust them, that you’re dropping by to check on their work. When you give people your full attention, when you look them in the eye as you talk, when you listen to what they have to say, you build trust. Work hard at making the people you visit the most important reason you stopped by.

Don’t walk up and down each aisle! That isn’t wandering–that looks like an inspection. If you’re wandering, then wander. Randomly enter different sections of your organization. Get the vibe of a team without interrupting anyone. If the team is in flow, leave quietly. If the team is gathered in a discussion, smile and give a quick wave. If you make this a habit, eventually people will feel at ease with you passing through and will begin calling you over to share what they’re doing. If you show genuine interest, they’ll start trusting you enough that they’ll actually look forward to you coming by.

When you show that you earnestly care about your team, when you show genuine interest in what they’ve accomplished, when your support is authentic, MBWA works amazingly well. If you can’t do this yet, start by building trust. Make the first move today.

Be Careful with Praise

April 14, 2010

“Praise” is an interesting word. It can mean very different things depending on how it’s used. When it’s used in the context of a group of people, it typically conveys the sense of subordinate admiration. For example, consider this sentence: “People praise their leader”. However, when used in the context of an individual, it conveys the reverse: “He praised his dog.”

While the conventional wisdom is that you should praise your employees, no one wants to be treated like a dog. No one wants to be tossed a bone. No one wants to feel like a subordinate even if that’s what the org chart says. “Praise” from a manager can often feel manipulative. If you’re praising your reports because HR said you should or because you just returned from a seminar on how to motivate your employees, then you’re doing it wrong. If you don’t normally do this, they you’re definitely doing it wrong. The more skilled and more senior the individual is, the worse this comes off. The worst case is when you try this on managers who report to you– they know exactly what you’re doing and why.

No matter what the management books say, no one really wants “praise”. What people want is recognition— recognition of their achievements, talents, and skills. Not recognition in the sense of “public recognition”, but literally that you recognize what they’ve done and are able to do, that you are aware of it, that you acknowledge it somehow. This is what gets people fired up. This is the best positive feedback you can give. This is the kind of positive feedback that can come from peers, people in other departments, executives, or anyone else in the organization. This is the foundation of mutual respect and trust.

When you’re authentic (as you should be), subtle is best. Use body language instead of words to convey recognition, respect, and admiration. A warm, genuine smile is often much more powerful than a speech.