D336 Business of IT - Applications carries banner number ITEC 2113 and is worth 4 competency units. Its subject is IT service management in the ITIL tradition: the terminology, the structure, the policies and the core practices used to run infrastructure, development and operations as a service rather than as a collection of machines. D336 is the current entry for this material; the legacy code with the same title is C179 under banner ITEC 2205, and your Degree Plan decides which one you complete.
Service management is a vocabulary you have to use precisely
D336 is one of the few courses where terminology is genuinely the content. An incident is an unplanned interruption or reduction in quality. A problem is the underlying cause of one or more incidents. A change is the addition, modification or removal of anything that could affect services. A service request is a routine user request handled through a defined process. Students who use those words loosely produce answers that look reasonable and score badly, because an aspect asking about problem management is asking about causes, and an answer about restoring service has answered a different question.
The structural idea underneath the vocabulary is that value comes from services rather than components. A server is not the thing the business buys; the availability of a system during working hours is. Once you write from that stance, the practices stop looking like bureaucracy. Change control exists because unmanaged change is the leading cause of self-inflicted outages. Service level agreements exist so both sides know what was promised. Continual improvement exists because a service that does not adapt slowly stops matching what the business needs.
The part students underuse is measurement. Service management is full of measures that mean something specific: time to restore, first contact resolution, change failure rate, availability against agreed hours. An answer that names the measure it would use to know whether an improvement worked is immediately stronger than one that describes the improvement alone.
Assessment at WGU is Competent or Not Competent, with no letter grades and no ordinary grade point average, and the 4 competency units size the course inside a flat-priced six month term. A course finished in six weeks rather than sixteen is capacity you can spend on the next one at no extra cost.
From scored aspects to a service management document
Where D336 is assessed by a performance assessment, the scored aspects usually map onto practices, and each one needs its own visible answer. WGU requires a score of 2 in each aspect for a task to pass, and aspects are judged separately, so an outstanding incident management section does nothing for an unaddressed change management aspect.
Budget before writing. Take a rubric with seven scored aspects and a target near 2,500 words. Reserve 170 words to introduce the organization and its service context, and 130 for the close, leaving 2,200 across seven aspects, or roughly 314 each. Weight by demand: three aspects that ask you to design or recommend a practice need about 400 words each, since each requires a purpose, a process, an owner and a measure. The remaining four aspects, which ask you to define, apply or compare, take 250 each. Three at 400 plus four at 250 is 2,200 exactly.
Inside each practice block, use the same four beats: what the practice is for, how it would work here, who owns it, and how you would know it is working. Four beats at roughly 60 to 100 words each fills a 400 word block naturally and guarantees that the measurement question, which students most often skip, always gets answered.
Shape for a service management proposal
D336 tasks typically produce a proposal or assessment of how an organization runs its IT services. These proportions work for that document.
| Section | Content | Share |
|---|---|---|
| Service context | The organization, the services it depends on, the agreed hours and who the users are. | 10 percent |
| Current practice review | What exists today for handling incidents, problems, changes and requests, stated without judgement first. | 16 percent |
| Gaps against practice | Where current handling diverges from recognised service management practice, and what that divergence costs. | 18 percent |
| Proposed practices | Each recommended practice with purpose, process, owner and measure. The core of the document. | 25 percent |
| Roles and governance | Who decides, who approves changes, and how escalation works when the process is not enough. | 13 percent |
| Adoption plan | Sequence, effort and the first practice to introduce, with why that one goes first. | 11 percent |
| Close | Expected effect stated as a measurable change, not as an aspiration. | 7 percent |
Sourcing in a framework subject
When a course is built on a framework, the framework itself is the authority and paraphrasing it loosely is the most common way to lose credit. Practice definitions, terminology and process purposes should be sourced to the published framework material or to the course texts that carry it, and quoted precisely where precision matters. Loose paraphrase of a defined term is not a style choice in this subject; it usually changes the meaning.
Where you claim an effect rather than a definition, the source changes. Statements about how service management adoption affects outage frequency or resolution time belong to published research or industry survey data, with a year attached, because those numbers move and an undated figure invites doubt. Where a claim concerns a specific tool, use the vendor documentation and keep the tool discussion subordinate to the practice discussion.
The scenario is again your best evidence source. If the case says a change was applied on a Friday afternoon and caused an outage on Monday, that sentence is doing work: it tells you about change scheduling, testing, and possibly about who is available to respond. Quoting the scenario detail directly into your analysis shows the evaluator you read it rather than pattern-matching to a generic organization.
Keep to the citation style the task requires and reference inline rather than in a closing pile. One further discipline helps in framework writing: when you introduce a defined term for the first time, define it in the framework's own sense before you use it in your own sentences. It costs one line and it removes any doubt about whether you know the distinction being tested.
The difference between Competent and returned
Competent submissions use the vocabulary exactly, keep incidents and problems distinct throughout, attach an owner and a measure to every proposed practice, and sequence adoption rather than presenting a wish list. They read like a document that would survive being shown to the service desk it describes.
Returns concentrate in four places. Terminology drifts, most often with incident and problem used interchangeably. Practices are described in the abstract with nothing tied to the scenario. Recommendations have no owner, so nothing in them is actionable. Or the adoption section lists everything as equally urgent, which tells the evaluator that no prioritisation reasoning happened.
There is a fast check for the first of those. Search your draft for the word incident and read every sentence containing it. If any of them is really about a cause rather than an interruption, you have a terminology problem that is probably repeated elsewhere. The same check works for change and for request.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, so submit once every aspect has a real answer rather than polishing. If your section carries an objective assessment as well, WGU objective assessments are proctored, and our boundary holds: we prepare with terminology drills, practice questions and a straight read on your preassessment result. We will not take your exam, give no help from the moment it starts, and portal sign-in details stay with you at all times.
Practices written but not landing?
Send the D336 rubric and your scenario. We map each practice to purpose, process, owner and measure, and return a plan with word targets.
Seven mistakes that cost time in D336
- Using incident and problem interchangeably. They are separately defined and separately practised, and blurring them is the most common single error in this course.
- Confusing the two codes. D336 is ITEC 2113 and C179 is ITEC 2205. Same title, different Degree Plan entries.
- Practices with no owner. A process nobody owns cannot be assessed as workable, and ownership is usually part of what the aspect wants.
- Skipping measures. Every recommendation should end with how you would know it worked. That sentence is often the difference between two scores.
- Paraphrasing defined terms. In a framework subject the definition is the content. Quote it, then apply it.
- Ignoring agreed service hours. Availability targets mean nothing without the hours they apply to, and scenarios usually state them for a reason.
- Treating adoption as simultaneous. Sequencing with a reason for the first step shows judgement; a flat list shows none.
Three questions students ask about D336
Do I need to memorise every practice name?
Is D336 the newer version of C179?
Does this course require IT service desk experience?
Where D336 sits in WGU's programs
The July 2026 catalog places this code in 12 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.