Define Your Job

You have a Program Management job leading a product or service development effort. Is your job as Program Manager a Tech job, or a Business job?

Take Tech to mean that the work you perform, or of which you directly manage content, will become part of the work product of the Program.

Take Business to mean that your work determines or manages spending for expense and capital, or manages use of workforce, or time; all used to develop the work product of the Program.

Sometimes the job can involve both.

Each side, Tech or Business, has quite different responsibilities!

A Program Plan manages the business of realizing the product-market vision of the organization, into the intended Product or Service, together with its intended financial performance. Technology is mapped to business execution of the Program. It may coordinate work in the same way as a SAFe Program Increment (PI) plan coordinates technical integration sequence requirements. But this plan methodology is a quantified extension of that, incorporating Time and therefore is a more accurate representation of work flow, capable of managing materials, partner work, and finances, inherently tying together money with time. Many of the elements of this methodology have been described in articles referenced at the bottom of this one. This article is about creating and using a quantified Program Plan using those elements to achieve excellent Program execution and product results.

The methodology described here scales pretty nicely. It's been used primarily to develop new products of multiple elements of EE/ME hardware and system software, with full system products for internal test as well as for customer system reference design. The concepts should map to many Program scenarios. More resources, references and tools are provided on my website, linked at the end of this article.

Universal Constants for Program Management

• Change is Constant.
• You can't beat Physics.
• You can't create more Time.
• You can't go faster than light.

... or can you? Sometimes that would be more than nice. Coupling effective planning and execution give your Program powerful methodology effective in avoiding and overcoming hard problems that result from these and other universal constants.

Why Wouldn't You Want a Program Plan?

I hear all these reasons to not create and use a Program plan:

• Planning is a large, complex effort, and always wrong
• It isn't Agile
• Estimates are guesses, un-certain, and don't foretell the future
• We have to estimate Time AND Cost???
• Estimates may be optimistic, aggressive, best-case, made to satisfy the boss, inaccurate, compromising quality
• Estimates may be pessimistic, worst-case (or un-managed), made for "a** coverage".
• Estimates fail to include all efforts, or indirect efforts, that add time and cost and increase inaccuracy.
• Estimates that do cover all effort tend to look un-aggressive and are unacceptable to Management.

Why Could A Program Benefit From a Plan?

"If you don't know where you are going, you'll end up someplace else." - Yogi Berra

A well-publicized plan identifying critical-path tasks and kept up-to-date in real time, provides a quantified mechanism:

• to coordinate multiple parallel/concurrent work efforts throughout the organization, through normal conditions and through change;
• to identify problems and solutions;
• to manage risks;
• to manage ever-present change;
• to mitigate adverse effects of mis-estimates, technical issues, change;
• to capitalize on unexpected opportunities;
• to make decisions - helping to identify decision points, deadlines, and criteria; and to model outcomes and manage implementation of changes;
• to develop and communicate project structure, status, and roles of contributors within it.

A plan can create visibility that

• Drives Involvement and buy-In throughout the organization,
• Creates day-by-day self-determination across, and at all levels of the organization, to meet identified short-term and ultimate objectives. People can figure out for themselves what they should be doing, identify and deal with risks, problems, and opportunities.

Planning and executing are an opportunity to assert valuable PM presence and to provide leadership. These make visible responsibility and accountability of Program Management, and then throughout the organization.

Agility still applies to these programs

The primary role of Program Management is to manage and deliver a complex, perhaps large, program to meet its constraints which include revenue date and program financial spending amounts and timing. Regarding agility, it is not necessarily PM intent to implement scrum in a prescribed manner, although the program may adopt that in whole or in part within an organizational custom. However, it can be PM intent to implement an agile mindset: Changes to product and program are inevitable during the course of the program, so the program must be able to be able to accept and incorporate change whether it affects a part of the program following scrum practices, or a part constrained by dependencies, sequences, time and finance.

Hardware development physics and logistics are different than for software development in many ways. Many of the factors are described in this article, and also described in others listed for further reading below. Nevertheless, important aspects of Agile can be productively applied to hardware development, described in this article and by the further reading articles. For reference, a series from another source also discusses Applying agile to hardware development.

Agility implies acceptance of change, and also real ability to incorporate change, all based on current conditions. It goes without saying that incorporating change should maintain or even improve business from the Program, rather than to degrade it.

"No Plan" during execution, particularly of large or complex Programs, may lead to chaos managing change. Numerous project elements developed in parallel with mutual dependencies on sequence, availability, resource and funding, each contribute to both logistical and technical complexity. Ad-hoc management of change to these projects can be a challenge.

You don't just make a plan and then store it in a corner. And, having a plan doesn't mean your project can just "turn the crank" and be successful. The world may change, or the plan may be wrong or incomplete. A plan is initially "due diligence" to tangibly support asserted business success of a proposal - "best known path from here". Then, the Plan becomes increasingly accurate as it is updated with actuals, as well as over time as constraint uncertainties are refined, and as tasks are completed, removing contributors to uncertainty in upcoming work. A plan updated with change may provide coordinated direction to specific processes and organizations to incorporate the intended change. Also, recording of such a plan on completion may provide organizational learning leverage to subsequent programs, on program structure and practices, timing and cost.

Common practices in System Development that support Agility and Agile methodology

Modular Architecture: Hardware, and related software (firmware, drivers, management) are inherently modular, separated by interconnect physical and logical interfaces. This allows for parallel independent workflow.

This article describes decomposition of a Program into several parallel Integration Cycles, with stated expectations on modules and organizational operation. Expectations include incoming and outgoing functionalities, with dates needed to coordinate integrations among system modules and organizational processes. This top-level Program structure allows each module development effort to choose its local methodology within the stated expectations, allowing substantial self-determination by developers, and balanced to support business needs on cost, operation, and timing.

Dependency Inversion: As design progresses, system entities become progressively abstracted: Architecture/Design (Function, Partition, Interconnect, Physical) -> Boards, Drivers -> Assemblies/Chassis/Platform -> System. Interactions among these are typically well-defined.

Modern hardware design is largely controlled by firmware with an element-level management processor, which can set chip configuration control values via control pins, messaging, or training operation. The firmware is connected via API or messaging, allowing separate management operations to configure and control low-level configuration and operation.

Dependency Elimination: Scrum methodology advocates elimination of dependencies, and many of the items identified in this section are means to do so. Dependency elimination is sometimes achieved by broadening scope of a Scrum team to cover development that would otherwise have been a dependency from outside that team.

That is not always possible, and may create awkward focus to the team. But there is another way: Planning, including identification of dependencies, far enough in advance that required work is completed before the work product would become a critical dependency.

SAFe methodology provides Program Increment planning that plans out upcoming dependencies in shortly-upcoming work. PI planning doesn't include dependency task duration so sequencing is approximate. So PI can be a partial solution, whether or not full SAFe methodology is employed.

For system work, the GANTT developed early in the Program, and updated throughout reflecting realities with increasing accuracy, identifies task dependencies with duration (at least approximate), so delivery sequencing and time can be planned. The GANTT methodology can provide complete elimination by planning and positioning work ahead to be completed before it becomes a time-critical dependency. The GANTT methodology requires work up-front and continual update. But it very reliably identifies dependencies and can be used to either eliminate or at least directly manage them, providing the best known way to optimize workflow.

