Project Management Initiating Tools & Techniques

Project Initiation is the process or activities associated with defining the boundaries of a project, or project phase, and gaining the approval of appropriate stakeholders to begin the work of project planning and project execution. Project initiation is always company-specific. While many of the tools of project planning or project control are standard and universal, the initiating tools must interact with the company's business environment and strategy planning process, and therefore are far less formal or deterministic. The project objectives, which form the basis for project boundaries, are directly related to the business strategic imperatives. These are different from business to business and they change over time. The stakeholder analysis involved in approving a project are based upon a combination of the business organizational structure and the personalities of the individuals involved.

The Project Management Institute identifies several outputs from the Initiating processes. These are the Project Charter, a Project Stakeholder Register, and a Stakeholder Management Strategy. On small or simple projects I recommend that these all be rolled into one document. On larger more complex projects, I suggest that two deliverables are created during project initiation, aProject Charterand aStakeholder Registerthat incorporates the stakeholder strategy decisions. I use a variety of tools and techniques to create these documents, depending upon projectcomplexityanduncertainty. These include:W's,In-Frame/Out-of-Frame,Project Dimensions,Project Requirements Document,Communication Strategy Matrix, andCollaboration Strategy Matrix. The project leader needs to determine which of these tools and techniques are appropriate for their project. Typically only two or three of them are used. The project leader should always follow corporate policies and directives with regards to required tools or techniques. In addition, unique characteristics of the project may require different tools.

Project Charter

The Project Charter documents the basic attributes of the project, essentially the project boundaries. As such it captures the understanding of the project by the project sponsors and senior management at the time they approve the project to go forward into a planning phase. The charter is not an in-depth project plan. It is a high-level document. It describes the expectations of the customers of the project and the senior management for the project results. A charter is normally developed by the portion of the business that is sponsoring the project, not the project team. On small projects the charter may only be a one-page document. On larger projects, the charter may require many pages.

A project team uses the charter document to assist in the planning process. The team attempts to develop a project plan that has a strong potential of achieving the project objective while staying within the project schedule and budget boundaries found in the charter. An example of a Project Charter format that I have used on small projects with several clients is shown.

Stakeholder Register

The Stakeholder Register documents the stakeholder planning process. It is often started during the initiating process. However, this is a living document. While created during the initiating process, it is continuously updated throughout the life of the project. During the project new stakeholders are often identified and the role or interest of stakeholders may change due to changes in business priorities or reorganizations. The Stakeholder Register tracks these changes and guides the project leader in making decisions with respect to stakeholder interaction planning.

A project leader uses the Stakeholder Register to guide elements of the Project Communication Plan. In addition, project risks, reviews and decision meetings are often structured based upon the strategies documented in the Stakeholder Register. Further, the project attributes associated with the stakeholder's "Wins" will inevitably become linked to entries on the Risk Register.

W's

The "W's" are one of the simplest methods for identifying the boundary conditions for a project. This technique is often used with small projects. It consists of discussing with the sponsor the answers to several questions that have a "W" in them. These questions can be asked in any order."What?" What is the project intended to do or deliver? "Who?" Who is the primary customer and are there any other key stakeholders?"When?" When does the project need to end? When does it need to start?"Where?" Where will the project activity be conducted? "Why?" Why is this project needed? Is it related to a specific business strategy or goal?

"How?" How should this project be accomplished? Are there any constraints on the approach, any procedures or regulatory guidance that must be followed, or any financial or resource constraints? (The "w" was on the end of "How")

In-Frame/Out-of-Frame

The "In-Frame/Out-of-Frame" analysis is an excellent technique for clarifying project boundary conditions with stakeholders who are vague or often change their mind. An effective use of this technique at the beginning of a project will significantly decrease the incidents of scope creep. This technique identifies all of the major elements that are to be accomplished and puts them "In the Frame." It also lists activities, analysis and work that, though potentially related to the project, is not requested or required by the stakeholders. These items are listed as "Out of the Frame." An important clarification is that the "Out of Frame" items are not itmes being withheld from the stakeholders, rather there is an agreement with the stakeholders not to expend project time and project money on those items.

The "In-Frame/Out-of-Frame" analysis assists the project team in setting a clear definition of scope. Often there are several possible interpretations of a project requirement. This analysis clarifies the interpretation. This analysis minimizes the likelihood of scope creep because it forces the stakeholder to clarify the boundary of acceptable performance. Many instances of scope creep are due to stakeholders asking for "just one more thing." This analysis defines the limits of what can be done with the available time and money in the project. If at the time of project initiation the "In the Frame" list is more extensive than the desired end date or budget can reasonably be expected to deliver, the discussion with the stakeholder occurs at that time to either limit the project scope or increase time and/or money.

Project Dimensions

Karl Wiegers introduced the concept of categorizing the various project requirements into different "dimensions." These dimensions are related to the criticality of the requirements. This tool is useful on larger, more complex projects and programs. When discussing with stakeholders the nature of their requirements, determine how strategically important each requirement is. Some requirements are "Constraints." There is no flexibility with respect to these requirements. If this requirements cannot be met, the project is canceled. Very few requirements are truly in this category. For these requirements, the project plan should be constructed to minimize risk in those areas. The next category of requirements is "Drivers." These requirements are often expressed by stakeholders in terms such as, "As much as ..." or "As soon as ...." These requirements should be optimized to achieve the best overall mix among them. If you have many stakeholders, this may prove to be difficult as some stakeholders will probably need to compromise on their preferred solution or actions in order to accommodate some others. The final category is "Degrees of Freedom." These are items that are not requirements in the minds of any stakeholders, yet are elements of the project that must be accomplished in order to complete the project. Since there are no stakeholder imperatives with respect to these requirements, these are the areas where the project team should be the most creative and take the most risk. When completing a Project Dimensions I normally use a spreadsheet to capture the items. There are often more than one hundred items between all of the categories.

Project Requirements Document

A Requirements Document is a formal document that describes all of the requirements for a project. It is most commonly used in government contracting or large commercial construction projects and programs. This document is prepared by the buying organization in order for sellers to fully understand all requirements of a project when they prepare to bid on the project or portions of the project. When a government agency determines that it will source a major project effort, the agency develops the requirements document. The document contains all of the technical and managerial requirements appropriate for the government agency and the type of project work. The document can easily be hundreds of pages in length.

Communication Strategy Matrix

