Project Management Concepts PK0-005 Practice Quiz

• A. Projects are temporary endeavors with a defined start and finish, producing a unique deliverable
• B. Projects produce standardized, repeatable outputs delivered on a continuous cycle
• C. Projects are performed only by external contractors, while operations are managed by internal staff
• D. Projects always require a budget greater than $100,000 and formal executive sponsorship

The two defining characteristics of a project are: (1) TEMPORARY, it has a defined start date and a defined end date; it does not continue indefinitely. (2) UNIQUE, the deliverable (product, service, or result) is distinct from all other deliverables; even repetitive project types (building construction) produce unique outputs for each instance. These two characteristics together separate projects from operations. A project also has a reason/purpose (the business need driving it) and may exist within a larger program or portfolio context.

• A. Portfolio, because they all relate to the same strategic objective
• B. Operations group, because they share the same business objective
• C. Project management office (PMO), because the PMO oversees all concurrent projects
• D. Program, because they are related projects managed in a coordinated way to obtain benefits not available from managing them individually

A PROGRAM is a group of related projects managed in a coordinated way to obtain benefits and control that would not be available from managing them individually. These three projects (website, mobile app, CRM integration) are technically interdependent, user experience decisions on one affect the others, integration must be coordinated, and there are shared resources and shared benefits. Managing them as a program allows the program manager to coordinate dependencies and realize the combined business benefit (improved digital customer experience) holistically.

• A. Development (coding/implementation), verify that design artifacts (architecture documents, data models, UI wireframes) are complete, reviewed, and approved; that development standards are established; and that the development environment is ready
• B. Deployment, verify the production environment is ready to receive the completed code immediately
• C. Testing, verify that a test plan exists and all developers are assigned to testing duties before coding begins
• D. Requirements, verify that requirements have not changed since the design was created before allowing coding to proceed

The traditional SDLC phases in sequence: (1) Planning → (2) Requirements Analysis → (3) System Design → (4) DEVELOPMENT (Implementation/Coding) → (5) Testing → (6) Deployment → (7) Maintenance. After the design phase, DEVELOPMENT begins. The project manager should verify: Design documents are complete, formally reviewed, and approved (architecture, data models, UI specs, API contracts); Development standards and coding guidelines are established; The development environment (IDEs, source control, build systems) is configured; Developers have been assigned and have the necessary access; Acceptance criteria for the development deliverables are defined (what 'done' looks like). Proceeding to coding without these artifacts and preparations risks rework, integration failures, and scope creep.

• A. The roles are identical. Scrum simply renames the project manager as Scrum master and the business analyst as product owner
• B. The project manager becomes the Scrum master (facilitator, not commander); the business analyst role is absorbed into the product owner (who manages the backlog and acceptance criteria); the QA team joins the cross-functional development team, sharing testing responsibility with developers
• C. All three roles are eliminated in Scrum, the self-organizing development team handles planning, requirements, and testing without any specialized roles
• D. The project manager retains authority in Scrum but delegates sprint planning to developers; the BA continues to write requirements documents between sprints

Waterfall-to-Scrum role mapping: Project Manager → SCRUM MASTER: The Scrum master is a servant-leader and facilitator who helps the team follow Scrum, removes impediments, and coaches the organization. The Scrum master does NOT assign work, manage schedules, or exercise traditional command authority. Business Analyst → PRODUCT OWNER (partially): The product owner owns the product backlog, prioritizes features based on business value, defines acceptance criteria for each backlog item, and is the single voice of the customer. Unlike a BA who produces a requirements specification document, the PO continuously collaborates with the team and stakeholders throughout development. QA Manager → PART OF DEVELOPMENT TEAM: In Scrum, quality is the whole team's responsibility. The cross-functional development team includes developers, testers, designers, and others, there is no separate QA organization. Testers work alongside developers within sprints, and testing is continuous, not end-of-phase.

• A. Inspect and adapt, developers cannot attend retrospectives if they are on multiple teams, reducing the team's ability to improve
• B. Dedicated team commitment. Agile and Scrum strongly favor team members who are fully committed (ideally 100%) to a single team; split allocation reduces individual productivity due to context switching and makes sprint planning unreliable
• C. Transparency, developers on multiple teams may withhold information about their progress from each team to avoid appearing underutilized
• D. Timeboxing, sprint length must be adjusted when team members are shared across teams to account for their reduced availability

