Getting your message across

Project sponsors are busy people.  Project sponsors are senior managers in a business and that means they could well be managing several projects at once.  It’s not easy to juggle sponsoring multiple projects.  Added to this is the likelihood that they won’t ask questions when they don’t understand something.  Some senior managers are happy to admit that they don’t know or need clarification, but many would rather not confess that they don’t have a clue what you are talking about.

It’s up to project managers to make project sponsor’s lives as easy as possible.  There are lots of communications tips to use when dealing with senior people.  Here are some to try with your sponsor:

• Don’t use vague email subjects.  What do you think is more likely to be read: ‘Project ABC news’ or ‘Project ABC within 2% budget’?  If you label your emails in a way that makes it clear what the content is they are more likely to be read in a timely manner. Read more »

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 »

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

The Formal Project Request

Depending on the size of your organization, and of course whether you’re dealing with internal or external projects, it may or may not be beneficial to have a formalized project request process.

I ran only internal projects for a very large aviation and engineering firm in the late 1990’s and early 2000’s and our web development team had created a formal online project request process that captured key information for each project request. What that gave us was a standardized type and amount of key information for each project that came through making it easier to prioritize and assign the projects to the correct areas of our department (based on the business units they supported and the type of project that was being requested).

In Carl Pritchard’s book “The Project Management Communications Toolkit” he outlines what should be contained in a general project request document and what it is used for. Again, this all depends on which organization is originating the project request. If you’re dealing with external customers, your internal formal project request still may serve you well as a means to get consistent types of project information loaded into a common database from which you manage your entire portfolio of projects. No matter how it is performed or where the project request originates, a common process is usually helpful and recommended.

Much of the following text comes from Mr. Pritchard’s section providing his take on this process – however, I have taken liberties to add some of my own thoughts and details to his text.  I believe that his process, for the most part, does a pretty good job of laying out the information that is important to capturing the project request.

The Project Request

Purpose

Because different organizations interpret project requests (as a practice) differently, their purposes may vary as well. A project request may be a simple one-paragraph description of a project that has been formally submitted to management (either through a chartering process or proposal process). It may also be a specific form or format for submitting initial information about a project that may be of interest to the organization or that may serve an organizational need. For the sake of this discussion, the latter is assumed.

Application

A project request is used as a means to initiate ongoing analysis (feasibility study, impact analysis) of a project concept. Information available for the project request is generally somewhat scant, as the project request is used only to trigger other processes.

Content

A project request form includes only the most rudimentary information about a project concept:

• Project name (or a few-word description)
• Project description (may include a brief description of the goals or objectives of the project, as well as any problems/concerns it is designed to resolve)
• Timing
• Special resource needs (may include material or human resources essential to project initiation or implementation)
• Support organization (the anticipated “home” for the project if it is determined to be viable);
• Name of person completing the form
• Budget and Sponsor information
• High-level business case
• Criticality of need (aids in project prioritization especially for internal projects)

Although other information may be incorporated, these are the essentials for initiating a project and ensure that a consistent baseline set of information is available for any project that will undergo further study or scrutiny.

Approaches

The information embedded here may be redundant with information collected for a project proposal or feasibility analysis. That is why, particularly in smaller organizations, a project request form may be embedded within those other processes. Larger organizations use project request forms as an initial screening mechanism to enter projects into the process and to ensure that those that undergo more formal feasibility assessment are initiated at the appropriate levels within the organization.

Considerations

Because the project request form data are frequently redundant with information gathered in other processes, it should be applied only when there are copious requests being filed on a regular basis, the organization is large, and tracking mechanisms are limited. In smaller organizations where project owners are easily identified, project requests may be seen as purely administrative overhead.

Project Planning: Evaluating the Political Environment

We’ve talked a lot about the act of planning your project. Review the statement of work (SOW)…check. Review the estimate from Sales…check. Request your project resources…check. Review the draft project plan and revise it – vigorously…check. Plan for your kickoff session with the customer…check.

What hasn’t really been discussed is the act of evaluating the political environment within your organization and the customer’s organization. It may be something you can’t always do too much of up front, but it is something that will have to be revisited and performed throughout the engagement. Here are the basics of what needs to be done up front and revisited in order to more successfully plan your project.

Consider the potential effects for your stakeholders. Once you’ve identified all of your project’s stakeholders, you should take that process one step further and identify who stands to gain (or lose) if your project succeeds and who will gain (or lose) if your project is deemed unsuccessful. It can be of value to understand and appreciate the nature of everyone’s stake in your project. Use this information to your advantage – it can be critical information to have on hand if you need roadblocks removed or key resources and skill sets made available to your project. Stakeholders can help make things happen.

Identify whose support will be needed. Try to identify who’s in the best position to help and support your project. More of the same from above. Keep this list close by throughout the project – because you will hit roadblocks and some of them may not be able to be overcome by your will and effort alone.

Identify who is likely to work against you. Identify the parties who may feel threatened by your project or who, for whatever reason, would not like your project to succeed. What you do with this list depends on the situation. At times, these individuals need to be avoided…and at other times they may need to be included and massaged to help ensure positive results. Power can definitely shift during projects – be aware.

Secure a project sponsor. Identify someone in management who can serve as a sponsor for your project. Sponsors are typically members of management who have a significant amount at stake in the success or failure of your project. Sponsors can work through political issues that are beyond your sphere of influence.

Address unrealistic targets or constraints. If your proposed project targets, specifically schedule and cost, exceed management expectations, you may be forced into a situation where you’re pressured into accepting cost, schedule, or other targets that are unrealistic. If this happens, I’d urge you to pursue either or both of these options:

1. Respond with a data-driven analysis that suggests that the project targets are unrealistic.
2. Continue to publish documents that display your original cost and schedule targets. Once you publish documents with unrealistic targets, you’ve pretty much sealed your fate and doomed yourself to project failure.  Don’t give in…stand firm if you know the targets are unrealistic.

Summary

Careful planning doesn’t guarantee project success, but it certainly doesn’t hurt. Failing to plan is planning to fail. Look at all the angles – consider who can help and who can hurt and act accordingly. You don’t have to make everyone happy – that’s for sure. But there are many eyes on your project and many individuals who stand to benefit from your project success. Know them and use that info to your advantage.