Condor - Building the project team

Building a project team is never a simple thing. While there may be such a thing as the perfect team for any given project, there are always some constraints. Depending on your organisation, you may have a limited pool of people to choose from. You may only know some of the people available. Some may not have all the skills you need. You may not be able to recruit externally, or you may have to choose permanent staff over more highly-skilled contractors.

But whatever the constraints imposed on you, the process shold be the same. Below, I will list some of the typical traps people (including me) can - and have - fallen into, and how to avoid falling in in the first place.

Trap No. 1 - forgetting about the obscure tasks.
First, you need to know what type of resources you need, and how many of them. And in order to establish that, you need to go back to your original estimate. The estimate should have detailed all the elements of work you estimated were needed based on the user's requirements. Okay? You should then be able to determine the skill set required for each task - do you need web developers or mainframe developers? What about database specialists, testers, defect managers, configuration managers? List them all. Be very thorough about the skills you need each person to possess. List all your requirements, and check them with someone who has managed projects in that environment before. Don't overlook anything.

Trap No.2 - under-estimating your needs.
Second, for each set of skills (Java, Oracle, CoBOL, DB2, etc. etc.) you need to work out how many people you will need to accomplish each piece of work within the time available. So if you have a high-level estimate of 70 man-days, but you only have 6 weeks - 6*5=30 days - to complete the task, you will need 70/30 = 3 people (always round up!). Now, list each role you have to fill (if you need 3 Java developers, list 3 roles). It may sound like a lot of people, but trust me, you will probably need them, and it's better to have too many people than not enough! Well, there is one exception to that rule - if you absolutely, positively canNOT go over the agreed budget, you will have to allow more time, but usually the constraint is more about time than money.

Trap No.3 - unproductive people.
Third, you need to work out when you will need them. Check your project plan, if you have one. When does the analysis work start? The development? How about the testing? For each role listed, work out when you will need to get each person to start. Factor in the need to get them through the interview process and HR checks, if you are recruiting them from outside the company. Allow for time for them to get acquainted with the project background and requirements. And make sure they all have a desk, chair, PC, network access, security pass, and anything else new people always need before they can actually do any work.

Now you can start looking at who you can get to fill each role.

If, like me, you must first look within the ranks of the company's permanent staff, fine. But make sure your needs are detailed enough. If you specify you need someone with DB2 experience, that's what you will get - someone who has done the course and once read some SQL code. If you want someone who can do database design in his sleep, say so! But make sure you have a balance. Never ask for ten experts because they will be constantly arguing with each other about the finer points of Java Beans or whether SOAP or REST is the better web services approach. You need balance! Define the structure of your team, and specify who reports to whom.

It is at this point that you are likely to fall into :

Trap No.4 - the people no-one wants.
Permanent staff who are available immediately, are probably available for a reason - they are on 'the Bench'! They have been released from a previous project because they were not sufficiently skilled, unproductive, didn't fit in, or just downright lazy. So check out every person you are offered before accepting them. Ask another project manager if he/she would work with the people you have been offered. You may hear that Bill is fine under normal circumstances, but never leaves after 5 and can't function before his third cup of morning coffee. You may hear that Judy is a fantastic coder, but is a little slow, and does not react well to pressure. Bear in mind that no-one is perfect, and everyone has his/her weaknesses. Just make sure that you can live with the ones mentioned, and can make allowances and adjustments if needed. And don't be afraid to say No to HR if someone is not suitable.

If the people you need are not available, you will have to recruit externally. It is useful to ask HR about contractors who have worked there before. Most contractors do not leave because they are not good enough; they leave because the budget dried up or the project was cancelled. If a contractor who fits the bill has worked at your organisation before for a period of more than a year, or was renewed more than once, get 'em in! Their earlier experience with your systems will avoid a lengthy learning curve that is just unproductive time.

Now you should start to see your team come together. First the requirements analysts, then the designers, the developers next and so forth.

In an ideal world you will have time to get the team together for an off-site kick-off meeting, where you can bond and establish everyone's DISC or Belbin profiles and perhaps modify the balance of your team so that you have enough but not too many of every type of person and everyone gets along. But in the real world, you need to get started yesterday, and you need these people on board NOW!

The important thing to remember in all of this is - if you don't ask, you won't receive.

Project Management is all about the people you have to do the job, and if you don't have the right people, you are creating problems for youself later.