The Project Resource Request

Here is yet another template that I am digging out of my archives to provide here.  As you can easily guess, this document is designed for requesting resources at the beginning of your project based on information in your statement of work (SOW) and the estimates of resource requirements that either you or Sales put together in the pre-engagement process.  It is also helpful for requesting additional resources during the project.

How useful this is to anyone depends on the organization they work in.  If you have a mature PMO with processes in place, then I would guess that you already have a standard form or spreadsheet to use to request resource for your project.  However, if you’re one of just a few PMs or personnel acting in a PM role in your organization or you’re in the process of building some PM processes for a newer organization or even setting up a new PMO, then any template may be better than nothing.

As with all of these documents, if you want the original Word doc file, just email me if you think this will be useful or helpful.  And please, provide your own example if you wish.  We’re looking to learn and share information so I’m happy to use and post whatever you would like to provide to the readers of PM Tips.

PROJECT RESOURCE REQUEST

[Save file name as: client name RESOURCE REQUEST yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

WORK DESCRIPTION AND ROLE

Describe the work to be performed on the project by the resource(s) and what role the individual(s) will play on the project team.

DESIRED SKILLS

Describe the technical, business or professional skills needed by the resource(s) to successfully meet the needs of the project.

DELIVERABLES

Describe the deliverables the resource(s) will be responsible to complete as a result of their work on the project.

DATES REQUESTED

Starting: mm/dd/yyyy Ending: mm/dd/yyyy

HOURS OR % FTE

Provide the estimated number of hours or the percent of time the individual(s) will be need to be allocated to work on the project.

WORK LOCATION

Describe all of the locations the resource(s) will be expected to be located – if multiple locations, provide dates as they are know at the time of the request.

REPORTING STRUCTURE

Describe the reporting structure for the project and how the individual(s) will be expected to operate within this structure.

Attributes of a Successful Project Manager – Part 1

In this three-part series, I’ll present Jason Charvat’s take on the attributes of a project manager as documented in his book “Project Management Nation: Tools, Techniques, and Goals for the New and Practicing IT Project Manager.

This basically another take or view on the two articles I’ve previously posted on this topic:

• The Characteristics of a Project Manager (that evolved into several parts)
• The Skill Set of the Project Manager – Another View (derived primarily from Gary Heerkens’ book)

ATTRIBUTES OF A PROJECT MANAGER

For about three years as a project manager, I failed to listen to my team members and came across as arrogant. The one thing I learned from experience is that right action gets right results and wrong action gets wrong results. This kept driving me compulsively to consider what attributes I needed to possess if I ever was going to be an outstanding project manager.

Project management, as a profession, has changed through the years and has produced many good project managers who have risen to higher levels, consulted world-wide, and often started their own organizations due to their broader understanding of business principles. Within the project management profession, a manager quickly becomes well-known in a very short period of time; clients identify those project managers who are good and those who cannot perform well. The following personal attributes demonstrate the profile of a good project manager:

• Self-confident
• Problem solver
• Good listener
• Able to gain the respect of the team
• An effective communicator
• Capable of reacting dynamically and making decisions quickly
• Considered a professional
• A team player
• Knowledgeable about project management

Project management consultants are normally distinguishable from other company managers by the following attributes:

1. Reputation. The project manager is well-known by name in his or her industry and is often called upon to deliver papers, case studies, and new concepts to this audience.
2. Experience. The project manager has sufficient experience and has completed many projects.
3. Leadership. The project manager possesses the necessary leadership skills to lead people.
4. Presentation skills. The project manager has the ability to communicate on all levels in order to inform about project status.
5. Expertise. A project manager is normally employed because he or she is an expert on the subject and can speak with confidence on any project discipline.
6. Professionalism. The project manager, who belongs to reputable project organizations, abides by a code of ethics specifically designed for the project profession, thus ensuring that clients, organizations, and society are able to entrust project managers with their daily duties.

In Part 2, we’ll further discuss other areas of knowledge and abilities that the project manager must possess to successfully lead IT projects.

Dealing with Other Department Managers

For relatively simple short-term projects that are executed strictly within a single department, you, as the project manager, may have direct control over the time commitments and priorities of each team member.

Because the work is relatively contained and you’re in control, you are aware of you’re the deadlines and workload variations for the team members and you can build your schedule around the workload and adjust it as needed. You can also balance departmental and project demands on the basis of your knowledge of each and the scheduling flexibility and control you’re able to exercise.

As the scope of your project grows, your task assumes a greater dimension, and you will begin to work with people from other departments. This is where your communication skills are tested.

A common complaint often heard from other managers is, “You didn’t tell me in time,” regardless of whether problems arise because of deadlines, the use of an employee’s time, or conflicts in commitment. But you can solve most of the problems you will encounter in working with other departments by remembering this key point:

Keep other department managers informed at all times: before and during the project.

By applying a few basic rules for communication between departments, you will be able to defuse the problems that beset all managers at one time or another: territorial motives, power struggles, and—in cases where communication breaks down completely—outright refusal to cooperate. Most of the time, the breakdown of cooperation arises not from a political or personality problem but from a failure in the communication link—especially when you have made the effort to communicate, but only once. People need periodic reminding, so don’t assume that a single message will be remembered.

Summary

I realize this is a fairly straightforward concept, but it can’t be emphasized enough. Communication is key. And when you’re dealing with large projects, and dispersed team, all the managers those team members work for, and all the departments that your large projects depend upon, then it’s your responsibility…as the PM…to ensure that everyone is on the same page. Keep critical project information, milestones, and commitments in front of everyone who “needs to know” often and at every update point.

They will appreciate it, you’ll see it in the way they support your project and your resources, and you’ll greatly increase your project’s likelihood for success…and that’s always a good thing. Never assume people – especially department heads who you must rely on – “just know.” Bury them with communication if you have to.

Defining Risk Management – Part 3: Risk Identification

Ok, so I decided to make the two-parter into a six-part series. I’ve received emails and comments on the first two parts and decided that I couldn’t end it until we dove further into defining risk identification, quantification, response, and control. In this entry from the book “The Project Management Question and Answer Book”, we’ll look further into Risk Identification.

What is risk identification?

The first step in risk management is identifying the risks that we will see in our project. These are the things that threaten to stop us from delivering what we have promised on the schedule we promised for the budget we promised. If we were completely certain about everything in the project and how it was going to turn out, we would not have to worry about risk management. From this lack of knowledge of how the project is going to unfold come the problems that we will have to deal with. These are the risks we want to identify. Every practical means must be used to discover the risks that are associated with the project. Meetings must be held throughout the project to discover new risks that have appeared and to dismiss risks that can no longer take place.

All of the assumptions that have been made to date on the project are potential risks as well and should be listed among the other risks identified.

The first thing we must do in risk identification is recognize the areas of the project where the risks can occur. This means that we will have to investigate the following areas:

• Scope. We must look at the work of the project. The work breakdown structure (WBS) will be useful here. The project scope must be clearly defined in terms of both the deliverables and the work that must be done to deliver them. Errors and omissions on the part of the project team and the stakeholders must be minimized. As always, the WBS will be very helpful in doing this.

• Time. Estimates for the duration of the project and the duration of the project tasks must be done accurately and reliably. The sequence of work must be identified, and the interrelationships between the tasks must be clearly defined.

• Cost. Estimates for tasks must be done accurately and reliably. All associated costs must be considered and reported accurately. Life cycle costs should be considered as well as maintenance, warranty, inflation, and any other costs.

• Customer Expectations. Estimates of project success must be considered in terms of customer needs and desires. The ability of the project to be scaled up or manufactured in different quantities or for different uses and sizes must also be considered.

• Resources. This involves the quantity, quality, and availability of the resources that will be needed for the project. Skills must be defined in the roles that will be necessary for the project.

• Organization. This is the ability to interface with the stakeholder’s organization in terms of communications and knowledge.

Many people both inside and outside the project will be necessary for risk identification. This includes input not only from the project team and all of the stakeholders but also from project managers who have managed this type of project before and even consultants who have special expertise about certain kinds of risks. It may be necessary to organize the types of risks into categories so that separate teams of people can be brought together more efficiently.

Many of the risks that will affect the project are risks that have happened in one form or another on other projects of this type. Utilizing the information available in the previous project’s lessons-learned documents will be very helpful in identifying risks for this project. An organized review of past projects should be done as part of the risk identification process.

Since much of the risk identification process will involve large numbers of people, formal group dynamics techniques should be used.

Brainstorming Technique. Most people are familiar with this process, and many have had disappointing results. In brainstorming a facilitator briefs the meeting attendees and asks the participants of the meeting to name risks that they think could occur in the project. The facilitator encourages the participants to name any risk they can think of, even ones that seem silly, and makes a list of the risks on a board or flip chart. What happens in brainstorming is that the ideas of one person generate new ideas from another person, and a kind of chain reaction takes place, producing the identification of many ideas about risk.

There are some problems with brainstorming that will affect the success you have with the technique. The main problem is that unless you have an excellent facilitator, there will be minimum participation from the attendees and few risks will be identified. This problem is even worse when there is a large difference in the status of the individuals attending. A person who is the supervisor of some of the participants may intimidate them or dominate the meeting.

Delphi Technique. This technique of group dynamics eliminates the problem of dominance, shyness, or intimidation that sometimes occurs in brainstorming meetings. In the Delphi technique the participants are anonymous to each other. This technique can be conducted with Internet messaging or even by e-mail and has the advantage that people can participate from many different locations.

In this technique the facilitator asks for input from the participants. He takes their ideas and consolidates them into a list that is sent to each participant. The participants then add ideas to those already listed. This circulation of the lists continues until no additional ideas are generated.

The Delphi technique creates a lot of work for the facilitator. All ideas have to be listed by the facilitator, who also usually has to telephone many of the participants in order to get them to participate in each round. The overall time to do the Delphi technique can be weeks depending on how dedicated the participants are.

Nominal Group Technique. This is another type of meeting technique. In nominal group the participants are known to one another as in brainstorming, but the ideas are submitted to the facilitator as written lists. This makes the ideas, if not the participants, anonymous. The facilitator lists the ideas on a flip chart or a board, and the participants add more ideas in another round of written lists until no additional ideas are added.

This technique reduces any status concerns or intimidation that might be present in a brainstorming session but does not eliminate it entirely. There is more work for the facilitator, but the nominal group method can be done in a single meeting, and participation improves over brainstorming even if some enthusiasm may be lost.

Expert Interviews. There might be experts available either inside or outside the company for a new project and a new kind of business. Expert interviews must be handled with care. If the project team is not prepared for the expert interview, much time can be wasted with the expert simply telling stories about his or her past exploits. An effort should be made to develop a list of questions for the expert.

Ishikawa or Fishbone Diagrams. Fishbone diagrams or cause-andeffect diagrams, also called Ishikawa diagrams after their founder, Kaoru Ishikawa, a Japanese quality engineer, are useful in identifying risks.

The Misconception of PMP Certification

I can’t get in to the PM Tips site at the moment due to a server issue in order to post comments, so I’m just going to write an article on the subject…since I think I can post an article through the login.

There have been great comments and discussions on the article I wrote entitled “Project Management: Is PMP Certification Worth It?” In fact, there have been nearly 100 comments posted on this article – by far the most of any on the site. I appreciate everyone’s comments and I think it’s been an incredible discussion – and it’s probably convinced many non-certified PMs to just go ahead and get certification.

The Premise

Remember, the premise of the article is that HR departments and hiring managers are becoming lazy in this job market by requiring PMs to have certification to even be considered for a position – it is happening on many jobs that are up for grabs out there. However, the overall perception is, it’s a game…if you want to play you probably should get certified. I agree.

Direction of Recent Comments

The comments are still coming through, but now they’re only trickling in. And what’s coming through now is equating PMP certification to an MD, or a CPA, or a certified CPR. I’d like to get my two cents in on these comparisons. I think they’re crazy.  (The comparisons, I mean…not the people making them.)

While all of those are important, they don’t equate to what a PM does. First, it’s not illegal for a PM to practice project management without certification. No one’s life is at stake. It is, however, very illegal to practice medicine without the degree. And sure, a person can administer CPR without being certified and a person can do taxes or manage your finances without being a CPA, but you’re probably more comfortable with a CPA doing your taxes. And as one comment suggested, if two people are standing over you when you’re choking and one is certified in CPR and the other isn’t but just knows it, you’d probably choose the certified CPR person if you’re given the choice. I would too.

Applicable to PMP?

How does this compare or apply to PMP certification? It doesn’t at all. PMP certification indicates you have a minimum amount of experience and passed a test so you know the fundamentals of PM and the PMI methodologies. What it doesn’t indicate are the soft skills that a PM must have to be very successful. A CPA or a person who is CPR-certified really doesn’t have to have the same interpersonal skills. They wife of a choking victim doesn’t care if the CPR responder can negotiate with someone or interact with the crowd of bystanders. They have one job to do and that’s it. The person having their taxes done by a CPA doesn’t care if that individual knows how to massage a customer and smooth over bad news. Or lead a team of project resources every day to accomplish all of the behind the scenes tasks. Not at all. They only care if their taxes are done correctly. And the CPA is pretty much a one-man show and he does the taxes correctly and that’s it. No song and dance.

For the PM, things are different. The work is not more critical or more important, just different. The PM must be able to inspire a team, bring confidence to a customer, manage a multi-million dollar project, answer to executive management, keep the CEO happy and do this on several projects at once. Again, not more important, just very different. And lots of soft skills that no test can ever validate. You either have it or you don’t. Some of these things you can’t get no matter how much experience you have, but experience usually can help you get there on most of them. Pass a test and getting certified won’t get you there.

I’ve been called in to fix projects where the customer was dissatisfied with the way the project was going so many times that I’ve lost count. A test doesn’t validate leadership, confidence, and that kind of experience.

Final Thought

So, yes, we all probably should be certified because that’s just the nature of how things are going. But, in my opinion, it’s very short-sighted to equate the PMP to an MD, a CPA, or CPR certification. It’s apples and oranges.