Some tasks are behind schedule, some resources are reporting lower than expected productivity, you are hearing about performance issues from the project team members. How would you as PM handle it, what would you do?

Providing Performance Feedback

It is safe to say that within most companies a major function of the Project Manager is to identify and remove roadblocks so that people who have the “R” (Responsible according to the RACI Chart) to do the work can do the work. Sometimes that requires us to look at our own performance.

 Providing both positive and negative feedback on the performance of your individual resources on assignment is an aspect of Human Resource Management, one of the critical PM disciplines. It is an important part of leading and developing your team.

 When you need to Provide Feedback on Performance

 Feedback is very important. Not only is the PM responsible for communicating progress to project sponsors and consulting management, but you are also responsible for informing the team and individual team members of the progress at regular intervals throughout the project. A PM must devote significant time to providing clear direction to team members, understanding their status and difficulties, and keeping them informed regarding the project and their role in it. This is most effective when good working relationships are maintained and the PM interacts routinely with each team member to review their efforts and personally confer on issues or challenges associated with progress. This is sometimes referred to as MBWA or “Management by Walking Around”.

In addition to providing ad hoc feedback to team members, the PM is usually also responsible for providing team members with formal evaluations of their performance on a periodic basis. These periodic evaluations provide feedback on the performance expected of the resource for their particular role on the project and for their title/level of consultant. The PM provides information about performance expectations, strengths, developmental opportunities, and ratings on specific competencies related to the resource’s role on the project. This documented feedback recognizes good performance and helps individuals identify areas where improvement is required.

Your Role in Providing Performance Feedback

 Once the project has been staffed, it is primarily your management of your resources that determines whether or not you are a success at the end of the project. The PM is the coach of the team and must:

•  Lead and motivate team members to achieve maximum contributions
•  Monitor the productivity of project team members through the effective use of productivity measurement tools
•  Identify any performance issues
•  Work with your resource management team to rectify the situation through mentoring, coaching, or other approved management processes.
•  Participate in the periodic evaluation process to perform accurate evaluations of resource performance.

Teams typically go through a universal process as they develop within the project life cycle. They go from Forming to Storming to Norming, to Performing. If the leader can successfully diagnose what stage the team is in, the leader can help the team from getting stuck in the past by providing what is needed. At each stage, teams need something very specific from their leader.

•  In the Forming stage – They need a clear vision, a picture of what success looks like.
•  In the Storming stage – Let conflict rise to the surface, then clarify roles and support.
•  In the Norming stage – Team members need feedback on whether their ideas and strategies for how to achieve goals are working or not.
•  In the Performing stage – The leader needs to recognize and reinforce success through positive feedback.

The framework above can help you to see how important feedback is to the success of your team, especially in the later stages. When it comes to building a coherent working team timely and accurate performance feedback is essential. Remember to apply the following tips on performance feedback on your next project team:

•  Performance issues are dealt with as soon as they are recognized and before they can negatively impact the project. 
•  The feedback states clearly:
  •  What needs to be improved
  •  Why it needs to be improved
  •  How much and by when it needs to be improved (the “how” part of improving performance should be left up to the resource to the extent possible)

Cheers,

 Craig

The Project Plan: Tasks & Time Estimates

After you have completed the WBS and each deliverable has been broken down to the appropriate level, i.e., the level where the task can be completed within 40 hours or less, you are ready for the next steps in developing the project plan. (Please note, 40 hours or less is based upon best practice by PMBOK where hard deliverable tasks are kept to no longer than 1 week in duration.)

 The next step is to assign time estimates to each of the tasks.

After you have assigned time estimates, the next step is to put the tasks in logical sequence. Task dependencies will determine the sequence of some activities. The sequence of tasks is very dynamic. You must re-evaluate the sequence of tasks throughout the life of the project.

 You are now ready to:

• Assign Human Resources – Consider the skill sets needed to perform the tasks.
• Build a Project Schedule – Your will base your schedule on: when the project starts, how long each tasks takes, how many tasks are assigned to a resource, and the priority you assign each of those tasks. To do this

When you need to do Time Estimates

The time estimates are part of developing the project plan. They are started as early as possible in the planning process, often before the project manager has been assigned to the project. They should be completed as soon as possible after the WBS has been broken down into the lowest level. Completion and ongoing revision is the responsibility of the project manager.

 The Project Manager’s Role in Time Estimates

As Project Manager, you are responsible for refining any existing project time estimates, for assigning specific time estimates to each task in the fully decomposed WBS, and for revising and updating time estimates in the plan as the project progresses.

 How estimates are typically done

Task estimates are developed in 3 ways:

