Capella PM FlexPath Capstone Guide

Unlike essay-style capstones, the project management capstone is fundamentally an artifact-based project: a project charter, a work breakdown structure, a schedule, a budget, a risk register, and a stakeholder communication plan, all built around one project and all consistent with each other. It's evaluated less on any single document in isolation and more on whether the full plan hangs together as something an organization could actually execute.

What the PM capstone typically requires

Exact deliverables vary by course version, so always work from your own scoring guide, but most versions of the project management capstone ask for some combination of the components below, integrated into one cohesive project plan rather than submitted as unrelated documents.

The single most important word in that table is consistency. Evaluators read the plan as one document set: if the charter promises a deliverable the WBS never decomposes, or the risk register flags a resource risk the budget ignores, the plan reads as assembled rather than engineered, and that gap between documents is exactly where capstone criteria most often land at Basic instead of Proficient.

Choosing a capstone project

Strong PM capstones plan a project that is specific, bounded, and realistic: implementing a new scheduling system at a clinic, relocating a small office, launching a defined product feature, or running a community event with a fixed date and budget. The project can be real (something from your workplace) or realistic (a detailed hypothetical), but it needs enough concrete detail to support genuine estimates, real dependencies, and plausible risks.

Two failure modes show up repeatedly at topic selection. The first is choosing a project so large (an enterprise ERP migration, a hospital construction project) that every artifact becomes shallow because no single student can plan it credibly at that scale. The second is choosing something so small (planning a dinner party) that there aren't enough work packages, dependencies, or risks to demonstrate the competencies the scoring guide measures. A useful middle band is a project a small team would deliver in three to nine months with a five-figure to low six-figure budget. That scale gives you 30 to 60 credible work packages, a real critical path, and a risk register that isn't padding.

How the capstone is scored: competencies, not chapters

Like every FlexPath assessment, the capstone is scored criterion by criterion against a scoring guide, with each criterion rated Non-performance, Basic, Proficient, or Distinguished. If the competency model is new to you, our guide on how FlexPath competency scoring works covers the mechanics; the capstone-specific point is that each planning artifact usually maps to one or more named criteria, so an incomplete artifact doesn't just weaken the document, it leaves an entire criterion unmet.

The practical implication: build a checklist directly from the scoring guide before you draft anything. For each criterion, note which artifact satisfies it and what the Distinguished-level language asks for beyond Proficient. Distinguished descriptors in PM capstones typically reward things like justifying methodology choices (why predictive rather than agile for this project), quantifying risk exposure rather than just rating it, and explicitly connecting the plan to organizational strategy. Those are additions you can plan for deliberately, not qualities that appear by accident. Faculty cannot score intentions or effort, only what the artifacts demonstrate, so any competency the scoring guide names must be visible somewhere in the document set, and it helps to make that mapping obvious with clear section headings.

It's also worth reading the scoring guide for what it says about integration. Many versions include a criterion that explicitly evaluates alignment across artifacts, and even where no such criterion exists, evaluators notice misalignment immediately because it's the first thing a practicing PM would check. Submissions that get returned for revision most often fail on exactly this kind of internal consistency; our breakdown of common FlexPath assessment return reasons applies in full to capstone submissions.

Building the charter first, and letting it govern everything

The charter is the smallest document in the set and the one that controls all the others. Write it first, and write it tightly: a two-sentence business case grounded in a real organizational problem, three to five SMART objectives, explicit in-scope and out-of-scope lists, key assumptions and constraints, and success criteria a sponsor could verify at closure. Every later artifact should be traceable back to it. If a WBS branch doesn't serve a charter objective, either the branch is scope creep or the charter is incomplete, and evaluators will notice whichever it is.

A discipline that pays off: keep a one-page traceability note as you work, mapping each charter objective to the WBS branches, schedule milestones, and risks that serve it. You won't necessarily submit it, but it forces the internal consistency the capstone is really testing, and it makes the final self-review fast.

WBS and schedule: where most points are won or lost

The WBS is deliverable-oriented decomposition, not a to-do list. Level 1 is the project, level 2 is major deliverables or phases, and lower levels break each deliverable into work packages. Two standards matter most: the 100 percent rule (child elements fully account for their parent, nothing more, nothing less) and a roughly consistent level of decomposition (one branch broken into 15 work packages while another stops at a single line reads as unfinished). Number the elements (1.0, 1.1, 1.1.1) so the schedule and budget can reference them cleanly.

The schedule then sequences those work packages with explicit dependencies. Evaluators look for realistic durations, correct dependency logic (mostly finish-to-start, with deliberate use of others where justified), clearly marked milestones, and an identified critical path with a sentence or two explaining what it means for this project: which tasks have zero float, and where the schedule is most fragile. A Gantt chart built in Microsoft Project, ProjectLibre, or even a well-structured spreadsheet is usually expected. The chart itself matters less than the logic behind it; a beautiful Gantt with arbitrary dependencies scores worse than a plain one whose network logic holds up.

Risk register and stakeholder plan: specificity is the whole game

