To install StudyMoose App tap and then “Add to Home Screen”
Save to my list
Remove from my list
A general model of organizational control includes four components that can operate in a continuous cycle and can be represented as a wheel. These elements are:
Project goal setting goes beyond overall scope development to include setting the project baseline plan. The project baseline is predicated on an accurate. Work Breakdown Structure (WBS) process. Remember that WBS establishes all the deliverables and work packages associated with the project, assigns the personnel responsible for them, and creates a visual chart of the project from highest level down through the basic task and subtask levels.
The project baseline is created as each task is laid out on a network diagram and resources and time durations are assigned to it.
Effective control systems require accurate project measurement mechanisms. Project managers must have a system in place that will allow them to measure the ongoing status of various project activities in real time. We need a measurement system that can provide information as quickly as possible.
Verified writer
Proficient in: Business
5 (876)
“ Have been using her for a while and please believe when I tell you, she never fail. Thanks Writer Lyla you are indeed awesome ”
What to measure also needs to be clearly defined. Any number of devices allow us to measure one aspect of the project or another; however, the larger question is whether or not we are getting the type of information we can really use.
When we have some sense of the original baseline (plan) and a method for accurately measuring progress, the next step is to compare the two pieces of information. A gap analysis can be used as a basis for testing the project’s status.
Gap analysis refers to any measurement process that first determines the goals and then the degree to which the actual performance lives up to those goals. The smaller the gaps between planned and actual performance, the better the outcome. In cases where we see obvious differences between what was planned an what was realized, we have a clear-cut warning signal.
Once we detect significant deviations from the project plan, it becomes necessary to engage in some form of corrective action to minimize or remove the deviation. The process of taking corrective action is generally straightforward.
Corrective action can either be relatively minor or may involve significant remedial steps. At its most extreme, corrective action may even involve scuttling a nonperforming project. After corrective action, the monitoring and control cycle begins again. The control cycle is continuous. As we create a plan, we begin measurement efforts to chart progress and compare stages against the baseline plan. Any indications of significant deviations from the plan should immediately trigger an appropriate response, leading to a reconfiguration of the plan, reassessment of progress, and so on. Project monitoring is continuous, full-time cycle of target setting, measuring, correcting, improving, and remeasuring.
As we discovered in the chapters on project budgeting and resource management, once we have established a project baseline budget, one of the most important methods for indicating the ongoing status of the project is to evaluate it against the original budget projections. For project monitoring and control, both individual task budgets and the cumulative project budget are relevant. The cumulative budget can be broken down by time over the project’s projected duration.
As a basis for evaluating project control techniques, let us consider a simple example. Assume a project (Project Sierra) with four work packages (Design, Engineering, Installation, and Testing), a budget to complete of $80,000, and an anticipated duration of 45 weeks.
To determine project performance and status, a straightforward time/cost analysis is often our first choice. Here the project’s status is evaluated as a function of the accumulated costs and labor hours or quantities plotted against time for both budgeted and actual amounts. We can see that time (shown on the x, or horizontal, axis) is compared with money expended (shown on the y, or vertical, axis). The classic project S-curve represents the typical form of such a relationship. Budget expenditures are initially low and ramp up rapidly during the major project execution stage, before starting to level off again as the project gets nearer to its completion. Cumulative budget projections for Project Sierra have been plotted against the project’s schedule. The S-curve figure represents the project budget baseline against which budget expenditures are evaluated.
Monitoring the status of a project using S-curves becomes a simple tracking problem. At the conclusion of each given time period (week, month, or quarter), we simply total the cumulative project budget expenditures to date and compare them with the anticipated spending patterns. Any significant deviations between actual and planned budget spent reveal a potential problem area.
Simplicity is the key benefit of S-curve analysis. Because the projected project baseline is established in advance, the only additional data shown are the actual project budget expenditures. The S-curve also provides real-time tracking information in that budget expenditures can be constantly updated and the new values plotted on the graph. Project information can be visualized immediately and updated continuously, so S-curves offer an easy-to-read evaluation of the project’s status in a timely manner. (The information is not necessarily easily interpreted, however, as we shall see later.)
Our Project Sierra example can also be used to illustrate how S-curve analysis is employed. Suppose that by week 21 in the project, the original budget projected expenditures of $50,000. However, our actual project expenditures totaled only $40,000. In effect, there is a $10,000 budget shortfall, or negative variance between the cumulative budgeted cost of the project and its cumulative actual cost. In the table it shows the track of budgeted expenditures with actual project costs, including identifying the negative variance shown at week 21. In this illustration, we see the value of S-curve analysis as a good visual method for linking project costs (both budgeted and actual) over the project’s schedule.
When project teams consider using S-curves, they need to take the curve’s significant drawbacks into consideration as well as their strengths. S-curves can identify positive and negative variance (budget expenditures above or below projections), but they do not allow us to make reasonable interpretations as to the cause of variance. Consider the S-curve shown. The actual budget expenditures have been plotted to suggest that the project team has not spent the total planned budget money to date (there is negative variance). However, the question is how to interpret this finding. The link between accumulated project costs and time is not always easily resolved. Is the project team behind schedule (given that they have not spent sufficient budget to date) or might there be alternative reasons for the negative variance?
Assume that your organization tracks project costs employing an S-curve approach and uses that information to assess the status of an ongoing project. Also assume that the project is to be completed in 12 months and has a budget of $150,000. At the six-month checkup, you discover that the project S-curve shows significant shortfall; you have spent far less on the project to date than was originally budgeted. Is this good or bad news?
On the surface, we might suppose that this is a sign of poor performance; we are lagging far behind in bringing the project along and the smaller the amount we have spent to date is evidence that our project is behind schedule. On the other hand, there are any number of reasons why this circumstance actually might be positive. For example, suppose that in running the project, you found a cost-effective method for doing some component of the work or came across a new technology that significantly cut down on expenses. In that case, the time/cost metric may not only be misused, but might lead to dramatically inaccurate conclusions. Likewise, positive variance is not always a sign of project progress. In fact, a team may have a serious problem with overexpenditures that could be interpreted as strong progress on the project when in reality it signals nothing more than their inefficient use of project capital resources. The bottom line is this: Simply evaluating a project’s status according to its performance on time versus budget expenditures may easily lead us into making inaccurate assumptions about project performance. Milestone Analysis
Another method for monitoring project progress is milestone analysis. A milestone is an event or stage of the project that represents a significant accomplishment on the road to the project’s completion. Completion of a deliverable (a combination of multiple project tasks), an important activity on the project’s critical path, or even a calendar date can all be milestones. In effect, milestones are road markers that we observe on our travels along the project’s life cycle. There are several benefits to using milestones as a form of project control. 1. Milestones signal the completion of important project steps. A project’s milestones are an important indicator of the current status of the project under development. They give the project team a common language to use in discussing the ongoing status of the project. 2. Milestones can motivate the project team. In large projects lasting several years, motivation can flag as team members begin to have difficulty seeing how the project is proceeding overall, what their specific contribution has been and continues to be, and how much longer the project is likely to take. Focusing attention on milestones helps team members become more aware of the project’s successes as well as its status, and they can begin to develop greater task identity regarding their work on the project. 3. Milestones offer points at which to reevaluate client needs and any potential change requests. A common problem with many types of projects is the nature of repetitive and constant change requests from clients. Using project review milestones as formal “stop points,” both the project team and the clients are clear on when they will take midcourse reviews of the project and how change requests will be handled.
When clients are aware of these formal project review points, they are better able to present reasonable and well-considered feedback (and specification change requests) to the team. 4. Milestones help coordinate schedules with vendors and suppliers. Creating delivery dates that do not delay project activities is a common challenge in scheduling delivery of key project components. From a resource perspective, the project team needs to receive supplies before they are needed but not so far in advance that space limitations, holding and inventory costs, and in some cases spoilage are problems. Hence, to balance delays of late shipments against the costs associated with holding early deliveries, a well-considered system of milestones creates a scheduling and coordinating mechanism that identifies the key dates when supplies will be needed. 5. Milestones identify key project review gates. For many complex projects, a series of midterm project reviews are mandatory. For example, many projects that are developed for the U.S. government require periodic evaluation as a precondition to the project firm receiving some percentage of the contract award. Milestones allow for appropriate points for these review. Sometimes the logic behind when to hold such reviews is based on nothing more than the passage of time (“It is time for July 1 review”). For other projects, the review gates are determined based on completion of a series of key project steps (such as the evaluation of software results from the beta sites). 6. Milestones signal other team members when their participation is expected to begin. Many times projects require contributions from personnel who are not part of the project team. For example, a quality assurance individual may be needed to conduct systems tests or quality inspection and evaluations of work done to date. The quality supervisor needs to know when to assign a person to our project, or we may find when we reach that milestone that no one’s available to help us. Because the QA person is not part of the project team, we need to coordinate his or her involvement in order to minimize disruption to the project schedule. 7. Milestones can delineate the various deliverables developed in the work breakdown structure and therefore enable the project team to develop a better overall view of the project. You then are able to refocus efforts and function-specific resources toward the deliverables that show signs of trouble, rather than simply allocating resources in a general manner. For example, indications that the initial project software programming milestone has been missed allows the project manager to specifically request additional programmers downstream, in order to make up time later in the project’s development.
Milestones, in one form or another, are probably the simplest and most widely used of all project control devices. Their benefits lie in their clarity; it is usually easy for all project team members to relate to the idea of milestones as a project performance metric. The problem with them is that they are a reactive control system. You must first engage in project activities and then evaluate them relative to your goal. If you significantly underperform your work to that point, you are faced with having to correct what has already transpired. Imagine, for example, that a project team misses a milestone by a large margin. Not having received any progress reports up until the point that the bad news becomes public, the project manager is probably not in a position to craft an immediate remedy for the shortfall. Now, the problems compound. Due to delays in receiving the bad news, remedial steps are themselves delayed, pushing the project farther behind.
An increasingly popular method used in project monitoring and control consists of a mechanism that has become known as Earned Value Management (EVM). The origins of EVM date to the late 1960s when U.S. government contracting agencies began to question the ability of contractors to accurately track their costs across the like of various projects. As a result, after 1967, the Department of Defense imposed 35 Cost/Schedule Control Systems Criteria that suggested, in effect, that any future projects procured by the U.S. government in which the risk of cost growth was to be retained by the government must satisfy these 35 criteria. In the more than 30 years since its origin, EVM has been practiced in multiple settings, by agencies from governments as diverse as Australia, Canada, and Sweden, as well as a host of project-based firms in numerous industries.
Unlike previous project tracking approaches, EVM recognize that it is necessary to jointly consider the impact of time, cost, and project performance on any analysis of current project status. Put another way: Any monitoring system that only compares actual against budgeted cost numbers ignores the fact that the client is spending that money to accomplish something-create a project. Therefore, EVM reintroduces and stresses the importance of analyzing the time element in project status updates. Time is important because it becomes the basis for determining how much work should be accomplished at certain milestone points. EVM also allows the project team to make future projections of project status based on its current state. At any point in the project’s development we are able to calculate both schedule and budget efficiency factors (the efficiency with which budget is being used relative to the value that is being created) and use those values to make future projections about the estimated cost and schedule to project completion.
We can illustrate the advance in the project control process that Earned Value represents by comparing it to the other project tracking mechanisms.
If we consider the key metrics of project performance as those success criteria discussed in Chapter 1 (scheduling, budget, and performance), most project evaluation approaches tend to isolate some subset of the overall success measure. For example, project S-curve analysis directly links budget expenditures with the project schedule. Again, the obvious disadvantage to this approach is that it ignores the project performance linkage.
Project control charts such as tracking Gantt charts link project performance with schedule but may give budget expenditures short shrift. The essence of a tracking approach to project status us to emphasize project performance over time. While the argument could be made that budget is implicitly assumed to be spent in some preconceived fashion, this metric does not directly apply a link between the use of time and performance factors with project cost.
Earned value, on the other hand, directly links all three primary project success metrics (cost, schedule, and performance). This methodology is extremely valuable because it allows for regular updating of a time-phased budget to determine schedule and cost variances, as identified by the regular measurement of project performance.
Following are some key concepts that allow us to calculate Earned Value and use its figures to make future project performance projections. PVPlanned value. A cost estimate of the budgeted resources scheduled across the project’s life cycle (cumulative baseline). EVEarned value. This is the real budgeted cost, or “value,” of the work that has actually been performed to date. ACActual cost of work performed. The cumulative total costs incurred in accomplishing the various project work packages. SPISchedule Performance Index. The earned value to date divided by the planned value of work scheduled to be performed (EV/PV). This value allows us to calculate the projected schedule of the project to completion. CPICost Performance Index. The earned value divided by the actual, cumulative cost of the work performed to date (EV/AC). This value allows us to calculate the projected budget to completion. BACBudgeted cost at completion. This represents the total budget for a project.
The first step in developing an accurate control process is to create the project baselines against which progress can be measured. Baseline information is critical regardless of the control process we employ, but baselines are elemental when performing EVM. The first piece of information necessary for performing earned value is the planned value; that is, the project baseline. The PV should comprise all relevant project costs, the most important of which are personnel costs, equipment and materials, and project overhead, sometimes referred to as level of effort. Overhead costs (level of effort) can include a variety of fixed costs that must be included in the project budget, including administrative or technical support, computer work, and other staff expertise use (such as legal advice or marketing). The actual steps in establishing the project baseline are fairly straightforward and require two pieces of data: the Work Breakdown Structure and a time-phased project budget.
A time-phased budget for this activity might resemble the following:
Activity| Jan| Feb| …| Dec| Total|
Data Entry| $14,000| $6,000| | -0-| $20,000|
Once we have collected the WBS and applied a time-phased budget breakdown, we can create the project baseline. The result is an important component of earned value because it represents the standard against which we are going to compare all project performance, cost, and schedule data as we attempt to assess the viability of an ongoing project. This baseline, then, represents our best understanding of how the project should progress. How the project is actually doing, however, is, of course, another matter.
Assume that it is now week 30 of the project and we are attempting to assess the project’s status. Also assume that there is no difference between the projected project costs and actual expenditures; that is, the project budget is being spent within the correct time frame. However, upon examination, suppose we were to discover that Installation was only half-completed and Project Testing had not yet begun. This example illustrates both a problem with S-curve analysis and the strength of EVM. Project status assessment is only relevant when some measure of performance is considered in addition to budget and elapsed schedule.
Consider the revised data for Project Sierra. Note that as of week 30, work packages related to Design and Engineering have been totally completed, whereas the Installation is only 50% done, and Testing has not yet begun. These percentage values are given based on the project team or key individual’s assessment of the current status of work package completion. The question now is: What is the earned value of the project work done to date? As of week 30, what is the status of this project in terms of budget, schedule, and performance?
Calculating the earned value for these work packages is a relatively straightforward process. We can modify the previous table to focus exclusively on the relevant information for determining earned value. The planned budget for each work package is multiplied by the percentage completed in order to determine the earned value to date for the work packages, as well as for the overall project. In this case, the earned value at the 30-week point is $51,000.
We can compare the planned budget against the actual earned value using the original project budget baseline. This process allows us to assess a more realistic determination of the status of the project when the earned value is plotted against the budget baseline. Compare this figure with the alternative method, in which negative variance is calculated, with no supporting explanation as to the cause or any indication about whether this figure is meaningful or not. Recall that by the end of week 30, our original budget projections suggested that $68,000 should have been spent. Instead, we are projecting a shortfall of $17,000. In other words, we are not only showing a negative variance in terms of money spent on the project, but also in terms of value created (performance) of the project to date. Unlike the standard S-curve evaluation, EVM variance is meaningful because it is based not simply on budget spent, but value earned. A negative variance of $10,000 in budget expenditures may or may not signal cause for concern; however, a $17,000 shortfall in value earned on the project to date represents a variance of serious consequences.
There are five steps in Earned Value Management (EVM):
Earned Value Management can work at the portfolio level as well as with individual projects. The process simply involves the aggregation of all earned value measures across the firm’s entire project portfolio in order to give an indication as to the efficiency with which a company is managing its projects.
Other useful information contained in the Portfolio Earned Value Management table includes the total positive variances for both budget and schedule, as well as determination of the relative schedule and cost variances as a percentage of the total project portfolio. The use of Earned Value Management for portfolio tracking and control offers top management an excellent window into the firm’s ability to efficiently run projects, allows for comparisons across all projects currently in development, and isolates both the positive and negative variances as they occur. All of this is useful information for top-level management of multiple projects.
Project Management and Organizational Control. (2016, Apr 10). Retrieved from https://studymoose.com/project-management-and-organizational-control-essay
👋 Hi! I’m your smart assistant Amy!
Don’t know where to start? Type your requirements and I’ll connect you to an academic expert within 3 minutes.
get help with your assignment
