Communicating Project Scope

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

The Scope Document

Once the project scope is defined, it must be documented to ensure that everyone assigned to the project will address the right tasks and work toward the same project goals. A formal scope document is essential to keeping a project on track. The order that these scope items are covered and the amount of space devoted to each in this document will depend on the type and size of the project and the number of scope items that need to be covered. On small projects, needs, goals, objectives, and missions will often be the same thing – easily described in a few statements. Distinguishing between these things is not that important, but establishing a flow from less measurable statements of need to more measurable ones truly is important. Read more »

Earned Value Reporting – To Complete Schedule Performance Index

In this article on Earned Value Reporting we’ll look at something similar to the To Complete Cost Performance Index – the To Complete Schedule Performance Index, or TCSPI. The To Complete Schedule Performance Index tells us the required schedule performance index that will be needed to meet the schedule.

The book “The Project Management Question and Answer Book” by Michael Newell and Marina Grashina is the source for much of this overview.

What is the to complete schedule performance index?

The to complete schedule performance index, or TCSPI, is similar to the TCCPI except that it calculates a required schedule performance index that will be necessary to meet the project schedule. This measure is rarely used. It is included here for completeness. It has the same problems as the TCCPI and is even more abstract and difficult for people to understand.

The calculation for the TCSPI is done by dividing the work remaining by the remaining schedule.

TCSPI = (BAC – BCWP) / (BAC – BCWS)

It can be seen that as a project’s schedule performance index moves below one, the TCSPI will increase and become greater than one. Although called an “index”, this is not really accurate since all indexes indicate something bad when they fall below one and this index indicates something bad when it is greater than one.

There is a mathematical difficulty with this term as well. If a project is over budget toward the end, it is possible for the BAC and the BCWS to be equal. This produces a division by zero and a point of discontinuity.

Under normal conditions it results in a value that indicates the required performance that the project must have from now until the end of the project.

Example:

Suppose a project is somewhere near 50 percent complete:

BCWS = $100,000

BCWP = $95,000

ACWP = $97,000

BAC = $200,000

SV = BCWP – BCWS

SV = -$5,000

What is the TCSPI?

TCSPI = (BAC – BCWP) / (BAC – BCWS)

TCSPI = (200,000 – 95,000) / (200,000 – 100,000)

TCSPI = 1.05

Notice that if the schedule variance remains the same as the end of the project approaches, the TCSPI increases rapidly. Suppose we have the following when the project is approximately 95 percent complete:

BCWS = $195,000

BCWP = $190,000

ACWP = $192,000

BAC = $200,000

SV = BCWP – BCWS

SV = -$5,000

What is the TCSPI?

TCSPI = (BAC – BCWP) / (BAC – BCWS)

TCSPI = (200,000 – 190,000) / (200,000 – 195,000)

TCSPI = 2.00

As we approach the end of the project, the schedule variance has not changed, but the TCSPI has changed from 1.05 to 2.00. This means that the work that must be accomplished from now to the end of the project must take place at a rate that is twice as fast as was originally planned.

Construction Software State of the Industry from Software Advice

My friends at Software Advice have sent over another interesting original article that they have put together pertaining to software in the construction industry. This one comes from Houston Neal and it kicks off a series of reports the group is doing on trends within the construction software industry. Please visit their site at www.softwareadvice.com for the original report.

Construction Software State of the Industry Report

This is the first in a series of “state of the industry” reports in which we will share our observations on construction software industry trends. While reporting the recessive state of the industry is not breaking news, there are some interesting trends that we can share. Not everything is gloomy, and significant technological shifts are underway.

Our observations are based on roughly 6,000 conversations with construction software buyers over the past year. In these calls, our team listened to buyers’ “pain points” – the business problems they were looking to solve with new software. From there, we recommended what we felt were the best solutions. We later surveyed each buyer to find out if they ended up buying software, what they bought and how it all went.

Estimating and takeoff solutions are in demand

We’ve seen a very healthy level of interest in construction estimating software across all divisions. Over and over we hear contractors saying something to the effect of, “Bidding has gotten very competitive, which means I’ve got to be as accurate as possible.” As a result, we’ve seen a lot of estimators replacing their spreadsheets and manual processes with database-driven estimating systems.