Generic risk registers are the most common weak artifact in PM capstones. "Project may go over budget" is not a risk; it's a category. A scoreable risk entry names a specific uncertain event, its cause, and its effect: "The clinic's EHR vendor may delay the integration API documentation past week 4, delaying interface development and compressing testing." Each entry needs a probability rating, an impact rating, a response strategy (avoid, mitigate, transfer, or accept, chosen deliberately and briefly justified), a specific response action, and an owner. Eight to fifteen well-specified risks beat thirty generic ones every time, and tying at least a few risks to your critical path shows you built the register from the schedule rather than from a template.

The stakeholder plan follows the same rule. Analyze real named roles (sponsor, department managers, end users, vendor contacts, regulators if relevant) on influence and interest, then match communication to the analysis: the high-influence, low-interest executive gets a monthly one-page dashboard; the high-interest end users get biweekly demos and a feedback channel. When the communication matrix visibly follows from the stakeholder analysis, both artifacts strengthen each other. When every stakeholder gets "weekly email update," the analysis was decorative.

A worked example: threading one decision through every artifact

Suppose your capstone plans the rollout of appointment-scheduling software for a three-location dental group. A key early decision: pilot at one location before rolling out to all three, or cut over everywhere at once. A weak capstone mentions the pilot in the charter and never again. A strong one threads it through the entire document set. The charter lists the pilot as an explicit scope element with its own success criteria (pilot location error rate under 2 percent before rollout proceeds). The WBS gives the pilot its own branch (3.0 Pilot Implementation) with work packages for training, data migration, and evaluation. The schedule shows the pilot evaluation milestone as a predecessor gating the two rollout branches, and notes that this gate sits on the critical path. The budget carries pilot-specific training costs plus contingency tied to the possibility of a second pilot cycle. The risk register includes "pilot reveals workflow mismatch requiring configuration rework," rated, owned, and mitigated by the evaluation gate itself. The communication plan schedules a pilot-results briefing for the sponsor before the go/no-go decision.

One decision, six artifacts, all consistent. That threading is what Distinguished-level capstone work looks like in practice, and it's achievable for any student who plans the connections deliberately instead of writing each document in isolation.

Making the capstone portfolio-ready

The PM capstone has a second life after graduation: it's often the one work sample a new project manager can show employers, and interviewers for junior PM roles frequently ask for exactly the artifacts this capstone produces. Building it portfolio-ready costs little extra effort during the capstone and pays off in job searches, especially since PMI's certification path (discussed in our PM program overview) values documented, applied project work.

• Use professional formatting from the start. A consistent document template, numbered sections, version and date on each artifact, and an executive summary that a hiring manager could read in two minutes.
• Sanitize real-employer details. If you planned a workplace project, replace confidential names and figures now so the version you submit is the version you can share.
• Export presentation-quality visuals. The WBS diagram, Gantt chart, and risk heat map should each stand alone as a readable one-page exhibit.
• Write a one-page project summary. Problem, approach, methodology choice, and key planning decisions, in plain language. This becomes your interview talking track.
• Keep the source files. The .mpp or spreadsheet behind the Gantt matters more to a portfolio than the PDF export, because it proves you built the logic yourself.

Common PM capstone mistakes

• Artifacts that don't agree. A budget that doesn't trace to the WBS, a schedule missing charter deliverables, risks with no connection to the actual plan. Internal inconsistency is the top scoring problem.
• Task-list WBS. Decomposing by activity ("make calls," "send emails") instead of by deliverable, which makes the 100 percent rule impossible to verify.
• Generic risks and boilerplate communication rows. Register and matrix entries that could be pasted into any project signal template-filling rather than analysis.
• Unjustified methodology. Declaring the project "agile" or "waterfall" without explaining why that approach fits this project's uncertainty, stakeholder needs, and deliverable type.
• Round-number budgeting. Costs invented at the total level and divided down, rather than estimated at the work-package level and rolled up with a stated basis of estimate.
• No closure thinking. Where the course asks for closure elements (lessons learned, acceptance criteria, transition plan), students often run out of steam; these criteria are usually the easiest Distinguished points in the whole capstone.

A practical capstone timeline

FlexPath's self-paced structure means the capstone expands to fill whatever time you give it, so a deliberate schedule matters; our FlexPath time management guide covers pacing generally, and the phase plan below adapts it to this project's artifact sequence.

The integration pass in week 9 is the step students most often skip and the one that most reliably lifts scores. Budget real time for it: read the charter, then check each artifact against it in sequence, fixing every number, name, and deliverable that drifted during drafting.

How the capstone connects to prior PM coursework

Every earlier assessment in the program was practice for one capstone artifact: the charter assignments, the scheduling and WBS work, the risk assessments, the stakeholder communication plans covered in our PM assessments and scoring guide all reappear here at full scale. Before starting, pull up your strongest prior submissions and the faculty feedback on them. Feedback you received on a standalone risk register assessment predicts exactly what the capstone evaluator will look for in your capstone register, and reusing structures that already scored Proficient or Distinguished is legitimate and efficient. Students coming from other programs can also compare notes with the business capstone guide; the strategic-analysis emphasis differs, but the scoring-guide-first workflow is identical.

Related guides