Setting Goals for Project Management Success

For new project managers, as you gain skill in managing projects, your career prospects will improve as well. In general, management recognizes success and rewards it, and projects are an excellent forum for demonstrating your leadership abilities especially in organizations focused on project management with proper reporting of project progress and successes.

In addition to developing the skills required for project management, continually set career goals for yourself as a project manager. Recognize that management is watching with high expectations and will likely be reviewing your performance based on how well you achieve these goals, which may include:

Acquiring the reputation as a skilled, effective project manager

Be aware that your reputation within the company will affect your career. A positive reputation includes the element of reliability. To become a skilled project manager, practice the ideas and techniques that make the process work. To become an effective project manager, keep your goals and deadlines in mind at all times, support your team, and work well with all resources, internal and external.

Meeting deadlines, without fail

Some people accept the fact that deadlines in their companies are not taken very seriously. Don’t allow yourself to think in this way. View the deadline as an absolute. It you never miss a deadline (except in the most extreme circumstances), management will think of you as a dependable, valuable resource.

Staying within budget

The budget, like the deadline, is often seen as an outmoded practice, as an idea with little validity. This is because so few people use budgets as they are intended – as control tools for measuring the effectiveness of management’s effort. The budget defines risk and potential reward for the organization, and should be carefully monitored and controlled while the project is underway.

Read more »

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.