How My Core Competencies Map To Working With Customer Systems

I created the figure below while I was working out the requirements for a simulation tool that would support analysis of this kind of system.

While this diagram represents a fairly specific example of the set of things I’ve been asked to analyze, model, automate, and improve over the years, if looked at more generally it can represent any type of system. I’ve made the same point here before, but in this case I want to do it with respect to specific sets of core competencies as follows. These apply to systems that can be described by similar diagrams in nuclear power plants, paper mills, building controls, inspection and security processes, enterprise business activities, and even in the software processes themselves.

Process Analyst, Business Analyst, Systems Analyst: You have to understand a system before you can analyze it, so I’ve become very adept at analyzing and understanding systems quickly. Most of the items on this list relate to process, business, or systems analysis. Part of the analysis has to do with identifying building blocks that can be defined, manipulated, and recombined in an approachable, modular, flexible way, and some of the analysis has to do with gaining specific subject matter expertise (e.g., pulp and paper, metals, controls, thermodynamics, enterprise document and information management, security operations, airport and border operations, deployment and maintenance operations, and so on).

Simulation Engineer: I’ve worked in both continuous and discrete-event simulation for most of my career, and the simulations I’ve created, contributed to, configured, and operated have been used for training, analysis, and control. I’ve written and worked with simulations and tools written in a variety of high-level languages so I understand the architecture of each method down to its core. Moreover, you have to understand a system at a deep level before you can simulate it, so this activity has always gone hand-in-hand with the analysis activity described above.

Discovery Analyst: Analyzing and simulating systems requires that you get to know what makes them up, what their scope and scale is, and what needs to be included and what doesn’t. I’ve used a variety of methods to get to know processes from guided walk-throughs with customers and interviews with SMEs, to research through printed and online documentation, to review of engineering data and drawings. I’ve created documentation for all findings and used the information discovered to determine what parameters and decision criteria characterize and control each system.

Data Collector: Once the parameters and control and decision variables are identified for a system the data that define them have to be collected. I’ve collected data using different methods including direct observation with timers and checksheets, video observation which was later broken down using the same type of checksheets, direct instrumentation readings, on-site measurements, electronic data capture of historical data, and calculations based on detailed research as described above.

Data Analyst: Identifying and collecting data are only the beginning of the process; the data also has to be analyzed. Both input and output data need to be rationalized, corroborated, and contextualized. You can’t trust whatever gets spit out of your discovery and collection processes; you have to read between the lines to see if it makes sense. You have to ask questions of the SMEs who know the system. You have to know not only how the data describes the system under analysis but also how it will be used by the system you are creating. You also have to ensure you understand the true provenance of all data and what tranformations may have been performed on it. If data is known to be missing or incomplete, you have to find valid ways of filling in the holes from context, identifying additional sources of information including valid analogs from similar systems, or finding ways to make educated guesses. I’ve done all of this and used an array of tools to do it.

Software Engineer, Scrum Developer: I’ve worked with software starting as a sophomore in college. I didn’t just learn how to do x, y, and z but more importantly why to do it. I learned in an excellent environment (at Carnegie Mellon University) and have continually studied developments in the field since. The main thing that drove my need to keep up was the requirements of the many kinds of systems I’ve had to develop, modify, and interface with. I had to learn a number of languages with different structures that addressed different challenges, different paradigms, different hardware and software architectures, different operating systems and development tools, and numerous methods of communication.

Operations Research Analyst: Operations research is the study of changes in system behavior when modifications are applied. This includes trade space analysis, analysis of alternatives, sensitivity analysis, cost-benefit analysis, and various kinds of optimization. Most of my experience in this area is based on my long work in simulation, though I’ve picked up a certain understanding of statistical analysis and an appreciation of many other methods from the field.

Process Improvement Specialist: Everything we do as engineers, analysts, and managers is a form of process improvement in a sense. We’re always trying to do things better, more quickly, and with less input. This means improving outputs by preventing errors and minimizing variations (the focus of Six-Sigma analysis) and by improving efficiency (the focus of Lean analysis). I identify pathways to improvement by reorganizing existing processes and by making individual processes more efficient through various means. I identify constraints and figure out how to reduce their impact. This area of endeavor intersects with all the others.