We’ve also seen plenty of interest in on-screen takeoff software. We’ve seen three primary reasons for this:

• Increasing the speed and accuracy of takeoff measurements (see previous paragraph);
• Avoiding the printing costs of paper plans; and,
• Responding to increasing electronic plan delivery and use of online plan rooms.

While demand for onscreen takeoff appears fairly strong and growing, we have seen a considerable amount of downward pricing pressure in that market.

Software as a Service is in the right place at the right time

Software as a Service (SaaS) is gaining momentum in many software markets. In fact, we would agree with other IT prognosticators that SaaS is a major structural shift in software deployment and is here to stay. We’ve seen this model succeed in the project management segment where there is a clear need for the collaborative benefits of web-based software. Moreover, the current recession is making the SaaS model more attractive to contractors because:

• Subscription pricing can easily be added to a project’s general conditions;
• Low up-front costs allow project managers to avoid an onerous approval process; and,
• Faster and less expensive implementation makes the new systems more digestible.

We have not seen much demand for SaaS accounting, estimating or service management, although we do get asked about it now and then. We also have not seen many vendors emerge to deliver that sort of solution. We would not be surprised to see SaaS accounting and/or estimating solutions emerge over the next few years.

LEED credit tracking creates new demand

Another trend driving the adoption of SaaS project management systems is the increasing demand for LEED credit tracking. LEED certification has grown in popularity; so too has the need to track the detailed documentation requirements related to earning LEED credits. At their core, projects seeking LEED certification need document control and efficient communication. This is the core of what project management systems deliver. Going one step further, we are seeing a number of project management vendors building in specific LEED credit tracking modules within their system. Houston Neal wrote a great post on how to Track LEED v3 Credits in Project Management Software back in July.

Stimulus funds are trickling down, slowly

Government and other civil construction has remained healthier than commercial and residential construction. However, we have not seen the American Recovery and Reinvestment Act of 2009 (ARRA) have a big impact on software spending. We believe that the temporary nature of stimulus spending is not enduring enough to drive capital investment in software systems. Our hope is that ARRA will help accelerate the economy to a point where traditional IT investment levels resume. However, Chris Thorman recently wrote a quick analysis of the ARRA that showed that stimulus spending has had a nominal effect on putting roughly 1.6 million unemployed construction workers back on the job.

There has been speculation that Stimulus-funded construction projects would drive sales of project management software. The thinking behind the forecast was that ARRA projects would require a higher level of accountability. Project management software – known for strong document tracking capabilities – would provide the audit trail needed for this transparency. However, we have not seen this translate into a meaningful increase in sales.

Fewer accounting & job costing replacements

We’ve seen fewer firms replacing their core accounting and job costing systems over the last year. In prior years, we had seen replacement activity when company growth pushed existing systems to their limits. In the absence of growth, more firms seem to be staying put with their existing systems. Firms that are buying new accounting systems tend to identify one or more of the following three pain points:

• Inability to achieve detailed job cost reporting from “generic” accounting systems;
• Lack of integration to project management or service management systems; and,
• The need to accomplish same amount of work with fewer employees.

Outlook for 2010

As the construction industry begins to rub its sleepy eyes, we agree with most experts who say that 2010 will be a transitional yet slow year for the industry as a whole. Company budgets likely won’t fully recover in 2010, limiting the purchase of construction software. However, so far we’ve noticed more activity this quarter than any other this year. Hopefully this level of interest will carry over to 2010.

This article originally published at: Construction Software State of the Industry Report.

Defining Risk Management – Part 9: Risk Control

This is the ninth and final installment in the Defining Risk Management series. In this final segment, we look at what risk control is and how we monitor and track the risks that are identified and new ones that are encountered on our projects. This information is again, for the most part, derived from the book “The Project Management Question and Answer Book.”

What is Risk Control?

The process of monitoring and controlling and keeping track of the identified and the unidentified risks is risk control. In this process we hope to identify risks that are no longer possible and risks that are coming due, as well as any new risks that may become evident. We will also monitor risk activity to make sure the risk plans have been carried out successfully. Problems that have been found out in the risk plan can help us adjust the plans for future risk activities.