1. Historical Information – some companies maintain project task plan templates containing pre-defined tasks for the specific product(s) being installed. The tasks are pre-estimated, based on experience from other implementations. Another source of estimates for tasks is previously used project plans.  Many project tasks, especially implementation project tasks, are repeatable and it is helpful to review how other project managers have estimated the tasks. (It is important to archive  your completed project plan in a common knowledgebase as part of your project closeout process. These estimates should be refined after specific resources (individuals) are assigned to perform the tasks.
2.  For work units specific to the current project (e.g., an interface or a report), the PM can solicit estimates from an colleague or expert who has performed similar work in the past.
   If extensive work units are to be estimated (e.g., after a complex model is completed), the PM may request a technical resource to be assigned to the project specifically to perform the estimates.
   Other sources of Expert Judgement
   Individual project team members are also a good source of knowledge. They will often remember actuals from previous projects.
   Use Caution
   Be cautious of technical estimates made by functional resources or functional estimates made by technical resources. Both tend to undervalue the effort required by the other.
3. Approved Estimating Algorithms – Spreadsheets containing formulas and estimating determinates may be available for estimating specific work units.
   Use Caution
   Before you use an estimating algorithm, make sure it is approved by the client sponsor or the PMO. An algorithm that fails to take the right factors into consideration can create big problems for your project.

Effort- vs. Duration-based Estimates

Most estimates are effort-based (i.e., the total effort or resource hours required to complete the task with no elapsed time factored into the estimate), but sometimes a duration-based approach is acceptable. For example, the time required to acquire workstation PCs is typically based on the vendor’s lead-time which is duration, rather than the number of resources applied to the task of PC acquisition. Therefore the acquisition task is duration (or elapsed time) based.

 Revising Estimates

You will need to revisit the initial time estimates once specific resources are acquired. Any estimates you use should be influenced by the capabilities of the individual assigned. The estimates found in the templates may assume an average skill and experience level, but the actual resource assigned may be a highly skilled resource with extensive experience. Such a resource will be capable of completing the work unit much quicker than the basic estimate. Conversely, an inexperienced, junior resource will require more time to complete the work. You should confer with the assigned resources to ensure that the estimates are as accurate as possible and to ensure that the resources can commit to estimates and will accept responsibility for completing the work within the estimated timeframe.
You may also have to make adjustments because of differences in the client situation.  As an example, maybe the current client has 5 resources available for analysis, while the typical client has only 1 resource. Pre-existing estimates are based on typical clients, so you would need to revise the estimate upward.

 Reconciling Estimates for New Project Managers

If you don’t have the subject matter expertise to reconcile a difference between the time estimate in a template or previous project plan and the one provided by the human resource assigned, what should you do?

• Use the estimates provided by the assigned resource unless the resource makes adjustments to pre-existing estimates that seem unreasonable. 
• If you sense that the adjustment might be out of line, use another source to confirm the resource’s estimate.  Possibilities include:
  • Looking back at previously used plans
  • Using one of the approved algorithms in conjunction with a historical estimate
  • Asking the PMO or a Project Manager with the subject matter expertise you lack is a good reality check.

 Skill in Estimating

As you become more skilled as a Project Manager, you will be able to refine estimates with greater confidence. The more experience you obtain with actuals vs estimates, the better your own judgment will become. Most implementation tasks are repeated project after project, so as you update your project plans, you will become more knowledgeable about how long tasks actually take.

Estimates Should Change Throughout the Project

Estimates can and should be changed as the project progresses and the team gains more knowledge about the work to be done. Completing significant tasks can provide information that invalidates early estimates for subsequent related tasks. For example, completing the functional design for an interface can indicate that too much time has been allocated for the development of the interface.

 General Acceptance requirements for Time Estimating

In summary, all time estimates should be based on the following criteria:

• primarily be effort based (as opposed to duration based)
• expressed in hours (not days)
• based upon historical information, expert judgment, an approved algorithm, or a combination of all three
• be agreed to by the resource assigned
• take into consideration unique circumstances of the client and non-standard requirements specified in the SOW and Contract.

 Happy estimating,

  Craig

Educating Clients & Managing Expectation

You have completed the Charter and given it to the client. Despite all your good planning efforts, the client responds by identifying some internal expectations that are in clear contradiction to what is in the charter. What will you do?

Educating Clients & Managing Client Expectations

The key to being successful is managing the client’s expectations from the beginning to the end of the project. That is easy to say, but it is not always easy to do. We all pride ourselves on having excellent relationships with our clients. Sometimes, however, we are so concerned with customer satisfaction that we are tempted to agree to things the client asks for that are not really within the scope of the project. When that moment comes, we have to step back, assess the impact on all resources, and educate the client about what is and what is not within scope, and then negotiate a solution. If we silently accept small changes in scope in the beginning, we are not only failing to manage scope, we are also stepping onto a slippery slope. It will be much harder to recover later on. Remember: A successful relationship entails the mutual satisfaction of needs. A relationship is not successful if one party benefits at the expense of the other.

When you need to Manage Expectations and Educate your Client

As we said, you’ll need to manage client expectations throughout the project, beginning with the Statement of Work. Whenever you assess that the client’s expectations are different from project team’s, the education process must begin.

Your Role in Managing Expectations and Educating Clients

 As Project Manager, you’ll be responsible to:

•   Set expectations about Scope in the SOW and Scope Definition Statement
•   Clearly define roles and responsibilities
•   Monitor those roles to make sure they are being fulfilled
•   Educate clients about the project methodology being followed
•  Educate clients about change control and procedures

Acceptance criteria for Educating Clients

When it comes to relationship building with customers it is important to realize that all people have three kinds of needs:

•  Social Needs
•  Security Needs
•  Results Needs

At any one time, one kind of need may be more important than the others. When people feel that one (or more) of their needs are not going to be met, barriers to relationship arise. Those barriers include:

•  Defensiveness
•  Tension
•  Self-interest

 When those barriers arise, we need to be able to listen, ask questions, and build bridges across those barriers. The three bridges are:

•  Trust
•  Empathy
•  Understanding

 The above is true for your client and your team members alike. The next time you sense a barrier rising, move to build a bridge. It doesn’t work to ignore the problem and hope it will go away, to stonewall, or to become aggressive and try to beat down the resistance you are encountering. Only when you understand the client’s need can you start building a foundation of trust and understanding. Once you have a sturdy foundation, continue building the mutually beneficial relationship by educating the client and re-setting expectations appropriately.

A sign of proficiency is when you can say “no” to the client when you need to (to enforce the rigors of the project management methodology being followed) in a way that doesn’t “beat up” on the client, but actually improves the relationship because the needs of both parties are being addressed. Remember that developing these skills takes time. If you sense that your skills need improvement, seek out a colleague or mentor who will work with you to help you improve and give you real-time feedback.

Cheers,

Craig

How to Get Your Project Back on Track

 Your last project status highlighted several issues that the PROJECT MANAGER must address. Although the overall project progress is acceptable at this point, the technical work is lagging behind and there are strong indicators that this situation will continue unless some proactive changes are made now. Ten of the fourteen technical tasks scheduled to start within the first two weeks of the project did not get started. This was due to one group not finishing tasks so that another group could commence. You have resources scheduled to go on vacation in the coming weeks and the client has reported that system performance is unacceptable. What will you do as Project Manager?

An important aspect of project control is determining whether schedule variations require corrective action. The Project Manager must conduct a risk assessment of slipping tasks and make some decisions about how to change the plan to meet the target for implementation. This may mean identifying workarounds or rethinking priorities and assignments to accelerate the overall schedule. These decisions are part of the on-going requirement for the Project Manager to control the project. To do this, the Project Manager must know the exact status of tasks and Identify impediments to progress. Appropriate actions may include:

• Reprioritizing tasks and changing task assignments to optimize the project schedule.
• Procuring additional resources to keep the project on schedule.
• Identifying performance issues and rectifying the situation through mentoring, coaching or other approved management processes.
• Identifying and recommending reductions in scope
• Initiating the change control process

When you need to get your Project Back on Track

As Project Manager, you must initiate action to get your project back on track soon as:

• you determine that it is off-track, or
• you discover that there is a strong likelihood of schedule slippage downstream.

As the scenario above has illustrated, the progress of one project group can obscure the lack of progress in others. This emphasizes the need to analyze and understand the plan at the task level and to track productivity and contribution at the individual resource level. This process is not specific to one phase, but is continuous throughout the project and involves ongoing planning and scheduling as well as controlling.

The Project Manager’s Role in Getting the Project Back on Track

When you detect a problem with the project you are responsible to:

• Identify workload balancing changes that could be made to the plan to bring it back into alignment (e.g., reassignment of tasks or reprioritizing tasks).
• Determine what resource changes to recommend (e.g., adding more or different client resources, employing 3rd party vendor when appropriate, bringing on more contract resources, etc.).
• Prioritize your recommendations and escalate them for higher level decisions when appropriate (when it will affect cost, timeline or functionality). When you need to escalate, use the Change Control process specified in the project charter.

Getting the project back on track always falls to the responsibility of the Project Manager. A quick check list you can follow should consist of the following:

• Identify when the project is going off track before irrecoverable time is lost.
• Assess the potential impact if the situation is not corrected (do an impact analysis).
• Identify possible changes to the plan that would bring the project back into alignment.
• If the changes require additional budget, resources, or changes to the timeline or deliverables, initiate change control.
• Obtain necessary approvals and implement the changes.
• Update the project operating plan with the changes.

 Cheers,

Craig

Do You Follow a Regimented Issue Management Process?

An issue is an unresolved decision or situation that will significantly impact the project.

Every project manager is confronted with issues during the course of an engagement. All issues must be evaluated and resolved to ensure that risks to project success are identified and mitigated effectively.

The identification of an issue and its preliminary analysis are sub-processes included in the risk identification process (The four basic processes within the Risk Management discipline are risk identification, risk quantification, risk response development and risk response control).

As issues surface they must be documented and evaluated to determine if they fall into one of three basic classifications: (1) an issue subject to change control, (2) an issue requiring some administrative action on the part of the service provider or client or (3) an issue that has the potential to become a tangible risk factor to the project. The issue classification step should assign the issue to one of these three categories and start the process to resolve or mitigate the issue. More details on each class follow:

(1) If the issue has a specific remedy that is defined in the terms and conditions of the contract under change control (e.g., a resource cannot find time to complete his assigned tasks and requests that a contract resource be assigned to help with interface development), then the standard change control process is executed.

(2) Another group of issues includes questions that are raised by the client or other project stakeholders that need additional research or discussion to satisfy the inquiry. The eventual answer may move the issue into the change control process or the risk management process, or it may simply be closed once the answer has been supplied. Every issue that is documented or vigorously pursued by the client is a potential risk to project and business success and must be resolved. The resolution should be documented and published to mitigate exposure to write-offs and post-delivery disputes that may result in litigation.

(3) The last category includes those issues that present potential risk to the project’s success.

When you need to Manage Project Issues

Issues can be identified at any time, during project planning, scheduling or controlling. They need to be managed (controlled) as soon as they arise. An issue can become a risk at any time.

Acceptance Criteria for Issue Management at AG Consulting

There are 4 aspects to Issue Management:

Issue Identification & Tracking – Identifying outstanding questions, decisions and other problems before they adversely affect the project. Establishing and tracking a plan for getting them resolved.

Issue Analysis – Understanding the issue sufficiently to consider future consequences of action plans made to resolve it.

Issue Control – Carrying out actions to ensure issues are resolved in a timely and effective manner. Prioritizing and orchestrating the issue resolution process.

Issue Communication – Communicating issues and their resolution to the right level of the organization to get them resolved, or to prevent them from escalating into risks.

The Project Manager’s Role in Scope Definition

Like Risk Management, Issues Management is a collaborative endeavor. Everyone is responsible for identifying issues. However, the Project Manager is responsible to:

Set up an issues tracking system. You will need to make a choice as to how you want to keep track of issues. Many organizations have their own process to follow.

Assess whether the questions or situations raised by other team members are truly issues, i.e, that the question or situation cannot be answered or corrected in time to prevent an impact on the project progress or budget.

If so, update your issues tracking system so that the issue is on record.

Initiate a resolution by determining the issue priority and assigning an owner with responsibility for identifying several alternative resolutions and recommendations. Assign target dates for reporting periodic status on the resolution.

Escalate the issue, if necessary. Some issues cannot be resolved within the project team. The project manager is responsible for presenting such an issue to those who need to know and for making sure that an action plan is created.

Select a resolution from the alternatives presented to you, or assemble the appropriate decision makers and present the alternatives together with recommendations

Notify those who need to know how the issue is going to be resolved.

Determine if the resolution involves a change request. If so, implement the Change Control Process.

Track the resolution progress n the Issue Tracking System and communicate the results.

As with Risk Management, although the ultimate responsibility for Issue management lies with the Project Manager, this is a collaborative endeavor. Team members are responsible for identifying issues and for escalating issues to you, the Project Manager, if they cannot resolve them at their level. It is your responsibility as Project Manager to encourage your team to identify issues throughout the engagement. Experience has shown that the people closest to the work usually know best how to resolve issues. Therefore, it is also your job to encourage each team to be responsible for resolving as many issues as possible at the local level. At the same time, it is important to escalate those issues which should be escalated as soon as possible.

If Issues are not resolved, there can be negative consequences for the Project Manager. The consequences include the following:

• Inability to deliver to contract timelines, cost, and schedule
• Poor or unacceptable functional design
• Poor reference from the client
• Post implementation disputes

Having a well documented issue management process is crucial to communicating and enforcing that process across your team. If your organization does not have one, be sure to create one for your project.

Cheers,

Craig

What is the Project Manager’s Role in Assigning work?

Once you have broken your project work down into tasks, estimated the time it will take to complete them and identified who is on the project team, you’re ready for another key PM responsibility. You must ensure all tasks are assigned to specific individuals on the team. In many cases, some or all of the core team will have been assigned to the project at the same time you were. If it is a small project, there will be few decisions about who will do what task – there will be only one person with the capability. In larger projects you may have some choices to make about who is assigned what work. Even if task assignments are a forgone conclusion, you are still responsible to ensure every team member knows what his or her task deliverables are, what the scheduled start and end dates are, and how many hours are allocated for each task.

One of the tools you can use to communicate work assignments is a “turnaround” document. This is really an excerpt from the project plan that shows the schedule of all tasks for an individual resource. If you are using MS Project, there is are several automated reports that can be used as a Turnaround document. If you are using an Excel spreadsheet, you must produce a report or table that contains the rows specific to an individual resource. When you prepare a Turnaround document for each team member, it should include pre-printed columns showing:

• The resource name and the group (e.g., Client or consultant, HR or Payroll team)
• The date of the data contained in the document and the date the document is generated
• A task reference number that will map back to the overall project plan
• A listing of the tasks assigned to the resource
• The estimated effort for each assigned task,
• The scheduled start date

Once you have taken a first pass at the work assignments for your team members, distribute the Turnaround documents and schedule a planning session with each team member. As the PM, you should ask individual resources to confirm their assignments in view of the skills or knowledge required. Additionally, the resource will review and perhaps adjust task estimates based upon his/her confidence level of information available. Once the tasks and assignments are confirmed, you will establish a baseline or “Point-in-Time” schedule. Subsequently you will compare project progress against this baseline to monitor and report slippage.

The Turnaround document can also be used as a means for tracking progress of assignments. Project Team members submit their updated Turnaround document weekly. Therefore the document should also include preprinted columns with blank fields for:

• Actual Start and Finish Dates
• A field for the team member to enter the total hours charged to the project for the week.
• A filed to record hours of work remaining on each task.
• A free form field for comments or other feedback

When you need to Assign Work

Work assignments are made in conjunction with the development of the baseline project plan. As soon as you have developed the WBS and added time estimates, you should assign generic resources (e.g., HR Functional, Benefits Functional, Tech, etc.) for all tasks. Before assigning any real resources you should first complete the schedule based upon the relationships between the tasks. This will give you a schedule based on the order in which work physically has to be done. Once this has been done, you can identify specific resources and start looking at the schedule impact of adding those resources. You should substitute actual names on your plan and prepare Turnaround documents for the resources you have. In some cases, your team members will already be on-site when your plan is developed. In other cases, you will need to work with Staffing or with your client to obtain specific resources. When this is the case, develop the Turnaround document as soon as the specific resource is available so that no time is lost in making work assignments.

Your Role in Assigning Work

As a PM, you need to assign work appropriately. You should plan work assignments to meet three goals:

• Maximize project effectiveness in terms of schedule and quality,
• Ensure the team has credibility with the client, and
• When possible and practical, provide developmental opportunities for newly-hired consultants.

At times, these goals can seem to conflict with one another, but the key is to keep the demands in balance by making conscious decisions about the trade-offs at every step.

You are responsible to:

• Provide a copy of the project plan and a Turnaround document for each resource to make sure that assignments are communicated (and documented).
• Check with resources to make sure that assignments are clearly understood by project team members and that they can commit to what you’ve articulated they will do in the amount of time you’ve allocated for it.

This means that it is your responsibility to do the initial planning of work assignments. Then, it is your responsibility to clearly communicate those work assignments in a manner that builds trust and openness within the team. You should be open to input from your team on these initial work assignments and be willing to make mutually agreed-upon changes based on the feedback you get from your team. As a Project Manager, you are responsible to inform team members what they are expected to do, but not how they are expected to do it. After any initial modifications have been made, you are responsible for tracking each team member’s progress on each of their deliverables.

Changes in the Project

When changes are made during the project (either through the Change Control Process or as a result of updating and refining the operating plan), you will need to assign any new tasks to a resource. Or a resource may leave the project for one reason or another, and you will have to assign work to a replacement. You will need to inform the team member(s), update the project plan, and issue a new Turnaround document to the resource in question.

Other Project Tasks

Inevitably there are tasks that don’t clearly fall in to the specific expertise of one resource or another, and you use these situations to make assignments that balance workloads, maximize working relationships, provide resource development, etc. For example, developing an Acceptance Test Plan or working with clients on test scripts can be done by any of the functional resources, so you could assign these types of tasks to one whose workload is lighter than another.

Mistakes to Avoid

There is one class of tasks you should never assign to another member of the project team: the tasks of project management. It can be very tempting to assign administrative tasks to others. However, a PM should never delegate away the responsibility for updating the Project Plan. Project Managers are expected to enter any updates to the Project Plan themselves because the process of updating the Plan requires making judgments about the work. For example, if a team member submits a revised target date for their work the PM must evaluate the situation. Why is the target date shifting? Is there a legitimate reason or is there a productivity problem that must be addressed? What is keeping the resource from making the progress expected? What is the impact of the revised target date on the rest of the project? A Project Manager cannot delegate the accountability or the responsibility for updating the project plan.

It is sometimes appropriate (and this takes good judgment) for a PM to delegate responsibility for some tasks that are considered “project management.” For example, developing a communications plan, or setting up an issue tracking system, or putting together the Charter. However, you cannot delegate the accountability for that or any other PM task.

It is unwise to assign even the responsibility for doing the task to a team member unless you have a large project, and both you and the resource know exactly what you are doing. One reason is that you have full accountability to maintain control of the project, and you have to really know what is going on in all aspects. Another reason to be sensitive is that you are actually assigned the PM work and clients are billed for you to do it, while other resources are billed to do specific functional or technical work. Team members really shouldn’t have gaps in their workloads that would allow you to offload work to them.

On the other hand, Project Managers may be tempted to do work that properly belongs to others. Many PM’s have difficulty keeping their work separate from their people’s work. In the Course Introduction you read about the common confusion that inexperienced PM’s have about their role. Many PM’s still want to play a technical or functional role on the team. You will often feel pulled to do your old job. If you give in to the temptation, you will jeopardize the project.

To summarize, project work assignments must meet the following criteria:

• The work assignments for each team member are “complete,” i.e., contain a list of all tasks and success criteria such as:
• expected target dates
• estimates of work effort
• a way to reference tasks back to the comprehensive work plan so that such information as task dependencies and supporting resources can be determined.
• Project Management tasks have not been delegated to team members
• Overall there is reasonable alignment of skills to tasks
• There is no avoidable imbalance, with one resource scheduled to work long hours and another with a very light load.

Cheers,

Craig

Conflicts can arise at any time in a project. In fact, they are common. What is uncommon is the ability to deal with conflict and to resolve it competently. Generally this is because we tend to hold misunderstandings about conflict; and these misunderstandings prevent us from developing conflict management skills.

For example, many people strive to avoid conflict at all costs. As a result of this mindset, we don’t actually avoid conflict, we merely delay recognizing and dealing with conflict until it turns into a crisis that can threaten the project. The key is to recognize conflict early and deal with it effectively.

There are several important things to keep in mind about conflict:

• Conflict is not necessarily destructive; it can be a positive force for change. Therefore, to manage conflict effectively, it helps to have a positive attitude toward it. Conflict is really opportunity.
• Conflict usually occurs when people’s needs are not being met.
• Conflicts are most likely to arise on a team during the “Storming” Phase. The Project Manager can best respond by clarifying roles and providing support.
• The key to recognizing conflict early is to develop your sensitivity to the signals of conflict. A sense of discomfort or tension; specific, unsettling incidents; and misunderstandings are all signs of underlying conflict. A conflict left hidden and unresolved for too long can result in a crisis.
• The way to get control over conflict is to a) Take a creative response to it and b) Aim for mutual gain.

