Project Product Time: Tailoring Delivery Based on Requirements Stability and Iterative Fea…

Project Product Time: Tailoring Delivery Based on Requirements Stability and Iterative Fea…

PMBOK v8 Definition

Project Product Time refers to the evaluation of how the nature of the product, its requirements stability, and the feasibility of incremental and iterative delivery influence the project's development approach and scheduling. The PMBOK v8 defines this by asking whether the project team "can develop and get stakeholder feedback on incrementally and iteratively, refining the product through repeated cycles, or is it hard to evaluate until it is near completion." This concept also considers the stability of core requirements, the technology involved, and the project timeframe to determine whether a predictive, iterative, or incremental approach is appropriate.

Why It Matters for the Exam

This concept appears frequently in PMI exam questions about tailoring the project approach and selecting development methods. Questions typically present a scenario describing product characteristics (e.g., stable vs. evolving requirements, tangible vs. intangible deliverables, short vs. long timeframe) and ask you to determine the most suitable scheduling or delivery approach. The exam tests your ability to link product attributes with the appropriate development method.

Key Points to Remember (for the exam)

  • Core Question: Can the product be delivered incrementally with stakeholder feedback, or is it hard to evaluate until near completion? This determines iterative vs. predictive approach.
  • Requirements Stability: "How likely are there to be changes to core requirements?" Stable requirements favor predictive; evolving requirements favor iterative/incremental.
  • Technology Factor: "Is the technology stable and well established or rapidly evolving and at risk of obsolescence?" New/innovative technologies require more iterative scheduling due to uncertainty.
  • Timeframe Impact: "Is the project timeframe short, in weeks or months, or does it span several years?" Longer timeframes increase likelihood of requirement changes.
  • Incremental Delivery: Each increment "builds upon the previous one, progressively adding features and functionality." Stakeholder value is realized earlier, but overall scope and timeline remain largely fixed.
  • Security Classification: "Are elements of the product business confidential or classified?" Security constraints may limit stakeholder access and feedback frequency.
  • Common Confusion: Confusing incremental delivery (partial product completion with fixed scope/timeline) with iterative development (repeated cycles refining requirements). Incremental = building pieces; iterative = refining through feedback.

Typical PMI Exam Example

A project involves developing a new drug where the final approval requires comprehensive testing that cannot be evaluated until near completion. The technology is well-established, and core requirements are stable. What approach is most appropriate? → Predictive, because the product is "hard to evaluate until it is near completion" and requirements are unlikely to change.

PMI Exam Traps

  • Trap: Assuming all projects with long timeframes must use predictive scheduling.

    • Reality: Long timeframes increase risk of requirement changes, favoring iterative/incremental approaches with rolling wave planning.
  • Trap: Confusing incremental delivery (partial product completion) with iterative delivery (requirement refinement through feedback cycles).

    • Reality: Incremental = building features piece by piece; iterative = repeating cycles to refine understanding and requirements.
  • Trap: Thinking security-classified products always require predictive approaches.

    • Reality: Security constraints limit who provides feedback, not necessarily the method; iterative approaches can still work with controlled stakeholder groups.
  • Trap: Assuming stable requirements always mean predictive is best.

    • Reality: Even with stable requirements, incremental delivery can provide earlier stakeholder value while keeping "overall scope and timeline remain largely fixed."

Important PMI Connections

Related ConceptRelationship TypeExam Attention Point
Tailoring (Section 3.4)Determines development approachProduct attributes (stability, technology, timeframe) drive tailoring decisions for scheduling and delivery
Rolling Wave PlanningComplements iterative approachUsed when long-term requirements are unclear; short-term requirements are well-defined per iteration
Project Team Attributes (Section 2.3.3.3)Influences scheduling toolsTeam size, geography, and experience affect how schedule is communicated and maintained
Business Case AlignmentValidates approach suitabilityThe project authorizing documents must demonstrate that deliverables and business objectives are aligned with the chosen approach

Quick Review Questions

  1. A project involves building a physical structure where the design is well-known and requirements are stable. The product can be partially completed and handed over to the client. What development approach is most appropriate?

  2. During project planning, the team determines that the technology is "rapidly evolving and at risk of obsolescence." How should this influence the scheduling approach according to PMBOK v8?

  3. A project team is evaluating whether to use iterative delivery. What is the PRIMARY question they should answer about the product according to PMBOK v8?

  4. In an incremental delivery approach, what remains "largely fixed" while stakeholder value is realized earlier?

  5. A project has classified/confidential product elements. Which product consideration from PMBOK v8 is most relevant to determining the development approach?

PMBOK v8 Reference

Section 3.4.3.2 - Project Team (Product considerations including stability of requirements, security, and incremental/iterative delivery feasibility) Section 4.5 - Incremental and Iterative Delivery (Increments building upon previous ones, partial delivery with fixed scope/timeline) Section 2.3.3.3 - Project Team Attributes (Team size, geography, experience influencing scheduling)