To My Classes

Here are a few words I offered to my IEM “students” this morning.  I thought I’d replicate them here as well.

A major part of what we are doing within IEM is related to “professional development.” As graduate students, you already have technical backgrounds and have demonstrated the ability to learn important concepts and methods and apply them. The goal now is to work together to help each of you find ways to leverage and amplify your abilities so that you stand out as leaders. To be successful in that way, you want to develop your professional presence – your ability to communicate, your ability to express complex ideas, your ability to select a framework or construct a narrative that helps your team or organization move forward in the face of tough challenges. You then become a difference maker.

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.




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?

A Futurist Looks Back

Extrapolation is second nature to me.  It’s how I’m wired.  I look at how things are and I make an instantaneous projection of how they will be in the future.  Maybe it’s intuition; maybe it’s analysis functioning at a cognitive level that I cannot quite discern.  Maybe those two possibilities are actually the same thing.

Either way, it’s a part of my nature and it has fueled a lifelong passion for futuristic thinking.

At the same time, there is much to be learned by looking back, and I indulged myself a bit recently as I thought back to what the information technology industry looked like when I first entered it.  Here are a few recollections:

  1. It wasn’t called IT, it was called DP (Data Processing).
  2. I programmed by typing lines of code onto 80-column cards using a keypunch machine – one line at a time.  (When I was done, I put a rubber band around my card deck in case I were to drop it.)
  3. To compile my program, I ran the card deck through a card reader.  (Then I printed off the compiler output on an impact printer to see if it had compiled cleanly.)
  4. My first programming language was FORTRAN.  (My second was COBOL.  My third was IBM S/370 Assembler Language.  My fourth was C. My fifth was MS Visual Basic.)
  5. One of my first tasks when I installed a new computer was to assemble the Supervisor (e.g., operating system).
  6. Virtual storage was a relatively new concept.
  7. Bisync was the dominant communications protocol.
  8. Few of my customers could afford a 9600 bps phone line for data communications.
  9. Online transaction processing was capturing the imagination of the industry.
  10. 1MB of real memory was usually enough.

The main observation I make, retrospectively, is that nearly everything changed at a rate and to a scale beyond anything I imagined possible back then.  I take that lesson forward now, yet I suspect the future will still be beyond what I can imagine today.

Zero to Many to One

If you’ve taken my courses, you know I say this a lot.  This is just a reminder.  The solution development process unfolds in a way that takes you from zero to many to one.  You have a design problem.  You start, in theory, with no solution.  You end up, ideally, with one solution.  In between, you generate and evaluate multiple possible solutions.

Sometimes, in our eagerness to “solve the problem,” we are too quick to say “okay, those are enough possible solutions.”  I think generating possible solutions is half the fun because that is where you get to be creative and innovative, exploring new possibilities and maybe taking a fresh look at some typical problems.  If time allows, use the opportunity to say: “Okay, that’s great; but, now, let’s try it this way.”