Agile principles and Scrum guidance are clear: team members should be fully dedicated (100% allocated) to a single Scrum team. Split allocation (developers on 2-3 teams simultaneously) creates multiple problems: Context switching overhead, research shows that switching between tasks reduces cognitive efficiency by up to 40%; developers lose focus time; Sprint planning unreliability, if a developer is 33% allocated, their true sprint capacity is unpredictable; stories may be over-committed and under-delivered; Team commitment and cohesion. Agile teams build velocity, trust, and working agreements over time; rotating attention between three teams prevents deep team formation; Productivity loss, a developer split across three teams often delivers less total value than three dedicated developers each focused on one team. The Scrum Guide recommends a Scrum team should be small enough to remain nimble and large enough to complete significant work within a sprint, and that team members should have the time and focus to do so.

• A. Evaluate each project against its continued strategic value, resource availability, and risk; reallocate resources from Project C to Project A if A's overage is recoverable, and allow Project B to continue as planned
• B. Isolate each project manager for performance review, individual accountability prevents the portfolio committee from intervening in project-level decisions
• C. Cancel all three projects and restart with better planning, portfolio instability indicates poor project management across the board
• D. Merge all three projects into one program, coordinated management would resolve the individual project problems

Portfolio management principles: Strategic alignment, each project must continue to justify its place in the portfolio through continued strategic value. Portfolio review actions by situation: Project A (40% over budget): Assess whether the overage is recoverable and whether the ERP remains strategically critical. If the business case still holds and recovery is feasible, the portfolio committee may authorize additional funding or resources. Project B (ahead of schedule): No intervention needed; success should be recognized and lessons captured. Project C (vendor bankruptcy): This is a significant external risk that may make the project undeliverable as planned. Options include sourcing a replacement vendor, descoping, or suspending the project and redeploying its resources (e.g., to help Project A). Portfolio resource reallocation is a core portfolio management tool.

• A. The security team is correct, security scans must be performed by a separate team on a fixed schedule to ensure objectivity and auditability
• B. The DevOps team is correct, security requirements should never block deployments; vulnerabilities are addressed in the next sprint
• C. Both teams are wrong, DAST should only be performed by a third-party penetration testing firm on an annual basis per industry standards
• D. The DevOps team is correct in principle; the BEST resolution is to integrate DAST into the CI/CD pipeline as an automated gate, scans run on every deployment, critical vulnerabilities block promotion to production, and results are automatically reported to the security team

The DevSecOps solution: DAST integrated into the pipeline as an automated quality gate. Every deployment candidate triggers the DAST scan in a staging/pre-production environment; if critical vulnerabilities are found, the pipeline fails (blocks promotion to production) automatically, no manual batch process needed; results are logged, reported, and tracked; the security team gets real-time visibility. This 'shift left' integration achieves both goals: security is never bypassed, and the CI/CD pipeline's continuous deployment capability is preserved. The monthly batch process is replaced by continuous automated testing.

• A. (1) Scrum, sprints allow flexibility for regulatory changes; (2) Waterfall, fixed MVP defined at start; (3) Kanban, WIP limits manage the large team
• B. (1) SAFe, the 24-month timeline benefits from PI Planning; (2) PRINCE2, project board governance for startup decision-making; (3) Waterfall, 200 engineers need a sequential coordinated approach
• C. (1) PRINCE2, manage by exception controls regulatory compliance; (2) XP, pair programming and TDD suit mobile app quality; (3) DevSecOps, security integration is critical for cloud migration
• D. (1) Waterfall, fixed regulatory scope needs sequential phase gates; (2) Scrum, iterative sprints with customer feedback drive evolving requirements; (3) SAFe, ARTs and PI Planning synchronize 15 teams across interdependent workstreams

Three-way methodology matching analysis: (1) Regulatory infrastructure upgrade → WATERFALL: Fixed scope (legislation), sequential dependencies, formal phase sign-offs, fixed timeline, textbook Waterfall conditions. The stability of requirements and regulatory compliance audit trail align perfectly with Waterfall's document-driven, phase-gate approach. (2) Startup mobile app → SCRUM: Unknown, evolving requirements are best managed iteratively. Scrum's sprint cycle allows rapid hypothesis testing, early customer feedback, and course correction. The product backlog grows and is refined as learning occurs. (3) 200 engineers / 15 teams / 5 interdependent systems → SAFe: SAFe's Agile Release Trains (ARTs) are designed for exactly this scale. PI Planning synchronizes all 15 teams every 8-12 weeks, mapping dependencies across interdependent workstreams. Without SAFe-level coordination, 15 independent Scrum teams would produce the integration failures described in the cloud migration.