D687 Computer Science Project Development with a Team, catalog number ICSC 3131, is the three CU course in the WGU School of Technology in which students expand prior coding work and prepare a project for submission to a mock technical and executive leadership team. The structure of that audience is the whole difficulty: two groups who want incompatible things from the same work, and both have to be satisfied.
Two audiences, one project
A technical review team wants to know how it works, whether the design decisions were sound, what the failure modes are and whether the code is maintainable. An executive team wants to know what it does for the organisation, what it costs, what the risks are and whether to continue funding it. Answering one well and the other badly is the standard outcome, and the aspects are usually arranged so that it costs you.
The specific failure differs by background. Students with strong development experience produce a deep technical account and an executive section that reads as an apologetic summary of the same material. Students with more business background do the reverse, presenting benefits confidently while the architecture discussion stays at the level of naming technologies. Both are visible immediately to an evaluator holding a rubric that scores each separately.
The second scored theme is the expansion itself. The course description says expand prior coding work, which means the delta matters. What was there before, what you added, why that addition rather than another, and how you know it works are all part of what is being assessed, and a submission that presents the whole project as if newly built loses the reasoning that the word expand implies.
Turning scored aspects into a section plan
Scoring detail lives in your Course of Study rather than the catalog. Count the aspects and build headings from them, in the rubric's own language. Each is judged independently against a three point scale and each needs a 2, so a strong technical presentation cannot carry a thin executive one.
Presentation heavy courses create a particular mapping risk, because much of the evidence lives in slides or a recording. State in the written portion which artefact answers which aspect, and label slides so they can be referenced precisely.
The word budget, worked. Assume seven scored aspects and about 1,900 words of written material alongside the presentation artefacts. Reserve 150 words for an opening naming the project and its state before this course, and 120 for a close. That leaves near 1,630, about 230 per aspect. Then take 50 words from each of two implementation aspects and give 100 to the executive communication aspect and 100 to the aspect covering risks and next steps. Those two are where technically strong students most often lose ground.
A structure that fits a dual audience submission
Where your directions specify a structure, follow it. Where they leave it open, this ordering supports both audiences without repeating yourself.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Project purpose | What problem this solves and for whom, in one paragraph without jargon | The executive entry point; jargon here loses the room immediately |
| Prior state and expansion | What existed before and precisely what you added | The delta is what the course is assessing |
| Architecture | Components, data flow, dependencies and the reasoning behind them | Technical audience section; scored on justification not description |
| Implementation decisions | The choices that required judgment, with rejected alternatives | Rejected alternatives are the strongest technical evidence |
| Testing and quality | What is tested, what coverage exists, what is verified manually | Frequently thin; it is what maintainability rests on |
| Business case | Cost, benefit, timeline and what continuing would require | Executive section; needs numbers rather than adjectives |
| Risks and next steps | Technical debt, dependencies, and a prioritised roadmap | Serves both audiences and is often the best received section |
Write the executive summary in language that survives being read by someone who does not know what a repository is. That constraint is the actual exercise, and it is far harder than it sounds for a student who has just spent weeks inside the code.
Evidence craft for a project presentation
Presentation work is judged on whether claims are supported, which is easy to arrange and easy to forget.
- Show the delta concretely: commits, files changed, or a before and after description of capability.
- Support quality claims with evidence such as test results, coverage figures or a defect list, rather than with assurance.
- Quantify the business case even roughly, and state the assumptions behind every figure.
- Document dependencies and their licences, since an executive audience is entitled to know what the project relies on.
- Cite any framework or standard you invoke, including development methodologies.
- Use APA in the written portion and credit any code or components you did not write.
Name the technical debt you knowingly accepted. Executives respond well to honesty about compromise, technical reviewers respect it, and it usually satisfies a risk aspect that would otherwise need inventing.
What separates Competent from a submission sent back
Aspects score independently, so returns tend to hit whichever audience you found less natural.
- The purpose paragraph contains no jargon and would make sense to a non technical reader.
- The expansion is described as a delta rather than as a whole project.
- Architecture decisions name rejected alternatives with reasons.
- Quality claims are supported by evidence rather than by assertion.
- The business case contains numbers and states its assumptions.
Performance assessment work can be revised and resubmitted with no grade penalty, so a return costs calendar rather than standing. Terms run six months at a flat rate, and presentation artefacts are slow to rebuild, which makes planning the two audience split before recording anything the efficient approach.
Six mistakes that cost time in D687
- One presentation for both audiences. The technical version bores the executives and the executive version frustrates the reviewers.
- Jargon in the executive section. Every unexplained term is a moment where a non technical reader stops following.
- No numbers in the business case. Executives evaluate proposals in cost and benefit, and adjectives do not substitute.
- Presenting the whole project as new. The expansion is what this course assesses, and hiding it removes your own evidence.
- Quality asserted rather than shown. Saying the code is well tested is not the same as showing what is tested.
- No roadmap. Both audiences want to know what happens next and in what order.
Explaining technical work to people who do not want the detail
The transferable skill in D687 is translation, and there are a few moves that make it reliably easier.
Lead with consequence rather than mechanism. Not that the service now uses a message queue, but that the system no longer loses requests when the downstream service is slow, which previously caused a specific problem. The mechanism can follow in a sentence for anyone who wants it, but the consequence has to come first or the mechanism has nothing to attach to.
Convert technical properties into business language deliberately. Latency becomes how long someone waits. Test coverage becomes how likely a change is to break something that was working. Technical debt becomes work that will have to be done later, with an estimate. Scalability becomes what happens when the volume doubles. Each translation is a sentence, and together they let an executive audience reason about engineering without pretending to understand it.
Use one number per claim. A presentation with a single well chosen figure per point is persuasive; one with a dense table is skipped. Keep the table in an appendix for the technical reviewers, who will want it.
Finally, prepare for the question you least want. Every review has one: why this took as long as it did, why an alternative was not used, what happens if a dependency disappears, or what would break first under load. Writing an honest answer in advance turns the hardest moment of a review into the one that most improves your credibility, and in a course scored on communication competencies it is often the difference between an aspect met and an aspect returned.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: a purpose paragraph written without jargon, a clear delta description, architecture reasoning with rejected alternatives, a business case with stated assumptions, and a prioritised roadmap. Plus rehearsal support on the hard questions so the presentation is yours to deliver.
D687 draws on work from earlier courses, so keeping that work organised pays off directly here. Terms are six months at a flat rate, and a presentation course is one of the easier ones to close quickly once the two audience structure is settled.
Questions students ask about D687
Is D687 the same course as ICSC 3131?
Which prior project should I expand?
Can you build and present the project for me?
Where D687 sits in WGU's programs
The July 2026 catalog places this code in 2 current WGU programs. 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.