New Technology, The Full Project Life Cycle, and Your Career

R.P. Churchill

35 Years of Simulation

35 Years of Simulation

Continuous simulation of the heating of a square billet and Discrete-Event simulation of a multi-phase process.

Article from My Final College Newspaper

Your first job (probably) won't be your dream job.

It might happen under certain, limited circumstances.

I knew I wanted to be an engineer, and I later knew I wanted to integrate computer systems with that... somehow.

I actually got pretty lucky, but I also did a lot of unexpected things.

I never did any one thing long enough to be really great at it, but I ended up being great at the meta, the overall analytical skills that apply across all build and modify-type endeavors.

I loved all of it almost from day one!

In the Real World You Solve the Hard Parts

Some of the earliest physics problems you do in school omit detail.

Sometimes you canNOT assume a massless, frictionless, non-elastic- but-perfectly-flexible physics connecting device!

Imagine the anchor chain on an aircraft carrier...

Image from http://hyperphysics.phy-astr.gsu.edu/hbase/incpl.html

"Under the Hood"

You need to know what's going on in a lot of different contexts.

You can't be expected to know them all right away, but you have to start somewhere.

Your knowledge and experience will start in a limited range and will grow from there.

Here are a few things I might have wanted to know before I started...

Levels of the Computer Tech Stack

Most will start in the programming language level, but even that includes issues like data structures, memory management, language structure, control mechanisms, "syntactic sugar", and so on.

Then you might learn multiple computer languages, what is the same and different about them, why they were created, and more general philosophical concepts.

Process vs. Engagement vs. Solution vs. Environment

The Process: Components

System: The whole enchilada Entity: Moves through and in the system Entry: Where entities go in Station/Block: Where work is done Group/Facility: Multiple elements working in parallel, but possibly specialized Queue: Where entities wait Bag/Parking Lot: Non-FIFO queue Path: How entities move between components Exit: Where entities leave the system Resource (not shown): What must be available to support other activities Resource Pool (not shown): Collection of resource entities Events, Decision Points, Roles, Schedules, Rules, and more can be defined.

Link to detailed discussion.

The Process: SIPOC (and COPIS)

S-I-P-O-C is forward/push; C-O-P-I-S is backwards/pull.

Any number of inputs and outputs are possible.

This view allows all operations to be connected and analyzed in detail.

The Process: Station/Process Block Events

OnEntry: What happens when entity arrives Transform: Change made to entity Merge: Entities are combined Split: New entities split from existing one Send Message: Send message to other component Wait for Message: Wait until message recept Wait for Permission: Wait for external permission Wait for Resource: Wait for resource to become available Status-Based Action: Act after defined change Time-Based Action: Based on elapsed or scheduled time Random or Non-Deterministic Action: What-evah! Complete Sub-Action: Wait for something internal to finish OnExit: What happens when entity leaves User Interface or Control Action: Respond to external influence

The Engagement

• Project Planning
• Intended Use
• Assumptions, Capabilities, Limitations, and Risks and Impacts
• Conceptual Model (As-Is State)
• Data Sources, Collection, and Conditioning
• Requirements (To-Be State: Abstract)
• Functional (What it Does)
• Non-Functional (What it Is, plus Maintenance and Governance)
• Design (To-Be State: Detailed)
• Implementation
• Test
• Operation, Usability, and Outputs (Verification)
• Outputs and Fitness for Purpose (Validation)
• Acceptance (Accreditation)
• Project Close

The Engagement: Simplified

•   Intended Use
•   Conceptual Model (As-Is State)
•   Data Sources, Collection, and Conditioning
•   Requirements (To-Be State: Abstract)
• Functional (What it Does)
• Non-Functional (What it Is, plus Maintenance and Governance)
•   Design (To-Be State: Detailed)
•   Implementation
•   Test
• Operation, Usability, and Outputs (Verification)
• Outputs and Fitness for Purpose (Validation)

The Engagement: Communication Models

There are multiple barriers to clear communication.

These can be mitigated by error-checking mechanisms — and by being clear in the first place.

The end blocks can be improved by review, mutual expertise, patience, and empathy.

