Caring Enough to Do It Right

I’m a foster parent who is also an adoptive parent.  What that makes me is a foster parent who ‘really’ cares…. a lot.  And I have friends who are in the exact same place.  I recently ran into a situation that translates very well into frustrations we see in the project management world all the time.  It centers around the equivalent to what we all know as requirements.

On one hand you have a biological family who pose a threat – they are safety concern for whatever reason.  They have visits with their biological child – that’s their right as parents until a judge says otherwise.  You have a visitation center who’s guidelines call a ‘supervised’ visit one thing.  On the other hand you have a caseworker who thinks a ‘supervised’ visit means something entirely different – like one-on-one supervision – not fully understanding that a truly ‘supervised’ visit requires a judge’s order.  And in the middle you have a foster parent who cares and happens to be the only one who sees and understands the disconnect between the two.

Do you see how this applies?  Has this ever happened to you as a project manager or a project team member?  You have the customer sponsor, primary stakeholder, or project manager who thinks they need ‘x’.  Then, during meetings after kickoff you encounter customer SME’s or end users (many times they are one and the same) who say they need ‘y’.  And there you are, the only one in the middle who really sees the disconnect.

You’re either a very concerned foster parent who’s trying to look out for the defenseless life of a small baby or the frustrated project manager who’s trying to look out for the well-being of a project that now appears headed toward a re-work phase where project requirements once thought to be ‘solid’ now need to be revisited.  At the very least you have a big project budgeting issue.  In the worst case scenario you will experience resource issues, extreme budget problems, task conflicts, timeline issues, and a potential project cancellation as you deal with going back and re-doing some work from the beginning while the project essentially comes to a screeching halt.

Read more »

Delegate and escalate: two important skills

When you kick off a project, you should know how you are going to get things done. You’ll have processes in place for many things already, thanks to your PMO, or as a result of having done them before. However, do you have a clear approach for delegation and escalation?

Delegation and escalation are two sides of the same coin. Delegation is giving work to someone in your team or maybe on the same hierarchical level as you. Escalation is giving work to someone above you, such as the project sponsor. The same principles apply for both task allocation exercises. The person receiving the tasks needs:

• Clear instructions on what to do with it
• A deadline by when you need it done
• An appreciation of what will happen if it doesn’t get done i.e. setting the task in the wider context of the project.

Read more »

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