jump to navigation

Errors Inexperienced PMs Make: How to Delegate(Part 2 of 3) March 17, 2013

Posted by thefieldgeneral in Leadership, Project Management.

You’ve finally decided to delegate something. However, you are still worried about the task. How do you make sure they understand what you are asking? How do you make sure you send things in the right direction? How do you cleanly hand it off to the people that are executing the work?

Thanks to Philo Nordlund @http://www.flickr.com/photos/philon/

Thanks to Philo Nordlund @http://www.flickr.com/photos/philon/

In order to delegate a project, put together a clear written charter with scope, timeline, and authority defined. Nothing is worse than going to the first project review and realizing that the team just got it wrong.

Here are some guidelines:

1. It should be a document, spoken directions are just too easy to misunderstand.

2. Define the Goals.
Goals are the desired end state of the project with time frames. They differ from scope in that they are usually broader. You need to define goals because sometimes your scope is wrong. Your delegates should be closer to the project than you and understanding your goals will allow them to notify you when described scope conflicts with the end goals.

3. Define the Scope.
Scope should define what the team needs to do. This can be as broad or as narrow as you like. The key thing is to make sure the detail matches the skill level of those you are delegating to. A highly skilled team might require only broad strokes. (“Find a way to sell this property for $200K more than we bought it for.”) A more inexperienced team might require additional direction. (“Get a property value assessment. Solicit local realtors to find our how we can improve value cheapest. Suggest the improvements, I will approve. Execute the improvements. Put the property on Sale and execute the sale. Report back to me every two weeks.”) If you use a broad plan, you can also require the persons accepting the responsibility to take the broad goals and break them down into a detailed, actionable plan. This is a good strategy as it reduces your prep time and gives them a stake in the project while maintaining your control.

4. Define a Timeline Timeline is really a part of the scope, but it is important enough that I want to mention it separately. Every person has a weakness that might prevent them from completing the project in a timely manner. Some people just don’t work well without a deadline. Others will procrastinate. Others will freeze seeing the work as monumental unless there is an established end date. I personally like to establish several intermediate goal dates as it lets the team know I will be periodically checking up on the project. One key item here, set the dates then allow the team to talk about them and adjust them. If they agree to the time frames, they are committed to them.

5. Define Project Authority
When you define project authority you will indicate if other designated resources have been assigned to the project and how much control the responsible leaders have over them. You will also describes when the leaders need to come to you for approval. With very inexperienced resources you may only allow them to execute exactly to the charter with no variation. With other resources you may find that allowing them to bring you solutions to approve is more efficient. With your most trusted and experienced team members you may only ask to be informed of decisions, giving them partial or complete decision making power. Knowing the amount of ceded authority gives your delegates the confidence to act. Michael Hyatt talks about The Five Levels of Delegation a good structure for defining delegated authority.

Below is a sample Charter. It’s only a piece of a larger document. It could have been improved by having a clearly and separately stated goal from the scope.

Sample Charter

Sample Charter

One  thing you will notice, is that all of this charter preparation takes time. I have had initiatives languish for weeks because I just couldn’t carve out the time to put together the charter. Despite this, I would encourage you to stand fast and complete the written charter before trying to delegate a responsibility. The consequences of not doing so are a project that travels in the wrong direction. The wasted effort is bad enough, but the real cost is the frustration of your engaged resources who often have to throw away some or all of what they’ve already done.

Tell me about your experiences delegating.

Comment Here



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: