Human Resources Planning


In Chapter 5 we covered resource planning as a process to identify the costs of your project. At that point, we identified human resources primarily by job title; we did not have actual people matched to each deliverable . Before work can actually begin on the project, you need to replace the generic job title requirements you identified with the names of real people. You also need to address how you will organize and manage your team through the completion of the project.

Human resources planning includes defining team member roles and responsibilities, establishing an appropriate structure for team reporting, securing the right team members , and bringing them on the project as needed for the appropriate length of time. Human resources planning results are achieved through the development of an organization plan coupled with the acquisition of the staff necessary to complete the project.

Organizational Planning

Managing a group of people to complete a unique product within a limited time frame can be very challenging. Each team member needs to have a clear picture of their role on the team and what they are accountable for.

start sidebar
Real-World Scenario: Building a Rocket Using a Geographically Dispersed Team

Recently one of us took a college class in organizing technical projects. The instructor for that class had as his day job a position as a senior systems analyst for a large aerospace contracting firm. Let's call this instructor 'Jim,' so we have a common reference name .

Jim's entire premise for the class was that it's very difficult to put together a group of people- especially highly specialized aerospace engineers -some of whom live in California, others overseas, still others in Colorado, and so forth to design, build, assemble, and deploy a rocket. Basically, his points were limited but salient:

  • You have to really understand the project thoroughly. All team members have to be clear about what it is you're building. There can be no question about vision.

  • With big projects you use the 'eat an elephant one bite at a time' principle, breaking the project into manageable chunks and grouping the team members together that pertain to the chunk you're interested in talking about today.

  • There is a center point to all projects. You can't, for example, design the fuselage first, then design an engine to fit around it. All components of a rocket project center on the engine itself. Thus, the engine is a well-known, well- understood quantity-the rest of the parts are designed around it. We believe this is probably true for the vast majority of IT projects.

  • In the case of geographically dispersed teams , you simply don't have the funding to fly everyone around the country so they can get together to work on the project (though this happened for Jim's teams at very critical junctures in a project's stage). Jim and his teams rely heavily on online collaboration, using software, audio equipment, and cameras to bring people together over the Internet in order to discuss drawings, design characteristics, and other components of the project. So important to Jim was this topic that the majority of our class time, he talked about the miracle that is online collaboration.

  • You don't necessarily need to be afraid of geographic boundaries when assembling people whose skills you need. A little thinking outside the box might lead to a well- formed albeit nonlocal team. That being said, you, the project manager, are the final arbiter of what will and what will not work for a given project.

    Moreover, the primary takeaway from the class was that projects-IT or otherwise -of massive proportions are being worked on every day. The power of the Internet has greatly impacted the speed with which team members can communicate and bring their projects to fruition.

end sidebar
 

Additionally, team members and the other project stakeholders need to understand how the team will be organized. If you have a small 8-person colocated IT team, the team reporting structure will look very different than if you have a team of 150 that is spread across six different organizations in four cities.

Other potential constraints may impact your project staffing. These include labor union agreements, organizational policies, team preferences, and team member knowledge.

Organizational planning is the process of addressing interfaces that may impact how you manage your project team, defining roles and responsibilities for project team members, identifying how your project team will be organized, and documenting your staffing management plan.

Project Interfaces

You need to consider various interfaces as part of your organizational planning, as they may impact both the selection of project team members and how the team is managed.

Organizational interfaces Organizational interfaces are the relationships that must be managed when a project spans multiple departments. The way you structure your team meetings, how you provide feedback to team members, and how you communicate status are a few of the areas that may be managed differently if you are managing a cross-functional project.

Technical interfaces Technical interfaces drive how the technical work of the project gets done. The people developing a new software application that interfaces with existing systems must understand application interfaces as well as the operating platform on which the new application will reside.

Interpersonal interfaces Interpersonal interfaces are the reporting relationships between the people working on the project. In an ideal world, everyone gets along with no conflicts or disputes; in the real world, a project manager needs to be prepared to deal with differences between team members. Knowledge of previous conflicts may even impact the team member selection process.

A key input to organizational planning is the documentation produced from defining your resource requirements during the resource planning process you went through as part of cost estimating that was discussed in Chapter 5. The Resource Assignment Matrix (RAM) or other documentation from resource planning can be used to start your documentation of roles and responsibilities.

start sidebar
Integrated Systems: The 'We Can't Figure Out Why It Didn't Work' Project

The above reference regarding technical interfaces is associated with implicit and subtle nuances . It's easy for company executives to say something like this: 'You know, we currently have this XYZ system and, while we think it's wonderful-it does all of our company's billing- it really needs to be augmented with a newer , friendlier look for the intranet as well as the Internet. Surely the technology you bring to this project can hook to the current system to do this!?!'

Well, the answer is yes, sort -of, probably, maybe, and no. When we begin to talk about applying new technology to an existing system, or bringing two or more totally different systems together, we're talking about integrated systems.

Our experience has been that it's remarkably easy for companies such as Microsoft to advertise a snappy new way to interface with an existing system in order to extract information from it for a totally new form of processing. However, the proof's in the pudding, as they say, and putting an integrated system together is much more difficult in practice than in theory.

Consider a mainframe system running Adabas and Natural (a well-known mainframe database and programming interface, respectively). The system has run successfully for 25+ years and though it's efficient, it has run its technological course. Users are tired of the 'green screen' look of the mainframe, and mainframe programmers have run out of ways to make it do what needs to be done for today's billing environment ( specifically Internet queries). You're now charged with a project to bring about an application server interface that allows you to extract the data from this system, render it in XML pages, and thrust it out to the intranet for your customer service folks, your Interactive Voice Response (IVR) system for customers who call in, and the Internet for your more progressive customers seeking assistance via the Web.

Where to start? All of your techies say the words 'application server' simultaneously as though it's clear this is the magic box that's required. But is anyone aware of the complexity involved here? Is anyone in the company prepared for such an undertaking? Microsoft BizTalk, BEA WebLogic, JBoss, and other such application server software (not to mention Internet interfaces for the mainframe such as IBM WebSphere) could potentially bring about the magic required-but does anyone possess the wand? These application packages are something that a project manager shouldn't just willy-nilly bring into play without first understanding what's required to maintain such a deployment and assessing how much of a corporately internal intellectual grasp there is of such software. After all, you don't want to deploy a project for your company that's going to have to be staffed full-time by expensive contractors. And though it may be acceptable to ask for full-time employees (FTE) trained to handle the care and feeding of such an animal, chances are the first time you say FTE in front of the sponsor you might find your project killed . (It's almost like an allergic reaction with some executives.)

Our point here isn't that you should never venture into integrated systems land, but that you should go there with your eyes open . Do not imagine (or let vendors tell you) that it will be easy to connect two disparate applications. It won't be. You'll run into issues that you hadn't counted on-running the gamut from simple things like workstation connectivity to ghostly apparitions taking on the form of mysterious disconnections between the two systems. Not to mention the whole issue of representing the system out on the Demilitarized Zone (DMZ-that area between the Internet and the private internal network where IT shops often put their Web and other servers) to Internet users and all of the assorted security concerns that go along with that idea.

As a wise project manager you'll doubtless interview those who've gone before you in an attempt to figure out what the pitfalls are for the proposed deployment.

end sidebar
 

Roles and Responsibilities

A roles and responsibilities document lists each group or individual team member on the project and their responsibilities. You have a portion of what you need to document roles and responsibilities if you assigned resources to each task in the schedule or created a RAM to match the activities to the resource doing the work.

But roles and responsibilities of project team members are more than just the assigned tasks. There are standards and methodologies to be adhered to, documentation to be completed, and time reporting responsibilities, to name a few. So in addition to assigning people to tasks , it is a good idea to develop a template to document roles and responsibilities beyond just the task assignment. The more clarity around who is responsible for what, the better.

start sidebar
Roles and Responsibilities Example

Every team member should have clearly documented roles and responsibilities. That includes the project manager; so let's take a look at how you might define the roles and responsibilities for the project manager on the voice-activated dialing project.

Title: Project Manager

Role: Lead the project management activities associated with the launch of voiceactivated dialing.

Primary Responsibilities: The project manager may perform some or all of the following:

  • Identify any departmental project management standards.

  • Lead team in all aspects of project planning.

  • Manage the project team in the execution of the project work.

  • Develop schedule and maintain updates on a weekly basis.

  • Run weekly project team status meeting.

  • Track, assign, and report progress on any project issues.

  • Track implementation of contingency or mitigation plans.

  • Provide a weekly status of critical issues to project sponsor and key stakeholders.

  • Prepare and present a formal monthly project status for the stakeholders.

    Similar documentation should be developed for each project team member. This document not only clarifies for each team member what he or she will be held accountable for, but can also be used to communicate team member accountabilities with the sponsor, functional managers, or other stakeholders.

end sidebar
 

Many teams often include the project sponsor in the roles and responsibilities documentation. This can be a good way of confirming joint understanding between the sponsor and the project manager as to when and how the sponsor will be involved in the project work.

Roles and responsibilities can be documented in a variety of ways-bulleted lists, tables, or paragraph format, to name a few. Check for any templates available in your organization or use the format that seems most appropriate for your team.

Tip  

Whatever format you choose, the intent is to be as clear and precise as possible in defining the key areas of accountability for each team member.

Tip  

Roles and responsibilities may change over the course of the project, so be sure to update this document as needed.

The development of project roles and responsibilities is a good time to clarify the project manager's authority with the project sponsor, especially if the project charter was vague or did not include this information. The project manager's authority can be formally documented in the roles and responsibilities, or it may be an informal agreement where the sponsor delegates some of his or her authority to the project manager. Any authority surrounding hiring and firing decisions or the spending of the project budget should be documented.

Project Organization Chart

It is always a good idea to develop a project organization chart; not only does it provide a snapshot of who is working on the project, it also shows the reporting structure. Depending on the complexity of your project and the number of people involved, there may be multiple reporting levels.

In a small centrally located project team, all team members may report directly to the project manager. However, for an 85-person team working on a large application development project spanning multiple organizations, the structure will typically have many team members report to someone other than the project manager. Large, complex projects often establish project team lead positions . The project team lead is accountable for either the people assigned to a particular phase such as development or testing or for the team members from a specific department such as sales, training, IT, or network. A sample project organization chart using the team lead concept is shown in Figure 6.1.

click to expand
FIGURE 6.1 Project Organization Chart

Staffing Management Plan

The staffing management plan is a document where you pull all of your staffing data together. The staffing management plan documents when and how human resources will be added to and released from the project team and what they will be working on while they are part of the team. Adding and releasing resources may be an informal or a formal process, depending on your organization. Make sure you are familiar with any corporate human resources policies that may impact how you release team members from the project. This is particularly important if any of your team members are covered by a collective bargaining agreement (union). Very specific rules regarding both advance notification and the specific process may be used to move these people on and off a project.

If your project involves complex interfaces, be they organizational, technical, or interpersonal, document how you plan to manage these interfaces. If all software development testing must be assigned to a specific work group, this requirement should be identified. If your team spans multiple cities or crosses multiple departments, you need to document plans to manage these circumstances.

The team member roles and responsibilities and the project organization chart also become a part of the staffing management plan to make this a cohesive, comprehensive document covering all aspects of managing your team.

Staffing management plans can be high level or very detailed, so it is a good idea to see if your organization has any project staffing management standards or templates.

Tip  

You need to be comfortable that your staffing management plan provides you the blueprint you need to manage the human resources assigned to your project.

Now that you have a plan for managing the staff, it is time to staff your project.

Staff Acquisition

In the staff acquisition process you finally get people assigned to the project. During this process you will put to use some of the general management skills we discussed in Chapter 1.

How the project manager actually goes about obtaining project team members and the amount of project manager involvement in the decision making process for staff assignments varies across organizations. In the best case scenario, the project manager interviews candidates for project team positions and has full authority to select the team members; however, in many organizations, project managers must negotiate with the functional managers providing the resources.

Interviewing Potential Team Members

The control a project manager has over the selection of project team members varies with the type of organization structure and the policies associated with project staffing. If you are in a strong matrix or projectized organization there is more opportunity to impact the decision of who will be included on the team. If you will be interviewing candidates for any of the positions on your team, you need to be prepared with the questions you will ask and the factors that you will use to make your decision. When preparing for an interview, you should make sure to cover several areas.

Skill level:

  • Does the person have the training and experience to complete the tasks?

  • Does the experience level of the candidate match what is required to complete the tasks?

Project experience:

  • Does the person have previous experience working on a project team?

  • What types of projects has the candidate worked on?

  • What were the candidate's previous project responsibilities?

Interpersonal skills:

  • Does the person demonstrate the ability to be a team player?

  • Does the candidate have strong written and oral communication skills?

  • What are the candidate's strengths and weaknesses?

This is a starting point. Based on the specifics of your project, you can add other areas to this list.

Note  

You may find yourself on a project where at least part of the staff is preassigned, if the staff has been defined in the project charter.

Tip  

The purpose of an interview is to determine the best person for the job. Preparation is the key to conducting a successful interview. Have a list of written questions that you want to ask each candidate and take notes as you conduct each interview. There are laws governing the personal information that can be requested from job applicants . If you do not have experience interviewing job candidates, you should find a mentor to assist you or obtain a template or checklist from your human resources department.

Negotiating with Functional Managers

In a more traditional organization structure, you will need to negotiate with functional managers to obtain your project staff. You may or may not have an opportunity to interview potential candidates, depending on how staffing is handled within your organization. But even if you interview candidates, you will need to work through the functional manager to finalize project staffing decisions.

start sidebar
Not a Big Field to Choose From

Suppose that you're a project manager in the middle of staffing a new software development project. You don't have a large field of developers from which to choose. The senior-level developers are engaged and are using the juniors from time to time for coding assistance. You're going to have to pick from a field of one or two junior-level developers who you've been told are available for your project.

Picking a junior-level developer isn't necessarily a bad thing, it's just that you will need to augment the development time required to compensate for the 'junior-ness' of your programmer. He or she can probably do the job, just not as quickly as the senior who has 'been there, done that.' Skill level and experience will drive task durations out and hence affect the bottom line of the project's due date.

If the project has a hard due date- that is, the sponsor says it must be done by such and such a date-then you're faced with working your junior overtime, or telling the sponsor that you need to free up senior-level resources to meet the deadline or you employ the techniques of crashing and fast-tracking.

end sidebar
 

The functional manager will determine whether resources are available on a full-time or a part-time basis. If you are acquiring people who are assigned to additional projects or other staff work, you must establish a clear understanding as to the numbers of hours each person is dedicated to your project.

In a matrix organization, where the project team members will have multiple bosses (the functional manager and at least one project manager), it is essential to clarify and obtain agreement on the team member accountability. A team member should only be accountable to one person for a given result.

Performance assessment is another topic to be discussed at the time resources are obtained. Your organization may have a formal policy that includes input from the project manager as part of the process, or you may need to reach an agreement with each functional manager as to how you will provide feedback into the performance appraisal process.

As the project manager, you should initiate a meeting with each impacted functional manager to discuss your staffing needs and come to agreement on who will be assigned to your project. Functional managers often have very large teams and are constantly fielding requests to provide staffing resources to project teams. You need to come into the meeting prepared to identify your needs and have a game plan to negotiate with the functional manager. Here are some suggestions to help make this process smoother:

Schedule a separate meeting with each functional manager. Unless your organization has a formal staff allocation process involving all project managers and all impacted functional managers, meet individually with each functional manager so that you can focus on the project needs from that specific area and make the best use of the functional manager's time. When scheduling a meeting, be clear on the purpose, allow adequate time to work through any issues, and hold the meeting in a workroom or private office. Do not try to complete the staff negotiation process in the hall or on the elevator.

Identify who would be part of your 'dream team.' Do your homework and become familiar with the people who report to each functional manager. Use your staffing management plan, your roles and responsibilities matrix, any documented information regarding the experience and qualification of available resources, and previous work experience with potential team members to pencil out a list of who you would bring to the team if the decision were in your hands.

Plan who you will request from each functional manager. If you want specific people on your team or you require people with a specific experience level, explain to the functional manager who you want and the reason behind your request. Let's face it; every project manager wants the best people, so you will need to make your case. Be prepared to provide a brief overview of your project, its strategic importance, and the importance of the resource(s) coming from this functional area.

Have a backup plan if you cannot obtain the resources you want, and be prepared to negotiate.

Request your most critical resources first. It is very unlikely that you will get everyone you ask for. Certain people may already be committed to other projects or the timing of your request may conflict with critical functional activities. You need to prioritize your staffing needs. Understand which activities are the most complex, are on the critical path , and have the highest risk potential. These activities are the areas where you want to make sure you have the best people. Work through getting these areas assigned first. You have more flexibility to agree to a different resource or accept the person assigned by the functional manager for activities that are less complex or have float time.

Following these steps may not always get you the team members you want, but it will help establish your credibility with the functional managers if you handle your requests in a professional manner. Whatever the outcome of a particular meeting, maintain a good business relationship with the functional managers; you will be back to see them again for future projects.

Other Staffing Scenarios

In some situations you may not be able to negotiate for staff. Only one person may be available with the skill set required. The project sponsor may assign some of the project team members, or the client or other executive stakeholder may request certain team members. Assignments made without your input may be good choices or bad choices. If you choose to challenge one of these assignments, make sure you are doing so based on hard facts such as the lack of the required technical skills. Unless the person simply is not qualified to do the work, you will probably have to live with this decision and make the best of it.

One last staffing scenario involves procuring resources from an outside supplier. Contract workers may be brought in if no internal resources are available for a time-critical project or if internal resources do not have the required skill set. Procurement planning is discussed later in this chapter.




Project+ Study Guide (Exam PK0-002)
IT Project+ Study Guide, 2nd Edition (PKO-002)
ISBN: 0782143180
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net