Program Roadmap

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.

Considering a Program Plan

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.

Cost/Benefit Analysis of a Program Plan

What characteristics drive need for planning a Program?

• The Role of Planning
  Planning may not be necessary for some classes of programs, but can be required for other classes. Whether required or not, though, managing a set of tasks with a plan can decode program complexity to optimize work, resulting in benefit to time, cost, and revenue. Inevitable change to the product or program can be coordinated throughout the organization reducing wasted time, effort and confusion. The work required of people may even diminish.
• This, at the cost of mental work by a few to determine a plan. Plans created need not be perfect, but will improve with progress on the program, and with experience and data in the organization. The result benefits customers, as well as the business of your organization. Organizations might even translate these results, or the pattern of results, to compensation opportunities for all staff (e.g. stock price?).
• Managing Complexity
  Management of complexity by itself covers dependencies and use of time, directly providing some of the benefits described in the section above. Management of complexity may also be a prerequisite to manage logistics and finance, discussed in a section below. Logistics and finance define the class of programs for which this is usually required.
• Program complexity is further driven by dependencies among tasks, usually driven by technology of the product to be delivered. Dependencies affect magnitude of effort, and impose specific requirements on design, development, delivery and production steps. For many technologies you could be developing simultaneously the product itself, as well as detailed implementation of capability to produce and support the product.
• A larger Program, or a Program conducted within a larger company, is very likely to encounter multiple methodologies among participating organizations, an important contribution to complexity. In practice it is very unlikely that all organizations in the company that you need for your program will be aligned toward your desired process. There will be requirements on your use of their processes, methods, and on use of corporate databases. The Program needs to utilize multiple processes across multiple organizations, to develop and produce your project – with agility! Best if you can incorporate their methodologies and use them to your advantage. For example, getting your product aligned with production supply contracts can result in quicker availability of material at lower cost – dig for such advantage and use it wisely. Corporate organizations support multiple product streams, multiple technologies and methods, and multiple products, both old and new. They are driven by multiple Business Units, not just your product and BU, and their processes reflect that. This probably includes Supply Chain, Manufacturing/CM, Finance, Sales, and Support. As Elon Musk says, “Prototypes are easy, production is hard“!
• Complexity is the enemy of time, because it most often places sequencing requirements on deliverables upon which other tasks are dependent. A dependent task could be waiting for a deliverable from a provider task not yet in progress, while a non-related task is instead executed. So arrangement of order of deliverables can make a difference to time. Time to delivery of a dependency, as well as its start time, will both matter because both drive delivery date.
• Not all tasks are equally important to this logic: a concept called Critical Path is discussed in a section below. A task is Critical if it has zero slack time before its subsequent task can be started. Critical Path is the sequence of tasks each with zero slack time, that results in minimum time to a specified endpoint like first delivery to a customer. So tasks on Critical Path have greatest impact on total program duration and delivery to customers. There is more flexibility on tasks that are not critical, which is usually most of them! The problem for program management is to determine the Critical Path, to design, manage and provision it, and to keep other tasks from influencing it.
• Finally, once the structure of a program is tangibly represented, described largely by its sequence of tasks as driven by dependencies and deliverables, and by the resultant Critical Path, changes to the program and to its deliverable product can be quantitatively analyzed and coordinated among tasks and organizations involved. This can reduce waste, confusion and mistakes. Furthermore, bottlenecks can be predicted in advance and avoided, mitigated or eliminated.
• Managing Logistics
  Need for Program materials is driven by tasks using the materials. Management of Program logistics is management of Program materials, and of finance driven by material and labor costs. Program costs include all tangible costs including material, labor, and licensing. Finance and Logistics are quite sensitive to timing.
