WTF?! No-BS PM -- Resource Allocation: The Core of Every Project

The performance of a manager is measured by how well that manager can organize a large number of people and how effectively he or she can get the highest performance from each of the individuals and blend them into a coordinated performance.

"People are the most important asset in my company." Every CEO or HR director will tell you this. But the people working in the company may tell you a different story.

What managers say matters very little. What does matter is how people assets are utilized. This separates a great company from the rest. If project teams are to excel, resource allocation is a most important issue to address. There's a big difference between a project-oriented company and a manufacturing company. The skills required in new product development projects and those needed for production are totally different.

Now we focus on resource planning and allocation for new product development projects.

Many organizations have a HR policy that goes some thing like this. "We value people as our most important as set, and we treat them with respect, trust, and dignity. With mutual agreement, we will allocate the jobs that fit their individual personal profile so that they will reach their full potential." However, assigning people with the right skill to the right job at the right time is always a challenge. Very few companies make a strong effort to achieve this goal. In fact, most companies just assign people to a project based on availability (not people's capability). Managers often say, "That's all we have; all my resources are used up." This problem can only be addressed by developing a proper resource planning system.

RESOURCE PLANNING

Many managers confuse resource planning with recruitment.

Resource planning has a much broader meaning than just hiring new people. Resource planning should be aligned with the company's vision and mission and its short- and long-term strategies. The question that should be asked is, "What type of people, with what kind of skills, do we need to achieve these strategic goals? How can we train and retrain our people in order to achieve these objectives?" These questions are answered by reference to the company's strategic intent.

Strategic Resource Planning

This is long-term resource planning based on the company's strategy. E.g., when a company wants to launch a new technology platform or enter into a new market, (such as moving from producing audio hi-fi systems to developing mobile phones), a unique kind of engineering staff will be required. It takes time and effort for a company to identify and recruit the required resources. Strategic resource planning, then, focuses on recruiting or developing existing resources for future needs.

Strategic resource planning is done to prepare and position the company for the future. It’s also intended to make the difficult technological switchover easier. As stated above, identifying future staff requirements begins with under standing where the company wants to go. Once this is accomplished, a plan can be developed to train the existing workforce and recruit individuals with skills that are so specialized that training existing people is not possible.

Strategic resource planning takes inputs from the following areas:

1. Long-term strategies.

2. Long-term product roadmap.

3. Long-term technology roadmap.

4. Long-term supplier technology roadmap.

The strategic resources plan should also divide the re source pool into two parts, one for new product projects, and one for technology building blocks. This is to ensure that the ratio of activities aimed directly at making money (product development projects) and activities aimed solely at preparing for the future (new technologies) are allocated properly and are within the company's means to control. Strategic re source planning is a continuous process that requires active participation from all management team members and should be led by the manager of innovation, R&D, or what ever group is charged with responsibility for product and technology development.

Tactical Resource Planning

Tactical planning is an effort to make the best allocation of the current pool of resources. Tactical management of re-sources causes companies great headaches. There are almost always more projects than can be properly staffed.

The tactical resource plan reviews current resource conditions and makes necessary adjustments to support current project assignments. It’s a summary of all projects, resource allocation, and status. Tactical resource allocation is the day-to-day operational aspect of managing projects.

Tactical planning requires inputs from the following areas:

1. Project priority list.

2. Product roadmap.

3. Technology building blocks.

4. Key components availability.

5. Inputs from various development councils and project managers.

Because tactical resource allocation is focused on short-term resource leveling, it’s best handled by the functional departments. However, their role now is to support projects rather than consider their functional departments as having priority. And this means supporting the project management office (PMO) (if you have one), since this department or function is responsible for the monitoring and support of all of the projects within the company. The objective is to ensure that resources are allocated in the best interests of the company as a whole, not just to satisfy the egos of specific functional or project managers.

This will be a new way of managing projects for many companies. The main advantage of this change is to have the development manager focus on technical issues while project managers are focused on delivering the projects per plan.

BASIC GUIDELINES FOR RESOURCE ALLOCATION

Here are some guidelines you should follow in order to make tactical resource planning work:

1. Allocate only 80 to 85% of the overall resource availability to projects. We know that this is heresy in the minds of many managers, who have been indoctrinated to think "lean and mean." The problem with the lean-and-mean approach to managing projects is that every time some problem occurs, it throws everything into a tailspin. Manufacturing operations have long known that you don’t want to load the facility beyond 85% capacity for any length of time, because when something does go wrong (a machine breaks down or raw materials are delayed), your entire operation is disrupted. If we lived in a steady-state universe, in which unforeseen problems never occurred, this rule would be unnecessary; but so long as turbulence exists, we need some reserve capacity to handle it.

2. Don’t allocate resources for more than nine months.

Any resource allocation longer than nine months is just a guess. In general, you can only make predictions about the next three to six months. Also, it makes more sense to focus on short-duration projects.

The only exception to this rule is a project that is set up under pure-project conditions, in which all re sources are assigned to that job on a full-time basis.

For standard projects in which resources are shared across projects, this guideline is sound.

3. If possible, allocate resources to only one project.

Most managers believe that they can allocate re sources to several projects on a shared basis, because they think that 30%+30%+40% is equal to 100%. It’s not. That's because there is always time lost during the transition from one project to the next. This is called setup time in manufacturing, and we have known for a long time that it’s wasteful. As a general rule, you should assign a person to a priority one project, with a backup that he or she can work on in case of dead time on the first priority job.

4. Don’t add more resources to a late project hoping that this will compensate for the delay: As "Brooks Law" says: "Adding people to an already late project may only make it later".

5. Each project member should do everything possible to make a project succeed, and this is not limited to his or her job scope alone. One project manager told Louis that he always has problems asking his team members to write meeting minutes. All members need the meeting minutes as a reminder of action assignments made during the meeting, or as a reference for critical project decisions. But everyone thinks that writing minutes is not his or her job.

The attitude that only certain activities fit into a person's job is detrimental to teamwork. To illustrate, in one instance a project member left some electrical components on a mechanical engineer's desk. The mechanical engineer was upset and complained to his functional boss that he was not a messenger and had no use for these electrical components. The complaint was later passed on to the project manager. It was then revealed that the mechanical engineer was supposed to check the components for dimensions and confirm if they would properly fit into the circuit board for which they were in tended. It was indeed his job, but because of his belief that these were electrical components, and had nothing to do with mechanical design, he caused the company much wasted time.

TECHNICAL/ DEVELOPMENT COUNCILS

Following is an experience related by a notable PM:

Many years ago, when I was a newly minted quality engineer, I had great difficulties applying what I learned in school to my work. While some in-house training programs did help, I always found the training came too late. I found it was more helpful to discuss the issue or problem with my seniors, those who had more experience in quality. However, while these discussions were very helpful to me, many of them did not have time for such discussions of a specific subject. This problem persisted until I joined the quality council, where I could freely discuss the quality issues with the same professionals and learn from them.

This quality council was formed after we attended the quality college presented by Crosby Associates. The purpose of the quality council is to bring together the appropriate people to share quality management information on a regular basis. We found that the same approach can be applied to other development functions, such as software development, electrical development, and so on. This is very important when we allocate full-time engineers to a project, because many of them won’t have all the experience needed to complete the task. A supporting structure must be available to help them resolve their technical issues. Development councils are for mal structures that support project team members in resolving technical questions and form the backbone of the full-time project members' approach.

Development councils should be led by technical experts who are not allocated to projects and should be chaired by functional managers. E.g., the software development council should consist of council members who are senior software development platform engineers, and the software development manager should chair it. The council should meet regularly and share information on technical developments. The project team can bring problems they encounter to the council for guidance. The council can advise the team on courses of action and may even assign an expert to help to solve a particular problem. However, the project team is al ways accountable for the results.

Some useful guidelines for a development council are:

1. The number of councils should be based on the company's needs. E.g., you may need an engineering council, or you may need a process development council and an equipment development council if you find the engineering council is becoming too big. You may need a quality council, electrical development council, and so on. The critical point is that development councils must have formal status.

2. Each council must have a clear mission and vision, and a clear area of responsibility and operation. The council must meet regularly, and all meetings should be recorded.

3. Development councils are also responsible for future technologies within their respective fields. The councils should also be responsible for the technology roadmap and how to build up the company's technical competence.

4. When the project team encounters specific technical problems that they cannot resolve, they may ask the technical council for advice. Before doing so, the project team must define the problem and specify the actions taken to address it and the results achieved. The council then looks into the problem and advises actions to be taken. If these actions don’t resolve the problem, the council may assign a technical expert to assist. All actions must be documented and may be used for future technical papers or patent applications.

5. Each council should prepare design guidelines for project teams to follow. They are also responsible for publishing technical papers and preparing patent applications.

Summary of Responsibilities

The major difference between old structures and the new, project-oriented organization structure is that the development, or technical, experts will always focus on technical is sues as well as future technology development, while project and administrative work is left to the project manager to handle. This structure will clearly grow the technical competence of the organization in a faster, more organized manner than is possible when these roles are shared. ill. 1 shows a proposed new project-oriented structure (note: NPI = new product introduction).

RESOURCE MONITORING

Resource utilization should be monitored closely but should not be overdone. Many companies require their project team members to record the time they spend on projects to the nearest fifteen minutes. If you are a lawyer or a consultant who charges your client an hourly rate, than this is fine, be because most professionals bill in minimum increments of from one-tenth to one-quarter of an hour. However, this practice may create too much paperwork for the project team. Team members won’t report the time during which they had coffee with their colleagues. Generally speaking, if you capture time to the nearest hour, your records will be good enough to determine development costs for new products.

One caution, however: People must record their time at the end of each day, whether they like it or not. If they wait until a week has passed to fill in their reports, they just guess at what they did, and this is not history, it’s conjecture.

Another issue is that most engineers and other professionals are salaried. They are only paid for 40 hours a week, even though most of them work 50- and 60-hour weeks routinely. You must capture overtime worked on projects, even though it’s unpaid, or on similar projects, when you use data from the previous project, your time estimates will be too low.

Keep in mind that this is not intended to punish people or to demonstrate that they are taking too long to do their work. Such an attitude only results in people falsifying their records. It must be recognized as a way of determining how long it really takes to do work so that the capacity of the re source pool will be certain. Without such data, your project "plans" are only guesses.