program management

#

EM.411 meeting Bryan Moser program management

→

#

Contact types

→

#

Contracts are essentially cost - value curves

→

#

Public private partnerships

→

#

Can be simple responsibility and pay for private sector

→

#

Could give the private sector some responsibility to operate for some time

→

#

Provides some investment

→

#

Contracts relating to scope and schedule

→

#

Spiral Project Concept

→

#

Is planning the same as forecasting ?

→

#

Planning can handle uncertainty but seems like you need to make statements about the future

→

#

Bryan does think planning is fundamentally forecasting

→

#

Reminds me of

→

#

Prediction is the same as intelligence

→

#

Lean

→

#

Toyota pioneered

→

#

Respect for Ford process, but added a Japanese perspective

→

#

Work like a stream

→

#

Flow like water

→

#

Mind like water

→

#

Kanban

→

#

Just in time

→

#

Right part, right time, right amount

→

#

Just-in-time Interface

→

#

Jidoka

→

#

Make problems visible

→

#

Trust people to improve their station

→

#

Kizuki

→

#

Notice, recognize, become aware of, perceive, realize

→

#

Stand in the circle, shut up, and observe

→

#

->

→

#

Good leaders need this

→

#

Adele Cadario

→

#

Regional and urban planning

→

#

Worked with the city of Paris

→

#

After SDM moved to Rotterdam

→

#

Works for global center for adaptation

→

#

EM.411 meeting Bryan Moser program management

→

#

Target setting

→

#

Managing value gap between null outcome and stretch goal

→

#

Target setting

→

#

Managing value gap between null outcome and stretch goal

→

#

Set target somewhere between these two

→

#

Manage uncertainty

→

#

=

→

#

Manage space between null and stretch

→

#

Paradox of stretch goals

→

#

Sitkin

→

#

Why plan?

→

#

Plan

→

#

From Moser

→

#

Organization of ram and work

→

#

Estimate

→

#

Commitments

→

#

Is a plan a map or the territory

→

#

Map, I think

→

#

At a startup, the plan is close to the territory

→

#

As the plan moves further away from the territory, you begin to need models

→

#

One way to think of it

→

#

A plan is a compression of the action

→

#

As you need to compress more and more, you lose fidelity

→

#

Another thought

→

#

This territory is over time and people

→

#

History

→

#

Henri Fayol

→

#

Frederick Taylor

→

#

We can find optimal way to do a job

→

#

Knowledge is more important than manual skill

→

#

Henry Gantt

→

#

Focused on time

→

#

Time is the fundamental measure of a job

→

#

Gantt Chart

→

#

Flow

→

#

Karol Adamiecki

→

#

Focused on the handoffs rather than the tasks

→

#

Laws of harmony in management

→

#

Harmony of choice

→

#

Harmony of doing

→

#

Harmony of (missed)

→

#

Used to design the Empire State Building

→

#

Line of balance

→

#

Thought of it as a marching band

→

#

This might be related to category theory

→

#

About relations (handoffs)

→

#

Projects as networks

→

#

Use of Bayes’ Theorem techniques for forecasting in ww2

→

#

Graph theory

→

#

Usually they focus on schedule

→

#

Two representations

→

#

Activity on node

→

#

Activity on arc

→

#

Arrows are functions

→

#

category theory

→

#

Critical path method

→

#

EM.411 meeting Bryan Moser program management

→

#

Model based program management

→

#

Map and Territory

→

#

All models are wrong, some are useful

→

#

Models are maps

→

#

Tradespaces of plans

→

#

Risk is a good dimension to include

→

#

Or is risk included in cost?

→

#

GERT

→

#

Deterministic task durations

→

#

Probabilistic network flow

→

#

Boolean logic for network paths

→

#

Relatively unintuitive representation

→

#

Fly over

→

#

Projects and operations are different

→

#

Projects are unique

→

#

Waterfall is from the 70s

→

#

Born mostly from the Apollo program

→

#

Moser

→

#

Modern manufacturing is more dynamic and considerate of the individual than modern engineering

→

#

Cost, schedule, and scope at quality are outputs not inputs

→

#

Herbert Simon

→

#

Order without a planner

→

#

Top down thinking is still rampant

→

#

EM.413 meeting program management James Lyneis

→

#

project design for quality

→

#

Makes me think of zen and the art of motorcycle maintenance

→

#

Grade vs quality

→

#

Grade is determined by scope

→

#

What you’re building

→

#

Quality is determined by defects

→

#

How well you built

→

#

Quality dynamics

→

#

Rework as a function of quality