When you need to Manage Conflicts

There is a window of opportunity that begins as soon as the signals tell you that a conflict may be present—and before these incipient conflicts become crises. This can happen at any point during the project. It is an important and ongoing responsibility.

Your Role in Conflict Management

As a project manager, it is your responsibility to resolve conflicts to maintain a positive and productive team.

When a resource creates conflict on the project, you must meet with the resource to seek a constructive resolution. When you do so, it is important to:

• Do your homework and collect pertinent facts in advance
• Listen to the resource,
• Observe behaviors
• Understand the issue from all perspectives, and
• Focus on what can be done to improve the situation

You may sometimes have to manage conflicts with the client project lead, for example:
The team lead may feel obligated to support the client team members even when they are wrong. Keep in mind that the client team members were likely a team before you arrived on the project and you may find your project team pitted against the client team. It is the responsibility of the PM to remain objective and resolve issues based on facts rather than feelings.
This may involve delivering bad news to the project lead’s boss (to the best of your ability avoid affecting the project lead’s career).

If the agreements made for resolving the conflicts will have an impact on project deliverables, time, or budget, remember to use the formal Change Control process before making commitments that will change the project plan.

If a conflict is very large and involves policy or an irreconcilable difference over standards and goals, you may want to involve the project sponsor or steering committee. For example, if you learn that this conflict is stemming from the client’s suppressed feeling that the system is not a solution for their department; the best thing to do is to contact the sponsor.

If the conflict continues

Unresolved conflict should be handled (documented, tracked and managed) like any other issue/risk, unless the project becomes stalled. If that happens, as the PM you must contact the sponsor so that appropriate actions can be taken. It is very important that you first do your utmost to address and resolve the conflict before it reaches such an impasse. You don’t want to be in the position of taking a long-standing conflict to your sponsor, and having to explain that you have not yet made any attempt to resolve it yourself.

Acceptance Criteria for Conflict Management

Projects suffer when conflicts arise but are not addressed and resolved. For consultant project managers you want to meet your contractual obligations, but also want a good reference from your client. Unresolved conflict may prevent a good reference even if you meet other objectives. You will have done an excellent job of conflict management if you:

• Identify a conflict early and determine what potential it has to jeopardize the project
• Identify the key needs and concerns (interests) of the parties involved and where they overlap.
• Explain how the conflict will affect the project if not resolved, and back this up with evidence (contract, SOW, status reports, or whatever is relevant).
• Address the conflict situation with the parties involved and get agreement on a course of action that:
• meets some key needs of all parties, and
• removes the project from jeopardy
• Follow up to ensure the problem is resolved, and if not, take further action.
• Apply issue management as appropriate (don’t document a personality conflict, document slipped schedules or disagreement on task completion, etc.)
• Any conflict situation
• Your common sense, sensitivity, and detective work
• SOW/scope definitions, contract, etc.
• Status reports, turnaround documents, and other specific data.
• Issue management and change control process as needed

Inputs to Conflict Management

Remember, all projects have conflicts of some form or another. As project manager it is your responsibility to remain objective and resolve issues to the best of your ability based on facts rather than feeling.

Cheers,

Craig

Progress Tracking Methods in MS Project

Over the last couple of weeks, I have had several people ask me “what was the best way to track progress with MS Project or on projects in general?” There are a couple of methods of tracking progress that is normally followed; the method you choose will depend on the level of rigor or accuracy you have decided on for your project. These are:

1. Percent of work complete
2. Hours of work done per period on each task
3. Actual work done and work remaining

Percent of Work Complete

For this progress tracking method, you would ask the resources to report the percent of work complete on each task. It is extremely important that everyone is clear on how you measure percent complete. Often the team will agree upon levels of completeness depending on the types of tasks. For example, development tasks could be 50% complete after coding, 75% complete after unit testing, and 100% complete after moved to user testing environment. Whichever way you measure percent complete, be sure to be consistent and that all team members understand and agree to the metrics.

The drawback to this method is that it does not completely represent the progress of the tasks. You do not get an accurate measurement of time spent on specific tasks. You are also not able to account for an early or late finish as you don’t have a real good picture of the work remaining on the task.

Hours of Work done per Period

Another method of tracking progress is by collecting hours of work done per period on each task. Here the resources will report the hours worked on each task over the period and you record hours directly into MS Project against each task. This method will allow you to track actual hours against a task compared to the relative planned (baseline) hours. This will give you a sense of whether or not tasks on schedule. However, as with the percent complete method, you really don’t get an accurate picture of early or late finish times on tasks as you do not know how much work is remaining on any one task.

Actual Work and Work Remaining

