MGT 646 Module 4 Sequencing and Schedule Example

Seventy-Eight Weeks With No Slack: Sequencing SmartSync and Buying Back a Buffer

Student Name

Master of Business Administration, Aspen University

MGT 646: Project Management Organizational Framework

Instructor Name

Month Day, Year

Seventy-Eight Weeks With No Slack: Sequencing SmartSync and Buying Back a Buffer

The SmartSync work breakdown structure lists what must be built. This module asks when. The charter gives eighteen months, about 78 weeks, to a holiday launch, and the retail partner needs shelf commitments months before that. This paper turns the WBS into activities, sequences them, finds the critical path and changes the plan when the first result shows trouble. Durations are the writer's estimates from the case and similar products.

The Critical Path Method

Kelley and Walker (1959) presented the critical path method to an audience of computer engineers as a way to plan and schedule large construction and maintenance projects. Their approach represents a project as a network of activities linked by dependencies, estimates each activity's duration, then calculates the earliest and latest times each activity can start. The longest path through the network, on which every activity has zero slack, determines the project's length. Activities off that path can slip by their slack without delaying the finish. The method also let planners weigh the cost of shortening activities against the value of finishing sooner.

Activities and Dependencies

The Forward Pass

Concept ends at week eight. Design ends at twenty and firmware at twenty-four, so the engineering validation build cannot start until firmware finishes and ends at thirty-two. Tooling runs to forty-six. Model training ends at twenty-eight, well before design validation needs it. Design validation ends at fifty-four, certification at sixty, the pilot run at sixty-six, the ramp at seventy-four and launch logistics at seventy-eight. The critical path is A, D, F, G, H, I, J, K, L. Design has four weeks of slack, model training eighteen and the app fifty-six. The project needs every one of its 78 weeks, with nothing left over.

Why No Slack Is a Problem

A schedule whose critical path equals the deadline assumes every critical activity finishes on time. In practice some will run late, and on the critical path every late week moves the launch. Tooling and certification are especially prone to rework. The durations above are single estimates, but the team also gathered optimistic and pessimistic figures for the riskiest activities. Tooling ranged from twelve to twenty weeks depending on how many mold revisions the enclosure needs, and certification from four to ten weeks depending on whether emissions problems are found. Using those ranges, the chance of finishing all critical activities within 78 weeks is well under even.

Shared People

Dependencies are not only logical. The Module 2 stakeholder plan noted that NexTech's other product line shares firmware engineers with SmartSync, and the firmware core sits on the critical path. If those engineers are pulled away, the schedule slips no matter how the network is drawn. The project manager has agreed with the other project's manager that two named firmware engineers stay on SmartSync until the engineering validation build, with any exception decided by both sponsors together.

Critical Chain and Buffers

Leach (1999) described critical chain project management, which grew from Goldratt's theory of constraints. Its argument is that individual estimates contain hidden safety time, which is then wasted through late starts, multitasking and the habit of using all the time available. Critical chain cuts individual estimates toward their likely durations and places the removed safety in a project buffer at the end of the chain, with feeding buffers where noncritical paths join it. Progress is tracked by how fast the buffer is being used.

Steyn (2001) examined the principles behind critical chain, including the theory of constraints, the statistics of pooling safety and the behavior it targets, and concluded that the approach has merit but must be applied with attention to resource dependencies and to how people respond to aggressive estimates. The lesson for SmartSync is to create a visible buffer at the end and watch it, rather than to trust a schedule with none.

Creating the Buffer

Two changes buy time. Adding a contract firmware engineer for sixteen weeks at about $64,000 cuts the firmware core from sixteen to twelve weeks, so firmware and design finish together at twenty and the validation build ends at twenty-eight. Arranging pre-scans at the certification lab during design validation cuts formal certification from six weeks to four, because known emissions issues are fixed earlier. Together these move the planned finish to week seventy-two. The remaining time becomes a project buffer of six weeks before the retail ship date, and model training keeps a feeding buffer of fourteen weeks before design validation.

Tracking the Schedule

The project manager reports buffer use with the share of the critical chain completed. Buffer burn that runs ahead of chain progress, for instance 40% of the buffer used with 30% of the chain complete, triggers a recovery plan. If buffer use reaches double the chain's progress, the sponsor is told that the launch date is at risk and asked to choose between adding people, cutting scope from the launch release or moving the date.

What the Changes Cost

Shortening the schedule is never free. The contract firmware engineer costs about $64,000 and needs two weeks to learn the codebase, so the gain depends on hiring before the concept stage ends. The certification pre-scans cost about $18,000 and give the lab an early look at a design that may still change. Both costs are small against the price of a missed holiday season, which the sales director puts at a third of first-year unit sales.

Conclusion

Kelley and Walker's method exposed a 78-week path with no slack, and Leach and Steyn's critical chain ideas gave a way to protect the launch. Two targeted changes create a six-week buffer, which the team will now watch.

References

Kelley, J. E., Jr., & Walker, M. R. (1959). Critical-path planning and scheduling. In Papers presented at the December 1-3, 1959, Eastern Joint IRE-AIEE-ACM Computer Conference (pp. 160-173). Association for Computing Machinery. https://doi.org/10.1145/1460299.1460318

Leach, L. P. (1999). Critical chain project management improves project performance. Project Management Journal, 30(2), 39-51. https://doi.org/10.1177/875697289903000207

Steyn, H. (2001). An investigation into the fundamentals of critical chain project scheduling. International Journal of Project Management, 19(6), 363-369. https://doi.org/10.1016/S0263-7863(00)00026-0