Onboarding with Success

When you’re asked to jump on a new project how do you go about doing that to ensure your best chance for success? That may often depend on why you’re being asked to take over the project … and it can be for any one of the following reasons:

• Previous project manager failed to manage the team and project effectively
• Previous project manager lost the customer’s confidence
• Previous project manager lacked the expertise to lead the project based on new direction
• An emergency necessitated an early departure for the project manager
• Co-management became a necessity due to changes on the project Read more »

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 »

Knowing When to Start Billing

In this article, I am again looking at it more from the perspective of the IT Consultant rather than purely a project management situation. Ultimately, the two are often one in the same, but in this instance the IT Consultant/Project Manager is running the entire show themselves in an independent role and working through the perplexing situation of when to start billing, what to give away for free, and how much leeway to give the customer/client.

One thing you must understand when dealing with new clients is when it is proper to start the clock – when you should start charging the client for your problem-solving services. Both during the interview and afterward, new consultants are tempted to rush in and do their best to solve every problem that the client presents them with – long before they’ve gotten any real commitment from the client to pay them for these efforts. Although providing such free assistance may make the client very happy, it by no means ensures that the client will subsequently pay you for more work. In fact, quite often the opposite is true. As one consultant I discussed this with stated that giving away free advice usually leads to giving away more free advice. It’s hard to break that cycle with some clients.

Clients are human

This isn’t because clients are exploiters. It is just normal human instinct to see what we can get for free and only pay for what we absolutely have to. But because clients will gladly allow you to do work for them for free that they can’t bring themselves to pay for, successful consultants must pull off a delicate balancing act. They must suggest to clients that they can solve their problems, without actually solving these problems until the clients agree to pay for it.

Which is not to say that you won’t do some work for free. Almost all successful consultants accept that they have to give some work away for free periodically to clinch a deal with a client. Most consultants give clients a free initial consultation lasting anywhere from one to three hours and many invest more unpaid hours drawing up formal proposals for potential clients.

Set consultation limits

But successful consultants also know that they must set clear limits on how much unpaid time they will devote to the client. One consultant I’ve worked with explains it like this…”Generally, I don’t bill for the first meeting with a prospective client. But I don’t give any real advice in that initial meeting either. Once we’ve gotten past the first meeting and agreed to the terms of the contract, then all the work that I perform related to that client is billable.”

Another colleague of gives potential clients one or two hours of free time in which he explains his services and shows them how he might be able to help them. Then he explains that for any concrete and in-depth analysis, they’ll have to pay.

Though experienced consultants emphasize the need to set strict limits on the amount of free time they spend on any client, new consultants often fear that they can’t get away with this kind of behavior because of their lack of experience. They tend to think that giving away a free sample of their work might be a more effective way of landing a new client. But experienced consultants will likely agree that this is almost always a mistake. If you don’t act as if your time is valuable when confronting clients, then why should they? I guarantee you that they won’t place a higher value on your time than you do.

Set client expectations

It is important to make it clear that you expect to bill for your solutions. It is equally important to let the client know when the billing clock will start ticking. Many consultants state that their potential clients tend to stretch out that first meeting and start to ask for advice during that initial consultation. An easy way around this is to follow a strict policy that the first hour is free. After that, all time is at the normal billing rate. This does dictate that the rate be discussed and established as early as possible so you need to feel comfortable about that very early on. Establishing policies such as the one free hour stance lets the client know up front that you will not allow yourself to be taken advantage of.

Earned Value Reporting – Intro Part 1

Some organizations place significant importance on Earned Value Reporting as part of their project management practice while others do not. I personally have yet to work for or with an organization that placed any emphasis on this aspect of PM reporting whatsoever. That’s unfortunate, thought it has made my reporting job easier over the years.

For the purposes of this and the next few articles, we’ll look at EVR and some of the different reporting scenarios that are used to show progress and value for the PM process and the PMO. Much of this information is coming from the book “The Project Management Question and Answer Book” by Michael Newell and Marina Grashina.

What is an earned value report?

An earned value report is the preferred method for measuring progress in projects. It has the advantage of showing on one piece of paper the pertinent performance criteria for a project. From the earned value report the time-phased, planned expenditures for the project can be seen along with the actual cost of the project work that was accomplished and the amount of work that was actually completed. From this report the cost variance and schedule variance can be calculated.

There are several factors in the earned value report that we must know in order to use it effectively. These factors are the budgeted cost of work scheduled (BCWS), the budgeted cost of work performed (BCWP), and the actual cost of work performed (ACWP). These three elements form the basis for the earned value reporting system.

PMI has seen fit to change this almost universally accepted alphabet soup. It remains to be seen whether PMI will be able to persuade the entire project management community to make the change or whether PMI will have to change back to the more widely accepted way of calling things. There are certainly going to be some difficulties since most managers use PV to mean present value and EV to mean expected value. We shall see. In the year 2000 version of the Guide to the Project Management Body of Knowledge (PMBOK), PMI refers to these as follows:

Budgeted Cost of Work Scheduled (BCWS) = Planned Value (PV)

Actual Cost of Work Performed (ACWP) = Actual Cost (AC)

Budgeted Cost of Work Peformed (BCWP) = Earned Value (EV)

We will keep the traditional terms, which are still commonly accepted.