The Communication Strategy Matrix is a tool for determining the communication strategy to be used with each stakeholder. On a small project with one or two stakeholders, the matrix guides the project leader to determine the specific communication techniques to be used with those stakeholders. On larger projects with many stakeholders, the communication strategy for each stakeholder is a major input used when developing the project communication plan.

Each stakeholder is considered individually. The stakeholder is placed in one of the four quadrants of the matrix. Based upon the quadrant, the communication strategy for that stakeholder is set. One caution with this technique, a stakeholder's oversight or interest may change as the project moves from one phase to another or as business conditions change. Therefore, the stakeholder's position within the matrix should be periodically reviewed and updated.

Collaboration Strategy Matrix

The Collaboration Strategy Matrix is a tool for determining the type of collaboration that must be done with each stakeholder. Collaboration in this context implies that the stakeholder must be involved in the activities and decisions of a portion of the project. On a small project with only one or two stakeholders, the matrix guides the project leader in determining the level of involvement required from the stakeholder. On larger projects with many stakeholders, the collaboration strategy drives decisions on project planning and on project review meetings.

Each stakeholder is considered individually. The stakeholder is placed in one of the four quadrants of the matrix. Based upon the quadrant, the collaboration strategy for that stakeholder is determined. The selected strategy indicates the level of involvement by that stakeholder in decision-making, both during planning and execution phases of the project. The more stakeholders involved, the more project management effort required to manage the relationships and interactions with stakeholders.

Project Management Planning Tools & Techniques

Project planning is at the heart of project management. One can't manage and control project activities if there is no plan. Without a plan, it is impossible to know if the correct activities are underway, if the available resources are adequate or of the project can be completed within the desired time. The plan becomes the roadmap that the project team members use to guide them through the project activities.

The development of a project plan is often an optimization process. Therefore it may require several iterations to establish an acceptable plan. Every project activity has risk in it. The planning process needs to balance the risks in a way to minimize risk on high priority items from the project charter, and take greater risk on lower priority items. This optimization revolves around the "triple constraint" of project management: scope management, schedule management, and resource/budget management. These three elements of project planning are so significant that I have dedicated a separate page for each of them.

Scope Planning Tools & Techniques

Schedule Planning Tools & Techniques

Resource/Budget Planning Tools & Techniques

There is one additional planning topic that is inter-related with all aspects of the triple constraint, that topic is estimating and I have dedicated an entire page to this topic also

Project Estimating Tools & Techniques

Once the triple constraint has been addressed, the project leader and project team must address several other elements of the project plan. These topics are broad enough that they impact the planning, executing, and controlling processes. Therefore I have created a standalone page of tools and techniques for each of them. They are:

Project Risk Management Tools and Techniques

Project Communication Tools and Techniques

Project Team Leadership Tools and Techniques

There are several other tools and techniques that span scope, schedule, and resources, but are specific to project planning. These include using aTollgate/Phase gate approach, establishing aQuality Management Plan, and conductingProcurement Planningfor the use of vendors and suppliers to accomplish project activities.

Tollgate/Phase gate Planning

Tollgate planning, also known as Phase gate planning, is used in order to control high project risk. Tollgate planning divides the project tasks into phases. Each phase is structured around being able to resolve a major risk issue on the project. The phases are then ordered so that risks are addressed in a manner that minimizes the impact on later phases. Once all the tasks for a phase have been identified, the tasks are then budgeted and scheduled for that phase. Often the detailed tasks of a later phase cannot be identified until an earlier phase is complete.

The Tollgate planning approach is excellent for managing risk because as each phase completes, a business decision meeting, called a Tollgate, is scheduled. The project team and appropriate stakeholders meet and review the results of the work from the preceding phase to determine whether the risk has been adequately mitigated. One of three project options is selected by those at the meeting. The first option is to continue on to the next phase since the risk has been adequately mitigated. The second option is selected when the risk has not been adequately mitigated. In that case the decision is to conduct additional activities beyond what were originally planned for the phase. These additional activities are designed to mitigate the risk. This entails a rebaseline of the project with appropriate adjustments to project end date and total budget. The third option may be selected whether the risk has been mitigated or not. This option is to cancel the project. Either the business needs have changed, or the activities needed to resolve the risk are more than the business is willing to undertake. In those cases, the project is canceled and the resources are released to work on other projects.

Phase/Tollgate Scheduling Technique: Identify the key project risk milestonesSequence the risk milestones to minimize overall project risk Identify the tasks needed to resolve each of the risk milestones. This does not need to be accomplished until preceding milestones have been completed Create a schedule (network diagram or Gantt) of the tasks supporting each of the milestones. This does not need to be accomplished until the activities for that phase are about to begin.

Conduct tollgate meetings at appropriate points in the project and decide to continue, rebaseline, or cancel the project.

Project Quality Planning

Quality planning is a project management activity that occurs on every project, but often it is done either haphazardly or unconsciously. A maxim in business is that, "You get what you measure." The project Quality Plan identifies what will be measured. By establishing the project performance characteristics that are to be tracked, the project leader indicates what project attributes are most important. If the schedule is most important, then that is the key quality attribute and schedule milestones should be what is primarily tracked and measured on the project. However, if technical compliance to a product or customer requirements document is most important, then that is what should be measured.

The characteristics of the project that are the key success factors for the major stakeholders should be the starting point for determining the quality characteristics for each phase and each activity. There are numerous quality analysis tools that can be used to assist in setting targets, such as Design of Experiments, and tools that can be used to establish the methods for measuring performance, such as Sampling Plans. However, I have found that the most important aspect of quality planning is to consciously consider with the key stakeholders and team members which project characteristics are the indicators of success on this unique project.

The results of quality planning are captured in two different ways. On the one hand, modifications are made to the project plan to add tasks or activities that will improve the probability of project success. On the other hand, the quality plan is used to guide the development of the project control plan be establishing a clear definition of success on each vital project characteristic.

Project Procurement planning

The characteristics of project procurement are different from the characteristics of production procurement. For this reason, a project leader cannot afford to just turn the procurement portion of the project over to the organization that handles production procurement. The differences are caused by the differences between project management and process management. Production procurement buys a well-documented, often commodity, item - and it buys a lot of them. Production procurement is focused on establishing a long term relationship with a supplier who will provide high quality at a reasonable price and will deliver the amount contracted for on time - every time. Project procurement often requires that a supplier deliver only one item for which no specification yet exists, and it is needed by tomorrow morning at 10:00 AM. Many production procurement organizations are not equipped to support project procurements, therefore, the project team must take on that role.