The most accurate method of tracking progress is using actual work done and work remaining. With this method, each resource reports the actual work done and the work remaining on each task. Now you are able to track the number of hours worked relative to the planned hours, plus you know the number of hours needed to complete the task. This work remaining is then used to calculate the new finish date of the task which can be earlier or later than the baseline finish date. Now your plan is more accurate and you are able to deal with scheduling questions on a plan that more closely reflects reality.

The level of rigor you apply to tracking your project’s progress will often depend on the several factors such as project length, project priority, project budget/time/resource constraints. So choose the method that best suits your project guidelines and stakeholders expectations, keeping in mind the accuracy of each method.

Cheers,

Craig

Tracking Administration Time in MS Project

In my last blog I talked about making sure your resources are assigned the appropriate availability to work on tasks by accounting for administration time on projects. So how do you track this administration time in your project plan?

First of all you have to determine if you need or want to actually track the administration time in MS Project. If you are not using MS Project to track the budget of the project then you may have no need to track that time. In this case your budget is probably being tracked by some other time entry system that captures all time against the project.  Here, in MS Project you would simply track actual time against your hard project tasks that you have assigned to your resources. However, you want to make sure that your resources fully understand that they are not to charge and administration time to these hard tasks so you do not collect invalid times against your project plan.

If you are tracking your budget in MS Project and need to account for every hour spent on the project, then you need to set up a way to track the administration time. How you do this will depend on the level of detail you want to track here. As we said earlier, administration time is for soft deliverables on a project such as knowledge transfer, team meetings, status meetings, etc. You can set up tasks for each of these and assign a percentage of the resources time to each and track them individually. However, I find that this can sometimes just be added work for team members and for the PM to organize and make sure time is being gathered correctly. What I find works best is to have one ADMIN task running across the length of the project. Create the task as a “Fixed Duration” task and set resources’ UNITS at the desired allocation. You can then track the actual time against that task the same as any other task in the schedule.

If you have resources assigned to your project such that all of their time is to be charged against the project, even non-project administration time (company meeting, breaks, etc), you can also set up a separate task for that time if needed, or agree to track that time as part of your one administration task.

However you set up your administration tasks, it is important to communicate to your team how they are to account for their time against these tasks. Like all tasks in your schedule, it is also important to monitor the progress on a regular basis for irregularities and productivity issues.

If you have any questions or comments on this or any other topic, I am always looking for feedback.

Cheers

Craig

Accounting for Administration Time in Project Schedules

 One of the most common mistakes I have seen in managing IT projects over the years is not adjusting resource availability to reflect reality. Many project managers simply set up their project plan and assign resources at full capacity. Even if a resource is only available on a project at 50%, I quite often see the resources assigned to hard project tasks at 50%. There are at least two areas that impact a resources productivity that are often not accounted for.

 Many studies have shown time and time again across all industries that no resource can dedicate 100% productive time to any project, even though they may be assigned 100% to that project. Two areas that impact this productive time are Project Administration and General Administration time.

 There are two types of task on a project; hard and soft tasks. Hard tasks would be those tasks that produce an actual deliverable. Good examples are a piece of code, a report, new screen, documentation, etc. Then there are soft tasks which describe tasks of administrative nature on a project that do not generate a specific deliverable. Such as project meetings, knowledge transfer, answering project related questions, status reporting, etc.  Research has shown that for most projects these soft tasks account for 20% of a resources time on a project. Therefore all resources that participate in these types of activities should only be assigned to hard deliverable tasks at 80% of their availability (6.4 hours of an 8 hour day if available 100%). If a resource is assigned to a project at 50% availability then 3.2 hours of an 8 hour day should be assigned to hard tasks. 

Far too often this 20% Project Administration time is not accounted for in the project plan and as a result hard tasks tend to slip as resources are not able to keep pace. The plan starts to fall apart and the team is left struggling to catch up from what was an unrealistic plan to begin with. 

There is another administration related time that can account for 5-10% time loss on a project as well. This is general work administration time that can take the form of bathroom breaks, personal phone calls, general staff meetings, etc. Depending on the environment you work in this time should also be accounted for. Some union environments also schedule regular breaks for employees, say ½ hour per day. This should also be reflected in your hard task schedule for each employee that is impacted. How you track and record this time differs from company to company and project to project. I will talk about tracking this time and recording the impacts on your project in my next blog.

As an example let’s take a project resource that works 8 hours a day, is allowed to take ½ hour per day in breaks, assigned to a significant number of soft tasks on the project, and needs to account for a work administration time. This resource should only be assigned to hard project tasks at 72% of their availability; that is 5.75 hours per day. (8 – .5 = 7.5 (actual working time) *.3 (Project & Work Admin Time) = 2.25) 

If you assume in your project schedule that this resource is working 8 hours every day against your hard tasks then your project is behind schedule before you start. Remember to account for reality and don’t omit Project and Work Administration time in your project schedules.

Cheers

Craig

What makes a good Project Manager?

The success of a project rests upon the skillfulness of the Project Manager. New project managers, in particular, are prone to certain behaviors that diminish the likelihood of success. If you are aware of these pitfalls you can take action to get feedback and shift your behaviors.

The Inexperienced Project Manager

Unfortunately, many new project managers misunderstand their role—or bring to the role the behaviors and attitudes that worked for them in their old roles. Now those skills and behaviors are sub-optimal. Consider the three following approaches to managing projects and see if you recognize yourself:

The Senior Analyst as Project Manager – Promoted for outstanding performance in a technical role, the senior analyst has little experience leading people. He or she tends to value technical knowledge and wants to retain expertise. He or she likes to be involved in the system design details and favors familiar, technical activities over project management activities. Symptoms include:

• He/she must personally inspect and approve design decisions
• Scope is expanded to optimize technical solutions
• Little attention to project plan maintenance and other controlling activities
• He/she feels frustrated and overwhelmed and considers many of the PM activities administrative
• Team doesn’t know scope or status of project

The Administration Manager as Project Manager – This is a common style for a department/functional manager. He or she will spend most of his/her time in meetings and will rely primarily on written reports and status meetings rather than first-hand observation. He/she is reluctant to publicize sensitive issues or problems and is willing to sacrifice short-term progress for long-term career development of subordinates. Symptoms include:

• Maintenance of project plan delegated to a subordinate
• He/she continues to focus on departmental activities
• Problems sanitized when reporting project status
• Project reported as on-schedule even when metrics point to slippage
• He/she always in meetings—losing touch with what’s really going on.

Question: Can a project succeed when either the Senior Analyst or Administrative Manager approach is used? Yes, but if the project succeeds, it is usually the result of superhuman effort by the project team. And, if the project manager is credited for success, team members may be resentful and disillusioned. And, if the project fails—Management will tend to blame the project manager or the project team members, but the real reason for the failure may never be recognized or addressed.

    The Project Manager as true Project Manager—

• Sees project management as a professional role
• Focuses on the project—not personnel administration or system design
• Provides strong leadership and support to the team
• Establishes procedures and monitors compliance with those procedures
• Stays close to project activities, status, and issues
• Does not shy away from delivering bad news.

 What are the effects of this true Project Management approach?

• Status and issues are reviewed individually and frequently with each team member
• Project plan reflects current status of all activities
• Performance and capacity of each team member measured by objective data
• Status reports focus on project metrics and identify open issues and changes
• Team has sense of purpose and direction

The Project Manager must be a leader, organizer, scheduler, manager, planner, communicator, team builder, mediator, decision-maker, delegator, teacher, inspector, appraiser, persuader, and counselor.

How can you develop your ability to be a good project manager? Predisposition and attitude are important. You have to be motivated to develop your skills and to request and get feedback. You also have to take a disciplined approach. Project Management is somewhat of an art, but it is also a set of disciplines which, if learned and practiced, can make you successful.

Cheers,

Craig

What’s old is new again – Use Cases?

When I first started working on AGILE projects, I was unfamiliar with the term “use case”. I wasn’t sure if it was a new buzz word or a new technique for gathering requirements specific to AGILE style projects. As it turns out, I had been using them all along.

A use case is simply a way of describing a business task or action that takes part with in a system, process or application. Use cases should not be confused with the features of the system under consideration. A use case may be related to one or more features, and a feature may be related to one or more use cases. There are two kinds of use cases (Business and System), but for this posting I will only focus on the Business Use Case.

A Business Use Case is described in technology-free terminology, which treats the business process as a black box and describes the business process that is used by its business users (people or systems external to the business) to achieve their goals (e.g., manual payment processing, expense report approval, register a customer). The business use case will describe a process that provides value to the business user, and it describes what the process does.

About 15 years ago, I attended a training session presented by Trond Frantzen on Rapid Business Systems Analysis. In his methodology, he uses techniques for defining all of the “Events” of a business process or application in a very fast and concise manner. These events are essentially use cases. I have used this methodology successfully on many projects since that time and am now applying it when defining functional requirements (uses cases) in AGILE projects. Mr. Frantzen has now updated his publication to show how it can be applied within the AGILE framework. I would recommend reading his latest book Rapid ‘Agile’ Business Systems Analysis.

This methodology guides you through an event modeling process using JAD (Joint Application Development) sessions to develop ERD’s (Entity Relationship Diagrams), detailed Entity Data Dictionaries for logical database creation, as well as full narratives of the event as described by the business users. By populating entity relationship tables, you quickly identify all relationships in the process, as well as specific questions that need to be answered by the business. I have found that this process quickly provides the project team with a detailed functional business requirement in narrative and model form with all relationships between entities identified and specific data requirements documented. It is a quick and precise way of gathering detailed business requirements in use case or events form.

Whether you call them events, use cases, or detailed functional requirements, the end goal is the same. There are many effective and efficient ways of gathering this information. What are some of the methods or tactics you have used?

Cheers,

Craig

If everyone managed their email well, then we might not have so much to do as ediscovery project managers … but since they typically don’t … we get to keep busy.

When I read John Mancin’s recent blog post about managing email, I looked at it first from the ediscovery perspective and second from it’s intended time management learning objective.  Read it now for its time management value — as a project manager, managing your time is one of the keys to success.

Then we will take a look at it from an ediscovery point of view together here:

John walks us through an easy 8-step program to regain control of lost time to managing our in boxes. He  describes some of the reasons for ediscovery challenges and places to look for relevant ediscovery.

#3. Reduce colleague spam, both what you send and what you receive.

This is a can be a problem on your electronic discovery projects but it’s generally easily overcome through culling and deduplication. This is a culture question that should be part of your PM checklist when planning for your document/ESI collection.

