Managers often will want to know why we should undertake a certain project. You boss will often want to see benefits from the work to themselves and their area of responsibility. Improving revenues and reducing costs would generally be on agenda. Savings and improved efficiency is highly desirable generally.
Making a business case of a project requires setting out the reasons for the project. It is all about, why it is worth undertaking.
So, what metics can be used to assess validity of a project?
For this, a number of mathematical methods can be used, such as Net Present Value (NPV) , Internal Rate of Return (IRR) , Cost Benefit Analysis and Payback.
Cost Benefit Analysis
In Cost Benefit Analysis we follow 3 simple steps:
Calculate the cost of the project
Assess the benefits in financial terms
Compare the totals
To generate the cost benefit ratio you can also divide the total benefits by the total cost. The bigger the ratio the better.
Assessing the benefits in financial terms can be a difficult task. The project might include some intangible benefits ( for example, improved decision making, better staff morale, stronger brand) and it is not possible to quantify such benefits.
The analysis of projected revenues can also take no account of time. Therefore there are "hard" and "soft" performance measures. Hard measures are those which are straightforward to assess in economic terms. Soft measures are the definite benefits and not easy to assess in financial terms.
We must, therefore take the best shot in converting intangibles into financial terms, even if little evidence is available. For example, estimation of staff morale increase of 5% per annum.
It is also possible to assess the intangible benefits in non-financial manner. For example a survey could be used to assess the aspect of customer or employee satisfaction on a scale 1-5. The stray could be repeated to examine changes.
Any aspect, however, which is reasonable easy to count is considered as a "hard" measure. Some "soft" measures can also be critical to the business, only that they are difficult to quantify.
Project Planning
Someone said to me once that "you can't schedule creativity" and that might be a good point. But, we must pretend we can because no-one will fund the project unless we put a time to it. However, when people are required to plan a project, they find it extremely painful.
There is even a pain curve model develop in project management.
Source: https://www.oreilly.com/library/view/effective-project-management/9781118016190/ch005-sec001.html
The project with a good plan has a higher chance of finishing successfully, within the scope, quality and time.
The project manager must resist the pressure to start the project now and take time for planning, however painful. Even the level of detail may seem as an overkill, but it is not. Plan, not details enough suffers too. The curve presents that proper planning can be painful, but it saves time and money.
We must have a plan to know where we supposed to be. Without plan, we cannot possibly have control. Therefore, planning is not optional.
We must ask ourselves the questions:
What must be done?
How it will be done?
Who will do it?
By when?
How much does it cost?
How good it must be?
The below should always be included in project plan:
Problem statement
Project mission statement
Project objectives
Project work requirements, including the list of all deliverables, such as hardware, software, reports. Often deliverables come with major project milestones so that the progress can be measured more easily.
Exit criteria - each milestone should have criteria established that will be used to determine whether the preceding phrase of work is actually finished.
End-item specifications are met - engineering specifications, architectural specs, building codes, government regulations,
Work breakdown structure - this is the identification of all the tasks that must be performed in order to achieve project objectives
Schedules and milestones
Resources needed - people, equipment, materials
Control system
Major contributions
Risk areas with contingency where possible
Once the plan was prepared it should be submitted to stakeholders for approval. This means that the stakeholders are committed to the contributions, agree to the scope and the schedule.
It is also rather unrealistic to keep the same plan. Plans change. Unforeseen changes are almost certain to arise.
Changes should be made only if significant deviation occurs. A significant change is usually specified in terms of percent tolerances relative to the original target. If changes are not managed properly the project may come considerably over the budget and/or behind schedule.
It is always difficult to get people together to develop a plan. Planning meeting agenda must be prepared and meeting should be time limited to the degree possible. If someone goes out of track, the facilitator should get them back on track. The people who will be executing the plan should be involved in preparing it as this assures commitment. We also must be prepared for replan. We should, therefore not plan too much details if there is a likelihood that the plan will be changed. Always conduct risk analysis of most possible unexpected events that may affect the plan. We can develop Plan B in case.
The simple question to risk analysis would be "What could go wrong".This should be done for all the parts of the project plan, including the schedule. If some risks are not possible to avoid, prepare back up plan. Do not go into "analysis paralysis" here. Only consider the risks that are likely. And finally, use Work Breakdown structures to divide the work into smaller chunks for which you can develop accurate estimates for duration, cost and resource requirements.
The Basic Project Planning Steps are:
Define the problem to be solved by the project,
Develop a mission statement followed by statement of general objectives,
Develop a project strategy that will meet the objectives,
Write a scope statement to define boundaries,
Develop Work Breakdown structure,
Estimate accurate duration, resource requirements and costs,
Prepare the project master schedule and budgets,
Decide on the project structure,
Create the project plan,
Get the plan signed off by the project stakeholders.
There are some key things to remember from this article.
If you have no plan than you have no control. The people who must execute the plan must participate in preparing it. The plan should be signed off in a meeting and not through e-mails. Keep the project documentation in an electronic file. Determine when milestones have actually been achieved. Ensure that changes to the project are approved before you make them. Risk management should be part of all project planning.
Mission, Vision, Goals and Objectives
Before the project team will start any work, we must ensure shared understanding. The terms defining the destination are generally "mission", "vision", "goals" and "objectives".
Every project solves a problem of some kind. A big mistake is to skip over the definition of the problem. The way we define the problem will determine the way we will solve it.
The mission is always to achieve the vision. The vision, is, however, the one that customer holds and you are trying to satisfy customer needs. That is your primary objective. You must, therefore know what the needs are and it is not easy. So you must translate and interpret them the best you can. You need to keep the customer involved in the project. The mission is answering the question "what" we are doing.
Only once the mission statements have been defined, we can develop the project objectives. The objectives must be specific and define desired results. The way we achieve the objectives is by performing a number of tasks.
According to Deming if a system is stable than there is no need to specify goals, since we will get whatever the system can produce. On the other hand, if the system is not stable, than again there is no need to specify quota, because there is no visibility of the system capabilities. Unless, we have a large number of sample, we cannot know what we can achieve.
Assessing Risks
Once we have established the objectives, we can develop plans. Unfortunately, the best plan sometimes do not work. It is therefore important about the risks that can sink the job. It is good to list the risks and think about contingencies - things we can do to manage those risks. It can help us to advert the risk, and if not possible, develop a back up plan. We should not try to identify every possible risk, just those ones most likely to happen.
Many project managers tend to address risks on informal basis with little or no prior planning.
A formal and comprehensive project risk plan allows to be proactive. Therefore, a clear understanding of the risks that face the project must be established. Typically, examples include loss of key team members, weather emergencies, technical failures and poor suppliers.
We should avoid the trap to delay risk assessment, thinking that we don't know enough at the early stage of the project. During the initiation stage, risks should be assessed on what could go wrong. This way, also potential opportunities are identified - positive risk. Variation often involves inefficiencies, therefore it is important to manage risks formally.
Step 1: Make the list - the project team should brainstorm on all the possible failures. Certain amount of research might also be involved, including phone calls, videoconference. The list should be as wide and holistic as possible.
Step 2 and 3: Determine the probability and negative impact. Here we deal with the prioritisation factors. We can determine how much time, money and effort should be made to prevent and mitigate those risks. It is always useful to use the HIGH, MEDIUM, LOW scale and apply to the risks. We need to consider how badly the risk will affect scope, budget. timeframe, resources if it becomes reality. As we rate the probability of the impact, we can add the value of the risk. The probability can be based on scale 1 to 10 ( 1-unlikely and 10 - very likely).
Step 4: Prevent or mitigate the risk. Some risks can be prevented and some mitigated. If we have the ability to prevent this risks, we should do so.
Step 5: Consider contingencies. Preventive measures are the steps taken before the risks become a reality. Contingencies are the specific actions that will be taken if the risks occurs.Contingencies are directly linked to priority factors. If the risks (probability and impacts) are high, we probably want to implement few contingencies. If the risk falls in the MEDIUM scale, we should establish at least one contingency. The ones with low risks, should not require much attention, but we need to put efforts elsewhere, where the risks are high.
Step 6: Establish the trigger points. These can be the most important elements of a project plan. There is a direct link between the trigger points and contingencies. Trigger point, is the point when the risk becomes enough to reality that we need to trigger the contingency. If we trigger too soon, we waste resources. If we trigger too late and we may be experiencing the full impact of the risk. The trigger should be a specific point in time or a defined range of time.
Reserves
A most comprehensive risk plan can be compromised if we realise that we do not have the time or means to take appropriate action. Contingency reserves are the designated amounts of time or budget to account for risks to the project that have been identified and actively accepted. They are in place to cover known risks to the project. Once the six steps of the risks are identified we should establish the reserves to cover the risks that have been identified and accepted.
Management reserves are designated amounts of time and/or budget included in a plan to account for risks to the project that cannot be predicted. Management reserves are created to cover unknown risks of the project.
Many managers also find themselves managing more than one project. This is because, many projects overlap or experience direct dependencies with other projects. It is important, however, to focus on individual projects and associated risks of each. Than, we can assess the entire portfolio and dependencies between the projects. The portfolio is the sum of all projects. A program, typically involves multiple projects working towards completion of a single deliverable. If you identify where the projects overlap you can determine what might go wrong.
The areas where projects touch are called coordination points. The Six step risk process should also apply to those coordination points as well as each project individually. When managing many risks, therefore a risk matrix is helpful.
Once the wreaths have been plotted onto the risk matrix. The prioritisation can be applied where the highest priority risk are positioned to the upper right corner and lower priority ones towards the lower left.
A Risk Register is also a helpful tool of managing the actions taken regarding accepted risks to the project. A risk register is a last ingredient of the project risk plan. It can help to track a risk status as the project matures throughout its lifetime.
Project risk assessment should begin early in the process and continue throughout the life cycle. We need to be proactive and not reactive. We need to manage the risks formally and be flexible. Establishment of contingencies and management reserves enables to leverage project to its fullest potential. Coordination points must be identified to analyse the multi project risk environment.
Work Breakdown Structure
Projects often fail because a significant part of the work is forgotten. Once the tasks have been identified the time and resources must be determined. This is called estimating. It is often challenging to determine how long tasks will take and the cost of them. Inaccurate estimates can lead to project failures, over budget and cause stress in project management.
The Work Breakdown structure can be, therefore, a very useful tool. It relates to subdividing larger tasks into smaller tasks. This way, it is easier to estimate how long a task will take and how much it will cost. In the WBS, we do not worry about the sequence in which work is performed. That will be worked out when we develop a schedule. The main idea is to capture all of the tasks. A typical WBS has 3 to 6 levels. A general guidance is that you stop breaking down the tasks when you can estimate the time and cost to the desired degree. It might be as detailed as to the desired day. But you might want to break it down to the desired hour. Remember, that people who do the work must participate in the planning. WBS should be developed before the schedule. It allows the manager to gather the resources, estimate the time and costs and show the scope in a graphic form. Super Project Expert TM software can be utilised to do so. To develop a WBS we generally go top-down, following a development of problem statement and mission statement.
A WBS can be a good way to describe the scope of the job. When you show a project in WBS form it is generally clear on to why a job cost so much.
Assigning responsibility is another important use of WBS. Responsibilities charts are use than to assign the tasks to relevant persons.
Estimating Time, Cost and Resources
Once the work is broken down we can estimate how long it will take. However, you cannot do time or cost estimate without considering who will perform the task. We should also try to estimate the time based on historical data. Generally we use average time to plan projects. Naturally, when we take average, the tasks take longer. We also have to understand "variation". We can not get rid of a variation, but we can reduce it through changing the process. But we must understand and remember that variation will always be there.
In order to estimate correctly we should:
- show the percent tolerance that is likely to apply,
- tell how the estimate was made and what assumptions were used,
- specify any factors that may affect the validity of the estimate.
In recent years, a new method of estimating knowledge was developed - consensual estimating. Rather than have individual estimated task durations, the new method asks at least three people to estimate each activity in the project that they know something about. They do this without discussing their ideas with one another. They than meet to find out what they have put on paper. There may be discrepancies, of course. For example: 10 days, 12 days and 30 days. To handle this it is important to ask each person what they were considering when making the estimates. Then, they all come out with one number which they can support. This is called "consensus". More people, can make more considerations than one person. Therefore, we are more likely to get the most accurate estimates. We should always record the time of tasks finished. Otherwise we will never get bettie at estimating.
Scheduling Project Work
A project is a problem scheduled for solution. The primary reason for scheduling is to ensure that the deadlines can be met.
Critical Path Method (CPM) determines critical path in a project of a scope or priority change. You will know which activities will be impacted most heavily and what will need to be done to regain time.
Critical path is the longest path through the network and determines the easiest completion of project work. A good rule of thumb is that no task should be completed later than four to six weeks later. A twenty-six week can be divided into few four week tasks which keep us more on the schedule.
We can schedule work in two ways. One is to begin at the end and work back until you arrive at the beginning. The second is to start at the beginning and work towards the end. First, we need to decide what can be done first. Sometimes several tasks can start at the same time. You simply draw them side by side and work from there.
Another rule is to keep time in the same increments. Don't mix hours and minutes. It is good to draw network on paper first and check for consistency before entering anything into the computer scheduling system. If the network has logical errors the computer will give you the "garbage-in, garbage-out" result. Sometimes it is also important to remember that there is no single solution to a network problem.
The next step is to try to figure out how long it will take to do the job. Time estimates for the job are made using the history. The estimate is only valid for the individual who will be performing the task.
Once the network has been drawn with duration activities, it is necessary to determine where the longer path is in the network and see whether it will meet the target completion date. Since the longest part through the project determines the minimum project duration, any activity on that path that takes longer than planned will cause the end date slip accordingly. This path is called critical path.
First consider what we want to know about the project. If start time is "zero" we want to know how long it will take to be finished. That is, the end date is dictated. In reality, we are generally told when the work must be finished. Whatever the case, we still want to know how long the project will take.
The first step in network computations is to determine where the critical path is in the schedule. There are two network rules:
Before a task can begin, all tasks preceding it must be completed.
Arrows denote the logical order of work.
We need to try and stay on schedule. It is always harder to catch up than to stay on target to begin with. Keep float in reserve in case of unexpected problems or bad estimates. Apply whatever effort is needed to keep critical tasks on schedule. If a task on a critical path can be finished ahead of schedule, do it! Than start the next task. Avoid the temptation to perfect everything, because that's what next generation product or service is all about. It is not ok to do the job sloppily or we shouldn't do our best work. Simply, do not try to be perfect. In definition, we will never reach perfection. Estimates of tasks are made on the assumption that certain people will work on these tasks. If someone else is actually used, you may need to adjust duration accordingly. This is especially true of the person is less skilled than the intended resource. No task should be scheduled with a duration much greater than four to six weeks. If we do, people tend to have a false sense of security. If a task has a duration greater than six weeks, it is a good idea to subdivide it. If the people doing the work did not developed the network, explain it to them and show the meaning of float. But you may give them a bar chart to work through as it is easier to show.
It is also possible to shorten the task by adding resources, reducing its scope, doing poor-quality work, being more efficient or changing the process by which the work is done. With the exemption of doing poor-quality work all other methods may be acceptable. Reduction in scope must be negotiated with your customer.
Scheduling is done initially on the assumption that you will have the resources you have planned on having.
While an arrow diagram is essential to do a project analysis of the relationships between activities during the project, the best working tool is the bar chart. The people doing the work will find it much easier to see when they are supposed to start and finish their job.
A major factor when dealing with resource allocation is the availibility of each person to do the project work.
Control and Evaluation
Being in control of the project is expected of the project manager. It is to manage business resources the way so that business objectives are achieved. Having authority will not guarantee that you will be able to get people to do the project work. We must understand the motivations of people so that we can influence them. Control in project is the act of comparing progress to plan so that corrective actions can be taken when a deviation from planned performance occurs. To control here, we use information.
Ultimately, in order to control the project is for every member of the project team to be in control of his own work. We should not practise micromanaging. We can set the conditions under which each team member can achieve control:
A clear definition on what they are supposed to be doing with the purpose stated.
A personal plan on how to do the required work.
Skills and resources adequate to the tasks
Feedback on progress that comes directly from the work itself
A clear authority to take corrective action when there is a deviation from the plan
Every team member must be clear about what their objective is. The second requirement is for every team member to have a personal plan on how to do the required work. The third requirement is that the person have the skills and resources needed for the job. The need for resources is obvious, but the person might have to be given training if they are lacking necessary skills. In no team member is available with the required skills it might be necessary to have the team member trained.
The fourth requirement is that the person receives feedback on performance that goes directly to them. The fifth condition is that the individual must have the clear definition of the authority to take corrective action when there is a deviation.
The control system must focus on project objectives with the aim to ensure that the project mission is achieved. To do that, the control system should be designed with these questions in mind:
- What is important to the organisation?
- What are we attempting to do?
- Which aspects of the work are most important to track and control?
- What are the critical points in the process at which controls should be placed?
Control should be exercised over what is important. On the other hand, what is controlled tends to become important. Project managers must monitor performance quality carefully to ensure it does not suffer.
A control system should focus on response - if control system does not result in action, than the system is ineffective. That is, if the control system does not use the deviation data to initiate corrective action it is not a control system, but simply a monitoring system. Being in control should not mean going into panic mode and micromanaging.
The response to control data must be timely. If action is taken too late it will be ineffective. This is frequently a serious problem. Data on project status are sometimes delayed from four to six weeks. Ideally, information on project status should be available on a real-time basis. In most cases that is not possible. For many projects, status reports prepared weekly are adequate.
Ultimately, you want to find out how many hours people actually work on your projects and compare that figure on what was planned to them. This means that you want accurate data. As difficult as it might be you need people to record their working times daily so that the data mean something when you collect them. Perhaps nothing. Perhaps future estimates will be better.
When information collection is delayed for too long, the manager may end up making things worse.
There is one point about control that is important to note. If every member of the project is practicing proper control methods, then reports that are controlled weekly are just checks and balances. This is a desired condition.
One control system is not likely to be correct for all projects. It may need to be scaled down for small projects and scaled up for big projects. The smallest control efforts that achieve intended results should be used. Any control data that is not essential should be eliminated. However, it might be a mistake to try to control complex projects with systems that are too simple.
To keep control simple, it is a good idea to keep periodically that reports which are being generated are actually being used for something by the people who receive them. We sometimes create reports because we believe that the information in them should be useful for others, but if the recipients don't actually use it, we are kidding ourselves. You might want to test it by sending a memo whether people want to receive future reports, if you don't hear from them their name will be removed from the distribution. You might be surprised that no-one uses some of your reports. Those reports should be dropped completely.
Review meetings
Maintenance meetings keep the projects on track. There are also improvement reviews which try to improve the project performance. These are:
Status reviews
Process and lessons learned review
Design reviews
Everyone should do status and process review. Design review are only appropriate if you are designing hardware, software or some sort of campaign, such as marketing campaign.
A status review is aimed at maintenance. It asks where the project stands.
To evaluate a project is to attempt to determine whether the overall status of the work is acceptable in terms of intended value to the client once the job is finished. Project evaluation approves the project performance in terms of results for the client. The evaluation provides the basis for management decisions on how to proceed with the project. The evaluation must be credible in the eyes of everyone affected, or decisions may not become valid. The project process review would be the primary tool.
The purpose of the review is to learn lessons that can help the team to avoid doing things that bring undesired outcomes and to continue doing those that help. Historically, an audit has been used to catch people doing things they shouldn't have done so that they can be penalised in some way. If you go around auditing people, be sure that they will hide from you anything they do not want you to know and those things that help company grow will be hidden. We have to improve every department and good project management will help with it.
A good project management can give a real competitive advantage, especially in product development. If you are sloppy managing projects you create unnecessary costs. In order to learn, people require feedback. The last phase of the project should be final process review conducted so that the management of projects can be improved. However, such a process review cannot be conducted at the end of the project. Rather process review should be done at the major milestones in the project, or every 3 months whichever comes first, so that learning can take place as the job progresses. Furthermore, if the project is getting into further trouble, the process review should catch the difficulty so that the decision can be made to continue or terminate the work. The main reasons for conducting periodic review are:
- improve project performance and management
-ensure that the project quality is on track and track costs
- review development issues early so that actions can be taken to battle them
- identify areas where other projects should be managed differently
- keep customers informed on the project status
- reassure the commitment to the project
Ideally, the project process review should be conducted by an independent examiner, who can remain objective in the assessment of information. However, the process review must be conducted in the spirit of learning, rather then the climate of blame and punishment. If people feel that they will be punished for problems, they will hide them. Even so, openness is hard to achieve. Unfortunately, by hiding we will review ineffective practices. They may save their face, but stop organisation from learning. The results of the review should also be published.
The Process review report
Process reviews can vary from comprehensive to less formal. A formal review should be followed by report. The report should contain the below as minimum:
Current project status. The best way to do this is to use the "value analysis".If the "value analysis is not used, the current status should be reported as currently as possible.
Future status. This is a forecast of what is to be expected next in the project. A significant deviations in the schedule, process or scope? If so, the project should specify the changes.
Status of critical tasks. The report should state the status of critical tasks, particularly those on the critical path. Tasks that have a high level of technical risks, should be given special attention and those being performed by outside vendors or subcontractors.
Risk assessment. The report should mention any identified risks that could lead to monetary loss, project failure, or other liabilities.
Information relevant to other projects. The report should describe what has been learned from this process review and can or should be applied to other projects, whether in progress or about to start.
Limitations of the process review. The report should mention any factors that affect validity of the process review. Are any assumptions suspect? Are any data missing or perhaps contaminated? Was anyone uncooperative in providing information for the process review?
The simple and more straightforward process review, the better. The information should be organised, so that both planned and actual results can be easily compared. Significant deviations can be highlighted and explained.
Summarising, the meaning of control is important for project managers. They need to use the information, compare the progress to the plan so that actions can be taken to correct from deviations from the plan. The best way to control the projects is when all their team members are in control of their won plan. The effort put in place to control projects should be worthwhile. If we take no action in response to deviation, we only monitor and do not control. Project working times should also be controlled and recorded daily. If people wait weeks to capture what they have done, they rely on memory and end up writing estimates.
The Change Control
The most comprehensive project plan will be wasted if some methods of controlling change is not implemented. When issues are found when project is being performed, change requests may modify project policies and procedures, project scope, costs or budgets, project schedule or project quality. If you do not keep the plan current, you have no plan. Change control is not easy and includes variables, judgment calls and sign offs. If left unchecked, changes to the projects may result in imbalance, regarding scope, schedule and budget. As changes occur you gain the ability to gauge overall impact on the project and react accordingly. The project must be updated accordingly and distributed to the stakeholders. We also need to determine appropriate communication paths, level of data dissemination and general guidelines for the project team.
As things mature and grow, changes occur naturally and are often positive and welcome. If issues occur and no corresponding assessment is done to the impact on the project, it might be detrimental to the project success. With some projects, the customer or internal departments may drive the change. They can affect either: scope, time or budgets.
Scope changes should be identified as they directly affect the project deliverables. As change hits the scope, budget to project time, we must control it and make necessary adjustments. Extra work may be needed to complete project successfully.
The scope may change due to other projects being added and planned, or customer may change the requirements. It could also be that market conditions shift or team engineers are encountering issues.
The schedules may change because delivery date accelerated, there are pressures from competition or customer / client requests early delivery.
Budgets may change because management pulls out a chunk of project money, raw materials costs escalate or project work requires additional team members.
Understanding and identifying the sources of change will allow us to remain proactive. The change control process will require a decision on whether or not to process the change request and whether to determine the most effective way to move forward.
Some changes are easy, for example customer request legitimate design improvement and requires delivery within 2-3 months. But changes require difficult assessment, analysis and various approvals before the change can be processed. It is not always evident that specific change adds value, therefore formal change control process should be exercised.
Six Steps in Change process
The change process may vary but usually includes a number of important and mandatory steps. Organisational culture, procedure and project type directly affect the steps implemented. The project manager would generally request change from the entity that can be an individual, department or manager. At this point it is important to confirm the current status of the project plan.
Step 1. Enter initial change control information into change control log. Entering initial change control information serves as the summary of all actions taken regarding change requested. A detailed change log can ultimately serve as a biography of the project as it matures.
Step 2. Determine if the change should be processed. By determining whether the change should be processed, you take the role of a project gatekeeper. We should not always accept change because they are simply requested. If the change doesn't make sense, if it doesn't add value or should not be processed for good reasons we need to push back. The project manager should request clarification or justification to help to arrive to a reasonable decision. If the change is rejected, log and stop the process.
If the change is accepted, begin assessing the impact to the project plan. This is typically done by asking "How does the change affect the side of my triangle: scope, budget and time?"
Quality, objectives and other elements of the project should also be considered when assessing impact. Prepare recommendations for implementation and complete change control form.
Step 3. Submit recommendations to customer or manager for review and approval. Recommendations for review and approval should be submitted to management or your customer, including those for impact assessment. Other approvals should be obtained as necessary. Make appropriate modifications and comments as received from the stakeholders.
Step 4. Update the project plan. Don't forget to update the project plan. This is often forgotten. You need to create new project baselines. This will become the new current plan.
Step 5. Distribute the updated plan. Communication of updated plan is critical. We use this step to ensure that all stakeholders are aware of change and the adjusted baseline plan. If the distribution list is incomplete, misalignment will occur between the project team and one or more of the stakeholders.
Step 6. Monitor the change and track progress against the revised plan. The impact of the change activity might be minor or severe, good or bad. Don't forget to check the project triangle (scope, time, budget) to ensure that it remains balanced.
Organisational culture determines how we establish the change control process and manage the changes. Be flexible. If you are faced with an environment where there are no change processes in place that is a good news, bad news scenario. The difficulty is in establishing change control while facing resistance to change as well as general apathy. Nobody wants to sign anything and there is little support in the decision-making process. Do it anyway! It is important to maintain control of the project. If stakeholder or department manager signature sign off cannot be obtained, write the department manager's name of the change control form and note the date. It is the responsibility of the project manager to fight the scope creep and keep the triangle balanced and under control. The good thing is that absence of any process allows to set this up anyway you like. This may be time consuming and a lot of work, but the payoff will be your process and your style.
For those who work in an environment with established change control procedures should use the processes.
Project Change Control Form
The change control form is the controlling document for the change process. This document is the project manager's tool for identifying, assessing and processing change that affects the project. It allows to keep the project plan current. It should be filled out completely upon acceptance of the requested change. It allows record keeping and requires analysis, estimation and collaboration with team members and stakeholders.
A project change control form would generally include:
Project title
Date
Project Number
Task number
Revision number
Date revised
Objective statement, need to be SMART
Description of change; what happened, how it affects project scope, time and budget, will it cause delay to the project? change of scope to budget?
Reasons for change
Schedule change information: Task, Original Stated Date, Original Completion Date, New Start Date, New Completion date
Estimated Cost
Approvals: Project Manager, Task Manager, Functional Manager Dates of approvals from each individual, manager or stakeholder
It is important that the project manager reviews the form and adjust to our own perceived requirements when managing changes as the project matures. If the document is too cumbersome we will loose efficacy. We should always include the objective statements on the document to ensure the continuity and eliminate uncertainty. Change can breed uncertainty and it is not our friend. As changes multiply on a typical projects, include the original objective statement. A brief description of the change is appropriate and the reason should be included as well. Reason for change can also serve as a check on the system to ensure that value is added by implementing the change. Schedule change information and estimated costs bring us up to the triangle (scope, budget, time). It is crucial that we quantify the estimated impact of the change on both the schedule and the budget. Sometimes estimated costs are actual costs already realised or quotes received from vendors. An effective change control form is rather important for project control but can also come in handy. You might be able to present significant costs before approvals and change would not be made eventually.
You may ask yourself a question on how much change is needed to trigger the process? Are there changes that are not significant enough to justify filling out the form, aquiring signatures and making other investments of time and effort? These are important questions for the project manager and they offer an excellent time to consider the thresholds. Most project processes require you to employ good project. If the change is consider minor and the project plan can absorb the change within minimal impact, make necessary adjustments and move on. If, however, the severity threshold has been exceeded, this should trigger action by the project manager and the team to implement the change control process.
For example, if a £5 million project endure £10 change, it would be a poor decision to trigger the process. A reasonable threshold may be £500, depending upon budget constraints and industry standards. If the project deadline, for example, is four months from the date of the change request and the estimated schedule delay is one week, the change process should be triggered. Schedule thresholds require more analysis based upon critical path implications and the durations to complete.
Because of the ever changing environment that surrounds most projects thresholds are flexible and the project manager will often require input from teammates or other stakeholders to determine the impact of a change on a project. If you have done your homework and invested time and effort in managing the previous project life cycle processes, you will be in much better position to make informed decisions regarding change.
The Change Control Log
Change Control Log is another mechanism designed to identify proposed changes and track those accepted throughout the process.
A log should consider:
Change number
Date of change
Description of change
Requested by
Status O/C
Schedule impact
Budget impact
Comments
As with many project templates the concept is simple but not always easy to apply. Discipline is the key ingredient here. As changes risks and Critical path issues are swirling about, you must be disciplined enough to stop what you are doing and work the log. Much of the information you input might seem self-evident but the simplest detail might loom large as the project progress. Change number, Date of change request and the Description of Change are standard information. There will be instances, where the changes will be accepted but budgets, schedule, technology, skill set or something else creates blockage or delay or even prevent implementation. O/C (open or closed) to identify status. We should then transfer the Schedule Impact and Budget Impact from the change control form and update as necessary. Many project managers add a column for scope or objective impact prior to the final input that is reserved for comments or miscellaneous issues. Typical comments may concern stakeholder reluctance, technical problems or remarks regarding other project issues.
Sometimes projects change, whatever the source, can be grounds for spinning off a new project while continuing with the original. Sometimes it is appropriate for the new project to simply replace the original due to the skill set requirements, location, budget demands or reprioritisation. There are also changes so severe that justify closing the project down. When we get hit with a big one, its not often easy and never fun. It doesn't need to be even one change. It might be an accumulation of changes that dramatically impacts the project. In any case, you need to have a firm grasp on the impact on the project and your recommendations moving forward. You might need to persuade with a good data from the project plan.
The project spin-off usually occurs when change is so dramatic that the manager and team determine that entirely separate project should be initiated. If a new project moves forward with an existing one, it can often be managed in parallel and move forward with coordination and alignment. If a new project manager takes over they may need coaching to began. If a new project becomes a subproject than impact is far less drastic and the new team will usually report directly to the original project manager. In contract, if the new project replaces the old, we might just need to move on to other projects. We will need to start from the beginning with a plan, than continue with the project life cycle as appropriate. It is important to capture all the data that can be useful moving forward onto the new project. A careful analysis should be done, in some places new skills of team members will need to be acquired. You may have to recruit an entirely new team depending on circumstances.
Project change should not be feared, but embraced. Changes often represent all necessary adjustments to the original project plan. It's how we manage those changes that makes all of the difference and helps to deliver the project on time and on budget.
In summary, we must control change and successfully communicate it. Understanding and identifying the likely sources of change assists us in remaining proactive. Typical sources of change are scope, schedule and budget adjustments. It is, therefore, critical to keep the baseline plan current. We need to use the change control form and log as primary change documents. We also should established thresholds when determining the response to the project change.
Earned Value Analysis
In projects, control is exercised to achieve project objectives. We know that there are performance, scope, time and budget targets. We know already, that when a deviation occurs we need to take corrective actions. We also know that status reviews are necessary to the maintenance and the project control. We ask ourselves where are we with the project, where there is a deviation and what causes it and what should be done about the deviation.
In regards to the last question of what should be done about a deviation, there are four possible actions:
Cancel the project
Ignore the deviation
Take corrective actions to get back on planned track and progress
Revise the plan to reflect the change in status that can't be corrected.
Sometimes a project gets so far off track, that it is no longer viable and the best thing to do is to cancel it.
As for ignoring the deviation, if you can control it within a certain percentage tolerance and you are usually within those limits, you should ignore the deviation, unless it shows a trend that will definitely eventually take it outside the limits. Otherwise tweaking may just get the situation worse. As to taking corrective action, there is no way to tell, what it means as it is specific to each project. Sometimes working people overtime gets the project back on track. Or perhaps we need to add people, or cut scope, or change the process. We must determine what must be done for the project.
In the event that the project is still viable, but nothing can be done to get it back on track, you may have to revise the plan. Of course, we may also consider working overtime or reduce the scope, since these were not originally called for. If we cannot recover, however, and we are revising the plan to show that the costs will increase, the deadline will slip.
Measuring progress
One of the hardest things to do in managing projects is to actually measure the progress. Sometimes, we have to estimate where we are, but it is only a guess and indicates poorly managed work.
Naturally, if we can't tell where we are, we can't exercise control.
Estimate its only a guess. And so we are only guessing where we are.
The fact that measures of progress are not very accurate it does not justify the conclusion that they shouldn't be used. If we have no plan, than we have no control. If we do not monitor and follow the plan than we definitely do not have control. What is important, however, is that some projects are capable of tighter control than others. Well defined work which can be accurately measured, can be controlled to tight tolerances. Knowledge work require wider tolerances. Management must recognise this and accept it. Otherwise we can go crazy trying to achieve 3% or 5% tolerances.
Measuring project quality
If we think that measuring progress is hard, we should try to measure project quality. Quality is the hardest variable to track and one that often suffers as a consequence. Often, so much attention is focused on schedule and bought that the quality of work is often sacrificed. In some cases, it can result in lawsuits against the company resulting from damages resulting from poor quality work. Project managers must pay special attention to the quality variable, despite of the difficulty from tracking it.
Earned Value Analysis using Spending Curves
It is one thing to meet the project deadline at any cost. It is another to do it at reasonable cost. Project cost control is concerned with ensuring that project stays within the budgets, while getting the work done on time and the correct quality. One system for doing this called "Earned Value Analysis" was developed in 1960s to enable the government to decide whether a contractor should receive a progress payment for work done. This method is coming to be used outside government projects and it is considered the correct way to monitor and control almost any project. The method is also often called a "variance analysis". Variance analysis allows the project manager to determine trouble spots in the project and to take corrective action. Some definitions should be used as well:
- Cost variance - compares deviations and performed work
- Schedule variance - Compares planned and actual work completed
- BCWS (Budget cost of work scheduled) - the budget cost of work scheduled to be done in a given time period or a level of effort that is supposed to be performed in that period
- BCWP (Budget Cost to Work performed) - the budgeted cost of work actually performed in a given period or the level of effort actually expended. BWCP is also called "earned value" and is a measure of the dollar value of the work actually accomplished in the period being monitored.
- ACWP (Actual Cost of Work performed) - the amount of money (or effort) actually spent in completing work in a given period.
Variance thresholds can be established that define a level in which reports must be sent to various levels of management within an organisation.
Cost Variance = BCWP - ACWP
Schedule Variance = BCWP - BCWS
Variance = any deviation from plan
By combining cost and schedule variances an integrated cost/schedule reporting system can be developed.
Variance Analysis
Variance are often plated using spending curves.
A BCWS curve for a project is shown above. It shows the cumulative spending planned for a project in blue. In the event that software is not able to generate the data above we can see how the data for the curve has been generated.
Consider the 6 tasks that are involved. The cumulative expenditures are calculated by adding the cost in each subsequent week to the previous cumulative total. These are plotted in the Actual Cost on the graph.
This is the spending curve for the project and it is called BCWS curve. Since this is derived directly from the schedule it represent planned performance and therefore it is called "baseline plan". Furthermore since control is exercised by comparing progress to plan, this curve can be used as a basis for such comparisons so that the project manager can tell the status of the program.
The above template demonstrates the use of EVM formulas to run a basic earned value analysis and monitor spending over the life of a project. We can start by adding tasks to the planned value template and entering amounts that will be spent on the task each period. After you have done defining the tasks and the budget, enter the same set of tasks in the EV (Earned Value) and AC (Actual Cost) worksheets. At the end of each period you will enter a percentage complete for each task in the EV worksheet and the amount spent on each task during the period in the AC worksheet. Transfer the cumulative EV and AC to the report worksheet and analyse the graph comparing the EV and AC to the planned value.
Planned Value (PV) is the Budgeted Cost of Work Scheduled (BCWS). When you create Project schedule you will create the Total Budgeted Cost (TBC) to each separate task. For longer term tasks this cost might be spread out over multiple periods and may not always be linear. The planned value is the baseline that we will be comparing to.
Actual Cost (AC) is the Actual Cost of Work performed (ACWP). It is the amount we have spent, including about and materials and other costs. The Actual Cost alone does not tell you anything about how much work was actually completed, but it is still a critical number to report.
Earned Value (EV) this is the Budgeted Cost of work Performed (BCWP). or the value of work completed. The project manager must come up with rules for how to assign the value. In the example graph the EV is calculated by multiplying the % complete by the Total Budgeted Cost (TBC) for each task.
The rules we use for assigning the Earned Value are highly dependent on how we define the project tasks. If we use a good Work Break Down structure assigning earned value may end up being a lot easier.
For example, if you had a task called "Expenditure" that spanned the entire project period. The planned value for the task would be nonlinear. We may spent £5000 at the start, than £1000 during month 3, than £2500 during month 6. The TBC for that task would be £8500. Assuming that the purchases were made on schedule, the % complete for that task as of month 3 would be (£5000+£1000)/£8500. If the actual cost of the initial purchase was only £4500 the earned value would still be £5000+£1000.The £4500 would be included in the actual cost. This is how you end up knowing that we are under budget.
Alternatively, the project manager may define "Expenditure" as separate category of tasks with each large purchase with a subtask and another subtask with miscellaneous purchases. Then whenever each purchase is made, it is a simple matter of marking each task as 100% complete.
Just because a task os 50% complete it does not mean that it earned 50% of the value.
Variance analysis using Hours
In some organisations project managers are held accountable not for costs but for the hours actually worked on the project and for the work actually accomplished. In this case the same analysis can be conducted by stripping the £ off the figures.
- BCWS becomes Total Planned (or Scheduled) hours
- BCWP becomes Earned Hours (Scheduled Hours X % of work accomplished)
-ACWP becomes Actual Hours Worked
Tracking hours only does lead to one loss of sensitivity. ACWP is the composite of a labour rate variance times a labour hours variance. When only about hours are tracked, you have no warning that labour hours may cause a project budget problem. Nevertless, this method simplify the analysis and presumably tracks the project manager only on what he or she can control.
Responding to Variances
It is not enough to simply detect the variance. The next step is to understand what it means and what caused it. Then we have to decide what to do to correct for the deviation. As we know already, there are four responses that can be taken when there is a deviation from a plan.
Source: http://wiki.doing-projects.org/index.php/Earned_value_management_(EVM)
When ACWP and BCWP are almost equal and larger than BCWS, it means that extra resources have been applied but at a labour rates originally planned. This can happen in several ways. Perhaps we have planned for weather delays, but the weather has been good and we have gotten more work done during the analysis period than intended but at the correct cost. This we are ahead of schedule but spending correctly.
2. When ACWP and BCWP are nearly equal and below than BCWS it usually means the opposite the previous situation, that is, we have not applied enough resources. Perhaps they were stolen from us, perhaps it has rained more than we expected, or perhaps everyone decided to take a vacation at once. The problem in being in this position is that it usually ends up in overspend when we are trying to catch up.
3, When ACWP is below BCWS and BCWP is above BCWS we are ahead of schedule and underspent. This generally happened when the original estimate was too conservative. Probably padded for safety. Another possibility is that we had a lucky break. You thought that the work would be harder than it was, so able to get ahead. Sometimes it happens because people were much more efficient than expected. The problem with this variance is that it ties up resources that could be used on other projects. There is always a chance that we were consistently padding estimates and were bidding against other companies on projects, we probably lost some bids. If the competitor using average value for time estimates while you were padding yours, your figures are likely to be higher and you will loose the bid.
Monitoring costs during the life of the project allows to trace the ACWP, which is the actual cost of the work performed. This is extremely relevant as the actual spent on projects often diverse from the planned ones as may unforeseen events can occur. Usually actual costs are calculated by checking actual division of work among man power and using tools such as cost and time reports which shows how the resources of the project team spent their time and the total amount of expenditure.
BCWS and ACWP alone do not provide any information on the nature of the potential deviation. For example if ACWP is higher than BCWS it might be that the project is either inefficient, so actual expenditures are higher than the budget or work is being done earlier compared to the schedule. For this reason traditional cost management is not precise enough and it is essential to analyse the third curve, BCWP.
BCWP is calculated by multiplying the % of completion (POC) with the budget at completion (BAC) which is the total budget of the project.
A useful way to conduct deviation analysis is to group the three metrics in one graph. It can provide four scenarios:
Project late compared to the schedule and inefficient
Project late to the schedule and efficient
Project on time and efficient
Project on time and inefficient
Acceptable Variances
What are acceptable variances? It all depends. If you are doing a well defined construction job, the variances can be in the range of +/- 3-5%. If the job is research and development, acceptable variances increase generally to +/- 10-15%. When the job is pure research, the sky is the limit. All progress is an attempt to reduce variation in what we do. We will never reduce it to zero, unless we eliminate the process altogether.
Using % Complete to Measure Progress
The most common way to measure progress is to simply estimate the % complete. This is the BCWP measure, but BCWP is expressed as a £ value, whereas % complete does not make that conversion. When % complete measures are plotted over time the curve raised more or less linearly up to 80% to 90%, than turns horizontal (means that no further progress is being made). It stays there for a while, than, all of the sudden, the work is completed. The reason is that problems are often encountered near the end of the task and a lot of effort goes into trying to solve them. During that time, no progress is made. Another part of the problem is knowing where to begin with. We already know that we only estimating progress. For example a task that has 10 week duration. If you ask the person during that task where he is at the end of first week he is likely to tell you 10%, at the end of second week 20% and so on. But what they are doing is making a reverse inference. The truth is that they do not really know where they are. Naturally under such conditions controls are very loose. Still, this is the only way the progress can be measured in many cases.
Forecasting
By calculating deviation, project managers have a picture of the project performance in that specific moment. However, before implementing any corrective actions it is necessary to understand what would be the final arrival point of the project if continued with the same trend. In fact, identifying, analysing and mobilising resources to implement corrective actions are time consuming and expensive activities and may not be necessary if the final performance of the project is within the acceptable range.
The key metrics to forecast future trends are EAC and SAC which stands for Estimates at Completion and Schedule at Completion. In addition to these metrics there is also Variance at Completion. From the graphical point of view, these metrics are obtained by extending the ACWP until the end of the project.
Remember, that control is exercised by analysing from the plan. Well defined projects can achieve tighter control over variations of poorly defined ones. There is a tendency to sacrifice quality if the deadlines are difficult to meet. It is not enough to recognise the variance. It's cause must be determined so that corrective action can be taken. Acceptable variances, can be determined only through experience. Every system has a capacity to maintain good tolerances.
Managing the Project Team
Far too many project managers see only the project tools to manage projects successfully. We assemble the team, give the instructions, than sit back and let the project self-destruct. Often, the problem is with people we manage. The tolls and techniques of project management are necessary, but not a sufficient condition for project success. Therefore, we need to turn people into team.
Building an effective team begins on the first day. The problem of commitment is a major one for both organisations and project teams.
Teamwork through Planning
The primary rule of planning is that those individuals who must implement the plan should participate in preparing it. Yet, leaders often plan projects by themselves and they wonder why the team members have no commitment to the plans. All planning requires some estimating on how long a task will take given the availability of certain resources. Bosses normally think we can do work a lot quicker that we can actually do.
When a manager gives a person an assignment that allows inequity time to perform, the individual naturally feels discouraged and the commitment is likely to suffer.
The four important steps in organising project team are:
1. Decide what must be done, using work breakdown structures, problem definitions and other planning tools.
2. Determine the staffing requirements to accomplish the tasks identified in the first step
3. Recruit members for the project team
4. complete your project plan with the participation of team members
When recruiting the team members the candidates should possess the skills necessary to perform the required work and the speed needed to meet deadlines. They need to participate in the project and have the temperament to fit with other team members who have already been recruited and with the project manager as well as other key players. The person must also not object to other requirements, tight deadlines etc.
Team's Mission, Goal and Objectives
It is said that excellent organisations "stick to their knitting". They stick to what they are good at. If members are not clear on the team's mission, they will take the team on where it supposed to go and it might not be the direction intended by the organisation. Working with your team to develop a mission statement is a good team building activity in itself.
Conflicts
It is widely know that team members are more likely to be committed when their needs are met. Sometimes members may have "hidden agendas", personal objectives that they do not want anyone to know about. Because they are afraid that other members will try to block them if their objectives are known. Since managers should help individual members to achieve their personal goals, the team leaders need to bring hidden agendas so that the individual can be helped to achieve his goal. If a personal goal is not the team goal, the individual can be moved to a different project.
The main issues generally cover: goals, roles and responsibilities, procedures and relationships. People must understand their roles and they must be clearly defined. Project managers and leaders often forget about the power of feedback from the team members in order to ensure that they are understood. People will often interpret what was said and do what they can.
The best way to do this is to comment on the problem as
"I know some of you may feel reluctant to speak up and say you don't understand, but we can't operate that way. Please feel free to be candid. If you don't understand, say so. If you don't agree with something, say so. This is the only way we can succeed. We will be lucky to have time to do the job once, much less time to do it over because one of you failed to do what was expected".
People also often respond positively when we are willing to admit that we don't understand something and being apprehensive to a project issues. The macho motion is many organisation's problems.
Frictions occur in almost every interaction between human beings. There are misunderstandings, conflicts, personality clashes and petty jealousies. Project managers must be prepared to deal with these. The behavioural problems come with the project management job. Personality clashes come from bad interpersonal skills. The best way to minimise the impact of such problems is to provide training to all team members in interpersonal skills.
Team development
There are four stages of team development: forming, storming, norming and performing. In the forming stage, people are concerned on how they will fit in and who calls the shots and make decisions. At this stage they look to the leader to give them some structure, sense of direction and help them get started.
The storming stage is frustrating for most people. Often people begin to question their goals.
At the norming stage they begin to resolve their conflicts and to settle down to work. They will develop "norms" on how they will work together and they feel more comfortable with one another.
When the team reaches the performing stage, the leader's job is easier. Members will generally work together well and produce high-quality results.
A newly formed team needs structure. A leader who fails to provide structure may be rejected by the group. During the forming stage leaders need to help team members to get to know one another and help them to become clearer on goals, roles and responsibilities. If we just tell the team members to get to work without helping them knowing each other, we are likely to fail. We should not see social activities as waste of time, even a nice dinner can be a mechanism for people to getting to nkow each other.
The leader must be aware, that during the storming stage people deal with anxiety. The leader must use influence or persuasion to assure they are on track. They need to feel valued. We should also try not to brush conflicts among the team members "under the rug".The conflicts must be managed. If not resolved, it will always come back.
Support is needed during the norming stage. Participate and sharing decision making is important here.
During the performing stage, the leader can sit back and monitor and analyse the progress of a project. Although members may feel accomplish, it can easily fall into the storming stage back again.
Five Rules to developing commitment:
Have team members interact frequently so that they gain the sense of being a team
Ensure that their needs are being met through participation
Let them know why the project is important
Make sure that team members hare the goals of the team
Keep competition within a team to minimum.Competition and cooperation are opposites. Let people compete from those outside the organisation and not among each other.
Members should meet frequently through conference calls, video-conferencing and other internet tools. Team don't just happen, they must be built. Participation in the planning is one way to start the process. We need to deal with goals, roles and responsibilities, procedures and relationships in that order.
Project Manager as a Leader
The project manager must take disciplined approach in project environment to lead the teams. All the players in the project management, including stakeholders need to be effectively managed. But before leading others, we need to do self-inventory. An improved understanding of yourself, as well as stakeholders will lead to more efficient communication and project success.
We need to be able to persuade, motivate and resolve conflicts. We should not insist for others to adjust to our leadership style. We need to be flexible in this approach. We need to invest time and effort in developing our leadership skills. We need to be able to stand out of our comfort zone and try to change our own behaviour.
We need to engage in trust and respect, perhaps even admiration. We do not expect perfection but require consistency.
We should also encourage risk taking and try to eliminate the fear of failure. Mistakes can also present important opportunities. If you make a mistake, say "by bad" and learn from it.
Positive team culture is also established when the titles are dropped. We need to encourage of exchanging ideas free of judgment and scarcity of embarrassment.
Getting the most of the team requires focusing on them as individuals. The most effective approach is to spending time with the team members, even over coffee. Accomplishments are to be celebrated. We can start by celebrating small victories and milestones.
If the chemistry between members is not right and daily clashes occur it can negatively affect the project. We must observe the dynamics of the group. Be proactive and identify danger zones.
Conflict resolution
All project teams experience conflicts at some point. Conflicts can become destructive. Generally the root causes are: personality issues, conflicting priorities, stakeholder disagreement, tight deadlines and technical issues.
There are several approaches to deal with conflicts:
Avoidance. Often called the "flight syndrome". Avoidance occurs when the individual delays the issue, withdraw from the situation and avoids conflicts.
Accommodating. The individual focuses on meeting the needs of the other person.
Compromising. This is the attempt to find the middle ground in which neither party meets their needs.
Collaborating. Both parties work together to come to mutually-benefitting solution. They may create the win-win scenario.
Forcing. In other words, "my way or the highway".
Meeting rules
Most organisations hold too many meetings that hold up too much time. Project managers are responsible for making the status meetings efficient. Some rules may apply:
- Minimum number of members for the meeting
-Consensus - in case of deadlock, if fine members agree, we are proceeding
- All titles are left at the door
- Confidentiality - everything said stays in the meeting room
- One person speaks at the time
- Start on time, end on time
- Keep meeting minutes
- Encourage participation to ensure that every voice is heard
- Do not accept and allow sidebar discussions
- - All electronic devices are off
Summary
Here are some suggestions on how to make the project management work:
Get the top management involved in the project. This includes planning, review meetings
Built in performance appraisals - reward people for practicing best methods and sanction them, when they don't.
Have the project team trained in the basics, often it is 2 days training that is required on rules in project management.
Have realistic expectations
Plan small wins for people. We should begin with the smallproblems and solve them. Then move on to bigger ones. This will ensure success at the start and motivation.
Practise management by walking around.
Do process reviews.
Deal with difficult people as soon as possible. Don't ignore the problem as it will week the entire team.
Be proactive and not reactive.
Have team members making presentations for senior management, give credit and built ownership.
If you are running a project and people still report to their own bosses, keep the managers involved.
Have someone trained on project management software.
Find out what other companies and competitors do about project management.
Have individuals take responsibilities and make them champions of their tasks.
Learn about project management and join Project Management Institute.
Treat project management as a challenge or even a game.
Give critical tasks to the right people who can make things happened.
Goos luck!
Commentaires