I have found that when planning project procurements, it is best to start with the Work Breakdown Structure (WBS) activities that you want to supplier to perform. Using those WBS activities and the project risk management plan, determine what level of specification can be created for the effort. Is it very specific or is it very general? Also, consider how complex the procurement will be with respect to the rest of the project. Does the supplier need to integrate with many other organizations? Does the supplier need to provide extensive reports and documentation that is unique to the project? The answer to these questions will indicate the type of relationship is needed for each of the project's suppliers.

If there is low complexity and a highly developed specifications, there is no need for a unique project relationship with the supplier. These types of procurements can be turned over to the production procurement department and handled through normal procurement channels. As a project leader you can keep the supplier at Arms Length. You do not need to expend any of your time and energy interacting with the supplier.

As the complexity increases or the specification becomes more general, the relationship may need to migrate to the Product/Service Provider interactions. In this case you typically have unique project requirements, either with the specification or with the project integration. Because of these unique requirements a standard Purchase Order is probably not adequate. Normally, in this type of relationship, the project leader or appropriate project team member must meet with the supplier at the beginning of the procurement to clarify the unique requirements. In addition, periodic meetings are usually needed with the supplier to answer any new questions that come up.

As the complexity further increases or the specifications become even more general, the relationship should change to the Solution Provider interaction. In this case the project leader or appropriate project team member will meet with the supplier on a regular basis. The contracted item is general enough that the supplier and the project team must agree on the solution that is being suggested by the supplier. There is often a great deal of give and take in this relationship as the solution is developed. Often the solution will have impacts on other aspects of the project that are not being performed by the supplier. The project leader or project team member must closely supervise the supplier activities or significant cost and schedule issues can arise throughout the project.

The most complex relationship is the Partnership relationship. This partnership is a partnership on the project. The corporation may have a partnership relationship with a supplier that is only providing commodity items on a specific project. On that project the supplier relationship within the project would be Arms Length. In the case we are addressing at this point on the project, the project circumstances dictate that the supplier is a partner on the project. This will often take the form of joint venture or business consortium. It is often difficult in this relationship to determine who the buyer is and who the seller is. Both parties are working together on the project team to achieve shared project objectives.

Although there are four different types of relationships, once a relationship is determined a subcontract can be crafted that contains appropriate deliverables and oversight to achieve the project objectives. Typically, for Arms Length and Product/Service Provider relationships a Fixed Price contract is used. However, a Cost Reimbursable or Unit Price (time and material) contract is often more appropriate for a supplier who is operating as a Solution Provider. A Partnership relationship often will require a Memorandum of Agreement or joint venture documents that are much more complex than what can be documented on a Purchase Order.Project Management Executing Tools & Techniques

Project Execution is the process or activities associated with completing the project activities defined in the project plan in order to meet the project objective defined during project initiation. This is the portion of the project where most of the project effort is expended. The focus for project management is the application of resources to project activities and the collection of information concerning the results of the project work.

The primary results of the Executing processes are the project deliverables and project performance information. In addition, when issues are uncovered while performing project activities, requests for changes to the project plan should be generated.

Once the project plan is in place, the most important aspect of successful Project Execution from a project management perspective is to ensure that appropriate resources are applied to each project activity so as to correctly complete the activity on time and on budget. The project manager must use the internal and external resources available to the project to ensure this happens. The management of internal resources is such as important topic that it is discussed on its own page:

Project Team Leadership Tools and Techniques

The application of external resources will be discussed below in the section onConduct Procurements. Even with the application of the correct resources, sometimes the results of the project activities will be other than what was expected. Therefore the other aspect of Project Execution to discuss is the use of aProject Management Information System. This system will collect the data that is eventually used by the Project Control processes.

Conduct Procurements

Conducting project procurement consists of contracting with suppliers and vendors to perform the project activities that have been designated to be outsourced. The Project Planningpage discussed how to determine the level of project management oversight required for a given project procurement. Now that the relationship has been determined, a supplier who is capable of performing the activity must be placed on contract. This entails typical procurement activities such as source selection and negotiations. The activities associated with administering the contract will be addressed in theProject Monitoring and Controllingpage.

Project Management Information System

The Project Management Information System (PMIS) is the set of communicating methods used by the project team to share plans and results of project activities. Years ago we recommended that the team establish a central location where information could be posted for all on the team and the stakeholders to see the status. We called those project "War Rooms" - but in today's politically correct world we call them Project Management Information Systems. Another change from what we did years ago is that the typical PMIS today is an electronic system. It is an e-room, a website, a common folder on the shared drive, or a common file with different levels of access for review and update. In my experience, a PMIS today will be in one of the following forms. Which one you choose should be based upon the team dynamics and the organizational culture. Project management software file available in a shared location

This approach is generally used withFull-scaleandComplexprojects. In those cases the project complexity is so high that project management software is used because of its superior capability to track inter-relationships between project activities and project resources. This is the best PMIS approach for highly complex projects. The disadvantage with this approach is that all of the stakeholders and team members must be trained and competent at using all of the features of the project management software. Some of the software programs are complex and awkward to use. They can require a significant amount of time creating a project plan and then maintaining the project status. They require special training to know how to read information and to update information. If the stakeholders and team members are not frequently using the software, they have difficulty reading and maintaining project information.

To overcome these problems, companies are beginning to hire Project specialists who are experts with the project management software. These individuals will create and maintain the project plan in the project management software. They then create reports in standard formats that are provided to both team members and stakeholders.Spreadsheet file(s) available in a shared location

This approach is generally used withSimpleandFocusedprojects. In those cases the project complexity is simple enough that the project activities can be planned and updated using several columns of a spreadsheet. This is often referred to as a WBS Dictionary, which is discussed in more detail on theScope Planningpage. The spreadsheet is typically easy for project team members and stakeholders to access and understand. The spreadsheet is able to manage a great deal of data and information. The disadvantage when using a spreadsheet for the PMIS is that it is difficult to track complex interactions between activities.

Meeting room or meeting space with a whiteboard, walls, and Post-it notes.

This method harkens back to the days when we used "War Rooms." This technique is often used withExtremeprojects because of their rapid change and redirection. With the advent of modern technology the room may now be a virtual room instead of a physical room. When it is a physical room, the team meets regularly in the room to plan and track project activities. When an activity is completed, the information about the execution is posted on the whiteboard, a Post-it note, or some other document that is posted on the wall. When the room is a virtual room, the team meets in the virtual world and each participant posts their information using the tools of the virtual room technology. The advantage with this technique is the ability to quickly react to changing project conditions. The disadvantage is that everyone must have access to the physical or virtual room and if it is a virtual room there is the need for training in the use of the technology.