Continuous Integration: Repeated, iterative Integration Cycles integrate changes and additions, abstract them, and provide for escalation of testing along the routes of abstraction (board-level, assembly-level, chassis-level, system-level). Each level of test persists throughout the development effort, and each Integration Cycle inherits test and change results from prior Cycles.

Feature Toggles: Modularity facilitates separation and function toggle, so much system debug can be done on live systems. However an anti-pattern exists: system elements operate at a low level in the system, and can require invasive interaction (crash, re-boot, power cycle) and initiate errors that can be fatal to system operation. Also, some system test must occur in hostile environments and may be tested to failure. The anti-pattern can be avoided by performing these tests on systems separate from other development efforts.

Team Development: System elements (hardware and associated software) are inherently cross-functional efforts (EE and ME, Driver, Supply Chain, Manufacturing, Firmware, System function, Test) driving constant review among team members. Dependencies in this environment are inevitable, but common practice, including capabilities discussed in this article, facilitate identification and management of dependencies among system elements.

The Program structure described in this article does not mandate Agile team structure or any other team structure. Team structures and methodologies are likely to be mixed in a system development program; the requirement is to meet the agreed Integration Sequence functionality and timing. The best team structures match their work content.

If there were a preferred team structure, it would emphasize personal responsibility and initiative and would eschew bureaucracy and group-think. Other articles in this sequence describe programs built as a hierarchy of focused teams organized around functional product elements or sub-groupings of functionality, with dev technical leadership, and coordinated by agreed details of the Program Plan. Focused teams are small, coordinating on their own focus and dependencies by communication and planning rather than by broadening team content. Communication is transparent and covers short-term work and position in the longer-term, and is relevant to each sub-team. This is accomplished based on data integrated among sub-teams and communicated using data and images. These are illustrated below. People love working in a focused team when related teams competently provide deliverables in well-coordinated fashion.

Version Control: System development Programs are usually large and complex, requiring version control throughout. Hardware elements operate within strict version control systems for hardware design (Verilog) and hardware entity builds (BOM, build plan). Driver and firmware inevitably work within private “development" branches prior to integration into system branch and release branch. In short, version control and branch management are commonly well-defined for system efforts.

API-First: Because of modular separation, physical interfaces are usually standards-based buses and serial links. These may embody several instances, but because they are adopted by customers, they are usually well-documented. Functional separation via driver interface to systems typically uses standard structures such as REST, SOAP, GraphQL, XML-RPC etc.

In the preferred Program Plan described in this article, infrastructure of the product is developed right up front in the Initial Design Sequence. This includes APIs along with architecture, function partitioning, interconnect, messaging, data structures, libraries etc. These are done early rather than throughout the Program, to avoid popping up asynchronously later, thereby limiting dependencies and allowing product function and feature development to use them without dependency.

Messaging Interface: Modern system-element design above chip-level is typically controlled by firmware and software, using message-based command verbs. Functions may depend on each other, but substitution of function from other sources (prior systems, commercial product) may be used to postpone direct dependency and separate integration and debug efforts.

Documentation: Because low-level system elements are typically designed among numerous partners (chip-supplier, board fab, standard interfaces and APIs, system designers, supply chain and Manufacturing Operations, plug-in suppliers, and PM logistics plans and Program Plan discussed in this article), numerous instances of documentation are common. These plans may also inform other program efforts operating in parallel, or archived plans can provide history informing subsequent program efforts.

Agility Through Automation

Complexity of a program is inevitably reflected in a Program Plan. Complexity may be due to details of its technologies, to program size, or to organizational complexities such as dependencies, locations or diversity of specializations. These are often characteristics of programs handling physical materials (computer hardware, civil construction) but could apply to software programs as well particularly if they span software application technologies, or broad global development or product distribution.

Such complexity has historically required onerous effort to plan and manage change, with the result that plans may remain inflexible if not inaccurate. But it is quite possible to build a plan in such a way that a computer can do the hard work.

This allows us to keep the plan up-to-date, reflecting current realities, incorporating change, and quickly able to communicate among organizations and individuals to coordinate tasks, priorities, outlooks and financials.

Using this methodology, a program can accept and assess change, then coordinate, incorporate and execute change with agility. A section below describes description of the Program plan as tables that can be JOINed, and QUERIED for reports and illustration, and communicated throughout the Program - using computer power to update and propagate change quickly and with minimized effort. Just takes some methodology and data design up front, which can also be leveraged repeatedly into subsequent Programs.

In addition to reducing work to plan change throughout the product and organization, a plan incorporating automated update may avoid planning mistakes and omissions, propagating change correctly among multiple repeated instances. Eliminating mistakes should also be an Agile consideration!

Summary of Planning Approach

Remember the advice from my article on PM Skills: When confronted by a big problem, break it down. It's never all-or-nothing. Planning inherently breaks down a complex work effort into chunks manageable over time and among multiple organizational, process and project elements.

• Business Plan Proposal and Review: Market Description, Opportunity, Date requirements; Product Description and Positioning; target Product cost; Estimated Program financials, Revenue Target; NPV or ROI estimate.
• Detail Critical Product Requirements. Coordinate internal design functionality.
• Development Initial Design Sequence: Architectures, Libraries/Infrastructure/Chipsets/Technologies, Element Partitioning and Function, Interconnect, Physical Design evaluation, Critical function prototyping; to design readiness for initial build/integration sequence.
• Identify Program Plan integration Focal Points, for build/integration/test sequences taking the product effort from initial/core design through work incrementally adding and refining functionality, and leading to shippable, produce-able, supportable, revenue product reliable/compliant/usable by customers. Define/Refine Focal Point Integration across Elements and Organizations.
• Build Initial Full-Program Task Plan Covering Focal Point Design and Integration Sequences
• Quantify/Estimate Task Durations. Design the Program Critical Path
• Attach Materials to the quantified Task Sequence plan. Develop Logistics and Finance Reports. Plan is the basis for Target Program Budget; Annual Program Budget; and Quarterly Program spending and outlook review.
• Plan Review in Program Kickoff, resulting in authorization of full activity with planned spending.
• Use the Plan to Monitor, Communicate and coordinate to all levels: Progress toward Ultimate, Recent Happenings, Risks, Mitigation; Implementation tasks and deliverables; Change planning and task coordination; and communication of short-term and long-term progress and objectives. See Organizing Program Communication.
• Update the plan in real time to reflect actuals, and continually improve accuracy.

Initial Design Sequence

A Program is typically formally initiated by a business proposal, usually driven by the market-oriented Product Management organization. The business proposal includes market concept and explicit product positioning and key features, with high-level estimates of development duration, cost, and NPV/ROI from Program Management. Once the proposal is accepted, work begins on initial development work, in parallel with full Program planning.

Much design work for product core structural hardware and software platform design occurs at the start of the program, even if design continues through the duration of the program. The following steps for core hardware and software design steps sketch out system-level programs. Even though other programs may differ substantially, I would expect a program to develop some sequential intent at least analogous to these steps.

Technical management of design work is generally led by DevLeads and Scrum Leads et al., more than by Program Manager.

Design work, and Test work are usually intangible and duration is difficult to estimate. I use TimeBoxing to allocate a block of time approximately adequate based on prior program actuals. For a program of the type and size of my examples here I use 6-months of design work described just below, followed by 3-months of physical design (layout, build drawings) with continued parallel design work. This 9-month block is followed directly by iterative/parallel/sequential Integration Cycles described below to build, integrate and test hardware/firmware/software prototypes, to further develop function and add-ins, and to develop production and support capabilities. These lead to production and shipment to customers.

