C783 Project Management is recorded under banner number ITEC 5320 and is worth 4 competency units. It works through the inputs, tools, techniques and outputs described in the Project Management Body of Knowledge. C783 is the legacy code for this graduate material; the current entry with the same title is E015 under banner ITEC 5322, and only the code your Degree Plan lists will close your requirement. Note that a separate business-school Project Management course also exists under a different code.
The body of knowledge is a vocabulary, not a script
The framework this course teaches is organised around processes, each with defined inputs, the tools and techniques applied to them, and the outputs they produce. Learning it as a list of process names is possible and almost useless. Learning it as a flow, where the output of one process is the input to another, makes the whole structure memorable and makes applied questions answerable, because you can trace where a document came from and what it feeds.
The graduate framing means you are expected to apply the framework rather than describe it, and to notice where it does not fit. The body of knowledge assumes a project with a defined product, a sponsor and a schedule; plenty of real technology work does not look like that. Saying which processes you would apply lightly, and why, is graduate judgement rather than a failure to follow the method.
Stakeholder work is the strand that separates capable project managers from schedule administrators. Identifying who is affected, what each of them wants, how much influence they hold and how they should be engaged is unglamorous and determines outcomes more often than any Gantt chart. When a scenario names a department that was not consulted, the aspect is about stakeholder management.
Integration is the process group students underuse. Change requests, the change control process and the integrated change control decision are what stop a project from being redefined incrementally by whoever asks last. A plan without a change process is a plan that will be quietly replaced.
Assessment closes as Competent or Not Competent, without letter grades, and WGU keeps no ordinary grade point average, while the 4 competency units simply size the course inside a flat-priced six month term.
Turning aspects into project documents
If your version of C783 uses a performance assessment, the aspects usually correspond to plan components and to justification of the choices in them. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a detailed schedule will not carry an unaddressed stakeholder or procurement aspect.
Budget before drafting. Take a rubric with ten scored aspects and a target near 3,000 words. Reserve 180 words for the project context and objective, and 130 for the close, leaving 2,690 across ten aspects, or 269 each. Weight by demand: four aspects requiring analysis and justification take 380 each, which is 1,520; the six remaining aspects, covering plan components, take 195 each, which is 1,170. Together that is 2,690.
Build artifacts before prose and write from them. The schedule, the breakdown structure and the register tables carry facts, and prose written from memory rather than from the artifact is where contradictions enter a project document.
Reserve budget for the tailoring argument. Saying which processes you applied fully, which you applied lightly and why is one of the most reliable ways to demonstrate graduate-level understanding of a framework, and it distinguishes your submission from one that simply followed the template.
Shape for a graduate project plan
C783 deliverables are usually plans or plan analyses. These proportions fit that document.
| Section | Content | Share |
|---|---|---|
| Charter and objective | Business case, objective, sponsor, success criteria and high-level constraints. | 11 percent |
| Stakeholders | Register with interest, influence and engagement approach for each named party. | 15 percent |
| Scope | Deliverables, breakdown structure, acceptance criteria and explicit exclusions. | 16 percent |
| Schedule and resources | Sequenced activities with dependencies, estimates, critical path and resource assumptions. | 18 percent |
| Risk | Register with likelihood, impact, owner, response and trigger for each entry. | 15 percent |
| Quality and change | How quality is defined and verified, and how changes are requested, decided and recorded. | 14 percent |
| Close | Tailoring argument: what you applied lightly and why, plus closure criteria. | 11 percent |
Sourcing project management claims
Process definitions, terminology and technique descriptions belong to the recognised body of knowledge or to the standard your course materials use, cited by edition, because terminology and process groupings have changed between editions and citing the wrong one produces subtly incorrect vocabulary.
Estimates need a stated basis rather than a number. Analogous estimating compares to a past project, parametric estimating multiplies a rate by a quantity, and three-point estimating combines optimistic, likely and pessimistic values. Naming which you used and why makes the estimate defensible and answers an aspect at the same time.
Claims about what typically happens on projects, such as failure rates or overrun frequency, are empirical and belong to published research or industry survey data with a year attached. These figures are widely quoted and frequently misattributed, so tracing one to its actual source is worth the ten minutes.
Scenario facts are your richest material. Constraints on staff availability, fixed regulatory dates, a sponsor with a stated preference or a supplier with a long lead time all shape the plan, and using them by name is what stops a plan reading as a template exercise.
Keep to the citation style the task requires and cite at the point of claim.
Competent plans and returned ones
Competent submissions are internally consistent, use the framework vocabulary precisely, name owners in every register, sequence work by dependency, and argue their tailoring rather than applying every process uniformly.
Returns cluster in four shapes. Artifacts and prose contradict each other. Risks or stakeholders are listed with no owner or engagement approach. Estimates appear with no basis. Or the framework is described accurately and never applied to the project in front of the student.
Procurement is the knowledge area students most often skip and it appears in scenarios more often than they expect. Any project that buys hardware, engages a contractor or licenses software has procurement decisions in it: make or buy, contract type, how a supplier is selected, and what happens if they deliver late. Contract type in particular carries risk allocation, since a fixed price arrangement moves cost risk to the supplier at the price of flexibility, while a time and materials arrangement does the reverse. Naming that trade demonstrates understanding rather than coverage.
Quality also deserves more than a heading. Quality planning asks what "good enough" means for each deliverable and how it will be verified, and the answer should be specific to the deliverable rather than a general statement about standards. A test plan, an acceptance checklist or a review step attached to a named deliverable is what an aspect on quality is looking for.
The consistency check that pays for itself is numeric. Pick the duration, the headcount and the budget, then trace each through every section it appears in. Long project documents accumulate drift during editing, and the numbers are the first thing an evaluator can verify.
Nothing is deducted when performance assessment work goes back for revision, so completeness beats polish when you are deciding whether to submit, rather than holding it back for another pass. If your section also carries an objective assessment, WGU objective assessments are proctored and our boundary is fixed: preparation only, with process drills, terminology practice and a candid read on your preassessment result. We never sit an exam, do not assist while it is running, and portal credentials are never requested or handled.
Plan following the template instead of the project?
Send the C783 rubric and scenario. We build the artifacts first, then the tailoring argument, with word targets per aspect.
Eight mistakes that cost time in C783
- Working the wrong code. C783 is ITEC 5320 and E015 is ITEC 5322. Same title, different Degree Plan entries.
- Memorising process names. Learn the flow: what each process consumes and produces. Applied questions need the flow.
- Estimates with no basis. Name the estimating technique and the inputs, or the number cannot be defended.
- Registers without owners. Risks and stakeholders both need a named person, not a function.
- Artifacts contradicting prose. Build the artifact, write from it, then check the numbers across every section.
- No change control. Without it, scope is redefined by whoever asks last and the plan becomes decorative.
- Uniform process application. Graduate work tailors deliberately and explains the tailoring.
- Citing the wrong edition. Terminology and groupings have changed. Cite the edition your course uses.
Three questions students ask about C783
Is C783 the same course as E015?
Does this prepare me for a project management certification?
Do I need to have run projects before?
Where C783 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.