Project Management Monitoring and Controlling Tools & Techniques

Monitoring and Controlling a project is the process or activities whereby the project manager tracks, reviews and revises the project activities in order to ensure the project creates the deliverables in accordance with the project objectives. Because of the unique and temporary nature of projects, they require active control. Unlike a process where the same set of activities have been performed repeatedly so that habits and expectations are stable, a project is inherently unstable. The activities are unique to the project or the sequence of activities and resources are only temporarily assigned and associated with the project and are redeployed when the project completes. Habits and patterns are not established before everything changes.

The primary results of the Monitoring and Controlling processes are the project performance reports and implementing project changes. The focus for project management is the analysis of project performance to determine whether a change is needed in the plan for the remaining project activities to achieve the project goals. In my experience, almost every project will require a change to the plan at some point in time.Traditionalprojects are the most stable projects because the requirements and the activities are clear and well understood.AdaptiveandExtremeprojects are the least stable. They require very close control and will require numerous changes - if for no other reason the project manager will need to refine the activities of later phases based upon the results of early activities.

Tools and techniques that are used by project managers to conduct the Monitoring and Controlling of a project fall into one of four general categories. The first is the collection of project performance information. Techniques supporting this category arePulse Meetings,Variance Reports, andProgram Reviews. The second category is the analysis of the project performance to determine whether a project change is needed. Techniques that are used in this category areTechnical Reviews,Project ForecastingandProblem Solving. The third category is reporting on project performance. Techniques that support this activity include the use of aProject Management Information System,Management Reviews, andDashboards. The final category is the management of project change. The technique I commonly use in this category is the maintenance of aChange Management Log. There are two areas of project management tools and techniques that closely support the Monitoring and controlling process but are also used more broadly throughout the project lifecycle. These are important enough to justify their own page.

Project Communication Tools and Techniques

Earned Value Analysis

Pulse Meetings

Pulse meetings are short team status meetings where the project management team is able to gather project performance information about the activities that are underway. These meetings should occur frequently and can either be face-to-face or virtual. Normally they are only a few minutes in duration. During the meeting, the beginning and completion of project activities is reported. In addition, the status of any activities that are underway is communicated to the rest of the project management team. Issues on any of the ongoing activities are identified, however, the issue resolution occurs at a separate meeting with the appropriate individuals present. The issue resolution meeting may immediately follow the Pulse meeting, but it is clearly a separate meeting and those project team members who are not needed for issue resolution do not need to attend. The frequency of the Pulse meeting is determined based upon the status of the project. When in anExtrememode, the Pulse meeting may be happening several times a day. Projects that are running smoothly may only need to have a Pulse meeting once a week.

Variance Reports

Variance reports are formal reports generated by thePMIS, by theEarned Value Management System, one of the other business management systems - such as the quality control system, or by a project supplier. Variance reports compare what has actually happened on a project against what was expected to have happened on the project. A variance report typically indicates both the absolute value of the difference and a percentage representation of the difference.

The actual performance achieved on a project activity (such as cost or duration) seldom precisely matches the estimated performance set at the time of project planning. The page onEstimatingexplains why project estimates are seldom precisely accurate. However, since the estimates often aren't accurate, it is imperative for the project management team to identify the variances in order to know what is actually happening on the project. The variances can uncover both positive and negative project risk.

Project variance reports often are expressed with two references. The first reference is what was supposed to have happened since the last reporting cycle. This is often called the "Current Period" variance. It is an indication of how well the project resources were able to conduct project activities in accordance with the project plan in the recent past. The second reference is what was supposed to have been done on the project since it started. This is often called the "Cumulative" variance. It is an indication of how well the project resources have been able to conduct project activities throughout the project lifecycle. The cumulative variance will have embedded in it any previous variances - either positive or negative. The current period variance provides a clear representation of what is happening right now on the project. The cumulative variance eliminates the effects of any short term conditions, either good or bad, that effected the project during the most recent reporting period. Both variances provide useful information.

Program Reviews

Program Reviews are meetings with the project team members and sub-project leaders that review the current status of the program as compared to the original program plan. These are most often used onFull-scaleandComplexprojects. Unlike the Pulse Meetings which focus on day-to-day activities, the Program Reviews focus on the big picture and emphasize the integration between activities and between sub-projects encompassed within the program. The question being asked is whether the program activities and the sub-projects are likely to interfere with each other. In addition, when I have a supplier who is a major contributor on the program and is performing customized work on this program, I will conduct Program Reviews with the supplier for their portion of the program. Program Reviews are sometimes combined with Management Reviews. I do not recommend this approach. The danger with this approach is that key stakeholders and managers may intimidate some project team members from providing a frank and honest appraisal of the status of program work.

Technical Reviews

Technical Reviews are formal meetings conducted with subject matter experts who are not members of the project team. These are in-depth reviews focused upon a technical aspect of the project. Examples would be Design Reviews, Code Reviews, Security Reviews, or Production Readiness Reviews. The reviewers should perform an in-depth analysis of the project deliverables and activities to determine whether the project work has been accomplished completely and correctly. These reviews will normally generate a list of actions that must be completed. These actions may require additional testing or analysis. In some cases it may even require redesigns of systems, software, processes or products. The results of these reviews are normally reported to senior management at the next Management Review. In many cases, the technical review must be completed before a project can proceed to a toll-gate meeting. When the Technical Review is linked to a toll-gate meeting, the action items do not need to be completed prior to the toll-gate. However, any open action item is listed on the risk register and the plan for resolving that action item is included in the project plan for the next phase.

Project Forecasting

Project Forecasting consists of taking the project status information and extrapolating the current project performance to the end of the project. Forecasts can be made with respect to project duration, overall project cost, performance/quality level of project deliverables, or any combination of these. A key element in forecasting is to review the risk events that occurred and the remaining risk triggers. A deeper discussion of this is found on theProject Risk Managementpage. A caution when doing forecasting, ensure you have adequate information to realistically forecast performance. My personal rule of thumb is that I wait until an activity, phase, or deliverable is at least 25% complete before I try to forecast. Prior to that point I stick with the original estimate, modified by any appropriate risk mitigation activities that have occurred.