#4. Reduce attachment spam.

Here’s where it starts to get interesting… in step 4, he tells us to reduce the number of attachments we send out. Good idea. However, another challenge we often see in ediscovery projects is identifying which file is the original or most up-to-date version of the document. We have tools/ technology for dealing with this issue too …. near deduplication.

Something else worth pointing out is the trend in the ECM (enterprise content management) world to get rid of attachments altogether and simply allow email users to create a link to the file on the server so that it resides in a single location. I wrote about this a while back. This is a trend that will reduce the volume  of ESI for ediscovery eventually however, it also means that as ediscovery project managers we have to add this to our identification / collection phase checklists.

#6. Don’t use email as a filing cabinet.

Wow! Thousands of examples are available on other blogs about the perils of  #6 in litigation…

• People regularly send emails to themselves… sometimes “themselves” = home / personal e-mail account (identification / collection checklist: “Did you ask the custodian …?”)  Also, think Bear Stearns: “He sent it from his home computer to the other guy’s wife’s system to steer clear of the company server?”
• Think document retention policy- many corporations limit mailbox size to discourage long term storage of data within the e-mail container.
• Now let’s consider searching within the context of this quote from Craig Ball’s recent post on the EDD Update blog:

ESI is encoded in many different ways, and it’s quite common for these encoded objects to be nested like Russian matryoshka dolls: a Word document inside a Zip archive attached to an e-mail message within a compressed Outlook PST container file residing on an encrypted volume. Each nested object is encoded differently from its parent and child objects, and even within the body of a single document or file, encoding changes as content changes.

• If I receive e-mail data from my client as a PST, then it’s a container that is not organized in easy to manage records. As an ediscovery project manager one of the things to consider with regards to searching and processing the data is our plan to deal with  nested files within the PST.

• Attorneys generally understand that most people use their in box as a filing cabinet so they typically will request this information in discovery. However, this is a limited view of what could potentially be relevant to the case… we’ll discuss this further when we get to #8 on John’s list.
  

#8. Use the right tool for the job.

I totally agree about using the right tool for the job… but as we’ve discussed already here, many don’t… so where else should we be looking for information? We already mentioned home computers… I would add Wikis, Blogs and Twitter to the list as well as company-managed instant messages and digitized voice mail.

E-mail is one of our necessary evils when it comes to project management. It’s great to have the resource to communicate with our teams, unfortunately, if we allow ourselves to become a slave to its constant interruptions throughout the day, then we risk missing deadlines for our projects. I am a big fan of closing Outlook for a few hours each day so that I can get some work done without interruption. Same goes for allowing calls to roll to voice-mail… See John’s steps: 1, 2, 5 and 7 for more pointers to free yourself from your e-mail.

When you’re working with your case teams on the identification phase of a litigation matter, ask them if they send email home or use their in box as a filing cabinet… odds are that their clients do too.

I attended this conference with two colleagues.  One an IT professional like myself, and the other a “super” paralegal.  I had high hopes for good ideas on how to better manage Litigation Support projects, as they tend to be a beast of their own.

We learned ideas for tracking our sub projects within projects from initiation of a case through closure and data destruction.  One thing I got excited about was the idea of a technical specification model.  At the onset of a project, write up the scope of work being done.  As the project goes on, version the scope with each change that comes along and have this as an audit trail for everything that is done to discovery and requested by the case team throughout the case.

One thing also discussed is the constant battle between deadlines and the time it takes to do what we, in Litigation Support, do. What will always be the case?  Court deadlines, changing time lines and the fact that as hard as we try to work with our case teams (attorneys, paralegals, clients, client IT, co-counsel, experts, in-house IT,etc) the name of the game is time and money.  The most common strategy that I’ve seen attorneys take is wait as long as possible before cracking into the e-discovery side of the case and try to work toward settlement.  Why?  This is an expensive part of the case.  We all know that.  Sometimes a cost higher than the worth of the case itself.  The challenge on the Litigation Support side is that it takes the time to preserve, collect, inventory, process, QC, cull, QC, review, QC, produce, QC any discovery. (did I mention QC?)

So that is the question I felt I left the conference unanswered.  How do we work with attorneys and case teams to educate them on the timelines for e-discovery so that they can better weigh the putting off of dealing with discovery issues for the sake of case strategy?

My one disappointment of the conference was that, while I love a good crack at attorneys, there was more than just a subtle rhetoric pointing to attorneys being our big challenge.  More than once paralegals were pointed out as paranoid and in the way.  Being as I work in a law firm it would not be healthy for me to view the attorneys or paralegals as part of the problem, however tempting that may be.  I don’t think that was the goal of any discussion at this well put together conference.  It was however constantly discussed and I feel that we have a responsibility to turn this conversation around.

First, paralegals are my best friends my com padres and my allies.  When an attorney contacts me on a case, if they do not already have a paralegal involved I encourage them get one involved.  1/2 the time this prevents me from doing the work of a paralegal.  The other 1/2 I can work with the paralegal with time lines, case setup, and me doing my work, the paralegal doing what they do best and presenting the attorney with what they need.

Second, attorneys pay my paycheck, so while I do prefer to be treated as an equal, respect must be paid.  I believe that the attorney / not an attorney line can change, and the burst of a need for IT Litigation Support to be involved in attorneys lives is an opportunity to do just that.  Litigation Support is a skilled industry involving a good deal of IT knowledge and PM ability.  Requiring this type of aptitude in individuals hired to these positions will slowly get to the attorneys in the form of a recognition that we are a valuable member of the team. One such discussion during the conference pointed ou that we as an industry will be better served if we present our services as consulting/expert(ise) rather that just support/data processing/etc.  Yes, sometimes we burn cd’s but what we did to get that cd together involved a lot of knowledge and awareness of issues like spoliation and privilege.

From the Lit Support side it is important to recognize that attorneys do know what they are doing, and that they are intelligent.  Rather than an obstacle, it is an opportunity we must take to constantly educate attorneys about what we do, why we do it and how. This is not the kind of overnight shift in paradigms that we would all like.  This is more one attorney or a couple of attorneys at a time.  Working with a partner is always a good idea because they will help with buy-in. Going after new associates in groups is also necessary as getting them on the bandwagon early can encourage going in the right path from the beginning.

All-in-All it was a wonderful conference.  I got to see a lot of familiar faces, talk with vendors about new and exciting technology (what can I say, I am IT and that is what excites me) and there were a lot of good discussions about what we do on a day to day basis.  It is a long time coming that there is a conference for IT Litigation Support Professionals.  Well done Litigation Support Today for getting this together for us!

- Courtney

Introduction

Practical realism is said to be the driving force behind Henri Fayol’s 14 principles of management, which he outlined in 1949, to define the terms by which organizations should be effectively controlled.  Over half a century later today, most of his principles, which include familiar themes like division of work, authority and responsibility, equity, order, and centralization, among others, continue to stand the test of time and serve as key philosophies behind current organizational management practices [1].  Of particular interest in this paper, however, is the principle of unity of command and the ideological dilemma between reporting along clear lines of hierarchical accountability and control, and the flexibility that is needed by project teams in order to get the job done.

According to Fayol, unity of command requires employees to receive orders from, and consequently, answer only to one superior. Once violated, the organization’s discipline, order and stability will be threatened [2].  But given the dynamic and demanding nature of today’s markets, it is counter-intuitive for organizations today to adhere to this.  Price says as much when he acknowledges that modern organizational theory has seen some increasingly sophisticated hierarchic designs that contradict Fayol [1].  Yet for all the advancements made in this area, organizations following a matrix design (not to be confused with the matrix ideology, which is a descriptor of an organizational culture type) to meet the increasingly project-oriented environment, seem unable to escape the power trap that plague project teams and functional units.

Why is this so? According to Cleland and Ireland, the matrix design – although a formal structure – is supposed to be a flexible arrangement to be negotiated between project team leaders and functional managers. In project management jargon, this is known as the project-functional interface.  Projects are horizontal in nature because they need a composition of skills and expertise from across the organization’s functional units to complete the objectives.  On the other hand, functional departments, as exemplified by traditional organizational charts, are vertical entities.  On paper, the dichotomy between these two entities is supportive of one another.  While the project manager is concerned with what is to be done, the functional manager thinks about how the task will be done.  The project manager wonders about when to do it, but the functional manager looks at where the job will be.  The project manager looks at how well the whole job is completed whereas the functional manager looks at how well his own aspect has been integrated into the project. Each has different, but complementary, concerns [3].  Well, on paper, at least.

In reality, the project-functional interface is more like a project management dirty word describing the state of divided loyalties individuals face when they have to answer to two bosses – the project manager and their functional manager.  According to project management guru Dr Harold Kerzner, unless project managers and functional managers work together, the project team performance often suffers as team members tend to bend towards their functional managers, who control their purse strings [4].  Thus, in what is a tussle for power and territory, the project-functional interface dichotomy discussed earlier may be summarized this way: while project managers contemplate who they can pick from the functional departments to staff their teams, functional managers are often asking why they should release their talents if it only seems to benefit the project managers.

The puzzle becomes crystal clear when we realize that in a matrix organization, project or program managers may have a lot of delegated authority but they rarely have much formal authority of their own [5]. Whereas project-centered organizations like those in engineering, construction or the aerospace industries have structures built around project teams as their functional units, matrix organizations basically follow the traditional structures, with some adjustments to their hierarchy to support project units.  Under such artificial conditions, control is centered around the functional managers.  Hence, in bargaining about staffing arrangements for example, the lack of formal authority puts project managers at a disadvantage from the get-go.

Of course, this assumes the worse, where the functional manager and the project manager are at odds with each other. But say we consider it hypothetically for argument’s sake, it really begs the question of how project managers are expected to succeed in such conditions – both within, and outside of the team?  The answer, it seems, lies in their interpersonal skills.  Cleland and Ireland argue that to get things done, project managers operate by influence, and must work through others and manage relationships on three dimensions. “Upward,” they say, “project managers must relate to their bosses, who are either general managers or managers of projects. Horizontally, they must relate to members of their project team. Diagonally, they [need to] relate to functional managers and other representatives outside the organization [3].”

