Generic Planning Checklist – Part 2

This post is a continuation of the sample checklist I introduced in my last post.  Let’s look at items 8-14.

  1.  Hardware Configurations
    • All devices and features supported?  Any compatibility issues?
    • How was hardware configuration validated?
    • Correct quantity and types of adapters, cables, and connectors?
    • Correct power, plug, and receptacles configured?
    • Firmware or microcode levels correct?
  2. Software Configurations
    • All components at required version and level?
    • Any maintenance to apply?
    • Have new products been properly licensed?
  3. Network Configurations
    • Any network address changes?
    • Any required firewall changes?
    • Connector and cabling components in place?
  4. Support Plans
    • Warranty understood?
    • Maintenance agreements in place?
    • Procedures documented for obtaining technical support?
  5. Service Offerings
    • Contract services required?
    • Agreements (contracts, SOW) in place?
    • Scheduling completed?
  6. Systems Management
    • Backup/recovery plans in place?
    • Problem management processes understood?
    • Change management processes understood?
    • Availability management process understood?
    • Newly required tools in place or on order?
  7. Equipment Removal or Disposal
    • Any components or parts to be returned to a 3rd party?
    • Understand who handles packing, delivery, and transportation costs?

As I said, this is a sample of a generic checklist.  It may seem like a list of obvious things.  If so, that’s good.  That’s the purpose of a checklist like this.

As Dr. Gawande says in his book, the function of a checklist is to be sure you get the “stupid stuff” right.

Exactly.

 

 

Generic Planning Checklist – Part 1

Checklists are a useful tool for verifying your readiness to move from one phase of a technical project to the next.  I realize that’s not exactly a news flash, but it’s something worth repeating occasionally.  That’s why for a number of years I required my students to read The Checklist Manifesto: How to Get Things Right by Atul Gawande.

As an example to my students, I present a somewhat generalized, 14-point checklist in my courses.  It’s patterned after the more elaborate checklists that I use when I’m actually implementing an enterprise system within my area of specialization.

I’ll list the first seven points in this post and the remaining seven in the next post.

  1. Expectations
    • Are performance expectations understood and documented?
    • Will the system meet performance expectations?
    • How were performance expectations validated?
  2. Resources
    • Are all appropriate resources involved in the planning and implementation activities?
  3. Responsibilities
    • Do all parties (management, staff, vendors, consultants) fully understand their responsibilities?
    • Are required contracts signed?
  4. Education and Training
    • Does the project team have the necessary skills?
    • Are there technical classes or training sessions that should be scheduled?
    • Is end user training needed?
    • Do operations personnel need training?
  5. Installation Plan
    • Is an installation plan in place?
    • Are key dates and milestones identified?
    • Has the plan been reviewed with all parties?
  6. Shipment and Delivery
    • Are product ship dates and delivery dates known?
    • Are their special requirements for delivery?
    • Any specific security/access issues?
    • Any loading dock issues?
    • Identified the contact person for delivery communications?
  7. Physical Site Preparation
    • Power, cooling, cabling, floor space/rack space requirements met?
    • Physical access issues?  Elevators?  Site walk-through required/completed?
    • Site planning checklists reviewed and completed?

Engineering and the Humanities

Let’s consider for a moment things like art, music, literature, history, and philosophy.  These disciplines or areas of study are often described as the “humanities.”  (We could add others.)

What they have in common, in large measure, is that they reflect ways that we humans express ourselves about what the human experience is like.  We draw pictures or sing songs or write stories or poems or histories or thoughtful reflections about life in all of its manifestations.  (Is this not the ultimate in unstructured data?)  The study of the humanities provides valuable intellectual balance.  It shows us the world through other’s eyes.

 

Unintended Consequences by Another Name

Part of designing systems is making trade-offs.  You give up some things to make room for other things.  Your goal is to “optimize” the system in some sense.

This process generally works well, provided that you have a good understanding of what effects the changes will have on the overall system.  Sometimes, though, systems reach a degree of complexity where you don’t have that level of understanding.  You change something and the result is something unintended – so-called unintended consequences.

You could also describe these as unexpected trade-offs.