Hardware: Much design is done before first build and integration steps, with corner and margin testing, testing scalability and stability, compliance, and regulatory following later in the program. Hardware early design work includes but is not limited to:

• Hardware Architecture, including identification of critical chip-sets and interconnect. Processor, Switching, Interconnect.
• Functional Block Diagram.
• Functional Partitioning, Interconnect, to Board-Level for Datapath function and Management.
• Chassis Dimensionality, Board-Level Form Factors, Chassis Backplanes, External Interconnect, Internal Interconnect, Power Supply and Distribution, Air Flow, Cooling, Specification of initial Plug-ins.
• Board-Level Major Item Placement, Routing Channels, Layers, 3D Dimensional requirements.
• Detail ME and EE Functional Logic design.
• Firmware (FW): Processor, SOC, power and clock configuration, VLSI configuration, Boot, Package load, FW update, FW Board test (bringup, corners, on-board diags, mgmt diags), software update, FW System Function.
• Board Place and Route.
• Integration Focal Point Sequences (more below)

Software: development is usually more open-ended than for hardware, with design extending through much of the life of the program. SQA and branch management are introduced, then bug triage, leading to release candidate.

Developing a good block structure of intended software and hardware development modules right up front helps break down the large problem into smaller executable pieces.

• (Sketches of) Software functional architecture, client and server data structures, database structures, messaging/interconnect, memory management, Ops management, Management framework, libraries, interconnect.
• Functional Block Diagram, allocation to physical execution entities, transports, interconnects. Libraries.
• Functional block detail, management, major data flows; database, I/O, interconnect.
• On-board firmware function -> Driver and Client-Server interconnect -> Low-level Management -> System-level function.
• Management block detail, interconnect, CLI/GUI/BUI. Device-Level, Subsystem-Level, System-Level, System Mgmt Framework integration.
• Interconnect, Driver, HW/FW platform virtualization.
• Plans for major data flow development efforts.
• Plans for piece-wise integration steps. Lash-ups -> on-board infrastructure, functional chunks, interconnect, messaging -> Interconnects (client-server), external services, databases -> remote operators.
• Performance, scalability, stability.
• Integration Focal Point Sequences (more below)

These pieces are next woven together into a small-fixed-number of major integraton steps of hardware and software functionality, leading from early development through broader development then readiness for production and release to commercial use, and subsequent enhancement/bugfix releases.

Develop A Focal Point Description of the Product

While the initial design sequence takes place, the Program Plan for development, qualification, and product delivery is developed, as described further below in this article.

As initial development proceeds, the full Program Plan in parallel develops detail incorporating design outcomes. This describes detail of product specification and critical design; plan for effort on development, production, and support; schedule (tasks, dependencies, critical path and time); logistics; and financials of the Program.

Translating the concept to executable reality, the Program Plan identifies "manageable entities" to be focused upon, planned and managed, guiding development of the program as a whole. Such entities might include some of these:

• Architecture and Design: Product Concept -> User/System Interfaces, APIs, GUIs, Maintenance -> Logical/Physical Architecture -> Functional blocks -> Interconnect -> Data Flow; Security.
• Product Structural Elements: Partitioning, Physical and Virtual entities, key data structures -> Functional descriptions -> Structural realization (files, branches; placement, routing channels, interconnect, critical component choices, libraries, licenses)
• Product Function Class:Product infrastructure (messaging, memory management, I/O), Data Transfer and switching (LAN, Bluetooth, WiFi, PCIe, NVMe), Databases, Management (Physical entities, Virtual entities, Product, System, Framework/Standards; and management data interconnect)

These "manageable entities" are next woven together as Tracks down a small-fixed-number of major Integration Sequences of hardware and software functionality, leading from early development through broader development then readiness for production and release to commercial use, and subsequent enhancement/bugfix releases. The Table figure below specifies functionality planned for each Integration Sequence as a row across columns of Manageable Entities; and the Track of each Manageable Entity as a column down the rows of Integration Sequences.

Initial development continues until the design is ready to build critical elements, assemblies and systems for an initial Integration Sequence. This Sequence includes production, integration and test, and then distribution across the organization for validation and broader development.

Typically when the Program Plan is developed and agreed among Program principals, the organization hosts a formal Program Kickoff enabling full spending and use of resources described in the Program Plan. This Kickoff authorizes full-product/full-system prototype build sequences described.

Spending on Integration Sequences involves distribution of systems to multiple organizations for continued development and test, a much higher, and spikier, expense than the more-focused initial development. When the design and Program are ready for this initial Integration Sequence, the Program Plan is reviewed in a formal Program Kickoff. Acceptance of the Program Plan by Management authorizes the significant spending required by the described development and Integration Sequences leading to delivery to customers, and installation, use and support.

Hardware and Platform: Authorized by the formal Program Kickoff review, hardware development and platform software below the "platform virtualization layer (firmware, driver, memory management et al and below.)" begin to incorporate full-product/full-system Integration Sequences including prototyping, internal test, and Formal Compliance test as described in the plan. Hardware is built for development and also for internal development of add-on hardware elements and for the breadth of software development described in the Program Plan. As each Integration Sequence occurs, management of logistics, spending, and material control complexities requires significant management.

Software: Concurrently, software development more or less continues down the methodology of the early design sequence: repeated cycles, possibly organized into sprints, of Architect, Design and Code, SQA, Compliance and Release.

• SQA covers evaluation of function, negative, performance, capacity, scalability, install/update, customer environment exposure etc. Compliance can include standards for Finance, Privacy, function and API compliance etc.
• Release probably includes at least two parallel streams: Beta (Internal Dev+SQA+Compliance+Customer Evaluation) and Production (Customer commercial use).

Develop Integration Sequences Around Integration Points

Assert Project major structure involving sequencing, and aligning major dependencies. Build buy-in throughout the organization, management, and adjacent functions, on product structure, sequencing, development and validation plan.

Assert key milestones and sequences. It's useful to focus on Integration Points, within longer Integration Sequences. An Integration Sequence typically includes operations for Material Acquisition (PO, distributor, lead-time); Fab (chip, board, metal components); Element build, assembly and Mfg. test (boards); Assembly build and Mfg. test (multi-element chassis); System Integration (full HW/SW); Distribution; and Use (Dev bringup, corners, SW, SQA, Formal).

An Integration Point to plan within each Integration Sequence is likely the first operation that irrevocably commits material to an Element Build (e.g., SMT step) within the Integration sequence. Preparing for, then executing and finishing each integration sequence, provides great organizational focus and accomplishment toward program delivery.

The content of each cell in the table below summarizes tasks on the Manageable Entity described in its column, during execution of each Integration Sequence specified by its row. In the Table figure below, boards for Integration Sequence P1 are fabbed at the Local Fab on a Quick cycle. For Integration Cycle P2, Management Software is completing tools for System Config and Benchmarking, and for collecting and presenting Stats. Bugfix on functionality from P0 and P1 continues.

The Program should build and quantify the plan with input, review, buy-in and agreement across and through all levels of the organization. Describe each Integration Sequence, covering: Usage and distribution of developed product, and status of manageable entities by owning organization for sequence start and completion. Include significant hardware, software, built entities, operational entities (e.g. permitting, formal test, regulatory). The figures below are high-level visuals of this, and the Tables farther down quantify configuration, usage et al. Each Integration Sequence is represented by a Row in the following Table; and by a row of sequential multi-color steps in the following visual.

