A Systems Philosopher?

It’s that time of the year when I think about what’s next.  What do I want to accomplish in 2018 and what do I need to accomplish?  What are my interests?  What are my priorities?

Do you ever find that your interests and your priorities don’t align very well?  I guess we all do.  That’s certainly my situation at the moment.  It’s one of the challenges of life, of course.  You have to make choices – trade-offs – and that’s not always easy.

I don’t have the answers, yet.  I know that I’d like to have more time to dig deeper and deeper into complexity and chaos.  Yes, I’m serious.  I suppose I’m more metaphysician than anything else.  If I could have made a living as a philosopher, that’s what I would be doing.

I’d also like to experiment with AI, just for some personal applications.  And, in general, I wish I could get back to doing more programming.  It’s been a long time since I’ve done that.

I’d also like to have time to do some writing, especially on professional development and consulting.  And I’d like to bring out a new version of my Effective Speaking book.

The desire to learn, apply, and teach is part of my nature.  Teaching is one of my question marks, though.  I have always enjoyed teaching, but, honestly, I seem to enjoy it less now.  Maybe it’s because I simply need to teach new things.  Or maybe it’s that, to me, technology has depersonalized teaching in the same way it seems to depersonalize everything else.

Then, there’s my profession – systems engineering.  It pays most of the bills and keeps me at the center of complexity (and always on the edge chaos).  It’s also “who I am” and “what I do.”  I’ll miss it when it’s gone.

How do I bring these disparate things together into a meaningful whole?

If only I could be a systems philosopher.

Trading Off Capabilities

My experience has been that net expense reductions in a mature organization almost always result in a loss of longer-term operational capabilities.  They rarely produce a net efficiency improvement.  Usually, there’s a corresponding reduction in value, quality, or capability.  It’s a trade-off.  The key is whether you understand the trade-off or not. If you understand it, fine.  But if not – if it manifests itself as an unintended consequence – then not so fine.

I saw an article recently in the Navy Times that captured the same idea.  I’ll post the link below, but here’s the paragraph that really caught my attention.  It’s an excellent example of what I tell my students.

From: https://www.navytimes.com/news/your-navy/2017/12/14/new-secnav-report-criticizes-navy-culture-and-top-brass-decisions/

“However, the cumulative effects of well-meaning decisions designed to achieve short-term operational effectiveness and efficiencies have often produced unintended negative consequences which, in turn degraded necessary long-term operational capability.”

Exactly.

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?

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.”

 

 

A Focus on Consulting Skills

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.

The Enigma of Creative Processes

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.