When forecasting project duration, the key is to understand the schedule performance and schedule risk of the activities on the critical path. Those activities will be the ones that drive the project completion date. On a resource constrained project, or a project with unpredictable resource availability, this can be very difficult because the lack of resources causes the critical path to vary. I have not found a good robust tool for forecasting schedule in this condition. It generally comes down to expert judgment and gut feel. When it is vital for the project to complete by a certain date, I often will convert my schedule tracking to a countdown mode where everything is measured in terms of how many days before project completion. Also, I will Pulse the project more frequently in order to quickly assess when I believe we are falling behind. If that sounds like micro-management it is because that is micro-management.

When forecasting total project cost, I prefer to use the forecasting methods that are embedded in theEarned Value Managementsystem. Unfortunately, many organizations do not have the financial systems in place that enable earned value management. When that is the case, I am forced to rely on trend forecasting - which is sometimes called "straight-line" forecasting. Trend forecasting takes the current project spending and extrapolates that rate of spending until the end of the project. This provides a rough forecast, but it does not take into account the effect that different activities may require resources that spend at different levels. The resources that perform the remaining activities may be higher or lower cost than the preceding resources. Also, it does not take into account that the project may be ahead or behind schedule. If the project is ahead of schedule, the spending done to achieve that condition inflates the extrapolated value of the project final cost. If the project is behind schedule, the lack of spending creates an extrapolated value of total project cost that is too low.

When forecasting the performance or quality of project deliverables, I rely heavily on prototypes and preliminary analysis. When the project does not have these, the risk that the project will not achieve the desired performance or quality established at the time of project planning is higher. If performance is the most important attribute of the project deliverables, then the risk of missing the forecast project duration or cost is much higher. The principle involved is the "Rule of Ten's." According to this principle, the cost to correct a technical issue goes up by a factor of 10 as the project moves from one phase to the next. Therefore it is imperative that performance issues be identified as early as possible.

Problem SolvingProblem Solving is a very broad topic. There are dozens of approaches to problem solving. My rule of thumb with respect to this technique is that if you have a process that works for you, use it! I recommend you have an agreement with your project core team members or key project stakeholder concerning the problem solving process that will be used. Will it be team-based or individually driven? Will you use a process that relies on data from past projects or only on data from this project? Once a root cause is determined, how will recovery actions be identified and approved? As I said, there are many problem solving methods and their answer for these questions and others is different. From my standpoint, the most important point is that you have a process to address issues, rather than jumping to conclusions or worse yet, ignoring the problem until it is a crisis.

If you don't already have a problem solving process, may I suggest this one that I refer to as CIV2:

1.Clarify: Clarify the problem. In which part of the project did it occur? Who was involved? When did it happen?

2.Investigate: Investigate the details about what happened. Gather data from both the project activity and the surrounding environment. Determine the root cause(s) of the problem.

3. Evaluate: Evaluate the options to address the problem. Consider the impact on the project objectives that each potential solution would likely have. What new risks are associated with each potential solution.

4.Choose: Choose among the viable solution/recovery paths. If necessary, coordinate the decision with key stakeholders. This must be done whenever the solution will impact a boundary condition of the project.

5.Implement: Implement the selected solution/recovery path. Modify the project plan with respect to any changes in scope, resources, or scheduled dates of any activities. Update the risk register.

6.Validate: Validate that the solution/recovery path is achieving the desired results.

Project Management Information System

The Project Management Information System (PMIS) was discussed in detail on theExecuting Tools and Techniquespage. The PMIS is the set of communicating methods used by the project team to share plans and results of project activities. The PMIS can either be a physical system or an electronic system. Either way, the PMIS is used as the clearing house of information on the project including; project plans, project status, project risks, project changes, project meetings, and any other information that project management team believes is relevant to the project team.

Management Reviews

Project Management Reviews are formal documented meetings with the project team and key stakeholders that review the current status of the project as compared to the original project plan. Unlike the Pulse Meetings and Program Reviews which are data gathering meetings that focus on understanding the current status of the project, the Management Reviews are with key stakeholders with the emphasis being on whether the project performance is adequate for the project to deliver on the overall project objectives. Often if the project has encountered issues, such as resource constraints or scope creep, the stakeholders conducting the review are able to provide assistance to the project team to overcome these issues.

The format for these reviews is usually set by the stakeholders and addresses the topics that are most important to them. The review may be a formal stand-up meeting, it may be an informal discussion setting, a written report, or an update to an electronic dashboard. Regardless of the method used, these are formal status reporting meetings and need to be treated as such. The project manager should keep an Action Item list or Stakeholder Issue log for any questions that arise in these reviews. Also minutes from these meetings should be maintained as part of the project records.

Project Dashboards

Dashboards have proliferated as more organizations start to manage projects within the context of a portfolio of projects. A dashboard is a great method for capturing a snapshot of a project and presenting that to stakeholders. Dashboards contain a small subset of project status information that is used as indicators of whether the entire project is on track. The dashboard information is used to make decisions concerning changes to projects or to the project portfolio.

Within a project team, Dashboards were used by project managers to focus the project team on the few key items that would drive project performance. Therefore the current critical path activity is tracked for schedule status, the current activity with the most uncertainty in resource requirements is tracked for cost status, and the most challenging activities are tracked for project performance/quality. This is an excellent use of dashboards, especially when working with a virtual project team.

As more organizations decided to manage their projects as a portfolio of projects, they have recognized the need to have a means of measuring the projects in the portfolio both against each other and with respect to their objectives. The dashboard offers that mechanism as each of the projects report on key metrics that are used by the senior management orProject Management Officeto check the status of the projects. Often the dashboard measures the status through the "Red light - Green light" method. This type of scoring uses colors to indicate project status on the key measures. A "Green light" indicates that everything on the project is going according to plan. A "Yellow light" indicates that there are some problems, but the project team is working the situation and should be able to contain the problem. A "Red light" indicates that the problem is so severe, the project team cannot resolve the problem and achieve the project objectives without help from the stakeholders. The senior management team and PMO use the Dashboard to make resource allocation decisions and to call special Project Management Reviews.

Change Management Log

This tool is very straight-forward. The need for it increases as the project complexity increases. I can't imagine running aComplexproject without one, but I have never used one on aSimple project. The necessity on a Complex project is because these projects are managed as a set of focusedandFull-scalesub-projects. The boundaries between these sub-projects will inevitably need to change as projects progress. Sometimes the changes are due to shifting milestones. Sometimes the changes are the result of activity deliverables that are passed between the projects. In any case, the changes in one sub-project cascades into changes in another sub-project. The Change Management Log tracks the implementation of the change across the sub-projects. It can also track the implementation of the change within a project, especially if the project activities are conducted in multiple locations or if there are multiple phases underway at one time. Using the Change Management Log is similar to using an action item list. Each item is tracked to ensure it has been completed.

