dbnet.home Bookmark and Share

MEET FEATURE REQUIREMENTS, SCHEDULE, and BUDGET! Consulting available to teach your organization to apply this methodology and tools for powerful quantitative management of your business processes.

  • Instruction of your staff at your site, using courseware, application example, and a functional template.
  • Mentoring your key staff on an ongoing or periodic basis, on these tools or on Quantitative Program Management.
  • Contracting or Employment in your organization on specific topics.

Brochure  ...  Contact for Details

Check out my YouTube Channel: Power Operational Intelligence

Now Live! Overview, Structure, Task Data, Table Design, SQL Server, and Re-Linking now showing.

Video courses covering material on this website, and more, are presented in the playlists.

Code snippet links at YouTube Code Snippets. Twitter at @poweroperation1, #poweropi, #poweroperationalintelligence.

Subscribe on YouTube, and click the "Notification" Bell icon to be notified as content is published.

Quantitative Management Manifesto

  • Structure and quantify the program in tangible plans. Envision the program plan top-to-bottom and end-to-end. Quantify Schedule, Materials, and Costs. The Schedule is driven by organizational task sequence and product function, and should provide necessary and sufficient detail required to get a clear picture of critical paths. Too much detail results in brittle, un-maintainable plans. The Build Plan is driven by Schedule and is based on configurations and allocations to test plans at all program levels, and drives prototyping, manufacturing and budget. Budget is driven by the Schedule and Build Plan, and includes materials, fees, and personnel. This software tool structure will help create interactions among plan components.

    • Design the program build sequences. EE/ME build Phases: Initial; Major Corrections; CM Test; CM Integration; Formal Qual; Production from Customer Order. Software Feature Block sequence: Core Function; Committed Features; Stretch Features + Non-Dependent projects sharing Code Drop. Integration Sequence: EE/SW Dev; EE/SW/ME Dev; Internal Alpha; External Beta and Formal Qual.

  • Tightly manage the Critical Path. Actively design the critical path to be limited only by un-compressible task sequences, typically fabs/builds. Overlap everything else under the un-compressible sequences. Continually review and layer quantitative plans to mentally live the plan in advance. Update and maintain quantified details to reflect progress and changes. Clear dependencies ahead of critical task execution. Provision the critical path in the Build Plan, and schedule pipelined material. Work daily with critical task owners. The PM should own any slack in the schedule, allowing schedule indulgence where needed on non-critical tasks.

  • Maintain active and constant engagement with EE, ME, SW, UX, Mktg, Supply Chain, Mfg, and Support. Keep the planning relevant and the people committed. A large program requires a hierarchy of regular communication, consistent with WBS. A Program Manager planning at this level must gain respect and credibility from management and technical team members.

  • Get points on the board. Complete non-critical tasks early so they don't become the critical path. Plan Hail Mary passes where there is opportunity, but don't count on them. Resolve every issue every time, maintaining only one set of schedule books. Always bias for action and pipeline for it. Plan for success of tasks, the plan can’t go better than that. Cover failures as exceptions and handle them off the critical path: build a separate path to handle recovery when needed, with subsequent re-integration.

  • Insist on technical correctness, and never compromise it. If necessary to accommodate in scheduling, hedge the technical risk. The following techniques are effective.

    • Plan WBS domains around independent work elements (e.g. EE builds, SW builds, ME builds, and system integrations). Manage a separate critical path within each domain so that delay on one element won’t directly affect critical paths in dependent domains. Use A-B builds particularly in early rev builds: "A" build for a new revision driving critical path on its domain; "B" builds pipelined to quickly supply dependent domains once the "A" build is sufficiently qualified for distribution (for most uses, earlier than final qualification of the revision toward full production).

    • Substitute adequate function if a dependency is delayed, to maintain progress and momentum. Build and substitute adequate function to support all critical paths, and plan and pipeline a recovery build for replacement and subsequent integration. On recovery of the dependency, build and replace substituted-rev units with corrected units when available, where necessary.