The communications plan described in the previous section is the output of the communications planning process. However, a project metric system must be in place to support the information requirements for all of the stakeholders. In general, project metrics should focus on the following key areas:
FYI (FOR YOUR INFORMATION)
Although the project budget, schedule, and resource assignments are in place, you can still have angered and frustrated stakeholders unless a comprehensive communications plan is in place. Rob Hennelly, a senior manager of financial processes and systems at Sears, Roebuck and Co. in Hoffman Estates, Illinois, points out that "communication goes to the heart of a lot of IT projects because it can ease the pain of change for end users." An effective communications plan should contain these principles:
1. Identify your audience and their communication needs. It is important to talk to the project's stake holders and ask them what they need to know and how often they need to know it. For example, sen ior managers may want detailed reports, while end users may only want short messages.
2. Determine the most effective means for communi cating with this audience. The basic question is how do the project stakeholders want to receive this information. In general, the most effective way to communicate is face-to-face, followed by phone conversations. Although talk is fine, a project's official mode of communication should be in written form.
3. Decide who should deliver the message. It is important to assess how well, or how poorly, the IT project team members communicate with the business people. Business people tend to listen better to their own, while technical people tend to focus more on the technology. Getting the corporate communications people involved may be a good idea, especially when stakeholders outside the organization (i.e., customers, suppliers, unions, or stockholders) must be kept informed. In addition, timing is critical. It's a good idea to make important announcements, such as letting users know when their workstations will be replaced, before the impact.
SOURCE: Adapted from Rick Saia, One Project, One Voice, Computerworld, February 8, 1999. http://www.computerworld.com /news/1999/story/0,11280,33846,00.html
Data to support these metric categories can be collected in a number of ways. For example, project team members may be asked to submit periodic reports or even time cards that describe what tasks they worked on, the time spent working on those tasks, and any other resources that they may have used on those tasks. In addition, the project team could report lines of code, function points, or even feature points. Data can be collected using expense reports, invoices, purchase orders, and so forth. Moreover, information can be provided informally through day-to-day contacts with various individuals or groups.
Collection of this data allows the project manager to compile a set of metrics that can be used to create the various reports for the stakeholders defined in the communications plan. A project metric may be defined as a qualitative measurement of some attribute of the project. This metric should be obtained from observable, quantifiable data (Edberg 1997). In addition, these metrics can be useful for developing a measurement program that allows the team and other stakeholders to gauge the efficiency and effectiveness of the work being done. Edberg suggests that a good project metric must be:
• Understandable—A metric should be intuitive and easy to understand; oth erwise, the metric will be of little value and will most likely not be used.
• Quantifiable—A quantifiable metric is objective. A metric should have very little bias as a result of personal influence or subjectivity.
• Cost Effective—Data must be collected in order to produce a metric. Subsequently, a metric should be relatively easy and inexpensive to create and should not be viewed as a major disruption.
• Proven—A metric should be meaningful, accurate, and have a high degree of validity in order to be useful. The metric must measure exactly what one wants to measure. "What gets measured gets done!"
• High Impact—Although the efficiency of computing a metric is important, the metric must be effective. Why measure something that has little impact on the project?
Meyer (1994) suggests that trying to run a team without a good measurement system is like trying to drive a car without a dashboard. He suggests the following principles as a guide (Meyer 1994):
• A measurement system should allow the team to gauge its progress. The project metrics should let the team know when to take corrective action rather than waiting for the project manager to intervene. Instead of using a measurement system to control a team, it should be used to empower the team to solve problems on its own.
• The team should design its own measurement system. The people actually doing the work know what metrics are best suited. However, a team should not develop project metrics or a measurement system without the aid of the project manager or other members of the organization because independent action could result in inconsistencies and parochial interests being served.
• Adopt only a handful of measures. The old saying, "what gets measured gets done," can be an opportunity if the right metrics and measurement sys tem are in place. Adding more and more measures as a means of encourag ing team members to work harder can have the opposite effect. Collecting data to support a measurement system takes time and can interfere with the planned work. Having a few key measures keeps the team focused and cre ates minimal interference. In addition, these measures create a common language among team members and the other project stakeholders.
• Measures should track results and progress. Using the metaphor of a car's dashboard, Meyer suggests an array of graphic indicators and easy-to-read gauges can be useful in helping a project team measure and track its own progress and in letting it know when to take corrective action. For example, a relative measure could be used to track the remaining project budget, as illustrated in Figure 9.2. As you can see, Figure 9.2 vividly shows that the project is consuming its budget faster than planned.
Suppose that you hired the infamous consulting firm Dewey, Cheatem, and Howe to develop an information system for your organization. The project is expected to cost $40,000 and take four months to complete. To keep things simple, let's also assume that the project requires twenty activities or tasks that are evenly divided over the four-month schedule. Since each task is expected to take the same amount of time, the expected cost per task is $2,000. By the way, the contract that you just signed also stipulates that four payments must be made at the end of each month. Therefore, your planned payments each month would be $10,000. This $10,000 a month that you plan to spend is called the budgeted cost of work scheduled (BCWS). If we were to graph the BCWS expenditures, the planned budget of cumulative cash flows would look like Figure 9.3.
At the end of the first month, let's say that you receive the following invoice for $8,000.
Dewev, Cheatem, and Howe
Amount Due: $8,000 Payment due immediately
This actually sounds like good news! If you take a look at Figure 9.4, you planned to spend $10,000 at the end of the first month, but the invoice you just received states that you only have to pay $8,000. It would appear that you are spending less money than you originally had planned. The $8,000 you must pay to Dewey, Cheatem, and Howe has another fancy name and is referred to as the actual cost of work performed (ACWP). That must mean your project is ahead of budget by $2,000, right?
Actually, all we are doing is staying within our budgeted or planned outlays of funds. To understand what's really happening, we need to take a look at the second page of the invoice.
Figure 9.2 Dashboard Metric
Dewey, Cbeatem, and Howe
Work completed for Month 1
page 2 of 2
It looks like the consultants from Dewey, Cheatem, and Howe are only charging us $8,000, but they only completed three out of the five tasks that were expected to be completed by the end of the first month. In fact, since we estimated that each task would cost $2,000, we have really spent $8,000 in actual costs to achieve only $6,000 of actual work. This $6,000 is called the earned value and tells us how much of the budget we really should have been spent for the amount of work completed so far. Earned value is often referred to as budgeted cost of work performed (BCWP), and Figure 9.5 shows the relationship of earned value to budgeted and actual costs.
Using these basic values, we can extend our analysis and see how the earned value metric incorporates scope, budget, and schedule. For example, we can determine a true cost variance, which is the difference between a task's estimated cost and its actual cost.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.