Project Management Communication Tools & TechniquesCommunication is an essential part of project management. I have never met a successful project manager with many projects under their belt that was not a good communicator. This is due to the inherent nature of project work as compared to process work. Projects are unique one-of-a-kind set of activities. If we did exactly the same thing in every project, the same way, with the same people, and in the same sequence, then project manager communication skills would not be as important. An individual could be trained for a job, placed in it and the expectations would be clear. But project work is always different. That is why we need good communication. Those working on the project need to understand what is required on this project, when it is required, how it should be done, and what other activities it must integrate with. Without good communication, projects fall into chaos.

The methods and frequency of communicating will vary from project to project. One of the most important considerations is theproject complexity. Simple projects require a minimum of communication, since it is usually a one person team and only one stakeholder involved. Focused projects require more communication planning and execution, but they typically are still relatively straight-forward since there are only a few people on the team. The project manager can often handle the communication through informal channels such as one-on-one meetings or calls to all of the team members and stakeholders. When the complexity grows to the size of Full-scale projects, the communication focus needs to shift. Now the project manager must spend dedicated time keeping everyone on the project aware of status, issues, and changes. Also, there are usually many stakeholders and stakeholder meetings on Full-scale projects. Once the complexity grows to the size of a Complex Program, the program manager is spending virtually all of his or her time doing communication and risk management. In fact, you could argue that communicationIS risk management. These programs are typically managed as a portfolio of integrated sub-projects. The program manager is continuously communicating between the sub-projects to ensure they stay integrated and to guard against a problem in one sub-project cascading into all of the others.

Tools and techniques that are used by project managers to aid in communicating start with theCommunications Plan. To develop a communication plan, a project manager will often do aCommunication Technology Assessment. Of course, aTeam Listshould be developed. Naturally, I recommend that when conducting a meeting - use good presentation skills, when composing a message - use good writing skills, when having a face-to-face encounter - use good interpersonal skills. However, these are not unique to projects so I am trusting you can get help on these from your Human Resources or Training department and you don't need me for that. I will stay focused on the parts of communication that are unique to project work.

The PMBOK includes Stakeholder Management activities in its communication chapter. I have placed the stakeholder management activities inProject Initiationand Project Controllingpages. Although those activities entail communicating, they are so integral to Initiating and Controlling that I felt it was better to address them in those sections.

Before I start to discuss the communicating tools, there are two topics I would like to address. The first is the understanding of a "Sender - Receiver" model. Whenever information is being communicated, it is translated from the sender's mind into a message and then from the message back into the receiver's mind. There are opportunities for misunderstanding in both translations, and for noise and errors to be introduced during the transmission of the message. That is why I believe every project leader needs to focus on communication. Since project work is often new or unique, the chance for misunderstanding is even greater. There is no established pattern or expectation. I strongly encourage the habit of "Repeat it back." for all project communication to minimize misunderstanding.

The second is the recognition that listening is a three step process. If a team member does not seem to be listening, it is important to understand which step of the listening process is the issue. The three steps of listening are: 1) hearing, 2 understanding, and 3) judging. The Hearing step is just that. The actual receipt of the message. Team members who "aren't on the call" will not get the message. For virtual team members you may need to create special channels of communication to ensure they actually hear the message. The Understanding portion of the listening process is the team member translating the message into desired actions or changes to the project. Team members who do not understand the acronyms or whose native language is different than the normal language of project communication may hear the message that is being sent but not understand what it means. To determine if this is the problem, the project leader will need to have a directed conversation with the team member and ask them what they think the message is telling them to do. The third listening step is judging. In this step the team member hears and understands the message and then decides whether or not they believe it applies to them and their project work. When this is the breakdown in listening the project leader will need to spend time with the project team member to determine either why the message does not apply in this special case or to explain to the team member why the message does apply to them.

Project Communication Plan

Every project manager uses a Project Communication Plan. Many project managers do not consciously develop one, instead they embrace one that has been imposed upon them from a previous project, they follow a procedure instituted by the PMO, or they conduct their communication in an ad hoc fashion. That is an approach for developing a plan - not a very good one - but an approach. I recommend that a conscious decision is made as to what communications need to occur for a successful project. I typically consider four categories of communication. All four types are not needed on every project, but they are typically found and should be planned for.The first category I consider is management meetings. This category is often an extension of the Communication Strategy for stakeholders that I discuss in the Projectpage. For this category, consider which managers need or want information, the frequency they need or want it, and the content detail. Major communication sessions with stakeholders, such as technical reviews that I discuss in theProject Controlpage are often reflected on the project schedule as milestones and should be included in this portion of the Communication Plan. The management meetings should be planned and proper preparation conducted. Some of these are face-to-face meetings and some are conducted using an electronic medium. A poor management meeting jeopardizes support for the project and reflects badly on the work of the project team.The second category of meeting is the project team meetings. Depending upon the size of the project and the team, these can be short ad hoc conversations, conference call updates, email chats, formal pulse meetings, or a variety of other communication approaches. Regardless, these are where the project manager is able to track the day to day work of the project and resolve issues while they are still small. The third category I like to consider is management reports. Many organizations require project managers to provide periodic reports for the management team. Often these are reviewed by managers who are not direct stakeholders in the project. These reports need to be able to stand alone in describing the project and its status. A project manager cannot assume the reader is familiar with the goals or risks in the project. That is why it is important to use the standard template or format the organization suggests/requires. The standard template guides those who are not familiar with the project to the areas of the project report that they are concerned with.The final category that I consider is project records. These are the method that the project team uses to communicate to the future. Whether the future is the business team members who use the project deliverables to implement business strategy, the next generation project, archives for litigation, or records for lessons learned, the records need to be complete enough so that whoever is reading them after the project has completed will be able to understand what has happened.

Communication Technology Assessment

The type of communication technology used by the project manager will vary based upon the organizational constraints of the project team and stakeholders. Factors that influence the technology include whether the team is co-located, the confidentiality of any information that needs to be shared, and communication facilities available to the team members, and the organization's culture for how meetings and discussions are normally conducted. Some technologies lend themselves to large group interactions and others are more appropriate for one-on-one discussions. The table below provides an assessment of the advantages and disadvantages of different communication technologies for use in a project environment.