As project managers seek more leverage in their negotiation with the functional managers, the notion of parity of power in their relationship becomes a very important concept.  The Negotiation Training Academy suggests that as one party wields some form of power, it is imperative for the other party to create a perception that they are able to counter the situation with a similar or different form of power that would render any further escalation of power needless [6].  According to Kerzner, building their interpersonal powers of influence may be one of the ways for project managers to level the playing field somewhat. He cites the 1959 research by French and Raven on the five interpersonal bases of [influential] power that are critical in the negotiation process: legitimate power, reward power, coercive power, expert power, and referent power [5].

Legitimate power comes from the ability to influence due to one’s hierarchy, where people at higher levels have power over those below.  One’s subordinates are key in this equation because this influence exists only when they accept a power as legitimate and complies with the leader.  In some literature, legitimate power is also known as normative power [7].  The organization’s culture, customs and value systems often interact to determine the limit of this category of power [6].  In this sense, legitimate power tends to have more gravitas in organizations whose ideology is power-driven, where influence and governance emanate from a central authority, and people are dependent on that source of power [8]. It also applies to places that are role-driven, where heavy emphasis is placed on bureaucracies built upon legality, responsibility, policies, and procedures [9].

On the other hand, reward power is used to support and reinforce legitimate power when leaders recognize compliance to their directions and orders through awards, monetary remunerations, and promotions.  Rewards may also come in the form of verbal and non-verbal expressions like verbal praise, the nodding of heads, showing of respect, and many others. The administration of rewards may further encourage employees in responding to subsequent orders, requests, and directions – this is the driver behind this source of influence [6].  In my opinion, reward power is effective in all organizational cultures, as people desire to be appreciated for their efforts. Perhaps the greater challenge lies in understanding rewards and recognition not as a one-size-fits-all approach, but as a customized approach according to the specific needs of the employees [10].

The antithesis of reward power is coercive power, which is the perceived ability to punish those who do not conform to the leader’s ideas or demands [7].  This power could take the form of a threat to withhold an anticipated transfer, a bonus payout, or it could even be the threat of a job suspension, or litigation action.  The common denominator is the use of fear to coerce people into certain actions and directions [6].  Psychologist and management theorist Fredrick Herzberg warns of severe downsides with the use of force that moves, but not motivates, people towards organizational goals. While short-term goals may be reached, the long-term consequences are loss of distrust and satisfaction [11].  Like rewards, the use of force tends to be effective under all organizational types.  However, it certainly has more weight in a power-ideology organization, and to a lesser extent, a role-driven one.

A person with an expertise that is highly valued by the organization will possess what is known as expert power.  These people have some degree of power and influence, whatever their hierarchic status is. The knowledge may revolve around line or support functions, and in general, the harder it is to replace them, the greater the degree of power they will have.  Sometimes also known as information power, expertise is usually an individual trait [6].  Experts often wield the most clout in task-driven environments, where there is no ideological commitment to order, hierarchy and procedure, only to what is most beneficial to the success of the job [12].  Decisions are made by those with the mastery in the knowledge-area required by the task at hand.  Experts may also develop influence in power and role organizations, but this depends on how persuasive they are in making their case to those in power with the information and knowledge they have.

The last social power base to be discussed is personal, charismatic, or, referent power.  This is the appeal seen in some celebrities, as well as individuals in sports, politics, and religion, among others. Hollingworth says that charisma is ascribed to those who have a unique mix of physical traits, personality, and self-confidence, which enables them to influence and mobilize large numbers of people 13].  Referent power stems from the need of individuals to identify with the magnetic nature of influential or attractive people. The greater the admiration and identification, the more referent influence is exerted by the power holder [14].  As this depends entirely on individual appeal, people in positions of great power and status, or those with expertise, will most likely possess a matrix of both referent power, as well as legitimate, or expert influences.

Coming back to the issue of the project-functional interface, and having discussed at length about the different social power bases in the organization, what does this all mean for project managers?  I would like to propose the following six broad suggestions for them in terms of building up their interpersonal appeal and influence in a matrix project environment:

1. Understand the dominant ideology (power, role, task, or matrix of the three) of the organization and how it influences the culture and systems.  This is the strategic big-picture that project managers have to develop, even before considering issues such as the project-functional interface, as it determines the overarching communication needs.  It is also important to conduct an audience analysis to know the preferred communication styles, and even personality traits, of key members of the main stakeholder groups: the senior management (or project sponsor), project team members, as well as functional managers and customers.
2. Customize the communication approach with the various stakeholders.  For example, if the functional manager is a tough person to deal with, avoid communicating through email but have face-to-face dialogues in his or her office instead. This shows sincerity and openness, and it also allows project managers to understand the counterpart’s concerns (e.g. concurrent projects where the same staff is needed). Very often, the functional managers know they must support the organization’s goals. However, it is imperative to secure their personal buy-in so that it relieves their staff from any split-loyalty dilemma.  Whether long-term trust is built depends largely on how communication of intentions is done in the first place.
3. Expand one’s level of subject-matter expertise and field of knowledge. While most of the social power bases covered in this paper may not fall within the direct control of the project manager, one area is, and that is the job or task expertise.  Being known to be a knowledgeable person on the job is extremely vital in building one’s expert power influence, and this is really an area that project managers can dictate how far they wish to go. Possessing expert power also helps to bolster their referent power, and this makes being part of their project team an attractive proposition, as people will be drawn by the appeal of learning under their tutelage.
4. Be judicious in the use of rewards and threats (in fact, use coercion only as the last resort, or better still, avoid it totally).   While project managers want to avoid excessively rewarding people for doing jobs that they are recruited to do, but neither would they wish to have a crisis of motivation due to a failure to communicate appropriate feedback or encouragement.  Clear and continuous feedback is necessary for sure. But one thing is clear: coercion is a dead-end approach and once people embark on this track, they immediately diminish in terms of their referent, and even legitimate power. In addition to losing the trust of the team members, the relationship with the functional managers may even be jeopardized. Of course, non-performers must be counseled or disciplined, but if it comes to that, the respective functional managers must be informed and involved.
5. Keep functional managers updated on the progress of their staff, and the development of the project as a whole.   This should be done on a regular basis, and especially after any update to the senior management or project sponsor. It is both a respectful and appropriate gesture.  By doing so, it is also a subtle application of reward power to show one’s appreciation for the support given by the functional managers because, at their level, they will desire to be kept abreast of ongoing developments, especially if certain feedback or comments received from the senior management may implicate their departments.
6. Be sure to uphold promises and agreements.   This is especially vital if there are certain arrangements made with the functional managers about how long their staff would be needed on the project team.  Like how project deadlines must be adhered to, any internal arrangements must also be honored. Project managers must remember that their integrity (remember referent power) is on the line, and a reputation as a trustworthy partner will go a long way in securing further support for other projects down the line.  If an extension is needed, project managers must try to work out some alternatives with the functional managers, but at no time should they assume things in their own favor.

Conclusion

The six broad suggestions discussed are just that: tips and recommendations, not ends in themselves. Negotiating the project-functional interface requires project managers to exercise considerable situational leadership to meet the strategic, tactical, operational and communicative needs of the environment.  Nevertheless, it is clear that success or failure will hinge on how well they juggle their interpersonal relationships and approach issues like authority and territorial boundaries.  After all, as Cleland and Ireland put it aptly, project success is ultimately about how the web of relationships is managed within the total organization [3].  Power does not necessarily have to be a zero-sum game in a project environment.  With careful cultivation of the social influence bases, it could well remain as the functional manager’s meat, but also serve as the project manager’s elixir to more supportive relationships on the road to project and organizational success.

* * * * * * * * * *

References

[1] Price, A. (2008). Classical organizational theory: Henri Fayol. In HRM Guide: Classical organizational theory. Retrieved October 29, 2008, from http://www.hrmguide.co.uk/history/classical_organization_theory_modified.htm

[2] Jarvis, C. (2005). Fayol (1841-1925) Functions and Principles of Management. In Business open learning archive. Retrieved October 29, 2008, from http://www.bola.biz/competence/fayol.html

[3] Cleland, D. I. & Ireland, L. R. (2007). Chapter 9 – Organizing for project management. In Project management: Strategic design and implementation (5th ed., pp. 190-194). New York: McGraw-Hill Professional.

[4] Kerzner, H. (2006). Chapter 4 – The staffing environment. In Project management: A systems approach to planning, scheduling, and controlling (9th ed., pp. 140-141). New Jersey: John Wiley & Sons.

[5] Kerzner, H. (2006). Chapter 5 – Management functions. In Project management: A systems approach to planning, scheduling, and controlling (9th ed., p. 206). New Jersey: John Wiley & Sons.

[6] Negotiator power authority. (2008). Parity of power. In Negotiation Training Academy. Retrieved October 29, 2008, from http://www.negotiationtraining.com.au/articles/powerful-intrapersonal

[7] Bases of social power. (2008). Identifying sources of power: Explanation of bases of social power of French and Raven. In 12manage: The executive fast track. Retrieved October 29, 2008, from http://www.12manage.com/methods_french_raven_bases_social_power.html

[8] Onepine. (2005, March 11). Charles Handy. In People whose ideas influence organisational work. Retrieved April 10, 2008, from http://www.onepine.info/phand.htm

[9] BBC. (n.d.). The Handy guide to the gurus of management. In BBC world service. Retrieved April 10, 2008, from http://www.bbc.co.uk/worldservice/learningenglish/work/handy/handy.shtml

[10] Nelson, B. (2005). Introduction. In 1001 ways to reward employees (pp. 3-4). New York: Workman Publishing Company, Inc.

[11] Herzberg, F. (1991). One more time: How do you motivate employees? In Motivation (pp. 7-13). Boston, MA: Harvard Business Review. (Original work published 1963)

[12] Interaction Media Group. (2008). Ideologies. In Directory M articles. Retrieved April 11, 2008, from http://articles.directorym.com/Ideologies-a800189.html

[13] Hollingworth, J. E. (2008, October 27). Leadership, peer relationships, and upward communication. Lecture presented at class on Organizational Communication, Emerson College (Walker Building, 504), Boston.

[14] Ratzburg, W.H. (n.d.). Power defined: Bases and sources of power. In Organizational behavior. Retrieved October 29, 2008, from http://www.geocities.com/Athens/forum/1650/htmlpower.html

Introduction

The saying goes that the Human Resource Management (HRM) profession is really six to seven different jobs all rolled into one.  The broad and distinct spectrum of knowledge areas that a HR practitioner needs truly runs the gamut, such as benefits, compensation, staffing, and many other specialties.  While there is probably no empirical basis for a direct comparison, I do believe that the field of project management would rank a close second if the expansiveness of a project manager’s job scope were to be considered.

Take the practitioners trained under the PMBOK (Project Management Body of Knowledge) system administered by the Project Management Institute as an example.  Apart from understanding the broad picture of how each project should be managed throughout its lifecycle, they also need to have a working knowledge of the PMBOK’s nine knowledge areas (integration, cost, scope, quality, HR and procurement, etc) and their subdivision of 44 management processes, and how they work together to guide the project to success.  It is little wonder that some people think of project managers as a mile wide and an inch deep!

Perrin [1], the author of Real World Project Management, points out that theory aside, harsh organizational realities such as out-of-the-world expectations, unclear needs that have been spin-doctored by senior executives, as well as the vagrancies of team members and their contributions, are just some of the problems that add to the project manager’s somewhat schizophrenic task of reconciling all these differences, and bridging what the organization wants with what can realistically be delivered.

Team building: Arguably the greatest challenge project managers face today!

In the plethora of concerns that face the project manager, one of the most pressing challenges, arguably, is that of team building.  After all, it is the individuals in the team and the various skills and expertise they bring that are the forces the project manager must harness in order to accomplish the project.  As early as the 1960s, Schmidt and Tannenbaum [2] already discovered in their research that one of the most uncomfortable moments for managers is when they are forced to deal with differences among people in their teams.  These are situations that, if unchallenged, may lead to the erosion of objectivity, personal relationships, and productivity.

Little has changed between now and then.  Kemp [3], in his 2004 work Project Management Demystified: A Self-Teaching Guide, argues that the one of the foremost reasons why projects continue to fail is because teamwork has not been effectively managed in the project group.  He defines teamwork as the process of communication within the team, and everything else that supports and leads to its success.  This logically implies both in-group communication, as well as external communication with the project sponsor, senior management, and other stakeholders.

In a survey that this author conducted this past September among a group of project managers from a large multinational firm, all the respondents unanimously rated communication as the top skill that a project manager had to possess.  60 percent of them believe that project managers should also have team-building and motivational skills, while more than a third of them feel that team-building, among other areas, is a critical communicative skill that many project managers lack today. These findings resonate with the conclusions of a separate market survey released by ESI International [4] earlier this year, where 38% of the respondents said that effective communication (e.g. within the team, between the team and stakeholders) was one of the most pressing challenges that project managers and organizations were faced with.

In the face of what appears to be unequivocal support for the importance of team-building skills as a crucial communicative skill set for project managers, I believe it is timely to take readers through a review of the four-step team development life cycle originally put together by Dr Bruce Tuckman [5] in his 1965 study of small groups. His research was pivotal in identifying the famous four stages that developing groups undergo: forming, storming, norming, and performing.  In addition to Tuckman’s study, this white paper will also review the recent work by Dr Tom Edison [6] of the Defence Acquisition University (DAU).  Edison expands on the Tuckman model by including new phases that cover the potential dysfunctional states that teams may slip under, in order to reflect the complete development life cycle of a modern work team.

Tuckman’s original four-stage group development model

In his original formulation of the group development process, Tuckman [5] argues that groups that exist for an extended period are likely to go through the four distinct stages of forming, storming, norming and performing.  However, while group members might be able to recognize the phases or stages in some ways, they may only possess a limited awareness of the changes involved, and their implications on group dynamics.  He believes that if people are able to better understand the processes surrounding group development, they will stand a better chance of enhancing the effectiveness of the group by taking certain interventions to keep the team moving forward [5][7].  We will now examine the four stages and the suggested interventions in greater detail:

Stage #1 – FORMING (the phase of orientation, testing and dependence)  

Tuckman [5] says that when people initially come together in groups, their first concern will be to orientate themselves within the team.  This is primarily accomplished through testing, which identifies the boundaries for both interpersonal and task behaviors.  In an environment where relationships are either nonexistent, or at best, distant, individuals are more focused on their own objectives.  Consequently, there is a tendency to strive for cordiality as the new team members hold their cards close to their chest while they suss out their colleagues [7].  People are generally unsure, suspicious and nervous, and this is entirely to be expected. However, because of the task-oriented nature of teams, individuals also understand that they would have to quickly develop certain dependency relationships with their leader and other group members [5][7].  Here are some measures that project managers should adopt when in the forming phase of group development:

• Lay out the group’s purpose and objectives, and set clear and high levels of expectations.   Blanchard and Johnson [8], using the gaming analogy, say that performance problems sometimes arise because team members do not know where the goalposts are.  Goal-setting research in the U.S., Canada, Europe, Japan, Australia and the Caribbean shows that people are generally predisposed to purposeful action, and performance levels tend to increase when higher goals are set because people will adjust their efforts according to the difficulty of the task assigned [9].  Furthermore, as the team has just been constituted and relationships and structures are tentative, the leader’s persuasion style ought to be a more affirmative one of telling and pushing [7].
• Help individuals to understand how they fit into the team.   Wetlaufer [10], citing Katzenbach in her article, argues that the ‘rules of the road’ must be very clear.  While teams may have a good mix of skills and experience, they are new to one another. Hence, the leader must play a visible role in clarifying how team members are individually expected to contribute and work together, what they will work together on, as well as how team meetings will be conducted, among other issues [10]. This goes back to the orientation and dependence-building process that Tuckman [5] says is characteristic of the forming phase.

Stage #2 – STORMING (the phase of conflict)  

The second phase, also known as storming, is characterized by the loss of systematic resolve, the heightening of differences, and the polarization around interpersonal issues, facts, goals, methods, and values.  Although fighting in the physical sense is unlikely, conflict may manifest itself in the form of emotional outbursts as team members talk at, rather than talk to, one another [2].  It is important to understand that conflicts often develop insidiously and usually do not begin as outright disagreements.  In this regard, project managers should find Schmidt and Tannenbaum’s explanation of the five stages of the ‘conflict creep’ phenomenon a useful reference [2]:

• Level 1 – Anticipation   Individuals are aware of the presence of issues (e.g. proposals, plans, methods, and values) that may lead to differences of opinion within the team.
• Level 2 – Conscious but unexpressed difference   Polarization occurs as members start clustering among those they trust to discuss the issues.  Facts are limited and assumptions are made.  Tension builds and there is a sense of an impending dispute and trouble.
• Level 3 – Discussion   As the issues are brought out for discussion and facts begin to surface, differing opinions start to emerge openly.  Undercurrents can be felt in the way the questions are phrased, as well as the body language and nonverbal expressions that are used.
• Level 4 – Open dispute   Arguments and counter-arguments begin to be articulated, and any differences in opinion that have so far been obliquely expressed are now stated more clearly and directly.
• Level 5 – Open conflict   Individuals are firmly committed to their positions, and they attempt to increase the effectiveness and power of their situation while seeking to minimize that of the others.

According to Schmidt and Tannenbaum [2], the project leader’s ability to intervene and mitigate the conflict is inversely related to the progression of the stages.  The earlier he or she enters the picture, the better the chances to influence the conflict situation.  Some other intervention measures that could be adopted during the storming phase are:

• Focus group efforts toward building up trust and interaction.   The project leader must continue to build bridges and relationships in the team by emphasizing his or her expectations and vision of how the team should work together.  A highly visible leader using the sell and consult persuasive approach may be useful here [7].
• Identify the protagonists and meet them out of the group setting.   A key issue for the project manager is to establish control over the unofficial power nodes in the group and prevent the conflict from escalating beyond repair.  It helps to meet the chief protagonists on an individual basis to understand their position on issues, and to solicit their identification on common goals and objectives. In the worst case, uncooperative or destructive individuals must be shipped off the team.
• Ensure differences of any sort are directed towards the idea and not the individual.   Dignity must be preserved even in the midst of critiques, or open and constructive communication will collapse [11]. 

Stage #3 – NORMING (the phase of group cohesion)  

Tuckman [5] says that this phase occurs when resistance is replaced by an in-group feeling, and a sense of cohesion.  This is also the time when group standards and processes evolve, and new roles are adopted.  Norming essentially marks the birth of the realization of the project manager’s vision for the group. As he or she continues to facilitate the development of the team, here are some measures to consider:

• Focus on developing group processes and task interactions. Relationships at this stage are more stable but still mechanical, so project leaders should focus on encouraging the team members away from an individualistic approach to problem-solving, and into a cross-functional approach.  Wetlaufer [10] believes this is critical in jarring people out of their individual or compartmentalized loyalties, and to develop a team-based big picture perspective.  In other words, the leader needs to facilitate the building of partnerships in the team.
• Soften up on direct leading and allow team interaction to blossom. To facilitate the team’s growth as a cohesive entity, and to move away from the single-leader approach, the project manager should adopt a light-touch approach towards leading if the group dynamics permit it.  In addition, he or she should also take up a back-stage, advisory role instead [7].

Stage #4 – PERFORMING (the phase of functional role-relatedness)  

This is the phase where roles become flexible and functional, and group energy is channeled into task completion [5]. The performing team is now a truly purpose-driven unit where members derive satisfaction from working together to overcome the challenges at hand.  Here are some issues for team leaders to consider as they continue to fine-tune their unit towards higher performances:

• Focus on team self-development and individual renewal.   This calls for a continued departure from the single-leader approach, and towards the situation where group leadership is dependent on the individual who is in the best portion to ensure performance [10].  The project leader should adopt a coaching role and provide his or her team members with help by the sidelines.  The persuasive style should be one of close observation and support [7].
• Develop the dynamic grouping of the team.   As with the norming phase of development, project leaders should continue to encourage and emphasize cross-functional problem-solving approaches [7]. The principle here is the progressive integration of job enrichment opportunities into the tasks to expand on the challenges faced.  This serves to drive the intrinsic motivation of individuals who demonstrate high levels of ability, and who desire to stretch their own limits and potential [12].  This is a channel to improve the efficiency of the team, as well as to edge the team into a high-performing mode.

Edison’s expansion of the Tuckman Model