→

#

Change

→

#

Emergent change

→

#

A problem with meeting existing requirements

→

#

->

→

#

Not sure that “emergent” is the best descriptor here

→

#

Initiated change

→

#

Based off a change in requirements

→

#

Am important takeaway

→

#

Adding resources can increase delay

→

#

Brook’s Law

→

#

->

→

#

Asking a question is like drawing a vector

→

#

The answer extrapolates from the direction of the vector

→

#

This explains why asking a question often involves additional clauses to help fine tune the vector direction so it doesn’t set the respondent off in an unintended direction

→

#

->

→

#

Put a model diagram on your wall

→

#

Inspired by example from F-18 project

→

#

Truly novel projects are hard to predict what requirements are actually valuable

→

#

Excess work in models?

→

#

EM.413 program management meeting Bryan Moser

→

#

multi project program management

→

#

some semantics

→

#

program

→

#

set of projects related by objective

→

#

portfolio

→

#

set of projects considered for collective performance, but not necessarily coupled by objective

→

#

optimizing resource allocation is np-hard

→

#

requires heuristics

→

#

some priority rules

→

#

FIFO

→

#

shortest operation first

→

#

maximum operation first

→

#

minimum slack

→

#

maximum slack

→

#

shortest activity from shortest project

→

#

longest activity from longest project

→

#

minimum total work content

→

#

maximum total work content

→

#

random

→

#

lol

→

#

max total work content and earliest late start time

→

#

EM.411 meeting program management Bryan Moser

→

#

Spiral

→

#

1986

→

#

Waterfall, spiral, agile

→

#

Waterfall was meant to actually have incremental validation

→

#

Agile development

→

#

Agile Manifesto

→

#

Agile is not a method

→

#

Roles

→

#

Product owner

→

#

External facing, prioritizes product backlog

→

#

The what

→

#

Scrum master

→

#

Removes barriers for the team

→

#

The how

→

#

Key difference is time boxed vs scope boxed

→

#

This feels like a critical way to categorize different methodologies

→

#

Kanban

→

#

A signal to indicate a need

→

#

Are there any new, unique ways to do work ?

→

#

Moser is skeptical

→

#

EM.411 meeting Bryan Moser program management

→

#

Critical path method

→

#

Building a project graph is a lot like a Cartesian closed category

→

#

Or maybe I mean a preset category

→

#

Slack

→

#

Some things are more important than others

→

#

The difference between earliest and latest start

→

#

Smallest slack is the critical path

→

#

This is a method for prioritization

→

#

Manhattan Project

→

#

Phillip Morrison

→

#

Bryan Moser studied with him

→

#

Set based projects

→

#

Is a concept

→

#

Delay design decisions as long as possible

→

#

Eliminate options over time

→

#

Maintain Optionality

→

#

PERT

→

#

Treats durations as probabilistic

→

#

Unlike critical path method which is deterministic

→

#

Optimistic, most likely, and pessimistic estimates

→

#

Use beta distribution

→

#

Choice of alpha and beta in distribution should be informed by priors

→

#

For each tasks

→

#

When combining tasks you get a summed normal distribution

→

#

You can get confidence of completion date from this summed normal

→

#

EM.411 Bryan Moser meeting program management

→

#

Know the classics better than the purveyors

→

#

Read the original work rather than textbooks

→

#

Galileo was the strongest Aristotelian

→

#

System Architecture

→

#

Conversation with materials

→

#

System Engineering

→

#

Conversation with context

→

#

program management

→

#

Conversation with self

→

#

Project is not an operation

→

#

Uniqueness is what makes work strategic

→

#

If nothing is different

→

#

After getting started, 95% of tide us

→

#

Strategy -> Plan -> implement

→

#

Making money is one thing, but what about social value

→

#

Strategy

→

#

Where to play, how to win

→

#

Michael Porter

→

#

Do activities differently

→

#

Free cash flow

→

#

Discount rate

→

#

Is a choice

→

#

Discounted cash flow

→

#

Choices of discount rate is part of strategy

→

#

Expose differences among parties regarding attributes

→

#

eg

→

#

Milestone A

→

#

Is it as commitment, a need, an estimate, etc

→

#

Project charter

→

#

Project charter is a formal request for a project plan

→

#

A useful charter acts as a boundary spanning object

→

#

Stakeholders

→

#

Cost

→

#

Schedule

→

#

scope

→

#

Tolerances

→

#

System Design/EM.412 meeting Bryan Moser program management

→

#

Donald Schön is one of Bryan’s favorite thinkers