Each Integration Sequence drives short-term focus throughout the whole organization. As each Integration Sequence is executed and achieved, real and coordinated progress is made toward the ultimate objectives of the program.

This doesn't need to be ultra-detailed. The organization will fill in details via contained element regular program meetings, sprints et al. Description needs to be able to identify critical elements, critical path, and expense with specifics. Minor items could be identified by groupings rather than detail. Typically 80% of electronic product cost is in a dozen key components, and these should be identified. Creating a tangible representation like the following image provides a basis for more detailed discussion when it is needed. For example, the Materials plan (table follows) implied by activities in this table will represent more detail.

The figure above shows a Table representing major program sequence.

This table describing characteristics of Integration Sequences is a critical part of coordinating the multiple development methodologies that may be in use. These develop electronic and mechanical hardware; software from firmware to management and system software; Supply Chain, Manufacturing Operations, Customer Engineering, and Analyst Support. This process simultaneously syncs product deliverables in time and function, satisfies many task deliverables and dependencies, and ratchets progress toward product and Program completion, independent of the multiple technolgoies, methodologies and processes involved.

Develop Implementation Plan Addressing The Integration Sequences

Usually 5-6 major program Integration Sequence steps are defined in such a table. Each Sequence includes an Integration Point at which deliverables specified by organization are integrated together, creating the major deliverable of the Sequence. This integrated deliverable is distributed and used for major Validation/Test/Compliance/Certification deliverable specified for the Integration Sequence.

The figure above illustrates Integration Sequences I have used for system products. Your product may have its own Integration Points different than these, but I expect you can map the concept illustrated. Further examples below.

Example Detail

• P0 Initial Bringup of physical platform. Product Elements, Local CM, prototype suppliers, Dev test. Hardware, firmware, test, scaffolding. Local focused distribution. Handful of units. 6 months P0 Fab to P1 Fab.
• P1 Virtual platform for limited local distribution. Driver, I/O interconnect, physical management. Client and Server connect. Product Elements + Assemblies, Local CM, proto suppliers, CM test. Corners, prep for compliance. Local development. 1-2 dozen units. 5 months to P2 fab.
• P2 Full product function for broad internal and limited customer distribution, User interfaces, scaffolding replaced. Product Assemblies + Systems, Production CM and test, prototype suppliers. Distribution within corporation, Alpha customer exposure, compliance. 2-3 dozen units. 4 months to PP fab.
• PP Full product function for formal test and customer exposure, Product Systems + Spares, Production CM, suppliers, test. Build to PM order. Beta customer exposure, Formal compliance, certification. 3 months to Pi fab.
• Pi (Pilot) Full product function for initial product sale, Product Systems + Spares, Production CM, suppliers, test. Customer formal beta. Build to forecast, ship to order. Initial International distribution. Support organization, spares. 2 months to FCS.

Showing progression of Tracks Through Integration Sequences

It may seem that the cycles shown are only about hardware development. But Integration Points can help focus software development, too. Furthermore, experience shows that even if development of hardware is included in the Program, about 80% of hardware built (including acquisition of off-the-shelf equipment) is for software development. That hardware is used for software development, distribution, test, certification, and customer exposure; requiring these or similar cycles. Even if new proprietary hardware development is not part of the Program, typically capacity and configurations are required for those software activities. Any internal capacity to be used must be sized, scheduled, and allocated. External hardware for incremental capacity or configurations would need to be sized, scheduled, purchased, and integrated. Some of these activities and spends could be somewhat invisible to the software development organization, if they will be executed by an IT or Lab organization. But the Program would inevitably retain responsibility for overall management including planning and results of these requirements.

Build A Quantified Plan Covering All Integration Sequences

The Initial Design Sequence discussed above is shown at top-left in the diagram just above. The Critical Path starts with it, and the Engineering Commit Review kicks off spending and Critical Path through the remainder of the Program. The Critical Path for each Integration Sequence has dependency on completion of design for the upcoming Integration Sequence, plus testing required to validate the prior Integration Sequence.

Start building the GANTT with a sequence of Timebox tasks to encompass build and initial test, one for each Integration Sequence. For a system development program, fairly large, experience shows the following. A smaller program likely requires fewer or shorter steps for build, assembly, software and integration, and Manufacturing development.

• Initial Design: 6mo + 3mo Physical Design; to P0 SMT
• P0: 6mo SMT+BdAssy+Bringup; to P1 SMT
• P1: 5mo SMT+BdBuild+AssyTest; to P2 SMT
• P2: 4mo SMT+BdAssyBuild+SysTest; to PP SMT
• PP: 3mo SMT+BdAssySysBuild; to Pilot SMT
• Pilot: 2mo SMT+BdAssySysBuild; to FCS

The Critical Path is shown by the red line running through parts of each Integration Sequence in turn. Program Management needs to identify it, keeping the plan up-to-date, and continuously identifying the CP, and focusing management on optimizing that path, prioritizing issue resolution and provisioning of CP tasks.

You may notice each sequence in the above example image starts with a long-duration task labeled "SupplyChain". The image actually is to scale from real experience on multiple programs of this size and technology. The SupplyChain duration in the image is driven by materials with long lead-time such as new chips, connectors, PCIe cards, switches, servers etc. The date for the Purchase Order initiating that lead time is calculated BACKWARDS from the Build task using that material. The Build task itself is driven by preceding tasks such as design readiness and test completion from the PRIOR Integration Sequence. Greater detail is shown in the GANTT image below. These illustrate how weeks of time can be taken off the Critical Path by advance planning, and overlapping tasks.

It is wise to split first builds from each CM provider site, into an A build and a B build (local P0-A, P0-B, offshore P2-A, P2-B), to check the A build for Dead on Arrival problems before committing remaining material to the B build. Material should be acquired for full A+B quantity, but build A is initiated for perhaps half of units up to 10, to be evaluated before SMT material commit to B build. Quick check of the A build commonly includes shorted power planes, clock issues, wrong sense on high-speed signal, layout-induced timing mis-match on memory data/address traces.

For hardware builds that may produce numerous prototype units, usually the GANTT only needs to detail the First-Off units, first to complete assembly and build test. The Program will use those First-Off units to provision subsequent Critical Path tasks. Later units can usually provision non-critical tasks, using slack without affecting anybody's schedule. And you can always add detail to your GANTT for last-off units if you have a situation that does need it.

Tasks preceding the irrevocable SMT task in each Integration Sequence should be calculated as reverse dependencies from SMT Start. See Design the Critical Path, Don't Just "Let it Happen". These include component supply chain, fab material, board fab, component acquisition, board-level mechanical part build/acquisition. As a result, they will not be on Critical Path, and can be started independently early to be ready for their associated SMT. Reverse Dependencies are a feature of Microsoft Project; they may need to be manually created in a different GANTT tool.

Development of software below the Virtualization Layer should be able to fit into the Integration Sequence overlaps. Interconnect drivers may need partitioning into subsets to achieve this. Software above that layer is more fungible and, if necessary, some function could be prioritized and sequenced, pushed to later internal or external releases as needed to fit requirements of each Integration Sequence. Some higher-level software for an Integration Sequence is not required early in that Sequence.