Dr Tom Edison, in his article The Team development Life Cycle: A New Look published in the May-June 2008 edition of the Defense AT&L Journal [6], argues for the need to look beyond the performing stage of the traditional Tuckman model.  It is important to understand the dysfunctional phases that teams may encounter, he says, in order to institute the necessary measures to keep the team at high-performing levels.  Edison’s thesis is that while the Tuckman model provides a general understanding of group development, teams may not always follow the four stages of growth.  In addition, it may also give the erroneous impression that teams will end at the performing stage.

Edison [6] labels Tuckman’s four-stages as the functional side of the coin, and develops his insights by bringing in the informing, conforming and deforming stages – the latter two which he terms as the dysfunctional phases for teams.  If the four-step process of the Tuckman model is viewed as a linear journey, the three new phases shall be added to the original model as follows:

Stage # 5 – INFORMING (the calm before the storm)  

Edison [6] calls the informing phase the proverbial mid-point of the group development journey.  This is where the organization recognizes the achievements of the project team and gets it to document and inform others about its results, processes and conclusions.  Citing a 2002 research by Dr Owen Gadeken, he says that the informing phase is still part of the functional stage of group development as the organization tries to, as part of knowledge management, capture the processes and lessons learned by the project team to enable its replication by other groups.  However, the informing stage is also the tipping point before a successful team begins its decline, so here are some issues that project managers should consider:

• Realize the impending danger of team dysfunction.   This point needs little elaboration.  Once project managers are made aware that the informing stage is also the precursor of the more dysfunctional states, they need to avoid lapsing into complacency. On the contrary, they must be acutely sensitive to the existing state of development of their teams, and what is needed to progress.
• Continue reviewing the team set-up and consider new blood.   The team’s composition must be continually examined to ensure that it has the right level of resources to survive and function.  I would argue that the two main challenges for the project manager are: (1) the addition of new blood that may disrupt group stability, and (2) the prospect of dismantling what appears to be a successful set-up.  There is no simple solution, but it does seem that unless there is an artificial yet constructive ‘destabilization’ of the seasoned team into jumping the curve and recreating new phases of storming and norming (what Edison [6] calls the transformation process), the team and its stable of old guards may just slip into the first state of decline that is characterized by groupthink.

Stage #6 – CONFORMING (the start of the slip)  

The manifestation of groupthink is really the first clear sign that the team is heading downhill.  The desire to conform threatens the team by subverting creativity, originality and innovation, according to Edison [6].  He says about the stage of conformity, ‘members have begun to think alike, and any of the unique yet appropriate ideas… from the team are lost or decreased because the team members are beginning to develop the characteristics of groupthink.’  The danger, as Drohn [13] and Hamilton [14] explain, is that sometimes, even experts may end up reinforcing each other’s ideas and opinions due to the phenomena of self-censorship, mind guarding, and the illusion of unanimity, for example. Hamilton [14] makes some suggestions to counter groupthink that team leaders should consider as intervention when faced with conformity:

• Have outside voices with opinions different from that of the team.     This suggestion of bringing outside experts into the group decision-making process to provide an alternative opinion actually validates the earlier measure discussed at the informing stage, which calls for the injection of new blood into the team to add new perspectives to the group dynamics.  Edison [6] describes this as the addition of more activation energy to energize the team.
• Rotate the leadership of meetings.   The incumbent project managers should consider deliberately missing some meeting sessions, and to rotate the chairmanship to allow different members to lead and facilitate instead.  This is primarily because their presence may be doing harm by inadvertently dominating the team processes [14].  To add to this, I think that it is also necessary to critically review the quality of the decisions made in the leader’s absence to test for signs of groupthink.  Otherwise, conformity if unchecked will lead to the team’s deformation, which is the next and final stage we will review.

Stage #7 – DEFORMING (the deforming phase: the team in peril)  

According to Edison [6], when the team is caught in the mire of conformity, it will essentially start to decay as a functional unit.  As more and more team members gradually lose the sense of gratification and motivation that initially characterized the group in the norming and performing stages, they may start to miss team meetings or even pull out altogether.  The team in the deforming stage is devoid of spark, life and effectiveness. Theoretically, the intervention measures discussed in the previous two phases may still be applied to try and transform the team, but in reality, Edison [6] says that any effort by this stage could be futile as the team may well be past the point of no recovery.

Conclusion

For a long time, Tuckman’s four-stage model has been the basis for understanding the main phases of group development.  However, stopping at the performing phase is apparently insufficient.  To have the true picture, teams also need to consider the perils and implications of the dysfunctional stages, where they may lapse into conformity due to groupthink, and eventually head towards deformation and disbandment.  I do hope that through this exposition of the thoughts of Tuckman, Edison, and other works that have been covered in this paper, project managers and team leaders may acquire a clearer understanding of the complete cycle of group development.  Furthermore, the insights should hopefully provide them with a means to assess the stage of growth (or decline) that their group may be at, and to take the appropriate steps to support or even transform their teams into high-performing units. 

* * * * * * * * * *

References

[1] Perrin R. Introduction. In: Real World Project Management. New Jersey, John Wiley & Sons, Inc, 2007. p. 1-2.

[2] Schmidt WH. Tannenbaum R. Management of differences. In: Ideas with impact: Harvard business review on negotiation and conflict resolution. Boston, MA: Harvard Business School Press, 1960. p. 1-3.

[3] Kemp S. Chapter 3: Six keys to project success. In: Project management demystified – A self-teaching guide. New York: The McGraw Hill Companies, Inc, 2004. p. 43-48.

[4] Punk JS. Survey identifies key challenges to successful project management. In: ESI International. Retrieved August 20, 2008, from http://www.esi-intl.co.uk/resource_centre/news/survey.asp., May 21, 2008.

[5] Smith MK. Bruce W. Tuckman – forming, storming, norming and performing in groups. In: The encyclopaedia of informal education. Retrieved October 13, 2008, from http://www.infed.org/thinkers/tuckman.htm., 2005.

[6] Edison T. The team development cycle: A new look. In: Defense AT&L. Retrieved October 15, 2008, from http://www.dau.mil/pubs/dam/2008_05_06/edis_mj08.pdf., May/June 2008. p. 14-17.

[7] Team technology. Leadership: Using the Tuckman model. In: Teamtechnology.c o.uk. – Publishers of quality online articles and resources. Retrieved October 14, 2008, from http://www.teamtechnology.co.uk/tuckman.html., 1995.

[8] Blanchard K. Johnson S. (2003). One minute manager. New York: Harper Collins Publishers, Inc, 2003. p. 66.

[9] Locke EA. Latham GP. Chapter 2 – Goal setting theory. In: H. F. O’Neil, Jr & M. Drillings (Eds.), Motivation theory and research. Hillsdale, New Jersey: Lawrence Erlbaum Associates, Inc, 1994. p. 17.

[10] Wetlaufer S. The team that wasn’t. In: Ideas with impact: Harvard business review on negotiation and conflict resolution. Boston, MA: Harvard Business School Press, 1994. pp. 37-38.

[11] Mai R. Akerson A. Chapter 5 – Trust builder. In: The leader as communicator. Notes provided by Dr Weiler for references purposes during the 11 Sep 2008 Strategic Communication class, 2003. p.78.

[12] NetMBA.com. Herzberg’s motivation-hygiene theory (two-factor theory). In: NetMBA – Business knowledge center. Retrieved March 30, 2008, from http://www.netmba.com/mgmt/ob/motivation/herzberg/., 2007.

[13] Drohn J. The dangers of group think. In: JDsBlog.com. Retrieved October 13, 2008, from http://www.jdsblog.com/2007/09/06/the-dangers-of-group-think/., September 2007.

[14] Hamilton C. Chapter 9 – Small-group communication and problem-solving. In: Communicating for results – A guide for business and the professions (7th ed.) United States of America: Thomson learning, Inc, 2005. p. 212-213.

I’ve been for a small vacation, so I thought i’ll post a small list of links of what happened interesting during that time:

• Vertabase project management software launches v 4.5, source
• Wikis that work: Four IT departments get it right, source
• Lessons learned for project management, source
• Extreme Toyota’s Lesson for American Auto
• Crisis Management in Action, source
• Measuring Productivity Metrics With Programmer, source
• New Deloitte Aerospace & Defense Study finds Root Causes for Program Cost Overruns in USA, source
• Six Sigma: Myths and Realities, source

So much for today, keep tuned!

It is common that the biggest mistakes are made at the beginning of the project, so in the end even a small mistake can cost you a lot, here a pretty good video on one common mistake at the beginning of the project:

Of course there are a lot of different kind of mistakes, what mistakes have you made while managing a project?

It's common wisdom that metrics are critical to how successful your project will be perceived. What's less often discussed is exactly how formal an approach one should take when communicating those metrics to the relevant audiences.

When trying to determine the appropriate level of formality for a particular project I’ve found it helpful to ask the following questions:

Add up your answers and compare the results to the table below:

Uncategorized | My Kayaking Buddies via kwout

Alex G made us laugh during one of our frequent Skype conference calls earlier today. We were catching up on the progress of our technical build and G who is acting at the build’s project manager was reflecting on the joys of his role. He told us that trying to lead the technical team through to launch was akin to trying to steer a raft down an enormous set of white water rapids.

As we now enter calmer waters and edge ever closer to our alpha launch we thought it might be a good time to share some of our key learnings of the project so far – in the form of a list (of course):

1. Work with people you have worked with before and like

2. Play to their strengths – people perform much better when they focus on the tasks they like doing

3. For key requirements hire full-time contractors

4. Reward your team on a deliverables basis

5. Factor in a contingency for production times. Then triple it

6. Let the team set specific, measurable, achievable, realistic and time bound objectives

7. If you run in to problems, focus on solutions as a team – finger pointing and shouting achieves very little

8. Manage expectations – yes, it’s an old cliché but it’s also so important

9. Get the right balance of realism and optimism – this is never easy to do as an entrepreneur but vitally important

10. Exercise regularly – even if you’re busy and working hard to meet a deadline – there is no better way to get rid of stress

11. Lastly, take time out to laugh, even when things seem really, really bad

Not sure this is anything like a definitive list but it is perhaps a start of one I will later publish on Snagsta. If you’d like me to add anything I would appreciate suggestions – while you’re at it, a couple of tips for Mr. G on white water rafting would be welcome too!

Like this post? Subscribe to our RSS feed and get loads more!