The Project Resource Request

Here is yet another template that I am digging out of my archives to provide here.  As you can easily guess, this document is designed for requesting resources at the beginning of your project based on information in your statement of work (SOW) and the estimates of resource requirements that either you or Sales put together in the pre-engagement process.  It is also helpful for requesting additional resources during the project.

How useful this is to anyone depends on the organization they work in.  If you have a mature PMO with processes in place, then I would guess that you already have a standard form or spreadsheet to use to request resource for your project.  However, if you’re one of just a few PMs or personnel acting in a PM role in your organization or you’re in the process of building some PM processes for a newer organization or even setting up a new PMO, then any template may be better than nothing.

As with all of these documents, if you want the original Word doc file, just email me if you think this will be useful or helpful.  And please, provide your own example if you wish.  We’re looking to learn and share information so I’m happy to use and post whatever you would like to provide to the readers of PM Tips.

PROJECT RESOURCE REQUEST

[Save file name as: client name RESOURCE REQUEST yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

WORK DESCRIPTION AND ROLE

Describe the work to be performed on the project by the resource(s) and what role the individual(s) will play on the project team.

DESIRED SKILLS

Describe the technical, business or professional skills needed by the resource(s) to successfully meet the needs of the project.

DELIVERABLES

Describe the deliverables the resource(s) will be responsible to complete as a result of their work on the project.

DATES REQUESTED

Starting: mm/dd/yyyy Ending: mm/dd/yyyy

HOURS OR % FTE

Provide the estimated number of hours or the percent of time the individual(s) will be need to be allocated to work on the project.

WORK LOCATION

Describe all of the locations the resource(s) will be expected to be located – if multiple locations, provide dates as they are know at the time of the request.

REPORTING STRUCTURE

Describe the reporting structure for the project and how the individual(s) will be expected to operate within this structure.

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.

Project Transition to Production Support

As part of methodologies I’ve previously discussed, the final phase is something that I call the Post-Deployment phase.  Once the project is implemented – or deployed – the delivery team, the customer, and the project moves on into the Post-Deployment Phase.

The Post-Deployment Phase is the period of time when the delivery team remains as intact as possible to support the customer and the deployed solution before a final and formal transition to technical, or production support.  This post-deployment period is usually somewhere between 30 and 90 days in length (30 is more likely) and that time period is set either during the sales process (and becomes part of the statement of work) or during the kickoff session.

Upon satisfaction of the post-deployment timeframe, support formally moves over to the company’s techical or production support team.  The template I am unveiling here is a formal document to record that transition process, allowing the project delivery team to identify specific things about the project that the production support team will need to know.  While reviewing this document, keep in mind that there are really three very key pieces of information in here that the support team will need to know the most about:

• Schedule
• Communication
• Change Control Process

PROJECT TRANSITION TO PRODUCTION SUPPORT

[Save file name as: client name PRODUCTION SUPPORT yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work performed.

SCOPE

Describe the deliverables/actions to be supported. Provide additional documentation as appropriate.

SCHEDULE

Describe the timing for support activities to be performed. Provide additional documentation as appropriate.

COMMUNICATION

Describe all required communication needs for support – What to communicate, to whom, in what format, and when. Provide additional documentation as appropriate.

QUALITY ASSURANCE

Describe the Q/A processes to be performed. Provide additional documentation as appropriate.

COST

Describe the support costs estimated by the project. Provide additional documentation as appropriate.

CHANGE CONTROL PROCESS

Describe how changes to the Production Support process will be addressed. Provide additional documentation as appropriate.

Closing Out the Project – Part 1

When you’ve reached the end and deployed the solution, then it’s time to make sure everything has been completed, all paperwork is done, and no stones are left unturned. It’s best to do that with some sort of checklist and I propose using a list similar to this:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?
• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?
• Do you feel the solution was cost effective?
• When would it be applicable to enhance or update the delivered solution?
• What is your executive leaderships view of the project outcome?

In Part 1, we’ll discuss the first three items above:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?

Have all the project objectives been achieved?

This should be fairly easy to evaluate. Look at the project schedule and review all milestones and deliverables. Have they been met? At this point, we’re not considering timeliness or budget, we’re just concerned with did we hand the customer what we said we would. Did we supply a Functional Design Document, did we provide weekly status reports, was training completed successfully and signed off, was user acceptance testing (UAT) fully completed including re-review of all issues and did we get official signoff, etc.

Though it definitely shouldn’t be the first time during the engagement that you do this – it’s also a very good time to go back to your kickoff session notes and see that all points discussed during that meeting have been addressed. Make sure at this point that the customer knows you’re concerned that you fully covered everything for the project – they’ll appreciate it and it definitely helps with customer satisfaction levels and can increase the chances of repeat business from this customer.

Is the client satisfied with the overall project?

You may think you can simply answer this yes or no based on your knowledge of how things went on the project and the communications you had with the customer along the way – but that is not always the case. On some projects, you can end up being very surprised by the customer’s on viewpoint of their satisfaction levels.

I’ve had customers on projects that went extremely smoothly later state that they weren’t happy about how I handled something or weren’t pleased with one of my team members or how we delivered ‘x’ deliverable. And I’ve had other projects were I was certain the customer was just about ready to ask that I leave the project only to find out that they were very happy with me and with the team and how things were going. They were just demanding and somewhat needed. But we were meeting their needs and they were happy. It’s amazing how off your perception can sometimes be concerning your perception of the customer’s satisfaction level and what their satisfaction level truly is.

Have the necessary post-project support agreements been established?

Usually you’ll move from deployment into a post-deployment with some sort of pre-defined plan to both hand-off overall support to your tech support group but also you’ll agree to make your original delivery team available for a 30 or 60-day window to do immediate fixes should problems arise in the functionality of the delivered solution. That’s something that just needs to be worked out with the customer and something that was likely planned for both by Sales with the customer during the sales process and discussed between you and the customer during kickoff.

Just make sure that whatever the plan is, you act on it. If it’s to keep your team available for 60 days should problems arise, then make sure that every team member knows that and that each of their managers know that as well. It can have an affect on their next assignments, but it must be addressed in advance of deployment.

Next

In Part 2 we’ll further discuss these items in terms of the project closeout checklist/review…

• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?

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.