Project Team List

The Project Team List is a list or database with all project team members and their contact information. This includes the core project team members and extended team members. I typically will also include key stakeholders on this list. The list is provided to team members to aid communication. I want project team members to know who to call when they have a question or an issue arises. The list can be maintained in as a spreadsheet, a word document, a file for your email server, a contact list in your project room, or any other mechanism that is a normal resource contact management system in your organization. One caution about the list, I provide business contact information, but not personal information. In this era of identity theft and the increase of "creepy people" I try to protect the team member's privacy as much as possible.

Project Risk Management Tools & Techniques

Project Risk Management is the process or activities associated with identifying risks, analyzing risks, developing appropriate responses to risks, and monitoring risk triggers. Risk management is a primary role of the project manager. While other project team members will be involved in all of the Project Risk Management processes. It is the responsibility of the project manager to ensure that risk management is done and that risk triggers are being monitored.

The PMBOK has defined Risk as, "an uncertain event or condition that, if it occurs, has an effect on at least one project objective." The objectives are identified during project initiation and include the major elements of scope or deliverables, key milestones, budget constraints, or any other aspect of the project identified as a key success criteria by the stakeholders.

Risks can be positive or negative. Typically we focus on negative risks, and these are the ones that are likely to result in project failure. However, there are positive risks which are opportunities for the project team to perform better than required on at least one of the major objectives. In my experience, positive risks, referred to as opportunities, must be identified early in the planning processes to take advantage of them in the project. Otherwise the cost and schedule impact of changing the plan will typically outweigh the benefit. Negative risks, referred to as threats, can be avoided if addressed early. However, these must be monitored and tracked throughout the life of the project.

The process of project risk management typically is viewed as a five step process. The first step isRisk Identification. Next isQualitative Analysisand, when necessary, Quantitative Analysis. Once analyzed,Risk Responsesmust be developed for those risks that require them. Finally,Risk Monitoringmust be done for those risks that require ongoing monitoring. I prefer to manage this process using aRisk Register.

Risk Register

The Risk Register is a spreadsheet that tracks the management of risks, both threats and opportunities, through the project lifecycle. The register not only aids the project manager in the process of risk management, it creates a document for archiving with the project files that can be used for Lessons Learned and a historical record.

The Risk Register is structured so that each row is a risk and the columns track information associated with the various risk management processes. The precise columns you use are a matter of personal preference. I like to have columns that identify the risk and where in the project the risk will have an impact. I then have columns indicating the results of qualitative analysis and quantitative analysis. I also have columns showing the selected risk responses and the status of any mitigating actions or the risk triggers that are being monitored.

Risk Identification

In order to do effective risk management, you must start with risk identification. That sounds really "Duh," but I have set in many project reviews and asked questions about the risk identification process only to find that it was never done. Instead someone copied the risk list from a previous project and started working with it, even though many of the items did not apply to their project.

There are many ways to identify risks and if your organization has a standard approach that works, use it. When there is no standard approach, my preferred method is to use a variation on the Fishbone or Ishikawa diagram. I start with a major project impact such as, "major schedule delay" or "test failure." I then try to identify all the possible reasons why that might happen on this project and document those in the bones of the Fishbone. I normally will do several of these diagrams, one for each major project impact. I will do these for both project threats and project opportunities. For instance, I might have one for, "Early completion" or "Major Under-run." All of the items that are listed then are transferred to the Risk Register for further analysis.

Qualitative Risk Analysis

Once the list of potential risks has been developed, the next step is to analyze them. This can look to be a daunting task if there are many risks. Therefore, the first step in the analysis is to filter the risks to determine which the significant risks are and which are insignificant. There are many techniques for this and they are known as qualitative risk analysis. I will discuss three of my favorite, the red-light/green-light rating, the risk matrix, and the urgency assessment.The red-light/green-light rating is a subjective assessment of whether the risk will likely have a major impact on the project. The risks are divided into three groups, one is "red" risks, one is "yellow" risks, and the last is "green" risks. The thresholds for these categories can be based upon the cost impact, the time impact, the quality impact, the probability of occurrence, or a combination of these. I normally view the "red" risks as those that are likely to occur and will significantly impact one of the project objectives. These risks must be addressed; usually with an immediate change to the project plan. The "yellow" risks are those that may have a major impact on the project, but that I believe we can manage through with the current plan. However, they are serious enough that they are watched closely. The "green" risks are those that either are insignificant or they are risks that were once "red" or "yellow" and have now been mitigated.

The next approach for qualitative risk analysis that I use is the risk matrix. This matrix can be setup as a 2x2, a 3x3, a 4x4, or a 5x5. What size you use is based upon personal preference. The vertical side of the matrix is labeled probability and the horizontal side is project impact. The scale on the matrix goes from low to high on each side. How low or high are defined should be based upon the major objectives of the project. Once the matrix is created, I place each identified risk on a post-it note and then locate the risk in the appropriate spot on the matrix based upon the likelihood of that risk happening on this project and the impact to the project objectives if it did occur. The risks in the upper right corner are major risks that must be addressed in project planning. The risks in the lower left corner are minor risks and can be ignored. The third approach for qualitative analysis I use is an urgency assessment. In this analysis I consider when in the project the risk must be managed. Some risks do not have the potential to occur until late in the project, others would occur early, and still others could occur at any time. The urgency assessment identifies anything that is an immediate issue for the project management team and which risk issues are not yet in play.

Quantitative Risk Analysis

Quantitative risk analysis are techniques that attempt to quantify the project impact of the risks. These techniques are generally much more complex than the qualitative techniques and therefore require much more time and effort to complete. I find that if I do the qualitative techniques first, I then can focus my quantitative techniques on just the few high risk items. These are the items that are most likely to require a significant amount of project management effort and possibly discussion with stakeholders to address threats to boundary conditions. Prior to the stakeholder meeting, I like to have a quantitative analysis done so that when I meet with stakeholders we can focus our discussion around the business impact of doing nothing as compared to doing something. The following is the list of quantitative techniques I recommend.Sensitivity Analysis - in this technique the project plan is developed without the risk factor occurring and then the risk factor is introduced and the plan is redone with the risk impact in place. This provides a demonstration to the stakeholders of why the risk is important and needs to be addressed. Failure Mode Effects Analysis (FMEA) - this technique is excellent for addressing technical or quality risks. It is not very effective for addressing cost or schedule risks. However, since the risk is quantified based upon safety and security issues, it can be very useful for explaining why a change in project requirements is needed.Decision Tree with Expected Monetary Value - this technique can require a significant amount of time to set up, but once established it can easily be reused as project assumptions start changing and the project is forced to react to the changing circumstances. The decision tree shows the impact of decisions and risk events on project activities and the expected monetary value quantifies those impacts.