The first one of these factors is the BCWS or PV. This stands for the budgeted cost of work scheduled or the planned value. Once you catch on, you will say that it is just what it says it is. It is a plot of the budgeted cost of the project activities on a cumulative basis over a horizontal axis of time. All project tasks have a task cost that was derived from the estimated cost of each activity and a schedule that says when the activity will take place. The BCWS is simply a plot of these values according to when in time the expenditures are expected to take place. So, this is pretty simple to see, as it is just the project plan plotted out in terms of dollars of budget showing when those dollars are expected to be spent.

This is a method of showing the project plan in an easy-to-see way on a single piece of paper. By showing it in a cumulative way we can see the total expenditures to date for the project as well as the total cost of the project all on the same piece of paper. Notice in Figure 1 that the shape of the curve is similar to the letter S. Nearly all of the planned value curves for projects will have this shape because projects generally start out spending money slowly and then increase the rate of expenditure, reach a peak where money is being expended at its greatest rate, and then reduce the expenditure rate until the project is ended.

FIGURE 1

Next

In Intro – Part 2 we will look at Cumulative Variance Reporting.

The Project Disaster Recovery Plan

From my experience, it’s not often that you’ll put together a Disaster Recovery Plan that is project-specific. The exceptions are government projects – which sometimes require separate one-time documents for the project for which you charge dearly to put them together – and larger, very visible and mission critical projects that may involve highly sensitive data.

However, if you find yourself up against a wall and facing a deadling to put a DRP together, maybe this template will be just what you need. As with all the others I’ve posted over the past few days, if you want a Word doc version of this template, let me know and I’ll be happy to send it out to you. And, if you have your own version that you’d like to see posted and share with the readers here on PM Tips, send it along to me and I’ll see that it gets posted.

Disaster Recovery Plan

1.0 Preliminary Planning

This part of the plan describes the purpose, scope, assumptions, responsibilities, and overall strategy relative to the plan.

1.1 Purpose

Describe the reason and objectives for having a DRP.

1.2 Scope

Describe the extent of the coverage of the plan in concise terms.

1.3 Assumptions

A DRP is based on several categories of assumptions. Most can be established only after the completion of a risk assessment that includes the following information:

• Nature of the problem
• Priorities
• Commitments to or Assumptions of Support

1.4 Responsibilities

Document the specific responsibilities as assigned by management to all activities and personnel associated with the plan.

1.5 Strategy

The selection of appropriate strategies should follow the risk assessment. Until the risk assessment is completed, it is difficult to know the critical systems that must be maintained, and the demand for resources that will be made to support those critical systems.

1.5.1 Emergency Response

The strategies selected must provide a sufficient base upon which procedures can be devised which afford all personnel the immediate capability to effectively respond to emergency situations where life and property have been, or may be, threatened or harmed.

1.5.2 Backup Operations

Most backup sites will not have sufficient equipment, personnel, supplies, etc., to sustain the complete operational requirements or another facility. In this case, a more detailed backup strategy must be developed.

1.5.3 Post-Disaster Recovery Actions

The strategy for recovery must be linked closely with that of backup operations, as initiation of recovery actions may overlap.

1.6 Record of Changes

Each DRP should be preceded by a change audit record that lists all changes to this document, including the change number, change date, change detail, person making the change, and the date that the document is published.

1.7 Security of the Plan

This plan should be available to just those personnel affected by the plan.

2.0 Preparatory Actions

This part of the plan is key. Preparatory actions are critical to the emergency response, backup, and recovery from all but the most routine problems.

2.1 People

Provide names, addresses, and telephone numbers of all people, internal and external (vendors and/or contractors) who may be required in any backup or recovery scenario. Alternates should be designated.

2.2 Data

It is essential that all data on which backup and recovery are dependent be adequately recorded, stored offsite at a secure, environmentally safe facility, maintained in as current condition as is feasible, and occasionally tested to ensure validity.

2.3 Software

It is also essential that a current copy of the systems and application software programs be stored offsite at a secure, environmentally safe facility that will make that software available immediately.

2.4 Hardware

A DRP should minimize, to the greatest feasible extent, the dependence on rapid replacement of hardware. Define a list of the hardware and where replacements are available. Identify any contracts in place to ensure the availability of any hardware.

2.5 Communications

Define both the internal (LAN) and external (WAN) communications connectivity.

2.6 Supplies

Describe any special supplies that are needed.

2.7 Backup Site

Describe the location of the backup facility. When choosing a backup site, consideration should be given to accessibility, and the site should be free of whatever external problems are hampering the supported facility.

2.8 Space

Describe the physical location where the recovery operations will take place.

2.9 Power and Environmental Controls

Define the power and environmental controls that are required for the recovery.

2.10 Documentation

Describe all backup documentation that is kept in the offsite facility.

3.0 Action Plan

This part of the plan consists of the “what to” actions to be accomplished by those personnel or activities identified in section 1.4, and should only consist of concise, short instructions of the specific actions to take in response to each of the categories below:

3.1 Emergency Response

Include the immediate actions to be taken to protect life and property, and to minimize the impact of the emergency.

3.2 Backup Operations

Describe what must be done to initiate and effect backup operations.

3.3 Recovery Actions

These should be limited to describing what to do in effecting recovery from disasters, including any alternate manual scenarios until the systems have been restored at the backup site.

4.0 Post-Disaster Review

Immediately after the resumption of the IT function, IT management should assess the success and adequacy of the plan, and update the plan accordingly.

Approved:

__________________________________________

Business Sponsor

__________________________________________

IT Director

__________________________________________

Development Director

__________________________________________

Infrastructure Director