D502 Data Analytics Capstone, catalog number DTMG 3901, is the four competency unit close of the data analytics degree. The catalog is unusually specific about what it requires: identify an organizational need, then plan, develop and document a data analytics product against all of the BSDA program outcomes. Two words in that sentence carry the whole course. Organizational, because a need you invented does not count. Product, because the deliverable is a thing that runs and not only a paper about one.
A product, not a paper about a product
Most students arrive at this course having written many documents and built few things that another person had to use. The shift is real. A report is finished when the reader understands it. A product is finished when someone other than its author can run it, get a result they trust and do something with that result. Everything difficult about D502 comes from that second standard.
The organizational need has to exist before the product does, and this is the sequencing error that sinks the most capstones. The tempting route is backwards: find an interesting public dataset, build something clever with it, then write a paragraph inventing an organization that would have wanted it. Evaluators recognise this immediately, because a manufactured need is always suspiciously well matched to the data and cannot say who would act on the output. Start from a person with a problem. Even a small, unglamorous, genuinely felt problem produces a stronger capstone than an elegant analysis nobody asked for.
The word documented is doing more work than it appears to as well. Documentation in a capstone is not a summary written afterwards, it is the evidence that the outcomes were met. Nobody watches you work. The document is the only witness, which means decisions taken during development have to be recorded while they are being taken, not reconstructed from memory in the final week when the reasons have blurred.
Write your acceptance test before you build anything. In one short section, state what the product must do for it to count as successful, in terms someone in the organization would recognise: which question it answers, how quickly, for whom, with what accuracy or coverage. Doing this first costs an hour and changes everything downstream, because results can then be tested against a standard you set in advance rather than against one you assembled after seeing what you got.
From a long aspect list to a schedule and a budget
Capstone rubrics are long, and the failure mode is not running out of words. It is running out of weeks. If your version of D502 is assessed by a performance assessment, the aspects your evaluator scores are both your outline and your project plan, and each one still needs a score of 2 on its own for the task to pass.
Worked example, twelve aspects into 5,000 words. Suppose the rubric lists twelve scored aspects across a document of roughly 5,000 words. Three of those are satisfied by the product and its own documentation rather than by argument, so give each a 200 word locator saying what the artifact is, where it lives and how to run it, which is 600. Reserve 250 for establishing the organizational need and 200 for the close. That leaves 3,950 across nine written aspects, or 439 each.
Write to 400 instead and hold the remaining 350 in reserve. In a capstone one aspect always turns out to be harder than the rubric made it look, usually the one asking you to justify a methodological choice, and a reserve means funding it does not require cutting something else at midnight.
Then convert the same list into dates, which is the part that actually saves the term. Count your available weeks and place a build freeze at the two thirds mark. After the freeze the product stops changing and only the documentation moves. Capstones that return late almost always kept improving the artifact until the final week, which leaves a document describing a version that no longer exists, and inconsistency between document and product is among the easiest problems for an evaluator to find.
Shape for a capstone product report
Where the work produces a written report alongside the product, these sections cover what such a document has to prove. Your task directions and course materials take precedence wherever they specify a format or an approval step.
| Section | What it must prove | Share |
|---|---|---|
| Organizational need | That the problem is real, whose it is, and what it currently costs | 10 percent |
| Product and scope | What will be built, who uses it, and what it deliberately will not do | 9 percent |
| Success criteria | The acceptance test, in measurable terms, fixed before development began | 8 percent |
| Data description | Sources, permission to use them, structure, quality and known limits | 12 percent |
| Methodology | The analytic approach, why it suits this need, and the alternative you considered | 14 percent |
| Development record | How it was built, what was decided during the build, and what changed from the plan | 13 percent |
| Results and validation | What the product produces, tested against the criteria set earlier | 15 percent |
| Delivery and handover | How the organization runs it without you, including refresh and dependencies | 10 percent |
| Limits and next steps | What it cannot do, and what the organization should do next | 9 percent |
Success criteria and results are deliberately far apart in the document and deliberately locked together in the argument. The results section should reference the criteria section by number and answer each one in turn, which is the clearest possible demonstration that you did not move the target.
Evidence at capstone standard
A capstone claims more than a course task does, so its evidence has to be sturdier in three specific places: the need, the data and the results.
- Evidence the need rather than asserting it. A quoted conversation with the person who has the problem, a report showing the time currently spent, or a count of how often the question gets asked all beat an unsupported statement that this would be useful.
- Record permission for any organizational data, and de-identify anything about individuals. Where a source is public, name its licence and its terms of use.
- Show that results can be reproduced. Fix any random element with a stated seed, record the software versions used, and note the date the data was extracted.
- Report performance honestly, including where the product does worse. A capstone that names a weakness and explains its consequence reads as competent judgment rather than as a defect.
- Cite methods to recognised sources in paraphrase with APA references, keeping quotation minimal because submissions run through a similarity check.
- Date and caption screenshots of the working product, since an undated image cannot be tied to the version being described.
Validation deserves more room than students usually give it. Producing an output is not evidence that the output is right, and the interesting question is what would have shown you it was wrong. Hold back part of the data and see how the product behaves on records it never saw. Compare its answers against a small set worked out by hand. Ask whether the result would change if a defensible alternative assumption were used, and report what you found. A capstone that shows one convincing number is weaker than one that shows a number and the tests it survived.
Where the product depends on data the organization refreshes, describe the refresh explicitly: what has to arrive, in what shape, how often, and what the product does when it does not arrive. Handover is a scored idea in most capstones because it is the difference between a demonstration and a deliverable.
What clears a capstone, and where support stops
Competent capstones hold together as one argument. The need is evidenced by something outside the author. The product does what the scope section said it would. The methodology explains why this approach and not another. Results are tested against criteria written earlier. Handover is real enough that a named person could run it. Limits are stated by the author rather than discovered by the evaluator.
Returns concentrate in five recognisable shapes. The analysis is competent and no organizational need sits behind it. Success is declared against criteria that appeared after the results. The product runs only on the author's machine, with undocumented dependencies. The document describes a build that has since changed. Or the write up narrates what the student did without connecting any of it to the program outcomes the capstone exists to evidence.
WGU records the outcome as Competent or Not Competent, with no letter grades and no ordinary grade point average, and four competency units at the end of a degree are worth clearing early rather than late. Terms run six months at a flat rate, so a capstone that closes inside the term it started saves a genuine amount of money. Performance assessment work can be revised and resubmitted with no grade penalty, which makes an early submission with every aspect answered a better strategy than a late submission that feels polished. Where a course also carries an objective assessment, WGU objective assessments are proctored and our position never moves: preparation only, never sitting an assessment, never taking part during one, and never asking for or handling portal credentials. On capstones specifically we also do not contact your organization, collect data on your behalf, or sign or submit anything in your name.
Capstone stuck at the proposal?
Send the D502 rubric and your idea. We pressure test the organizational need, write the acceptance test with you and return a dated plan with a build freeze.
Six mistakes that cost weeks in D502
- Picking the dataset first. A need reverse engineered from available data cannot say who would act on the result, and that gap shows in every section afterwards.
- Writing success criteria after seeing results. Criteria set in advance are a test. Criteria set afterwards are a description, and an evaluator can tell which one they are reading.
- Building past the freeze. Every late change to the product invalidates part of the document, and the mismatch is easy to spot and expensive to repair.
- A product only its author can run. Hard coded paths, undeclared package versions and manual steps performed from memory turn a working artifact into an unverifiable one.
- Using real organizational data casually. Permission and de-identification are part of the work, not paperwork around it, and a capstone that skips them creates a problem larger than a return.
- Narrating instead of evidencing. The document exists to show the program outcomes were met. A chronological account of your weeks does not do that, however accurate it is.
How the capstone runs with support
Send the rubric, the directions and the situation you are considering. The first session is scoping and it is deliberately sceptical: whose problem is this, what happens today without your product, who would use the output and what would they do differently because of it. If those questions have answers, the capstone has a spine. Then the acceptance test gets written, the aspect list becomes a dated plan with a build freeze, and the document grows section by section while the build is still fresh rather than being assembled at the end.
Reviews run against the rubric aspect by aspect, and the last pass is a consistency read that checks the document against the product it describes. The technical foundations sit in D326 Advanced Data Management and D497 Data Wrangling, the rules about handling the data live in D494 Data and Information Governance, and our general method for long assessments is on the capstone help page.
Questions students ask about D502
Is D502 the same as DTMG 3901?
Does the capstone have to produce something that runs?
What if the data I need is not available to me?
Where D502 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.