All of these techniques require hours and possibly days to complete. There are other quantitative risk techniques, however, I find that they are even more time-consuming and expensive. The results of the other techniques are typically no better than the ones listed above.

Risk Response Techniques

Based upon the analysis, some risks will require a response in the project plan, some will only require a response in the project monitoring, and some will not require any response at all. If a risk is deemed to be high, it needs a response. Responses to negative risks - threats, are one or a combination of these five responses: Avoid - the project plan is changed so that it is impossible for the risk to occur because the project is never susceptible to that type of risk. Some risks cannot be avoided.Mitigate - the project plan is changed so that when or if the risk occurs it will only have minor effect because the threat has been anticipated and provisions for addressing it are in place. Transfer - the project plan is changed so that an outside agency assumes responsibility for addressing a portion of the risk impact. Accept - the project plan is not changed because the risk is so insignificant or the risk is so improbable that no change is needed.Contingency Plan - the project plan is not significantly changed, although a risk trigger is established that can be used to indicate whether the risk will occur and if so in what fashion will it impact the project. If possible a "Plan B" is developed, or at least has been considered. If the trigger occurs, the "Plan B" is put into effect and the project is changed at that time.

There are also five possible responses for positive risks - opportunities. In almost every case, these opportunities must be identified early in the project if there is to be any hope of realizing the positive benefits they entail. The five responses to opportunities are:Exploit - the project plan is changed from the normal approach for this type of project to take advantage of the unusual condition that is occurring.Enhance - the project plan is changed so as to create an opportunity for improvement in the ability of the project to achieve one of its objectives. Share - the project plan is changed so as to bring an outside partner onto the project that creates opportunities to improve one of the project objectives. Accept - the project plan is not changed because the opportunity is so small or so unlikely that the risk of change creates a negative risk outweighing the opportunity.

Contingency Plan - the project plan is not significantly changed, although a trigger is established that will provide notice that an opportunity is now available to improve on one or more of the project objectives.

It is important to note that in the absence of choosing to do something different, the "Accept" option will apply to any threat or opportunity. If "Acceptance" is not appropriate for the risk, action must be taken to either change the plan or to begin monitoring the risk trigger.

Risk Monitoring and Control

Risk monitoring is much of what a project manager does once a project moves beyond the planning stage. As project activities are being accomplished, the project manager should be tracking the risk triggers to see if any project changes are needed. The risk triggers should be listed on the team-level project dashboard. In addition, I revisit the risk register whenever a project goes through a re-planning and at major Management Reviews to determine which risks have been eliminated and to add new risks to the register.

I also use the risk register to document the result of risk monitoring activities. The risk register tracks the status of project changes or mitigations that have been initiated to address risk issues. The risk register also captures the impact of mitigating actions for those risks that are mitigated.

The Mitigation Plan could be:You take one car along, someone follows you, and in case there is any problem in the car you are traveling you change the car.The Contingency Plan could be:You keep some buffer time and if something happens to car tires, you change them and since you have timed buffer you still reach on time.

Differences

Risk Mitigation PlanRisk Contingency Plan

You identify actions which you will take in advance irrespective of the occurrence of riskYou plan actions, but you monitor certain warning signs. You take these actions only when you see the warning signs.

You spend time and money in advance for the given risk conditionYou do not spend time or money in advance, but you keep them ready, and invest them when needed

We are expected to mitigate the risks which are outside the risk threshold. By applying a mitigation plan, we reduce the probability of impact of the identified risk.By identifying the contingency plan, we do not change the probability or impact of the current risk, but we plan to control the impact as risk event looks like occurring.

This works as the first level of defense for the high exposure risksThis works as a fallback plan for the high exposure risks.

Conflict ManagementConflict is a situation which arises when a person or a team is not in agreement with other person or team. In other words, conflict is due to differences in opinion between teams or individuals, and if not resolved in time with the information backed with their common goal, may result in unwanted/unpleasant storm of ego and personality clashes at workplace.Conflicts are unavoidable but can be minimized by following ways but not limited to: Communicating role and responsibilities to all the team members. System should be designed in a way that is sufficient enough to keep the team and other relevant stakeholders informed about priorities and current situation transparently.People work together as per assigned priorities, but the lack of communication between them related to continuous changes or facts in environment, forms the basis of conflict. For example if a team member is redeployed to another work as a response to an occurred risk, and if it is not communicated properly, it may result in risk.What information can prevent conflict, can be visualized as following:WHENPrimary reason of conflict is when (time), when are we getting this deliverable?

WHATAfter time comes what (priority), which task is most important?

WHOThe third possible dimension of conflict would be who, who will work on this area?Few team leaders would be asking for same resource as they believe that this particular resource is most capable.

HOWThen comes how (options) what kind of design or methodology should we use?

LIKELastly like, a person do not like another person. Personality should be the least important reason for conflict.

PROBLEM SOLVING or COLLABORATE (Win-win) -This method is preferred when team members are comfortable with each other, they trust each other and working together for the common goal. Here the Project Managers intervention is required to only remind the team what is needed to bring things on track.

COMPROMISE (Lose-Lose) When relationship between the parties is really important, stakes or differences are not very high and time is less, this method of resolution is preferred. Both the parties are losing something for their common goal in order to work their relationship.In Compromising a middle path is chosen as a resolution.FORCE (Win-Lose) -In forcing technique, solution is forced to the people who are involved in conflict. This method is good when relationship is less important compared to very high stakes or differences. An authorized person may enforce the resolution in such situations. In case time is less to go into details, this technique may be used. Later on, it is recommended that you communicate why the resolution is taken.Sometimes forcing is also used to ensure compliance of rules.SMOOTH or ACCOMMODATE Smoothing works well when people believe in working with each other differences between them are not much severe and few points exist among them, which are in agreement. Here focus on those agreements is used to resolve the conflict. However, it does not develop permanent solution always.WITHDRAW or DO NOTHING Method is used when you give up on the situation, due to high level of storm within the people who are in a conflicting situation. Sometimes you need time to bring the condition in control and/or to take preliminary steps before you come up with a viable solution.