The middle blocks can be improved by clearing up the communication medium.

The Engagement: Working Together Means Having Conversations

• Work is rarely completed successfully on the first try.
• You should think of (any kind of) work as a conversation where the back-and-forth continues until all parties understand and agree...
• ...ideally, sometimes you need to cut things off and move forward.
• You can often revisit conversations when more is learned or conditions change.
• I represent a conversation as a loop with a standard entry and exit shown moving left to right at the bottom. This shows the normal flow of work moving forward.
• An additional entry and exit are shown at the top, moving backward from right to left. This illustrates the capability of revisiting prior work to make additions, deletions, or modifications.

The Engagement: Customer Feedback Cycle

Review every phase with the customer until they agree it's correct, especially for the Conceptual Model (As-Is State).

Needs discovered later could require the creation or modification of earlier elements.

This framework is usable for both Waterfall and Scrum, and really for any management style.

Link to detailed discussion.

The Engagement: Phases May Have Multiple Sub-Levels

The Engagment: Context

The framework phases all happen, the question is when. In Waterfall the phases proceed in order. In Scrum you might have many offset phases working though parallel pipelines. In a hybrid situation you might do the implementations by priority in the context of an overarching design.

Link to detailed discussion.

The Engagement: Context (continued)

Building a simulation or tool is often embedded into a larger analytical effort. Existing system: Create Conceptual Model based on what's already there. New System: Conceptual Model process is really part of the Design exploration. These processes are iterative.

Link to detailed discussion.

The Engagement: Requirements Traceability

• Ideally, all elements should map in both directions across all phases.
• Relationships can be one-to-one, one-to-many, and many-to-one.
• Tracing can be done across phases (horizontally) and heirarchically within the design (vertically). All elements should align in the design phase.
• Doing this ensures you do everything you need to do to address the stated problem, and that you don't do things that are not needed to address the stated problem.

Link to detailed discussion.

The Engagement: Extended Life Cycle

The Engagement: Bob vs. the SDLC

The SDLC phases are a little jumbled, in my estimation.

But if you consider the iteration between phases, and the fact that nothing ever really happens in a formal, fixed order, you can see that all the pieces are there.

The Process: Know What's Coming and Plan Accordingly

It is EXTREMELY important to understand the structure of an engagement before beginning one.

This involves being aware of and provisioning for every activity that needs to be completed for a successful effort.

Participants in different roles will be concerned with different things, but all must be able to work together in a shared context.

Participants never want to be surprised that something needs to be done. The design and implementation phases will generate all the surprises anyone needs. Don't let surprises happen during the engagement management process.

The Solution

The solution is the change made to serve customers, whether it means building something new or modifying something that already exists.

These approaches are not mutually exclusive.

Link to detailed discussion.

The Solution: Tradeoffs

List of considerations

The ultimate optimization is to minimize the total cost of ownership over the entire life cycle.

The Environment

The environment is what supports the team members and the work. If the environment is wrong, how can the work be right?

The proper environment should support:

• Effective onboarding and training to get new hires integrated and up to speed
• Strong and open communications, both formal and informal
• Effective management practices shepherded by people who truly understand them
• Active communities of practice
• Allowing and inspiring people to do their best work and not just socializing over a foosball table
• Understanding that all work is iterative, which allows people to experiment, learn, grow, and make (and recover from) mistakes
• Formal and informal support for ongoing training and certification

The Environment: Management Practices

Practitioners should understand the underlying theory of each framework, and not treat the formal documentation as holy writ.

The Wikipedia article for every management practice seems to include a section for criticism. The criticism is essentially always the same, that following the specified steps doesn't by itself lead to the desired outcomes. This is because all the management guidance is more about art than science. You have to get beneath what is written.

Managers are sometimes also contributors, but managers should understand that their primary goal is to make others great, and not necessarily themselves.

Professional management is more about preventing bad outcomes than shooting for optimal ones. Creating the right environment gives the best chance for greatness to happen.

Technological Life Cycles

Summation

This presentation and other information can be found at my website:

rpchurchill.com

E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill