Analysis Schedule Development

Definition s, Lessons Learned,

Techniques , and Tips NASA Annual Cost and Schedule Symposium

August 14 , 2019

Background

• Analysis schedules • No explicit guidance on content, size, or even purpose

• NPR 7120.5E doesn’t mention them

• DoD scheduling and risk analysis guidance doesn’t mention them

• However, their use predates the concept of JCL • 1976 RISKNET paper on NTRS – “For the purpose of a RISKNET analysis, a more

generalized network is preferable”

• Until recently, the need was probably driven by computational limits

• T o understand how to make analysis schedules, we should firs t understand why we’re making them and what benefit they bring

Why do we need o r wan t an analysi s schedule?

210/25/2019

The IMS and Why We Wan t an Analysi s

Schedule:

• Uncertainty

• Repetition

• Redundancy

• Superfluity

310/25/2019

ATP SRR - MDR/SDR PDR CDR SIR TRR I&T END Date PSR LRD Actual Launch Date

Mission Level SPACECRAFT ELEMENT

Spacecraft Bus

Attitude Control Subsystem

Command and Data Handling

Communications Subsystem

Propulsion Subsystem

Structure Subsystem

Thermal Control Subsystem

Wire harness

Software Development

PAYLOAD ELEMENT

Instrument 1

Instrument 2

Instrument 3

Schedule Uncertaint y on Large Schedules

• No historical dat a at the task level

• ONCE has a database of schedule files, but need to parse and map tasks to each other

• There are issues with assigning uncertainty based on task-level inputs (Whitley, 2014)

• Good modeling practice: Don’t model below the level of your data

• Unavoidable to some extent with schedules because of logic

Wha t schedule data is actuall y readil y available?

CADRe Part C

templat e giv es u s a n

idea what t o expect:

Mission , S C an d

subsystems , an d

instrument s b y

milestone 410/25/2019

IMS Repetition

• Exampl e wit h subsyste m giver/receivers (i.e . CDR Ls)

and summary giver/receivers • This approach offers clarity at

the expense o f complexity • Useful for managing many

integrated schedules whic h are independently developed

• Often enti re CDRL lists • Size can be significantly

amplified 510/25/2019

IMS Redundancy

Task A Task B Task C

• A->C is already implied by A->B and A->C, the link is redundant

Thi s doesn’ t look so bad – why the worry?

• Below is more typical – only there may be dozens of PDR predecessors and dozens o f redundant links

• Makes tracing the logic much more difficult and complicates summarization

610/25/2019

PDR

Here’s the redundant link

IMS Superfluity

Name

Project Mgmt Budgeting Activities

Yearly PPBE Activity

PPBE FY 2017

PPBE FY 2018

PPBE FY 2019

PPBE FY 2020

PPBE FY 2021

PPBE FY 2022

PPBE FY 2023

Yearly Phasing Plan Activity

Phasing Plan FY 2016

Phasing Plan FY 2017

Phasing Plan FY 2018

Phasing Plan FY 2019

Phasing Plan FY 2020

Phasing Plan FY 2021

Phasing Plan FY 2022

• Level-of-Effort work (like pictured)

• Sometimes periodic recurring tasks (here it’s yearly,

sometimes schedules have monthly)

• Often very long activities spanning significant portions

of the schedule

• Just-in-Time (JIT) tasks

• Don’t mesh well with forward-scheduling

– To avoid As Late as Possible logic you get seemingly

arbitrary constraints or lags to “place” the task

• Examples like document generation and milestone prep

710/25/2019

These tasks have to go – otherwise the y ma y drive

schedule even withou t uncertaint y – “Ten t Poles”

Let ’s Ma ke an Analysis

Schedule!

• Prepare the IMS

• Delete, remove, excise

• Summarize

• Adjust summaries, repeat

810/25/2019

Analysi s Schedule Developmen t - Overview

Two broad techniques

High-leve l schedule fro m scratch

• Requir es intimate knowledg e of the project • Lots o f assumptions go into the degree

o f summarization

• Ca n directl y circumvent an y issu es with IMS

• High er level product avoid s low-level schedule volatility

Schedule derived directl y fro m IMS

• Requires relatively healthy IMS

to start from

• Process-driven an d repeatable

• Fina l result tends to still be

relatively large • Can make a good first cut

Followin g slides focus on derivin g fro m IMS 98/14/2019 NASA Cost and Schedule Symposium

Prepare the IMS

Custom Field Name Field Data Type Field Content

Original Start Date Date Copy and paste original task start dates

Original Finish Date Date Copy and paste original task finish dates

Current Finish Delta Number Equation: [Original Finish Date] – [Finish]

Merge Exclude Flag “Yes” for margin tasks, edays tasks, and other tasks that you don’t

want to be summarized

Merged UIDs Number This will be a list of task UIDs that have been summarized

Flag for Removal Flag “Yes” for LOE, non-driving, etc. tasks

• Ad d these custom fields to your schedule file

• Find task s without successors • They eithe r need a successor (often), are important for cost mapping (unlikely), or

you ca n delete

Tip! Prefix the custo m field names with your initials to find the m easily 10 10/25/2019

Delete Unnecessar y Tasks

• Flag LOE, other task s tha t you want to delete • Look at their fre e and total slack, if both numbers a re relatively large it’s probably safe

to delete without much more examination

• If fre e slack is low or 0, make sure the LOE tasks aren’t driving important wo rk downstream – this is a ba d scheduling practice in general

• Use a predecessor trace tool to find predecessor s to key milestones • Schedule analysis tools like JACS have one, or you can use a macro

• If an activity (appropriately) does not tie into important logic, you can delete it an d possibly its whole “path”

• Launch is obvious to examine, but delivery of key subsystem hardware as well – even i f not near critical path those milestones will possibly drive cost

• Ideally you will also flag summarie s if you’re deleting whole sections but that can be hard to keep track of • Frequently check for tasks with no predecessors OR successors with estimate

durations, these are former summary tasks you can delete

11 10/25/2019

100% Complete Task

FS +

LAG

Un-started Task Driven by

Complete Task

Now

Delete Completed Task s (Optional)

• This step significantly cleans up the schedule

• Also removes lot s of potentiall y redundant links

• In a perfect world, you’d delete tasks with % Complete = 100%

and call it a day, but scenarios like this occur:

• Effective but inelegant solution: make sure you’ve recorded all original and finish dates per the first step (all deltas 0!) • Delete all the finished tasks: Find any deltas that are no longer 0

• Set those tasks to a constrained start = Original Start

Tip! It’s never a perfec t world in scheduling 12 10/25/2019

Remove Redundant Links

• Do this after significant schedule clean-up

• Acumen Fuse can find redundant links very quickly

• Otherwise, it’s programming time

• In this example, ID 4->7 is redundant • 4->12 is not, but could be confused as such

Here we go:

For each task: • List 1: Find the task’s

immediate successors

• List 2-n: For each ite m in list 1, find ALL successors (not jus t immediate)

• If anything in list 2- n matches list 1, that lin k is redundant

• See backup chart to see how this plays out

13 10/25/2019

Summarizing Approach

• The Rules of Summarizing: • Do not summarize between summary tasks

• Do not “lose” any logic

• Do not summarize margin tasks, or other tasks of interest

• Do not mix calendars

• Do not summarize over constraints (unless at the beginning) For each Task(@ID):

For each Task(@ID+1) //for conciseness I will call Task(@ID) and Task(@ID+1) “Tasks”

Are Tasks unde r the same summary ? continue : Exit Loop

Do Tasks hav e multiple predecessors AND multiple successors ? Exit loop : continue

Do Tasks hav e same calendars ? continue : Exit loop

Does Task(@ID+1) hav e constraint ? Exit loop : continue//Need to confirm which task is “second”

Do either of Tasks hav e [Merge Exclude] set to “Yes” ? Exit loop : continue

CREATE new task unde r summary :

Calendar = Task(@ID) calendar

Name = Task(@ID).name + “ – “ + Task(@ID+1).name + “ [merged]” //beware 255 character limit

Notation Notes:

Task(@ID ) - The tas k

wit h giv en ID number

Conditio n ? Tru e : False

14 10/25/2019

Summarizing Result

• No logic lost • Note how Task 2E and 2F don’t merge because of the mixed calendars

Before

After

15 10/25/2019

Nex t Steps

• PACE IMS total size was 14,181 lines • Performing those steps gets schedule to 4600 lines

• While still large, this is a much more manageable starting point

• The bulk of the steps ca n be done by analyst without a significant time commitment from project staff

• Map cost and risk per typical JCL procedure

• Find tasks with high total float • Are they driving cost? Do they have a risk mapped?

• If not, then tha t whole branch of the schedule is a candidate for removal

• Linearize schedule – change giver/receiver sections into direct links • Of the 4600 PACE lines, 542 were rec/del milestones

16 10/25/2019

BACKUP CHARTS

2019 NASA Cost and Schedule Symposium

1710/25/2019

The Integrated Master Schedule

• Integrated Master Schedule (IMS) per 7120.5e • A logic network-based schedule

• Total project scope of work

• Traceable to the WBS

• Discrete and measurable tasks/milestones and supporting elements

• Time phased through the use of valid durations based on available or projecte d resources an d well-defined interdependencies

• NASA Scheduling Handbook • Project IMS will receive final baseline approval at the end of Phase B (at KDP C)

• Basis for time-phasing of the EVM Performance Measurement Baseline

• Task detail should be discrete enough to accommodate the collection of actual time and cost charges...

Neithe r 7120.5 E no r NASA Scheduling Handbook prescribe

specifi c IMS requirement s (e.g ., task durations) 18 10/25/2019

Other IMS Guidance

• GAO Schedule Assessment Guide (10 Best Practices), DoD DI-

MGMT-81650, and DoD EVMIG provide more specific guidance

• Milestones

• LOE Tasks

• Constraints

• Summary Structure

• Margin

• Rolling wave planning

19 10/25/2019

Large Schedule Complexity

• Large schedules routinely have three features that complicate thei r use in risk analysis: • Repetition – e.g., giver/receiver or CDRL sections

• Redundancy – Complicated logic networks make it easy to insert redundan t logic

• Superfluity – Recurring LOE tasks, just-in-time tasks on or near the critical path , work not really driving launch in general

• None of these issues necessarily indicate bad scheduling practice • Giver/receiver sections help organize and highlight key interfaces

• Redundant logic prevents the schedule breaking when deleting tasks

• Tasks tha t are superfluous to a risk analysis on the launch date are still necessary for planning, tracking, and EVM

20 10/25/2019

Practical Consideration s with NASA Master Schedules

• The typical JCL is performed before PDR and KDP C • IMS is typically still a work in progress in this phase

• No defined size, but 5,000+ tasks is typical fo r integrated schedules – as high as 20,00 0 not unusual • Size often seems arbitrary, driven by structure decisions and contract structure

• Summary tasks in Microsoft Project usually align with WBS at higher levels • The uniqueness of projects and their schedules comes through at the lower

levels

• The level o f available data for uncertainty and schedule complexity drive the need for a simpler, higher-level analysis schedule

21 10/25/2019

Redundancy Example

• We’ve reached task ID 4

• In this example,

the link between

ID 4 to ID 7 i s

redundant

• Not the link

from ID 4 to 12

• List 1 = 5,7,12 (this is the order I go through them for this example) • List 2 = 6,7,14 (all successors to 5) • List 3 = 7,14 <-7 here matches the 7 in List 1! (all successors to 7) • List 4 = 13,14 <-nothing here matches list 1! (all successors to 12)

22 10/25/2019