Friday, October 19, 2012

Beginners Guide To Project Management
Part 16 - Putting Your Team to Work

Now that you have your plan near completion and the work is about to start, what do you do? Between getting your team and put them to work, buying the stuff you need, produce the information on your project status and performance that you and your stakeholders need, keep your risks under control, and of course, control your costs, schedule and scope, where do you start?
You can approach this in a few different ways, but most cases what makes sense is to do first is to get your team together and put them to work. And all the rest of your work just kind of develops from there. Continue reading to check out the details.

Previously on the Beginners Guide to Project Management:

Introduction
Initiating
Planning



Get them where you can

What skills are in need? What do you need to be done? Where can you get the people you need from? Do you already have some attributed to your project? Do they need trainning? What's in it for them? What motivates them?
These are some of the questions you need to answer. Out of the planning process you just went through, you should already have a clear idea of the skills you need in your team. If you don't, it's time to take a step back and check it carefully because you really want the right people with the right skills for your project. You can get them from many places:

  • Attributed: some can be attributed by a stakeholder with enough saying on your project
  • Your own organization: either from your department, or your workplace, or another department, or another location, or bringing someone new to your organization
  • Another organization: outsourcing part of the work, or hiring some skills at a daily (hourly or monthly) rate
All these are possible solutions but they answer to different problems and demand for different approaches.
For instance, if you're in the Marketing department running this project and you need someone with financial skills that happens to work in the Financial department, you must be aware, for starters, that you have no authority over that person. Remember that the one who's evaluating that person's performance at the end of the year and decide her/his raise or promotion is her/his boss in the Financial department, not you or your boss in the Marketing department. So having someone like that on board requires some creativity from you: how are you going to make that someone play ball? What's in your project that can motivate her/him?

The same goes for the other options that you have. Defining a sub-project and outsource it also demands a different approach and it also answers to different problems than hiring an extra hand by the hour. Most of the times you just want to bring strangers onboard if the work that they have to do is not core to your business, so you could consider either of these options in this case. If it's not core and the work is not much inter related to the rest of the project work, you may consider outsourcing it. If not, your best option is probably to get the skills you need from another company but put them to work as part of your team and pay them by the hour (or day or month).

Whatever happens you may count on a lot of negotiation going around: because you don't want this person on your team but you want that person instead; because the rates for the skills you need are too high; because there's no one in your company available to work for your project at the moment; because there's other stuff going on in your company that's more important and you can't move things forward; because you can't get your sponsor involved enough. You name it, you have to negotiate for it. If you just stand there waiting for your team to enter the room ready too work you're up to a bitter surprise.

Put them onboard

Puting a group of people working together doesn't make it a team. They will have to connect and trust each other (you included) and, most of all, they have to want to be in that team. Although I'm not a fan of the expression "team building" you have in fact to start there when the people in your team don't know one another and you can do it in a wide variety of ways - your imagination is the limit. Why now a wine tasting event? Or a kart race? Just get them together because of some reason that makes them interact with one another.

Also this is a great occasion to check out what kind of people you have onboard: who's extroverted? Who's to shy to speak? To whom does everyone look to when an action is expected? Who's funny? Who listens first, forms an opinion and then communicates it? All these are probably useful in your team and they should have the role they can perform the best. Puting someone who's too shy to speak making a presentation or a training session is probably a bad idea, right?

Whatever you don't introduce someone to the team as "hey guys, this is Daisy, she'll take care of the database for us" and leave it there. Make sure everyone knows what part they play in the project and that the roles and responsibilities are clear to everyone.

Another important part of putting them onboard is to clarify expectations. What will your behavior be? How demanding? How close will you work with your team? How much space will they have to decide, to criticize and to make suggestions? Believe it or not, some people are just not comfortable with simple things such as feedback (more on this the article "How to give feedback"), so all these have to be made clear to everyone.

But please note that turning a group of people and make them a team doesn't happen overnight. The popular theory around this topic involves the cycle:
Forming -> Storming -> Norming -> Performing -> Adjourning
This clearly implies time between stages. So before getting to a performing team you have a few stages to address first, each one with it's own challenges and taking some time.

Building a Cathedral

Remember your project plan? Does your team know all about it? Do they know what part they play? And what's at stake? Besides the tasks your team has to perform, they should have a broader view of the project. What deliverable are they working on when they're doing this task? Why does your company want this deliverable in the first place? What impact will their work have? If you go back to part 4 of this guide, you'll find some more on this, including outputs and outcomes.
I can't trace the origin of the following tale that illustrates this perfectly. But it's a wonderful story that makes my point and it goes like this:
A man enters a village where he sees a group of men working. He approaches the one closer to him and asks him what is it that he's doing. And he answer's "Making bricks". That really didn't answer his question so he turns to another man and asks what is he doing. And he answers "I'm making a wall". He sees a third man and again asks what's he doing. And he answers "I'm building a Cathedral".
See? Having a vision of what the end result is makes all the difference. While one man is making bricks (which doesn't sound very interesting) another one is actually building a Cathedral! There must be a huge difference in the motivation that moves them, right?

Distribute the work

And of course you have to distribute the work to be done by the team members. Or give them to chose the work they want to do. Whatever you decide about it, you must make sure everyone knows what to do so you really need some sharing tool to expose it. You can use sophisticated software integrated with your company's ERP where tasks are clearly assigned to team members or just a white board.
Distributing the work can also play a role in growing the team. For instance, you can put a junior team member working along with a senior one so he learns how things are done - not only technical things but the way you want things done in your company and in your project.

But this isn't what it was planned

Somewhere along the line of putting your team to work you'll notice that you're not following your initial plan. It may be that you couldn't get all the necessary people, or maybe some of the ideal skills that were on your plan are missing on your team, or maybe some team members are juniors instead of seniors and will take longer on the tasks than you initially planned. This is not a problem, this is the way projects go. Projects are not static, things change along the way and you must adapt your plan to respond to these changes.
What you must do is keep you plan updated and keep changes under control at all times. Delivery dates can change, costs can change but you have to know to what they're changing to. If someone asks "When you will be done?" you better have an answer! You can have a different answer next week, but you must always have an answer.
The amount of changes you're allowed to have depends on the project context. It may even happen that you have a deadline that you cannot change - but you can increase costs. Or the opposite - you can't increase your budget but have some flexibility on the delivery dates. But you must know how much maneuver space you're allowed in each project.

Conclusion

Although this is the 16th part of this Beginner's Guide, it's actually here that the project work (as in building something) begins. And logically you have to get the team who's doing the work together so I started this way. But it's just one of possible ways to start.
Anyway, when you get to this point, you have to pay some attention to these:

  • Get the people with the skills you need
  • Put them onboard
  • Give them a vision
  • Distribute the work
  • Update the Project Plan

A final note

The expression "your project" that I often used in this article (and also throughout this guide) is quite misleading. The project isn't your's. And if it is you better be your complete project team.
Depending on who's looking at your project, your project is owned:

  • by the project manager,
  • by the sponsor,
  • by your company,
  • by the company who's paying for this project,
  • or even by team members!



Images from http://eandt.theiet.org/

Posted by

No comments: