Getting to the Actual Project

The real need?  Does the customer know it?  Do you know it from the initial information given to you?  Let’s look at the following project scenario….

Dave walked briskly over to Bill’s cubicle. “Bill, I just got a call from Amy. She’s got a problem and needs our help. I’d like you to go over there right away and get the details. Figure out what she needs and take care of her.”

Bill was pleased to be assigned to one of his organization’s most valued clients. By the next afternoon, he was sitting in Amy’s office, carefully reviewing the documents she’d prepared.

“Bill, we need the capability of screening all of our incoming components before they come into the assembly line,” said Amy. “You’re free to do this any way you’d like; just make sure that they fall within these guidelines.” She handed Bill some design documents and a list entitled Incoming Material Screening Requirements.

Bill was happy that Amy had given him free rein in determining the solution to her problem. He studied the project requirements and formed a project team. Then, he and his team developed and installed the hardware and software necessary to check all incoming components for compliance with the screening requirements. It was truly a thing of beauty. Bill was proud of the job he and his team had done.

Less than a week later, Dave called Bill into his office. “Bill, Amy just called me,” he said. “They’re still having the same problem as before— too many rejects coming off the end of their assembly line. What happened?”

Suddenly Bill realized what had happened. He had just discovered Amy’s true need—the hard way.

(The above project scenario comes from Gary Heerkens’ book entitled, “Project Management.”)

I really like the example above.  It’s simple, straightforward, gives you the impression that the problem has been solved through the project work and then BAM! … you realize that nothing has changed and you’re smacked upside the head with management questioning you wondering what you actually did on the project.

Read more »

Improving Requirements Quality with Use Cases

People sometimes like to dive right in to requirements definition by simply starting to write them on a blank sheet of paper – or blank Word doc for those of us who have gone completely green. Starting the requirements definition process this way can be very intimidating at best and full of oversights, omissions, and conflicts at worst. Even if you define and document scope in detail as I’ve discussed in the past, it’s still a big leap from a scope document to detailed requirements. Customers often have a hard time with requirements and you certainly can’t write all the requirements for them. You can help … but be sure to bill for it.

Sample ATM system usage use case diagram

Use cases are a simple, cost-effective way to build a consensus among stakeholders and to discover missing requirements. They tend to address two large classes of requirements errors – omitted requirements and conflicting requirements. While drilling down further into requirements, the customer – usually with your help – can utilize use cases to get detailed requirements across all life-cycle phases to support the requirements definition process.

Why develop use cases?

Use cases are relatively easy to generate. The customer must access their stakeholders and subject matter experts (SMEs) to get well-thought out use cases that can be used to derive detailed and meaningful requirements for the engagement. Below are some of the reasons and pluses for generating these use cases: Read more »

A Nine-Step Process to Requirements Definition

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.

Until a few years ago, the requirements definition process was only briefly discussed in books that addressed project management, systems engineering, and software engineering. Many texts assume that the requirements are a given and show the requirement definition process as a single step on a waterfall chart. Most college curricula never even address the subject of requirements, much less the requirement definition process. Books devoted to requirement definition finally began to appear in the early 2000’s. Some outlined complex requirement definition processes, but more complex is not necessarily better. Most, if not all, of the benefits of a complex requirement definition process come from a few key steps. Overly complex processes use significantly more resources than simple ones do without significant incremental gain. 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

Documenting Lessons Learned

It is my belief that the act of conducting and documenting a Lessons Learned session with your team and your customer is critical and one of the least utilized tools of the project management trade. Seriously…the project is basically deployed and you’re ready to move on to other things. One of the last things on your mind is to examine the good and the mostly bad things that went on during the project.

However, when utilized, this can be very helpful and critical information both for you as a PM on your future projects and for your organization. It can also be very helpful for your customer and your own tech support in post-deployment support situations.

Carl Pritchard outlines his version of a Lessons Learned report below from his book “The Project Management Communications Toolkit.” Again, by including it here, I do not necessarily agree with everything stated, but I think as PMs it’s important for us to understand the various ways to handle such activities because what works in one industry or for one customer or project may not work for another.

The Lessons Learned Report

Purpose

Lessons learned are used at midpoints of the project and at project completion to catalog significant new understandings that have evolved as a result of the project. They are used to build the knowledge base of an organization and to establish a history of best and worst practices in project implementation and customer relations.

Application

Lessons learned should be applied across the organization to facilitate consistency. They should be used and reused as new projects evolve with concerns similar to those addressed by the original lesson learned.

Content

Lessons learned include detailed, specific information about behaviors, attitudes, approaches, forms, resources, or protocols that work to the benefit or detriment of projects. They are crafted in such a way that those who read them will have a clear sense of the context of the lesson learned, how and why it was derived, and how, why, and when it is appropriate for use in other projects. Lessons learned represent both the mistakes made on projects and the newer “tricks of the trade” identified during a project effort.

The content of a lesson learned report should be provided in context, in detail, and with clarity on where and how it may be implemented effectively. Because lessons learned are often maintained in a corporate database, the lesson learned documentation will frequently include searchable keywords appropriate to the project and the lesson.

Approaches

Although forms, databases, and simple documentation are the norm for documenting lessons learned, the approaches to cataloging the information can vary widely. Some organizations capture lessons learned in on-line cartoons and captioned scenarios. Others post lessons learned in hallways and project war rooms. Most capture lessons learned in simple document files or databases. The storage medium is not nearly as important as ensuring that the content includes detailed, in-context information about why the lesson was deemed important enough to store and what specific action can be taken to implement the lesson on future projects.

Considerations

Storing lessons learned information is one critical consideration, but equally important is the establishment of protocols to ensure access to the information on a consistent basis. Lessons learned may be captured and logged in depth, but if they are not accessed by project managers in the future, they do not serve any real function. Access may be encouraged through creative documentation approaches (like cartoons), physical location (hallways and project war rooms), or by including the mandate to access lessons learned as a key component of the performance criteria for project managers and team members.