Control Systems Engineer: Here I am specifically referring to my work with industrial control systems, written in high-level software languages, that are used to control the operation of physical processes in the real world. I have not worked with PLCs or industrial HMI packages like Wonderware, but I have worked with systems that interface to them and to sensing, output, and actuation hardware, directly.

Test Engineer: It has never been my full-time job to design and administer tests of large scale software systems but I have used a wide variety of methods to test, verify, validate, and gain acceptance for the many software systems I’ve created. I also participated in an eighteen-month project to perform a full VV&A on a third-party system meant to manage the entire fleet of F-18 series aircraft for the U.S. Navy and Marine Corps. The methods that guided our efforts was developed by a senior Navy analyst. I’ve been exposed to a number of current tools and methods, some of which recreate methods I’ve previously employed in different ways on my own.

System Architect: I’ve designed, specified, implemented, and modified a wide variety of computing solutions for a number of applications on a range of hardware and operating systems in an array of environments of varying size and scope. I have performed all kinds of testing, documentation, management, and negotiations with respect to those systems. Some systems were composed of single, stand-alone processes hosted on individual desktops while others involved multiple processes and programs as well as communications with other processes and external systems. The systems have been used for analysis, control, training, and automation. Some are meant to operate in real-time while others were meant to run on a fire-and-forget basis. Some supported interactions with users while others ran to completion once started.

Enterprise Architect: The line between system and enterprise architecture is the subject of a great deal of discussion. Systems at all levels of complexity, if conceived and implemented well, should consider flexibility, recoverability, robustness, ease-of-use, and similar factors. Is it then just a question of scale? Is it a question of adaptability to change? It it a reflection of the type of users or results? Is it a question of the tools used? Does the use of SAP, Appian, or IBM FileNet make something an enterprise system? Does it have to do with business function? Is HR or marketing more “enterprise” than manufacturing or building control? I think it’s hard to say. If the experts can’t agree then it’s clearly a difficult problem. I can say I’ve done elements of work at every scale, including enterprise transitions when I did the discovery, analysis, and implementation for FileNet document imaging systems. I would also, as I note, be very comfortable working at the plant-wide scale discussed here.

Project Manager: Having worked with so many different kinds of systems, architectures, customers, solutions, sizes of organizations, and types of colleagues I have an excellent feel for putting all the pieces together. I have served as a researcher, developer, project coordinator, site liaison, technical lead, technical manager, and project manager in many different situations. I have supported sales, security, discovery, design, implementation, test, acceptance, commissioning, service and support, and end-of-life and replacement efforts and so have seen every phase of project and product life cycles from beginning to end. Most importantly, I’ve seen things done well and seen things done poorly during my career, and I’d like to think I have the organizational skill to take a step back to ensure I consider all facets of this experience and the insight to apply it to offer the greatest possible support to all colleagues and customers.

Program Manager: A program is nothing more than a portfolio of projects, so that is largely a question of scale. I have served as a program manager with duties that included contract management, working with subcontractors (and prime contractors in other situations), multiple sites, multiple customers, invoicing, reporting, and planning. The important thing to consider when managing programs is that one has to manage their limited bandwidth. I learned from studying the National Emergency Management System that when the number of reporting (departmental or functional) entities gets beyond four for any one person, that an additional layer of interface should be added. That conflicts with today’s trend toward flatter, more cooperative organizations in general, but the insight remains that individuals have to consider and coordinate at an appropriate level. Program managers (and their analogs) have to know how to gain insight into the operational effectiveness of their reports, but they also have to know how to offer guidance and correction without getting into too much detail.

Scrum Product Owner: My most natural position is working with customers to identify their needs and with developers to meet those needs (while also supporting the developers’ needs). I’ve done this through my career almost from the beginning. I’ve worked in a consciously agile, iterative fashion that seeks lots of feedback and allows appropriate correction, but have not spent time working in a formal Scrum setting. I leveraged my experience to earn my Scrum certifications as a way to get up to speed on the details as quickly as possible.

ScrumMaster: I have taught people to develop new systems in new languages for new applications in new settings. I’ve worked in development efforts at various scales and with differing needs for tools and mechanisms to manage complexity and cooperation. I’ve participated in different methods of software, hardware, and process governance. I am not looking to serve as a ScrumMaster without direct experience in the role and with Scrum in general, but I appreciate what they do and can work with and support such individuals with aplomb.

This entry was posted in Management and tagged , , , , , , . Bookmark the permalink.

Leave a Reply