• Commercial corporations manage their Balance Sheet, Income Statement and Cash Flow. These include items of Revenue, spending on Expense and Capital items, and either directly or indirectly, on staffing cost. If a program involves significant amounts of any of these categories, or if it has some amount in any of these categories that is of concern to the corporation, then planning and tracking are likely to be a requirement on the program. Finance and Time are closely related: Available funding must shared among programs and coordinated in time by financial Quarter; so managing Logistics usually also requires management of time i.e. program schedule. One more PM plan detail: Finance must be informed of relevant dates for material: PO likely in a prior quarter due to lead time. Payment timing can vary: with-PO for some material types, on-delivery for others, or 30-day ARO following delivery, etc.
• Material lead-time must be planned for programs requiring material for prototyping or development infrastructure. Orders should be quoted, approved, and placed long enough for delivery ahead of staging, setup, and use. PM can plan this backward from date for use. Jellybean material may take 2-3 weeks, but even some common material may be long-lead: early VLSI, new connector type, a specific crystal or diode might require 14 weeks. Cables are notorious for high failure rates. It is the Program Manager who must avoid “For want of a nail the kingdom was lost”! Quantity should be planned considering short-ship, split ship, breakage, delay, un-planned changes, spares. Abnormal events can occur: supply chain disruption; earthquake or tsunami; hostilities. Advance consideration of material time, quantity, and variation are not to be forgotten!
• Revenue Coupling
  Various business models may affect coupling of a program product delivery to a revenue stream. Desirability and requirement for program planning is directly proportional to the degree of coupling of product delivery to timing or amount its generated revenue stream.
• The business model that most closely ties a program to revenue is Payment-on-Delivery. This covers most programs with tangible material deliverables e.g. computer system hardware elements plus associated software. These programs usually have significant materials expense, therefore they are doomed to manage time, materials, and finance. A product on a Payment-on-Delivery model often also initiates revenue from a lucrative continuing Maintenance Contract as well.
• Business models more loosely coupled to revenue include Maintenance Contract, Subscription, or Seats; with fees paid periodically like annually, quarterly or monthly. Delivery of a feature a month earlier or later may not affect such payments at all. These decouple delivery of product or services by varying degree from payment date and periodic payment amount.
• For a Leasing model, payments begin on delivery of product, but timing and amount of subsequent periodic payments are unaffected. So a Leasing model somewhat disconnects revenue over time from exact delivery.
• More complete decoupling comes from a program product that results in revenue from a different entity. A widespread example in current practice, exemplified by Social Media, is program product whose use results in collection of demographic data, or user patterns, or other specific data to be used to target efficiency of advertising. Thus Advertising is the revenue-generator, whereas the product of the development program provides little or no direct revenue; or perhaps a nominal subscription. A related example is online commerce, where revenue is collected for items sold (apparel, furniture etc.) In this model the development product, such as the website, app, associated databases and infrastructure, act as agents to revenue resulting from of sale of a different product. Sales website user data may additionally be collected and sold.
• Complete decoupling includes not-for-profit efforts, providing information or reference. These could be funded by grants, contribution, or public good.
• Net: the more closely the product of a program is tied to revenue, or to sensitive development costs, the more planning and tracking of time, delivery date, and development cost will be required. Conversely, the looser the connection between program product and revenue or cost, the looser the requirement for planning and tracking.
• Customer Type
  It may seem that a hardware prototype can be designed, fabbed at domestic fab/metal shops, assembled at a domestic Contract Manufacturer, tested for compliance; and it will be “good to go” for customers.
• Well, that depends on the customers – if the product is for consumer/mass production, or for Enterprise use, it’s more involved than that. For Consumer, the issue will be production quantity; for Enterprise, add product integrity and support.
• Production Quantity: To develop a product for consumer-level production volume, component, fab and CM suppliers must validated to supply your product in volume. Volume availability of fab material must be verified, and purchased- and fab-material availability should include use of alternate-source components. To validate this, units must be produced, tests and test fixtures developed, and incorporated into production flow at the fabs and CM; and then the varying builds must be tested for function, margin, etc. Production yield, first pass yield, and product cost are also a function of volume and margins; and can require component selection, design margin adjustments, board spins and testing.
• Product Integrity and Support: Enterprise use means data integrity, reliability, capacity, security, and product support for hardware and software. May also need subsequent enhancements, and extended production. Broader compliances may be needed: environmental, security, privacy, financial, country-by-country/region safety and emissions at host countries. The product will be developed and tested for these by your organization, and again at pilot production. Units will be produced for this testing; some will be sacrificial. Field Analyst and possibly Customer Engineer training, and also spare parts, will be developed and distributed.
• Need a plan for these? There are many dependencies, sequences, partners, and evaluations required to develop, produce, distribute, use, and support product developed for Consumer and Enterprise use. Product design and production parameters are closely related. These parameters are intrinsically part of the product development process, in order to avoid cost and time to do them separately from product development. They likely affect the product design to some degree (changes to components, packaging, shielding, airflow, margins etc.); and qualification and compliance must be performed on the design to be shipped and from the production facility that will produce the units shipped. Most likely a plan is needed to manage the logistics; and it’s more effective for this to be incorporated into the overall development plan; which would probably be needed anyway.
• Hybrid Programs
  Some, maybe most, Programs include both time-sensitive complex Elements, as well as Elements that may be impossible to sequence at a detailed level or for which task durations may be impossible to estimate with any level of meaning. These typically include efforts of pure design, integration, and test such as is common for pure software efforts. Early hardware development efforts also include architecture and high-level EE and ME design leading to prototyping, that are difficult or impossible to quantify.

  Just to add complexity, these poorly-quantifiable efforts may also gate Elements with complexity of cost, critical path, or irrevocable operations. Larger programs commonly do have such constraints. For such a Program, planning and estimation for the Program as a whole are necessary, to manage the parallel efforts including both development and implementation of change.

  An estimation method in a section below, Assign time available, helps quantification for such intangible complexities.

• Program Management Career Development
  In revenue-sensitive product development efforts, someone is taking responsibility for spending and time, to optimize business results. For small programs, that’s likely shared between Product Management for positioning and revenue expectation; line managers and finance Controllers for development timing and spending; and with technical operation managed among Tech Leads, Product Owners, Scrum Masters, or positional equivalents. But for large projects spanning not just Development but also corporate or partner operating functions, Program Management is generally responsible for planning, operations, and finance of the program within and among all functions; and of course working with principals in participating functions.
• Even assuming Management gets competent expense and time management from all development efforts, they still determine which of multiple opportunities should be funded to optimize the business. For a large complex project, that is more than a technical decision, involving also time, expense, and revenue. Thus, the Program Manager of a large program usually must step up to provide the broader level of management that includes tangible quantifications of time, expense, and revenue. The PM is the only one in the organization with program-wide visibility, quantification, and ability to knit together such data from multiple organizations. To take broader positions like this, the PM usually must have gained confidence of corporate management by demonstrating this capability. I think Program Managers do themselves a career favor by gaining experience and demonstrating expertise in these factors.
• Further examples of program factors affected by time and finance that benefit from a planned approach:
  • A portfolio of development programs may be constrained by available cash or available free cash flow within the corporation, leading to internal project and organizational competition and politics for funding (always at program inception, and annual budget; and frequently ongoing quarterly). Use of cash among project efforts requires regular statement and comparison of Program current and projected financials. These are often compared using investment criteria such as Net Present Value (NPV) or ROI.
  • A market competitive offering (e.g. CPU/GPU next-generation chip introduction among competitors) may drive a priority imperative among programs to achieve competitive introduction timing of product using such chips.
  • End-of-Life material availability for a currently-shipping product, requiring a last-time buy to provide inventory for a fixed shipment duration, may require current product enhancement or replacement before that inventory is exhausted.
  • A program may support a business commitment to partner or contract requiring specified timing or financials.

Statistics are that a large majority of projects fail… How Agile is a project that fails? Thinking through how to translate a concept into shippable reality, building a plan for that, built-in to be adaptable and capable of accepting and implementing change, then actively USING the plan to achieve success… Maybe that’s a good business plan after all, and Agile besides!

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.

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

• 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 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

• Vertically, Each Row represents one Integration Sequence, Stating its Distribution and Purpose.
• Looking down any table column: Sequence through Integration Cycles, showing for each its Objective and use, and Deliverables for each operational organization.
• x
• Horizontally, a column for each Operational Organization
• Table column for each Organization shows its Integration Cycle objectives plus deliverables to the Integration Point.

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

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. 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 “best case” target to Critical Path, and report, escalate, resolve or mitigate deviations as the program progresses.

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

• 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

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.

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 estimationcommunity.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.

Design The Critical Path, Don’t Just “Let It Happen”

• 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.

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

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.

Allocation: Represents use, configuration, Integration Cycle, and quantity. Includes key-fields for local cost aggregation and JOINs to related tables including Program BOM and element data reference.

Program BOM: Represents a Product Tree structure including components, built items, assemblies, and systems, for each Integration Cycle/Phase. Includes key-fields for JOIN.

Source Table: Program BOM Quantification (click to enlarge)

MS Project Import: Raw data import from MS Project for task data. In the MS Project file, field “TaskMilestone” has been added and populated to provide a key-field for JOINs to related tables.

Source Table: MS Project Schedule (click to enlarge)

Dates: Normalized table associates dates from MS Project import table with Program BOM items. This table implements date aliasing to support purchased items not represented in MS Project that can be synced to builds. This simplifies scheduling of those items that do not need task sequencing. Key fields for JOIN are included in the table.

Source Table: Material Dates Quantification (click to enlarge)

Element Data: Raw data for each component, element, assembly or system item planned. Configuration detail, cost, supplier, distributor, slots, ports, cap/expense rules, lead-time etc. – any item data to be included in reports of affect rollup in other tables. Includes key-field for JOIN.

Source Table: Element Data Quantification (click to enlarge)

Images of example relevant Material and Finance Reports

A report summarizing equipment allocated to Development, by organization with equipment detail, its use (indicated by named SysID), its targeted build in an Integration Cycle, then its quantity, cost, and capital/expense status.

Equipment Allocation and Configuration by Organization by Integration Cycle (click to enlarge)

A report for Operations listing dates to plan and execute board builds within each Prototype Cycle; and assembly, integration, and test. The report results in a table of many dates, so Excel conditional formatting is used to highlight and alert for actions upcoming shortly, and for actions that should have been recently completed. Dates for operations completed further back in time are shown muted so that upcoming operations will be shown more prominently.

Operation Start by Element by Prototype Cycle (click to enlarge)

A report for Finance showing all expenditures summarized by item, and by Fiscal Date. Dates in other reports for Operational tasks are shown using calendar dates but for Financial reports, dates are translated to Fiscal dates within the Excel PM tool. This translation often falls to Program Management. Typically Finance uses many reports for planning and actuals, for expense and capital items, for cashflow timing, and many more.

Finance Rollup by Element by FY and FQ (click to enlarge)

A report planning Purchase Orders, and tracking progress of items purchased. Purchase Orders are planned to start in time for item deliveries for builds – dates for built items are shown in the Operations report above. And it doesn’t make sense to start a build unless necessary items have been delivered. Once delivered, status tracking of physical storage and distribution of items helps prevent “lost” items from impeding progress implementing the program plan.

Purchase Order Plan and Tracking (click to enlarge)

---

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

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.

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.

Organizing Program Communication

The schedule is in fact always wrong. But that’s 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 (sequences of preview release – certified release each IP), Compliance, and Certification. 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.

How Does Accuracy Improve Over Time?

• 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.

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.

Further Reading: Core Program Quantitative Structure for System Programs

Credits

My website: www.softtoyssoftware.com
Copyright © 2024 Richard M. Bixler
All rights reserved