This post is a continuation of the sample checklist I introduced in my last post. Let’s look at items 8-14.
- 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?
- Software Configurations
- All components at required version and level?
- Any maintenance to apply?
- Have new products been properly licensed?
- Network Configurations
- Any network address changes?
- Any required firewall changes?
- Connector and cabling components in place?
- Support Plans
- Warranty understood?
- Maintenance agreements in place?
- Procedures documented for obtaining technical support?
- Service Offerings
- Contract services required?
- Agreements (contracts, SOW) in place?
- Scheduling completed?
- 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?
- 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.
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.
- Are performance expectations understood and documented?
- Will the system meet performance expectations?
- How were performance expectations validated?
- Are all appropriate resources involved in the planning and implementation activities?
- Do all parties (management, staff, vendors, consultants) fully understand their responsibilities?
- Are required contracts signed?
- 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?
- Installation Plan
- Is an installation plan in place?
- Are key dates and milestones identified?
- Has the plan been reviewed with all parties?
- 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?
- 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?
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.”
I began IEM 630 (Systems Engineering) this term with a strong initial focus on basic consulting skills. It’s a useful way to help my students develop a mindset that they are not just “learners,” they are problem solvers and problem owners. In a sense, it personalizes the subsequent course content. It makes the material “about them.” Or so I hope.
As I told them on the first day of class, the point of all this is to give them the knowledge and confidence to take ownership of any technical project at any stage of its life-cycle and manage it effectively.
It also moves our overall focus a little more toward systems engineering management – which is exactly where I want us to be.
One objective of a business process is to perform a business activity in a standardized, repeatable way that provides consistent results with minimal management intervention. And many managers take that very seriously.
“Just do it the way we tell you to do it. Don’t get creative.”
I speak from experience in telling you that getting “creative” can cause consternation for your manager, irrespective of the results.
“Do not work outside the process.”
But there are some activities that simply do not lend themselves to this sort of process-driven logic. For example, I once had to document my process for solving technical problems for customers whose mainframe systems were down in the middle of the night and could not be fixed using standard 1-800 number methods.
I balked. It was like asking me how I cooked Chinese food. Well, I never do it the same way twice. It’s NOT A PROCESS.
I finally yielded and described my “process:”
- I arrive at the account.
- I ask them what the problem is.
- I ask them to show me the mainframe.
- I fix the problem.
- I tell them I fixed the problem.
- I leave.
That’s a pseudo-process.
My experience has been that tasks requiring creativity and innovation benefit only marginally from “processes.” Processes have their strengths without a doubt, and they are numerous and real. But driving creativity and innovation is not one of them.
Managing complexity is one of the central themes in my systems engineering course. In one of my lectures, I offer ten practical suggestions for managing complexity. The list isn’t exhaustive, but these ten ideas usually provoke some interesting discussions.
- Improve Communications
- Verify and Document Assumptions
- Instill a Culture of Thoroughness
- Simplify Where You Can
- Establish Quality Assurance Processes
- Manage Risks with Accountability
- Understand the Value and Risk of Decomposition
- Understand the Value and Risk of Abstraction
- Exploit the Use of Hierarchy
- Maintain a Systems Perspective
I’m a Systems Engineer who specializes in enterprise system design and implementation, but I also spend a considerable amount of time doing technical sales. I work continually with new, complex, innovative products and technologies. I get involved at an early stage in the product lifecycle and I get to participate in the product launch and rollout into the marketplace.
One of the challenges you face with the rollout of emerging technologies is that the level of experience and expertise is initially somewhat limited. It takes time to scale up. There are experts – but it takes a while for the expertise to spread throughout the organization. Everybody is on the front end of the learning curve at first.
Because of that, there is a bit more risk doing system design at this early stage. Experience, while growing, is still limited. Feedback from the field is gathered and analyzed, but it often accumulates slowly. Then, there is the unexpected. Not all of the inevitable surprises are discovered on day one.
So there’s some extra risk to be managed.
An effective way for a technology vendor to address this is through pre-sale solution design reviews. Complex designs at the beginning of the lifecycle need to be reviewed. In my industry, it’s part of a process traditionally known as systems assurance, though it has gone through some name changes over the years.
One key to having an effective design review process is to understand the kinds of issues that emerge from the design reviews. To get the most value from the reviews, you need to constantly improve the process itself. A starting point is to know the kinds of issues that surface in these meetings and the frequency with which they are encountered. You need to know what to expect and to have the methods and tools in place to solve the issues effectively.