Test of Board, Assembly, and System in each Integration Sequence is broken into two phases in each Integration Sequence: First, test proving the current build will be viable to initiate next-Integration Sequence irrevocable SMT; Second, formal test unlikely to affect irrevocability in the next Sequence. The formal testing can cause component values in the next sequence can be changed, firmware updated, ME parts replaced etc. without violating the next Sequence. Anticipated fab-level rework, however, would force the next Sequence to wait until that can be incorporated before that build. However, that would be unusual beyond P1.

Testing following the build viability validation will not gate the next Integration Sequence, so will not be on Critical Path. Some testing from later Sequences (Compliance, Certification etc) may gate final product release, however.

Estimate tasks and dependencies, build a GANTT plan consisting of major tasks with dependencies, and with estimated durations. The Critical Path shows on the GANTT. More on Estimation, below. Iterate the plan for best fit of the Critical Path to Program Objectives. Escalate solvable discrepancies, commit the Program to Likely schedule and budget, manage Critical Path to Best Case, and report, escalate, resolve or mitigate deviations as the program progresses.

Budget bloat can be somewhat controlled by building DevKit systems for most development work. Most developers don't need the full capabilities of the product, and a "stripped-down" configuration will be sufficient. So DevKit configurations include limited processors, memory, failover, scalability, LAN (use VLANs), displays, etc. More fully-configured systems can be built for SQA, Compliance, and internal and external Alpha and Beta systems, and can be used for corner testing of scalability, fault-tolerance, capacity etc.

The result of the Timebox infrastructure, with detail for each Timeboxed Sequence of the Supply Chain acquisition, Board/Assembly/System build and test, and Formal test sequence defining each Integration Sequence, should be a plan consistent with the overlapped image above.

When the Critical Path tasks have been incorporated into the GANTT, the Timebox task structure may optionally be removed. That could shorten that part of the Integration Sequence; or if GANTT tasks require more time in an Integration Sequence, they will drive the planned time for the critical path of that Sequence.

GANTT Quantification should specify major staffing. This might be at the levels such as: Corporation, CM Local ("CM" - "Contract Manufacturer", typically offshore with onshore limited capability), CM Offshore, CM Production Site. Associate a calendar with each. No need to identify days off and weekends, you can't identify that level of accuracy, and you can manage around it in real time. But you need national calendars that identify major effort deviations such as Lunar New Year, Golden Week, Christmas, Thanksgiving. Also, Asian sites typically work a 6-day week vs. 5-day weeks in Western sites. Size tasks in weeks, duration reflecting local weekly workdays.

Below is a detail image showing a piece of a program GANTT plan implementing the above image. Note the Critical Path indicated in red. Dates for some predecessor Supply Chain tasks are calculated backward in time, as above, from the irrevocable critical path Build task.

From MS Project, an Excel file can be exported using VBA containing fields chosen to represent the Program. That file is link-able with logistics Tables via field TaskMilestone inserted into the MS Project file. Templates (free) are provided from my website referenced at the end of this Article.

How To Estimate Durations

Some tasks are easier to estimate than others.

• Bringing up an existing, working, code base on a new platform: not hard to estimate or Timebox.
• Bringing up an existing library not previously used, on an existing platform: not too hard to estimate or Timebox.
• Bringing up an existing library brought up on a prior version of new platform: not hard to estimate or Timebox.
• Board and chassis build, assembly and test are not too hard to estimate but pay attention to parallelism and critical path as illustrated in this article.
• Compliance Test and Certification are not too hard to estimate or Timebox but note international Compliance may introduce case-by-case impediments including shipping, customs, agency test scheduling.
• Bringing up new code on an existing platform: harder to estimate, may need continual rework during debug.
• Fab, build, board test, assemble, assembly test: Easy to estimate, incorporating past CM times. Reflect improvements through Sequences, to Supply Chain, test automation and local cycle times. Pay attention to locality requiring shipment and customs.
• Designing a new chassis with new board assemblies: hardest to estimate, Timeboxed initial tasks. Incremental function may overlap Integration Sequences. Probably on critical path of everything else.
• Designing and bringing up new code on a new platform: hardest to estimate. Timeboxed initial structure, more overlaps among recurring Integration Sequences. Try not to put on critical path of everything else. Build workarounds, scaffolding to mitigate.

Wherever possible, keep difficult-to-estimate tasks off the Critical Path. Ideally, bring up new stuff on a context of older stuff, or on scaffolding. That is not always possible, but check your cases, most parts of a program will not gate irrevocable tasks. You might also push function among releases to support the program as a whole. You could plan based on "how long do we have for this".

Basic estimating - References
www.projectmanagement.com/project-task-duration-estimation-and-scheduling
valuetransform.com/duration-estimates/
www.projectmanagement.com//project-task-duration-estimation-and-scheduling

Estimation Methods