→

#

Small changes in intermediate mapping can lead to significant reframing of complex systems

→

#

Uncertainty

→

#

Variation

→

#

natural variation within a range of probability

→

#

no further investigation

→

#

Ambiguity

→

#

insufficient evidence of project state

→

#

may also be imprecise definition

→

#

discovery is possible

→

#

Vagueness

→

#

knowable but not yet decided

→

#

choices can lead to certainty

→

#

->

→

#

Surprise

→

#

Claude Shannon

→

#

Surprises express more information value

→

#

There are no surprising facts, only models that are surprised by facts

→

#

surprise requires an update of your priors

→

#

Bayesian updating

→

#

Decision trees

→

#

always include the do nothing, pause, and cancel options

→

#

Risk

→

#

uncertain future condition associated with some probability

→

#

can be the third dimension in a cost / duration project Tradespaces

→

#

Risk Management

→

#

Biases

→

#

read Daniel Kahneman

→

#

confirmation

→

#

hubris

→

#

EM.413 meeting Bryan Moser program management

→

#

Model based project design

→

#

Systems have

→

#

Elements

→

#

Relationships

→

#

Dynamics

→

#

Model types

→

#

Network

→

#

CPM

→

#

DSM

→

#

System dynamics

→

#

Agent based

→

#

Parametric

→

#

Models can handle different complexities better or worse

→

#

Detail complexity

→

#

Dynamic complexity

→

#

->

→

#

Different functors from reality to model chooses different granularities

→

#

If there was a good way to store category theory database we could use that as a backend with different front ends

→

#

category theory

→

#

Good projects should improve organizational capability

→

#

Do compounding work

→

#

How does individual and team effectiveness evolve?

→

#

Nonaka on knowledge cycle

→

#

SECI

→

#

Socialization

→

#

Externalization

→

#

Combination

→

#

Internalization

→

#

Moving between

→

#

Tacit knowledge

→

#

Explicit knowledge

→

#

->

→

#

Knowledge graph

→

#

James Lyneis

→

#

Learning dynamics

→

#

How does individual and team effectiveness evolve?

1

#

Not much published data on this

→

#

Bruce Henderson

→

#

Boston consulting group

→

#

As experience doubles, efficiency improves around 20-30%

→

#

From 1936

→

#

Learning curve

→

#

Are there zero cost ways to transition tacit knowledge to explicit knowledge ?

→

#

Nonaka

→

#

→

#

EM.411 meeting program management Bryan Moser

→

#

We want a better model than critical path method

→

#

Moving from mechanistic and components thinking to social cultural and systems thinking

→

#

Incorporating adaptation

→

#

Projects as elements: system

→

#

What is a project system?

→

#

What is not trivial and not part of project systems ?

→

#

Scope

→

#

Is work linear with scope?

→

#

Scope as ends

→

#

Where the best measure of scope are measures that are means that are close to the ends

→

#

Scope is not cost or schedule

→

#

Scope could be like man months

→

#

But doesn’t consider communication complications

→

#

Mythical man month

→

#

Scope vs estimation

→

#

Planning poker, COCOMO, functional point analysis

→

#

Scope as about of new content

→

#

This is something I haven’t thought much about before

→

#

For Bryan

→

#

Scope is the tangible outcome of project tasks

→

#

I think he considers scope to be a true sibling of cost and schedule, not above or below

→

#

Scope is not value or work but the basis of value and the result of work

→

#

This makes me think

→

#

Scope is the mapping from work to value

→

#

Scope attributes

→

#

Units: drawings, parts, etc

→

#

Effort: nominal hours, story points

→

#

Divisibility

→

#

Complexity, uncertainty

→

#

Target neutral

→

#

If customer target changes then value of scope changes but the scope is not changes

→

#

Resource Nominal

→

#

eg

→

#

Man months

→

#

Exception realistic

→

#

A way to describe a scope partial, imperfect, and rework

→

#

Examples of scope types Bryan saw through interviews

→

#

Fixed duration

→

#

Linear burn down

→

#

Units non linear effort

→

#

Map coverage

→

#

Some sort of spatial division

→

#

Cyclical operation

→

#

The goal is to have a scope map around which you can design your system

→

#

System Design

→

#

EM.413 meeting program management Bryan Moser

→

#

Project Design for Diversity and Distribution

→

#

Why go global?

→

#

my thought

→

#

cost

→

#

access to larger talent pool

→

#

asynchronicity

→

#

some of the benefits are often false promises

→

#

Coordination

→

#

Coordination is the management of dependencies

→

#