Risk control and monitoring are part of the risk management process and must be started early in the project and continued until the end. As the project progresses, we will find that many of the risks will change, some will no longer be possible, others will happen and be disposed of, and new risks will be identified. In addition we will learn about the project and the risks associated with it and adjust our vision of individual risks.

The level of risk tolerance should be monitored as well. The attitude of the stakeholders will change during the course of the project. Communication with all stakeholders is important since it gives us a means of assessing changes in their risk tolerance.

Risk control may involve changing the way we look at risk. There are several reasons why this might take place. The risk tolerance of the stakeholders may change; the risk tolerance of the project team may change. As the project progresses toward its completion, certain risks that were thought to be very important to the success of the project may become risks that are no longer thought of as being so important.

In the beginning of the space shuttle project, the heat-resistant ceramic tiles were originally thought of as being one of the major risks in the program. If the tiles were lost or their integrity was compromised, the heat of reentry, some 3,000 degrees Fahrenheit, could reach the airframe’s aluminum structure and cause breakup of the ship. As time went by and NASA flew over one hundred missions with the space shuttle vehicles and the whole take-off and landing process became routine, the perceived severity of the risk diminished. During this time there were minor failures of the reentry tiles, but these failures proved to be minor repairs, and the shuttle vehicles suffered only minor damage. A program to develop a method of repairing risks in space was discontinued because it was deemed impractical. Part of the impracticality was probably because of the perceived reduction in the probability and impact of heat shield failures.

On February 1, 2003, just three days after the anniversary of the crash of the space shuttle Challenger, Columbia, the oldest space shuttle in the fleet, disintegrated on approach to landing. At this writing the investigations have hardly begun, but the heat shielding tiles are once again suspect because there is little that can go wrong on reentry except for a heat shield failure.

We see that during the project, the evaluation of the risk of heat shield failure began as a high risk. As time went on, the risk was revalued lower and lower. After the crash, the valuation of the risk has no doubt been raised higher than its former level.

In all projects, as we gain knowledge and experience about the project and its risks, we will change our attitude toward the risks in the project. This is natural and important. As we learn, we must change the level of effort we spend in certain areas or we will never have the resources, time, or money to complete any project.

A control system for risk is influenced by the organization the project is being managed under as well. In a project that is high in risk, we might have a person who is at a high level and is exclusively responsible for managing risks. On projects that are relatively routine by comparison, the risk manager may be the person responsible for the tasks that are most affected by the occurrence of a risk. These persons are responsible for communicating risk progress to the project manager and other affected stakeholders.

Risk audits can be used to document the effectiveness of the risk plans and the strategies that were used to mitigate, avoid, or transfer risks. A judgment can be made as to whether it was cost-effective to ignore the risks that were ignored.

Deviations in the project performance may indicate the effect of risks on the project. The earned value reporting system is helpful in identifying trends in performance on the project. Generally, schedule slippage and cost overruns are the result of some problems that have occurred. Trends in certain areas may indicate that risks are more severe than was anticipated or that new risks have taken place. One important product of the earned value reporting system is the indication of the cost and completion date at the end of the project. The sooner these slips in schedule or budget overruns can be communicated to the stakeholders, the better it will be for the project. Schedule slides and budget overruns that are severe enough can result in project termination.

A workaround is an unplanned response to a risk that was previously unidentified. These are the unknown risks that were discussed at the beginning of this chapter. They are also the risks that were passively accepted since these were deemed to be risks that would be ignored. Workarounds are paid for from funds from the contingency reserve or the management reserve, depending on whether the risk was identified and accepted or whether it was unknown until it occurred. In any case, the funding for the workaround comes out of these accounts and is put into the operating budget of the project, and a new baseline is created.

Since contingency plans and workarounds are not part of the project baselines until they occur, they should be initiated and approved by the execution of an official change notification. Remember that changes to the baselines should require an official change notification as the vehicle for showing the change in funding, schedules, and scope resulting in a new and current baseline.

Defining Risk Management – Part 5: Risk Tolerance

