C179 Business of IT - Applications is recorded under banner number ITEC 2205 and is worth 4 competency units. It covers information systems and the management of them: how systems get developed, how an organization keeps running when they fail, and the issue-tracking tools that carry the work in between. C179 is the legacy code for this material. The current entry with the same title is D336 under banner ITEC 2113, and your Degree Plan decides which one closes your requirement.
Systems management is a chain of handoffs
C179 asks you to think about information systems from the outside, as a manager would. A system has a purpose someone can state in business terms, a development history, a support arrangement, a set of people who depend on it, and a plan for what happens when it stops. The course connects those together, and the questions it asks are almost always about the joints rather than the parts.
The system development material is where students who have only worked technically find something new. A development approach is a decision about how to handle uncertainty, not a preference. A predictive, sequential approach commits early and works well when the requirements genuinely are known and change is expensive. An iterative approach delays commitment and works when the requirements will be discovered by building. If an assessment describes a business with shifting requirements and a tight compliance deadline, both of those facts are pulling in different directions, and the good answer names the tension rather than picking a favourite.
Business continuity is the section students most often treat as boilerplate, and it contains the two numbers that decide everything: how much data you can afford to lose, and how long you can afford to be down. Every continuity decision, from backup frequency to standby capacity, follows from those two targets. Writing them down before you recommend anything turns a vague plan into a defensible one.
Work here returns Competent or Not Competent, because letter grades and an ordinary grade point average do not exist here, and the 4 competency units measure course size within a six month term sold at one price. That term is flat priced, so pace matters: closing this course early buys space for a heavier one in the same six months.
Reading the aspects as a management document plan
If your version of C179 is assessed by a performance assessment, the aspects your evaluator scores are the outline for a business document. WGU requires a score of 2 in every aspect for a task to pass and scores each aspect on its own, so an excellent continuity section cannot compensate for a development-approach aspect answered in two lines.
Convert aspects into a budget before drafting. Suppose the rubric shows six scored aspects and the task suggests roughly 2,200 words. Reserve 160 words to describe the organization, its systems and the decision being asked for, and 120 for the close, leaving 1,920 for six aspects, or 320 each. Weight by argument load: two aspects that require you to compare options and recommend need about 430 words each, while four aspects that require you to describe and apply need 265. Two at 430 plus four at 265 is 1,920 exactly, and the plan is ready before a sentence is written.
Keep one rule while filling it: every management claim needs a consequence attached. Saying an organization should adopt an issue-tracking tool is a preference. Saying it should adopt one because unlogged requests are currently invisible to capacity planning, and that a shared queue would make the backlog measurable, is an argument. The aspects reward the second consistently.
Shape for an information systems management report
C179 deliverables usually take the form of a report to a decision maker. These proportions fit that shape.
| Section | Content | Share |
|---|---|---|
| Organization and systems | What the business does, which systems support which processes, and who depends on each. | 11 percent |
| Problem statement | The management problem in one paragraph, framed in business impact rather than technical symptoms. | 9 percent |
| Development approach | Options for building or changing the system, what each assumes about requirement stability, and the recommendation. | 21 percent |
| Continuity analysis | Tolerance for data loss and downtime, the threats considered, and the measures that meet those targets. | 20 percent |
| Tracking and workflow | How work, incidents and changes are recorded, who owns each queue, and what the records are used for. | 15 percent |
| Cost and risk | What the recommendation costs, what it does not solve, and the residual risk being accepted. | 15 percent |
| Close | The decision in one paragraph plus the first action and its owner. | 9 percent |
Evidence for management claims
Management writing has a specific evidence problem: the claims are about people and organizations, and it is tempting to support them with assertion. Development approaches and continuity practices are documented in published standards, professional bodies of knowledge and recognised texts, and citing those is what turns an opinion into a position. Where you claim a general effect, such as how often projects overrun or what typical downtime costs, use published industry research and name the year, because these figures move.
Product claims are different again. If you recommend a class of issue-tracking tool, describe what the category must do and source capability claims from the vendor's own documentation rather than from a comparison site with an affiliate model. Keep the criteria ahead of the products in your document so the evaluator can see the reasoning drove the choice.
The most persuasive material in a report like this is usually the scenario's own detail. If the case describes 40 staff, two locations and a nightly batch process, use those facts in your continuity arithmetic instead of speaking generally about resilience. Applied specificity is what separates a report about this organization from an essay about business continuity.
Follow the citation style named in your task and put the citation where the assertion actually appears. Where you state a target such as an acceptable recovery time, mark clearly whether it came from the scenario or whether you are proposing it, since an assumed target presented as a given is the kind of slip that undermines a whole section.
Competent reports and returned ones
Competent submissions read like something a manager could act on. The problem is stated in business terms, options are genuinely different, recommendations name their costs, and continuity measures trace back to stated tolerances rather than appearing as a list of good practices.
Returns cluster in four shapes. The report describes systems at length and never reaches a recommendation. Continuity is answered with a generic list of backups and redundancy with no targets behind it. The development approach section explains methodologies in general without applying either to the scenario. Or every aspect is addressed and nothing is prioritised, leaving a decision maker with six equal recommendations and no first step.
A quick structural check catches most of that. Read only your topic sentences in order. If they form a coherent argument that ends in a decision, the report works. If they read as a series of definitions, the document is a summary rather than an analysis, and no amount of extra detail will fix that.
A returned performance assessment costs nothing in grade terms to rework, so completeness beats polish when you are deciding whether to submit, and treat the first submission as a way of buying exact feedback. If your version also uses an objective assessment, remember that WGU objective assessments are proctored: we prepare with structured study plans, practice questions and a candid read on your preassessment result, and we take no part during any assessment. We never ask for or handle portal credentials.
Report reading like a summary?
Send the C179 rubric and scenario. We turn the aspects into a headed argument with word targets and a decision at the end.
Seven mistakes that cost time in C179
- Working the wrong code. C179 is ITEC 2205 and D336 is ITEC 2113. Same title, different catalog entries. Only the one on your Degree Plan counts.
- Continuity without targets. Acceptable data loss and acceptable downtime are the two numbers every other continuity decision follows from.
- Methodology as preference. A development approach is a response to uncertainty. Justify it from the scenario's requirement stability, not from what you like.
- Recommendations with no cost. A proposal that does not say what it costs or what it leaves unsolved is not a management document.
- Undated industry statistics. Figures about project failure and downtime cost move constantly. Name the source and the year or leave the claim out.
- Products before criteria. Naming a tool first makes the whole selection look like preference, however good the tool is.
- No priority order. Six equally weighted recommendations are harder to act on than two ranked ones. Rank them.
Three questions students ask about C179
Is C179 the same as D336?
Do I need management experience to do well?
How technical should the writing be?
Where C179 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.