Coordination has a distance

→

#

communciation efficiency

→

#

distribution and time zones

→

#

exception handling behavior

→

#

different priorities

→

#

misreading indicators

→

#

Coordination can be designed

→

#

Tacit abilities are an asset

→

#

If you can predict it, you can design it

→

#

Knowledge is testable prediction

→

#

Culture

→

#

Geert Hofstede dimensions of value in culture

→

#

Individualism

→

#

Masculinity

→

#

Uncertainty avoidance

→

#

Power distance

→

#

Long-term orientation

→

#

EM.411 meeting program management James Lyneis

→

#

James Lyneis

→

#

Worked with Jay Forrester

→

#

Project Dynamics

→

#

Dynamic

→

#

Strange loops

→

#

Something with reflexive changes

→

#

Dynamic systems are strange loops

→

#

System Dynamics

→

#

Might be possible to learn about this through software

→

#

A good software can teach as well as a good lesson

→

#

Expected staffing (effort) over time

→

#

Plan is a symmetric hump

→

#

Two seemingly common breaks from model

→

#

Hump moves to the right, maybe a second hump

→

#

Still attempting to finish on time

→

#

A long tail of burn down

→

#

Over shoots schedule

→

#

Dynamics driven be cause effect relationships

→

#

The physics is the system

→

#

Accumulation processes

→

#

Feedback processes

→

#

Balancing

→

#

Reinforcing

→

#

The rework cycle

→

#

Work done + undiscovered rework = work believed done correctly

→

#

Discovering undiscovered rework shows like zero productivity time

→

#

Seems like agile is meant to be structured in such a way to minimize and surface sooner rework

→

#

Causal loop diagrams

→

#

Reinforcing loops

→

#

Positive loop, virtuous circle

→

#

Negative loop, vicious circle

→

#

Balancing loop

→

#

Deaths and births balance population

→

#

Fred Brooks Brook’s Law Mythical man month

→

#

Adding people to a late software will make it later

→

#

System dynamics model produces a dynamic hypothesis

→

#

These deeply connected network models need to have core goal metrics

→

#

Like “value”

→

#

Would be a function of schedule cost morale etc

→

#

Direct vas indirect impacts

→

#

direct impacts

→

#

Something hits the plan

→

#

Indirect impacts

→

#

The internal looping ripple dynamic effects

→

#

EM.413 program management meeting

→

#

Bryan Moser

→

#

Project design for flexibility

→

#

don’t ask for one plan, ask for a thousand plans

→

#

enabled by model based approach

→

#

what is the form of the plan?

→

#

can it be close to the

→

#

James Lyneis

→

#

Adaptive resource control

→

#

EM.413 meeting Bryan Moser program management

→

#

Denver airport and rail case study

→

#

Ted Halsey

→

#

Worked on courthouses

→

#

Airport

→

#

Planned to have new, efficient baggage handling system

→

#

September 2005 they finally gave up on this

→

#

BAE went out of business after this

→

#

Construction started November 1989

→

#

Planned to end October 29 1993

→

#

expert opinion

→

#

based on funding cycles and bond paybacks

→

#

Fastracks train line from Union Station to the Airport

→

#

->

→

#

thinking about Induced Demand

→

#

increasing capacity may not always prove to increase utilization, if the corridor is in a complex system that has other moving parts

→

#

this may be the best argument against assuming Induced Demand is ubiquitous and inevitable

→

#

maybe Durham should provide gantt charts for all projects

→

#

Initial screening involved a lot of reality checking to reduce ~100 possible routes over the first 4-6 months in Dec 2003

→

#

Issues with signaling and satellite system at at-grade crossings

→

#

thinking about the RTD vs DIA projects

→

#

DIA is more isolated, was more ambitious

→

#

RTD has public engagement and more checks and balances, so more restricted

→

#

two problems

→

#

no agreed upon optimization function

→

#

maybe not needing to agree on the optimization, but understand the tradespace of tradeoffs

→

#

no agreed upon time horizon for calculating value

→

#

System Design/EM.412 Bryan Moser meeting program management

→

#

Project Organization

→

#

Capabilities

→

#

Structure

→

#

Rules

→

#

->

→

#

What is the function of structure?

→

#

Leaders of technical projects have choices in the design of the project

→

#

including shaping culture

→

#

Teach, embed, articulate

→

#

Edgar Schein

→

#

Organization types

→

#

Influence Project Organization

→

#

Matrix Project Organization

→

#

Dedicated Project Organization

→

#

Organizing and leading heavyweight “development teams”

→

#