In this article, we will cover risk tolerance – your organization’s ability to tolerate different risks and identify those lines in the sand for tolerable risks and intolerable risks. Many factors can weigh in to an organization’s ability to tolerate certain risks. Some that come to mind are: how critical is the risk to the success of the project, will avoidance cost us on the project or cost us a certain level of customer satisfaction, and how does the cost/benefit analysis on the risk compare with the profitability of the project and the risks potential impact to that profitability.

This discussion on risk tolerance comes mainly from another excerpt of the book “The Project Management Question and Answer Book.” After reading, please feel free to share your thoughts on the subject as I feel this one is critical as we move forward on our projects. Do we care about certain risks? How much effort do we put into avoiding or mitigating certain risks based on their perceived financial or schedule impact…etc?

What is Risk Tolerance?

Risk tolerance is the willingness of some person or some organization to accept or avoid risk. In any group of people there are gamblers or risk takers and there are nongamblers or risk avoiders. People who have a low willingness to accept risks and the consequences of risks are called risk avoiders. Those people who are willing to take risks are called risk takers.

It is important to know that people and organizations have differing risk tolerances. Some customers do not want to risk the delivery of the project they are paying for by taking a chance on something new. Other customers will welcome the opportunity if the danger is not too great. For example, if we were manufacturing a product like some of the products that are advertised on late-night television, we would probably have a relatively high risk tolerance for the product’s failure. This is because the product is priced very low and is not going to put anyone’s life in danger. Customers buying very low priced items can expect them to have a shorter useful life than the advertising indicates. If customers want a product that will last longer, they buy an item that is built better and is probably more expensive.

This ability to choose is related to risk tolerance. In the mind of the consumer there is a tolerance for risk, which is expressed in his or her willingness to spend money. A consumer who is interested in having a highly reliable product that will last a long time is willing to pay more to get these features. Another consumer who is not willing to pay more to get a better product will be more accepting of the risk that the product will fail.

If we draw increasing impact and increasing probability on an X and Y axis, we can draw the locus of all points of equal severity as a line on the graph in Figure 1.

Figure 1: RISK TOLERANCE

Acceptable risks are any risks that are below and to the left of this locus of points of equal severity. Unacceptable risks are those risks that have a severity above and to the right of this severity line.

If we shift the severity line up and to the right, as in Figure 2, we are describing a person or an organization that is more of a risk taker. That is, the severity of the risks that one is willing to take is higher than before we shifted the line, and the person or organization shown is more of a gambler.

Figure 2: RISK TOLERANCE: GAMBLERS

If, on the other hand, we shift the line down and to the left, as in Figure 3, we are describing a person or organization that is less of a risk taker. That is to say that the severity of the risks that a person or organization is willing to take is less than before we shifted the line.

Figure 3: RISK TOLERANCE: AVOIDERS

In the classes we teach, we often perform the experiment of telling the students that we are willing to bet money on the roll of a single die, a cube with a number one through six on each side. (That’s half of a pair of dice to you nongamblers.) In the bet we say that if the die comes up with a one or a two, we win. If the die comes up with a three, four, five, or six they win. The question is, “Who would be willing to play for a penny?” Nearly everyone stays in the game at this point.

Then the stakes are raised to one dollar, and some of the people no longer want to play. As the stakes are raised higher and higher, more people drop out of the game. Eventually, unless there is a really hard-core gambler, everyone drops out of the game because the stakes are too high.

Even though the odds are very favorable, four chances out of six to win, when the bet is high enough, people will not play because the pain of losing is too great even when there are favorable odds. This is a great example of risk tolerance. Individuals and companies do the same thing with threats and opportunities. In risk tolerance we are concerned with people’s personal values and views as well as the company’s values and views. We may be dealing with a high-flying company that is willing to take many chances, but the individual who is representing the company may not be willing to stake his career on the risk you are suggesting. On the other hand, we do not want to be misled by the salesperson who is optimistic about everything until the sale is made.

Risk tolerance is somewhat describable in monetary terms. Our risk tolerance is how much we are willing to lose if the risk happens. In the case of a product that is sold to a consumer, the cost of the failure of the product might be the cost of the repair or replacement of the product if it fails. In the situation where someone’s life is in danger, these decisions become much more important. The tolerance for a risk that is life-threatening is very high indeed. This is because we cannot put a monetary value on human life.