• Timeboxing. If a section of work produces an intangible work product, and therefore no particular quantitative estimation method applies (several following in this section; history is the most likely guidance), then break the work into Timebox segments. New-design work is commonly intangible. Intangible work defines more tangible subsequent work efforts on implementation, but intangible work itself is difficult to quantify.
• To quantify such work, set up a a sequence of timebox segments, each with an intended objective leading to objective of the intended overall work section. These can be represented as a collection of rows in the form of the Integration Sequence Table. Each row indicates its objective, and indicates work distributed along manageable-entity tracks described in its columns.
• Such a plan need be neither completely detailed nor immutable; content should be managed in planning at the start of each timebox segment. Assign a reasonable "Time Available" quantity to each timebox segment, so that they add up to the time available for the section of work as a whole.
• As each timebox segment expires, plan its upcoming timebox segment. Push un-completed items from the expired timebox segment into the upcoming segment. Update the upcoming timebox segment to reflect its will fit items, pull-in might fit items from its following segment that seem possible to complete. Push won't fit items to the following segment. Of course, continue to reflect required dependency-deliverable sequences.
• New timebox segments can be added where needed, defined with objectives. But of course, the whole organization should continue to attempt to maintain the overall timebox sequence duration. If its duration pushes the Program critical path (some might, many won't), then as with any task pushing out critical path, you will need to mitigate that push or else re-commit to updated Program completion of the critical path.
• This essentially works as sprints honoring overall time constraints, and can likely be managed with Scrum methodology, good at managing intangible work for almost any technology.
• For a program as a whole that includes hardware as well as software, much of the intangible work for hardware is reasonably solid before integration cycles are initiated, before the overall Program schedule is committed. For software, much of its work is intangible for the duration of the project. The ask here is that software deliverables overlap Program integration cycles, shifting work as needed to match Program-level function and time requirements for each.
• Planning for intangible work has led to the #NoEstimates movement, commonly implemented in Agile/Scrum projects, moving away from creating and then following a quantified plan. This has resulted in people thinking that planning "isn't Agile". This may be a matter of scoping the #NoEstimates movement, to intangible work. As long as integration point functionality and timing are met, #NoEstimates can work for software, and for hardware intangible design; but it's hard to see how it would work for integration cycles that include hardware work subject to all its dependencies, deliverables, partners, etc.
• Search #NoEstimates for many good discussions:
  The #NoEstimates Movement
• https://medium.com/serious-scrum/the-logic-of-noestimates-4238e0be3bb6
• https://medium.com/@riaanfnel/the-problem-with-estimates-f3d5cddd5e62
• Allen Holub Get Rid of Estimates https://youtu.be/RrlarrIzbgQ?si=EQT_y66_BptcF6ns
• Basic Agile/Scrum: Story Points with Velocity
• Historical project plans, interpreted for current program, are better than educated guesses: what actually happened in similar situations? These estimates and actuals cause learning even if they were wrong. Furthermore, it is a good idea to archive and maintain project plans for reference when planning subsequent projects. Retrospectives from throughout prior Programs may provide data, especially if time, budget and variance are commonly evaluated in retrospectives (as PMs should advocate!).
• GANTT dependencies and sequencing with PERT duration estimation accounts for Pessimistic and Optimistic estimates, with heavier weighting for MostLikely estimate.
• PERT Duration estimation: T = (Pessimistic + 4 * MostLikely + Optimistic) / 6
• Google search shows many references to PERT estimation
  www.google.com/pert estimation
  community.mpug.com/3-point-estimating-technique-pert
• Oracle Crystal Ball can simulate schedule to show effect of variation in duration or other factors. Model task duration as a fixed value +/- a stochastic variation. You can then determine distribution of possible milestone and completion dates with probability of each. In the event of major adverse operational requirements (such as additional fabout, etc.) the distribution can illustrate multi-mean completions.
• www.oracle.com/crystalball/
• AI: Work is being done to use AI in task estimations for time estimation. AI may be able to estimate based on data from prior programs within your corporation, or perhaps from program data that others have uploaded to the public Internet. (TAKE NOTE: most corporations PROHIBIT upload of data from your corporation up to the public Internet. DO NOT upload your data without permission from a source accredited within your corporation.)
• Article on AI used for Estimation:
• uu.diva-portal.org/

Keep slack out of task estimates, they just pad estimates resulting in a false understanding of the program. Keep slack as a variable that can be used by the Program Manager to alleviate real problems when they occur. Don't give that away before you even start.

Iterate the schedule and material plan to meet objectives of both time and cost, until met or until immutable barriers are identified and explainable. Note that prototype spending spikes at Build tasks, so needs to fit into organizational finance. You may find at first that the organization has not considered spikes in spending, or the need to issue purchase orders in a quarter earlier than material receipt, due to lead time. You may need new agreement on rules for capitalization (lifetime, cost; use of material in destructive or damaging test). Get agreement on schedule timing, and spending amounts and timing profile.

Initial Estimations: Bottom-Up, Or Top-Down?

Time and Money are topics on which the Program Manager must lead. Bottom-up planning on these as a first effort is a path to failure; better to go in with a Plan to be evolved. Bottom-up planning usually encounters planners including invisible slack; extra material; durations likely to be unnecessarily pessimistic (or optimistic!); Trade-offs, especially if cross-domain, haven't been well evaluated; critical-path not known or evaluated. Schedule or Budget planned and executed bottom-up are unlikely to contract later - nothing adds decision criteria as much as Budget and Schedule that fit the business plan. As Program Manager, first determine "how long do we have to do this", go to the Team with a plan that breaks up the work to fit. Then review and update with the Team principals, continuing with all participants driving toward agreed business objectives.

To fit available time+resources+cost, you may be able to shift work (features, non-critical path testing) out (to avoid delay) or in (for opportunity or improved result) among Integration Sequences. Forgiveness or permission for more time or budget vs. agreed objectives is more likely if you can describe the problem and mitigations tried. Time is the most valuable resource, more valuable than money.

Tasks that are NOT Critical Path have more flexibility on duration and start planning; use their slack if changing work flow, to help the Critical Path. If a critical path item is delayed, attempt to remove that work from the critical path, and replace it there with a work-around to maintain critical path progress. Keep the whole program working, not waiting for some uncertain resolution. Then when the issue with the delayed item is resolved, insert it back to use on the critical path. You may find that such a re-fit need not be universal, and can be focused to supply only work needing specifics of that particular item.

Break Critical-Path tasks if possible into Critical and non-Critical segments, and allow only the Critical portion on Critical Path. For example, after a Build, identify tests REQUIRED prior to irrevocable material commit in the NEXT Integration Sequence build tasks as a dependency for that commit. Testing of the previous Integration Sequence usually continues beyond that and may drive dependent tasks that can be revoked, reworked, repeated in later Integration Sequences.

Design The Critical Path, Don't Just "Let It Happen"

Overlap work wherever possible based on dependencies and staffing.

• As a rule, nearly all tasks should begin when ready: dependencies met, staffing available without higher priorities. Don't wait for some big formality; hold a readiness review for the task if that's useful and coordinating. Plan, prioritized on dependency/deliverable constraints.
• Tasks that make irrevocable commitments (e.g., irrevocable use of material at SMT build step) in an Integration Sequence should be gated by test/readiness dependencies, likely from the prior Integration Sequence. Create few of these cross-Sequence dependencies, keep each Integration Sequence as independent as possible.
• Identify Main tasks with inflexible duration beyond limits you control, or that are controlled by physics (such as hardware fab, build, assembly and test by CM partner, regulatory compliance and certification test, transport, customs)
• Since those are inflexible, overlap everything else possible with these identified critical inflexible path sequences, including tasks from both prior and subsequent Integration Sequences. There will be times where work is proceeding simultaneously on 2-3 Integration Sequences. You can see this in the figures above.
• Each Integration Sequence starts with variable work (design and acquisition of materials for this Integration Point, test of previous Integration Sequence) overlapped with Critical Task Sequences driving this Sequence Critical Path, and followed by completion of non-critical-path Integration Sequence testing of product produced in the Sequence.
• Plan scheduling backwards from critical-path tasks (like Build, Assembly, Integration, Test) for deliverables on which those critical tasks are dependent - like acquisition (RFQ-approval-PO-approval-supplier lead time-transport/Customs-delivery-distribution-setup); or work procedures; or test development.
  
  
  • Backward planning is quite useful for planning when to start tasks required to finish in time to start a specified task. This is often driven by need for parallelism to keep work off of the Critical Path. There's not much help online on Reverse Dependency planning in MS Project, and even some mis-information, so here's how it works. (There are examples illustrating the following construct in the PowerOpI tool project files (free) on my website.)
  • Default dependency in MS Project is FS meaning Finish-to-Start - when prior FS-dependency tasks Finish, the dependent task Starts. (The dependent task states its FS dependency on the task providing the deliverable dependency.) Now, say you have a board Build task whose Start is driven by specified FS dependencies (like Test completion in the prior Integration Sequence etc.). So how can you schedule a task for Acquisition of component parts to Start in time, considering specified lead-time Duration, to Finish automatically (i.e., not requiring manual adjustment on change, so preventing omissions) to make parts available to Start the Build task?
  • You want the Acquisition task to Finish in time for the Build task to Start. So the Build task would specify an SF dependency on the Acquisition task: When the Build task Starts, the Acquisition task must Finish. For an SF dependency, MS Project sets the Finish of the Acquisition task to the Start of the Build task, and uses the Duration of the Acquisition task to drive the Start of the Acquisition task backward in time.  SF tasks can be chained using SF dependencies to define sequences of tasks scheduled backward, to Finish the chain at the Start of the dependent task. A chain might include RFQ, Quote, PO approval, fab material acquisition, shipment time, staging for build, anything not included in the Duration, to Finish in time to Start the example Build task.

The net of this construction creates the Critical Path optimized across overlapped Integration Sequences, as shown in the images above.

• The figure shows how Critical Path flows through and across Integration Sequences, how the Integration Sequences themselves overlap, and how testing in one Integration Sequence gates an irrevocable task in its following Integration Sequence.
• Plan and manage sequence for: Material acquisition, Build, Assembly, Validation/Certification Test development,Test min time, max time on critical path

How Does Accuracy Improve Over Time?

Accuracy of the schedule plan improves as the Program progresses. Factors include:

• Update Actuals as tasks complete, and when appropriate adjust future tasks of the same operation considering what caused the current task duration to change.
• As they are completed, tasks no longer add to uncertainty. Reflecting Actuals in the schedule reduces uncertainty.
• As designs and other sequences become known and their durations or sequences are updated, uncertainty of the future is increasingly resolved.
• Only tasks on the Critical Path contribute to End Dates, so estimation inaccuracies in tasks not on Critical Path do not contribute to uncertainty in the End Date AS LONG AS THEY DO NOT CREEP TO LATER BECOME MEMBERS OF THE CRITICAL PATH.
• The overall schedule is most-influenced by its Critical Path. And you're monitoring and managing the Critical Path closely to meet schedule... aren't you?
• For reference, Critical Path tasks are those that have zero slack (zero time to start of dependent task). You can display slack for Program tasks by adding the Free Slack column in MS Project. When the schedule is exported to Excel, you can sort on increasing slack time to identify critical tasks as well as tasks with little slack i.e. that are close to becoming critical. You should be aware of and manage tasks that are critical (zero slack) and near-critical.
• Intuitive Central Limit Theorem postulate. I cannot prove this conclusively yet but here is an intuitive observation.
• Plan accuracy may be helped by Central Limit Theorem (CLT). If task durations are estimated using uniform estimating principles, then errors in sequential paths may cancel out for the aggregate path. Some tasks may finish early and some late, subtracting error in the aggregated path duration. This could be modeled using Oracle Crystal Ball describe above in Estimation Methods.
• Consider task duration estimate as Likely Duration +/- potential variation as percentage of duration.
• Error magnitude distribution of the Estimate may approach Normal distribution as sample size increases. More tasks in a sequence with Normal distribution of estimation error may result in greater accuracy as sequential errors cancel. Fewer tasks may result in greater uncertainty. As a rule, CLT prefers 30 or more sample quantities.
• Central Limit Theorem: www.investopedia.com/Central Limit Distribution Shape.

Attach Materials And Therefore Finance To The Integration Sequence PERT Plan

Broaden the plan beyond timing to include Resources, Logistics and Finance. Resources include Material (quantities, item cost), Staff, and Licenses. Logistics include material Acquisition (RFQ, Quote, PO, Lead Time, Delivery, Inventory, Marshalling, Build), Tracking, Distribution. Finance includes costs (schedule time of PO vs Lead Time, Material receipt, Pay Date), and expense/capitalization determination. Overall, Schedule drives Logistics, and Logistics drives Finance.

If you use Microsoft Project you can export the GANTT plan to an Excel or XML table that can be JOINed with other Tables (via a linked database environment or Excel PowerQuery) itemizing materials and expenses to be associated with milestones in each Integration Sequence. This is automated in the PowerOpI tools (free) available on my website www.softtoyssoftware.com. The website also provides many descriptions, examples, code samples, links and resources to help you build your own tooling.

Materials and Finance Tables are discussed in article Advice for Program Managers: 4-Program Management Specialization: System Programs Phased Methodology and illustrated in Organizing Program Communication.

Images of example relevant Material and Finance Tables

The following Tables, SQL, Reports and Images are taken from tools described, and available FREE, from my website softtoyssoftware.com. The site also describes underlying methodology and tooling for your own design.

/* QUERY Build Plan DB Tables */
SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER ON

  SELECT [SQLServerRemoteDB].[dbo].[xlAlloc].*, [SQLServerRemoteDB].[dbo].[xlBOM].*, 
    [SQLServerRemoteDB].[dbo].[xlDates].*, [SQLServerRemoteDB].[dbo].[xlBuilds].*, 
    [SQLServerRemoteDB].[dbo].[xlElements].*, [SQLServerRemoteDB].[dbo].[xlPurchReq].*, 
    [SQLServerRemoteDB].[dbo].[xlAlloc].[akQty] * 
        [SQLServerRemoteDB].[dbo].[xlBOM].[bmSubQty] 
        AS QtyExt, 
    [SQLServerRemoteDB].[dbo].[xlAlloc].[akQty] * 
        [SQLServerRemoteDB].[dbo].[xlBOM].[bmSubQty] * 
        [SQLServerRemoteDB].[dbo].[xlBOM].[bmSubCost] AS CostExt
  FROM [SQLServerRemoteDB].[dbo].[xlAlloc]
  LEFT OUTER JOIN [SQLServerRemoteDB].[dbo].[xlBOM] ON 
    [SQLServerRemoteDB].[dbo].[xlAlloc].[akAllocRevKey] = 
    [SQLServerRemoteDB].[dbo].[xlBOM].[bmBOMItemKeyIn]
  LEFT OUTER JOIN [SQLServerRemoteDB].[dbo].[xlDates] ON 
    [SQLServerRemoteDB].[dbo].[xlBOM].[bmBOMItemKeyOut] = 
    [SQLServerRemoteDB].[dbo].[xlDates].[daSchedItemRevKey]
  LEFT OUTER JOIN [SQLServerRemoteDB].[dbo].[xlBuilds] ON 
    [SQLServerRemoteDB].[dbo].[xlDates].[daSchedItemRevKey] = 
    [SQLServerRemoteDB].[dbo].[xlBuilds].[bdBuildRevKey]
  LEFT OUTER JOIN [SQLServerRemoteDB].[dbo].[xlElements] ON 
    [SQLServerRemoteDB].[dbo].[xlBOM].[bmBOMItemKey] = 
    [SQLServerRemoteDB].[dbo].[xlElements].[emElementItemKey]
  LEFT OUTER JOIN [SQLServerRemoteDB].[dbo].[xlPurchReq] ON 
    CAST([SQLServerRemoteDB].[dbo].[xlAlloc].[akPurchReq] AS VARCHAR) = 
    CAST([SQLServerRemoteDB].[dbo].[xlPurchReq].[prPurchReq] AS VARCHAR);

Images of example relevant Material and Finance Reports

---

Example images derived from Program data illustrated above:

Images provide intuitive vision and understanding of where we are and where we're going, both short-term and long-term, to all levels of an organization. Images displayed here are all driven from the GANTT.

Operationally: Use The Plan - Adaptively

Did you think you can make a plan, execute it, and it will stay fixed while you do that? Keep plan current in real time. Make real-time estimates. - Use Automation to make updates possible with reporting/guidance available in short time with minimized labor.

• Manage organizational focus to Integration Points - status, outlook and issues, and on Integration Sequences that achieve them and exploit them.
• Keep the Program Plan realistic, and keep it up-to-date including actuals. Make estimates as realistic as possible, using history if available - but in any case, neither unreasonably aggressive nor pessimistic. Keep padding out of quantitative plans, it's for use by PM to mitigate or cure problems.
• Identify Critical Path and keep it communicated. Many tasks are not Critical Path. Provision Critical Path tasks well, and work with Line management to mitigate continuous staff overload. Organizationally commit the program to a reasonable schedule and budget - perhaps three months beyond best case. Then directly and continually manage Critical Path to best case.
• The Integration Sequence Deliverable Table coordinates the multiple processes across the Program, and focuses the product and the organization toward completion of the product, and of the full Program breadth.
• Agility Accept change, use the Program Plan to help evaluate effects. Use automation to plan and communicate implementation. Use Agile/Scrum methodology where appropriate (software + hardware design and test), and Quantified Integration Sequences for logistics and finance. Integration Sequence content and dates apply across all methodologies used.
• Be prepared if shortfalls in progress, materials or staffing may occur: Use the plan in part to foresee problems and prioritize fixes. Envision workarounds for tight work, plan some spares for material shortfalls. The first workaround tried may be insufficient, try to foresee tight spots and envision several possible workarounds. In case of a shortfall on Critical Path, initiate workarounds to take the problem off the critical path, then re-introduce the fix when it's ready. Keep the whole organization working while the problem gets fixed. Re-fit the fix to users sensitive to the functionality fixed.
• Keep the product technically correct and robust. Software above a level that virtualizes the platform can often be shifted among releases. However, platform tests and internal and external interconnect hardware and software must be available at Integration Point dates.

The Program Manager, and all Program team members, should use representations of the Program Plan to communicate: up, down, across, throughout the Program and all participating organizations. Communicate current standing relative to ultimate objectives, and on current and shortly upcoming tasks; as relevant to participants in the dialogue. Collect ideas, adopt if appropriate and propagate through the plan. Collect current and upcoming issues, work out reaction and propagate through the plan. Use automation of the Plan to facilitate this. The article on this site, Organizing Program Communication, discusses many ways of facilitating communication about the Program in all dimensions.

The schedule is in fact always wrong. Let's state that more usefully: The schedule is always approximate, stating The Best Known Path From Here in a way that is useful for coordinating subsequent tasks and milestones. It's all a matter of degree: remember, the "schedule" contains tasks with estimated times (which is where most error can occur), plus sequencing of tasks driven by dependencies, which is usually pretty accurate. So update it continually toward correctness. That alone will add value to the project, and the schedule will become more and more accurate as data is corrected, as operational changes are incorporated, and as uncertainties are resolved and reflected in the plan.

Identify risks that the plan illuminates - at Planning, During Execution. Report the risks in advance, and handle them.

Identify decision points, get homework done in advance, get the decisions made on time to avoid unforced error.

Monitor for risks. Practice Avoidance, Mitigation, Alternatives, Solution, Operational change.

Take seriously tasks for Validation, SQA, Field Test with Multiple Customer environment exposure. A release sequence might consist of full-function and SQA'ed preview release, then Certified Release inclusive of exposure, Compliance and Certification. Certified release could be further broken into multiple release branches targeted to customer classes, perhaps geographic or consumer/enterprise, and released over a time sequence to achieve incremental customer environment exposure while avoiding broad mishap due to product defect detected as exposure broadens. Avoid field-level disaster - don't sacrifice product integrity in favor of early delivery to live customer use.

Implement Agile Mindset: Be open to necessary or opportunistic change, be able to Incorporate Change.

But: don't let Agility derail the Program or customer.

• Accept change where it fits the plan, insist on buy-in to plan change if it doesn't fit. Don't let the grail of Agility destroy program success. Incorporate required change in a way that maintains a valid plan.
• Be prepared to push or pull function from one Integration Sequence to another, to push function to post-delivery release, to pull in function where capability to do so exists.
• Respect backward compatibility by change incorporation, maintaining existing APIs, UI training, and documentation in use by users and customers. Avoid a board change that forces a backplane change that requires change to a chassis assembly requiring field update of whole chassis elements (for example) requiring new builds, on-site installation by Support, and other such logistical nightmares.

In Short: Execute The Plan, Use Agility To Advantage

• Build the plan, keep it updated. Execute the plan.
• Continual monitoring of Dependencies, Integration Readiness, Logistics, Purchase, Build, Test
• Continual Progress and Communication. Keep the whole organization working, don't hold up the group waiting for a change to a sub-elements.
• Continually Monitor for progress, blockages, opportunities
• Regularly Report on Progress up, down, sideways through the organization
• Whenever current, Report on Change, alternatives, consequences
• In meetings, website, Develop and distribute knowledge via Visual and Tabular quantifications
• Everybody in the organization is executing the plan. That's what all the communication and monitoring are about. Manage operation of the program, don't get stuck just updating a plan that nobody is actively working to achieve.

Advice for Program Managers: The Blog Series

1-Program Management Opportunity

Introduces a vision and framework for development of Program Managers and PMO, for Program Management specialization to its environment, and for improved effectiveness and integration of PM with organization operational management.

2-Program Management Career Path

Describes career path thinking for Program Managers including sourcing, progression, advancement, and connection with organizational management.

3-Program Management Career Skills

Career path thinking for Program Managers including skills and behaviors that develop Program Manager capabilities and leadership and pave the way toward advancement.

4-Program Management Specialization: System Programs Phased Methodology

PM Best Practices and Core Program Structure for Hybrid integrated system programs using Phased HW – Agile SW, mixed-technologies. Full-Program agility via automated plan tools with continuous plan update.

The Series also solicits contributions to this Blog site, to extend coverage of PM Best Practices and Core Program Structure to a broadening set of Specializations.

5-PMO Role

PMO behavior to achieve Program Management effectiveness specialized to its environment managing PM practices in the organization, including PM development and advancement and connection with organizational management.

6-Quantified Agile for Hardware

Program Quantification applied to Phased and Agile methodologies to deal with organizational quantitative requirements.

More Articles by this Author

Three Levels of Program Management

Guiding Principles for Program Management Action, Program Quantification, and Leverage Through Tooling.

Organizing Program Communication

Program Management depends on effective communication. Design Program communication paths for everyone throughout the Program.

Database Platforms for Program Management Logistics

Logistics Tool extended, using SQL Server and MS Access with MS Excel and PowerQuery.

PowerQuery Tool

Logistics Tool using MS Excel Power Query.

Quantitative Management

Tool methodology for agility with continuous plan update: Program BOM, Tie to Dates, Builds, Element data.

Complex Programs: Structure

Structure Program with Parallel Phasing. Describes coordination of EE/ME, FW, Test, Supply/CM, Driver/Kernel, Transport, Management. Scheduling, Integration points, scaffolding, and starting work. Hybrid Program Cross-Domain Coordination of development frameworks, including Phased and Agile/Scrum where appropriate, via integration points and scaffolding. Software Integration Sequence and Dependency Planning.

Managing Complex Projects

Problem Statement. PM responsibility for Program Management drive throughout an organization, also includes schedule, budget, integration, critical path, logistics.

Program Roadmap

Planning work structure for a Program, and using the plan effectively.

Lifestyle AI

AI effects on current and future lifestyles. Personal strategies for proactive and defensive use of AI.

Iterative Thinking

Using Iterative Thinking to solve big problems and complex logistics.

Link To Free Tools To Manage Schedule, Logistics, And Finance

Author's www.softtoyssoftware.com website with articles on Program Management and Program quantification tooling using Excel, MS Project, and MS Visio with SQL databases PowerQuery, SQL Server, and MS Access. Articles describe how you can use tools available from the website, or develop these capabilities yourself using commonly available tools.

Tools available from this website are free. They can handle small to large programs, limited only by your imagination. Using the included Program Template to envision, organize, plan, and run a large program puts me in mind of unleashing a Roman Legion to a sure outcome. Veni, Vidi, Vici! – Julius Caesar.

• https://www.softtoyssoftware.com/dbnet/programmingprojects/powerquerytool.htm
• Details on design of Structured Tables, JOINs, Reports/Pivots in Tools.
• Schedule, Visualization, Reporting.
• Hybrid program agility with continuous plan update.
• Microsoft 365 Desktop - based.