EM.411 meeting Bryan Moser program management

→

#

Relationships in project systems

→

#

NASA, Mercury to Apollo

→

#

Von Braun

→

#

Any good teams have belonging, pride, group, and an element of spontaneity to them

→

#

More cultural and organizational view

→

#

Bob McNamara

→

#

Brought in the “Whiz Kids”

→

#

using statistical techniques to improve efficiency

→

#

used Work Breakdown Structure

→

#

More technical and optimization focused

→

#

like Frederick Taylor

→

#

Work Breakdown Structure

1

#

a decomposition of work

→

#

tree structure

→

#

identifies “terminal elements”

→

#

Cartesian closed category

→

#

Bryan Moser

→

#

Detail and certainty are not the same thing

→

#

Waterfall

→

#

Each step still has a verification

→

#

There are feedback loops

→

#

Similar to the System Engineering V

→

#

If you remove the left to right assumption of sequential steps, it looks a lot like agile

→

#

Dependencies

→

#

if there are no dependencies, does it need to be managed?

→

#

Precedence relationships

→

#

Finish to start, finish to finish, start to start, etc

→

#

similar to necessary / sufficiency relationships

→

#

Finish to finish is like necessary but not sufficient

→

#

QFD

→

#

DSM

→

#

rows are tasks / activities

→

#

can identify sequential, parallel and coupled task sets

→

#

Visualizations as dimensions

→

#

dimensions

→

#

left to right

→

#

top to bottom

→

#

networks

→

#

size

→

#

etc

→

#

what’s interesting is if you can have visualizations that communicate more value per dimension

→

#

category theory

→

#

dependence, sequence, connectivity, terminal, initial are all communicated

→

#

it’s “easy” to add dimensions

→

#

Bryan Moser ideas of dependence

→

#

precedence is a result not a cause

→

#

dependence as “area of demand”

→

#

can represent dependency between processes with a 2d chart where each axis is the time progress on each task

→

#

if there is no dependence, all paths from start (bottom left) to end (top right) are available

→

#

dependence represented as a “bottom-right” space of the chart

→

#

route of actual work and proximity to “area of demand” indicates how efficient the actual work is

→

#

also how fragile the coupling is

→

#

can represent mutual dependencies with a dependence area on the “top-left” space

→

#

->

→

#

this is a very interesting idea related to Visualizations as dimensions

→

#

EM.411 meeting Bryan Moser program management

→

#

Resources

→

#

Supply of material, labor energy, information or other asset which of used to realize scope

→

#

What about this definition

→

#

That which costs

→

#

May cost time, money, coordination, effort

→

#

Is there anything that “costs” that isn’t a resource

→

#

Resource based view

→

#

Wernerfelt

→

#

Helps identify advantages that can come from early moving on resource monopolization

→

#

Resources in system models

→

#

Some attempts at Useful model

→

#

Useful models should push back

→

#

Have constraints

→

#

IDEF

→

#

UML

→

#

SysML

→

#

System modeling language

→

#

OPM

→

#

Team

→

#

Attention allocation

→

#

Jim Conway

→

#

Game of life

→

#

Autonomous agents

→

#

The ghost in the machine

→

#

Koestler

→

#

Roles and allocation

→

#

Link resources to tasks

→

#

Supply to demand

→

#

RACI matrix

→

#

Responsible, accountable, consulted, informed

→

#

Feels like you shouldn’t need responsible, accountable person should handle that

→

#

An example of too much detail

→

#

Resource assignment matrix

→

#

PDQA

→

#

Primary, decision, quality, assist

→

#

Design of project through roles

→

#

Mythical man month

→

#

Leads to my theory of atomic units being key

→

#

Contracts

→

#

How do they relate to resource allocation

→

#

EM.413 program management Bryan Moser meeting

→

#

Questions in the design of complex projects

→

#

Is the project designed to be stable and predictable?

→

#

Project Control

→

#

Cost of reporting needs to have some return in the form of a change in process

→

#

otherwise reporting will stop

→

#

Earned Value

→

#

Made up of

→

#

Budgeted Cost

→

#

Actual Cost

→

#

Work Performed

→

#

Work Scheduled

→

#

EM.413 meeting program management Bryan Moser

→

#

Project design for alignment

→

#

If all events are independent, no alignment needed

→

#

Dependencies are satisfied through coordination

→

#

but simplified dependencies can reduce the need for coordination

→

#

Using DSM to “unplanned iterations”

→

#

less clustered DSMs might be better candidates for Agile development

→

Search Results

program management

↑ 20 References