E014 Problem Solving for Technology Business Problems carries banner number ITEC 5301 and is worth 2 competency units. It teaches step-by-step frameworks for pinpointing causes and developing solutions to business problems such as technology inefficiencies and process improvement opportunities. E014 and ITEC 5301 are one requirement. Its whole value is the discipline of not jumping to a solution, which is the single most expensive habit in technology work.
Define the problem before anyone proposes anything
Technology organizations solve the wrong problem constantly, and almost always because the problem statement was skipped. Someone reports that a system is slow; a project starts to replace it; eighteen months later the replacement is also slow because the actual constraint was a nightly job nobody examined. The frameworks in this course exist to slow that first step down: state the problem in measurable terms, establish what is actually happening before deciding why, and separate symptom from cause explicitly.
Root cause techniques are the operational core. Repeatedly asking why moves from symptom toward mechanism. Cause and effect diagrams spread the search across categories so it is not confined to the first plausible explanation. Comparative analysis asks what is different between the cases where the problem occurs and those where it does not, which is frequently the fastest route to an answer. Each has a shape and each rewards being finished rather than abandoned at the first satisfying answer.
Solution development is the second half and it has its own discipline. Generating several genuinely different options before evaluating any of them prevents the common failure where the first idea becomes the plan and everything after it is justification. Criteria should be written before options are compared, or the criteria will quietly be shaped to fit the preferred answer.
Implementation and verification close the loop. A solution proposal that does not say how you would know the problem was solved has left the most important part unspecified, and in a course about problem solving that omission is conspicuous.
Work here returns Competent or Not Competent, since WGU issues no letter grades and holds no ordinary grade point average, and the 2 competency units measure course size within a six month term sold at one price. Two competency units inside a flat-priced six month term makes this a good course to close early alongside a heavier one.
Turning a small rubric into a rigorous analysis
If your version of E014 uses a performance assessment, expect a compact rubric where each aspect carries real weight. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a strong root cause analysis will not carry an unaddressed evaluation or implementation aspect.
Budget carefully. Take a rubric with five scored aspects and a target near 1,500 words. Reserve 120 words for the business situation and 90 for the close, leaving 1,290 across five aspects, or 258 each. Weight by demand: two aspects requiring the cause analysis and the option evaluation take 360 each, which is 720; the three remaining aspects, covering problem definition, implementation and verification, take 190 each, which is 570. Together that is 1,290.
Write the problem statement in measurable terms and then check that every later section refers back to that measure. If your problem is stated as a 40 percent increase in ticket resolution time, then your cause analysis explains that increase and your verification measures that same number. Documents that change measure midway lose the thread and the aspects with it.
Reserve budget for the option you rejected. Two developed alternatives with a stated comparison is worth more than one recommendation with three straw options beside it, and the comparison is usually where the analytical aspects are scored.
Shape for a problem solving analysis
E014 deliverables usually analyse a business problem and recommend a solution. These proportions fit a compact document.
| Section | Content | Share |
|---|---|---|
| Situation | The organization, the process affected and who is experiencing the problem. | 11 percent |
| Problem statement | What is wrong, in measurable terms, with the gap between current and desired state. | 14 percent |
| Data gathering | What evidence you used to establish what is happening, before asking why. | 14 percent |
| Cause analysis | The technique applied, worked through, with causes ruled out as well as in. | 22 percent |
| Options and criteria | Criteria stated first, then two or more real options measured against them. | 20 percent |
| Recommendation and implementation | The choice, the steps, the owner and the resources required. | 13 percent |
| Verification | The measure that would confirm the problem is solved, and when you would check. | 6 percent |
Evidence in a problem solving document
Framework descriptions belong to published sources on problem solving and process improvement, cited properly, because the techniques have defined shapes and using one loosely produces analysis that looks methodical without being so.
The strongest evidence in this course is usually data from the scenario. Ticket counts, cycle times, error rates and cost figures given in the case should appear in your problem statement and again in your verification section. Where the scenario provides numbers and your analysis does not use them, an evaluator will notice.
Where you infer a cause, distinguish between causes you established and causes you suspect. A cause supported by a pattern in the data is different from one that is plausible but untested, and saying which is which is a mark of analytical honesty rather than weakness.
Cost and benefit estimates should show their components. Even rough figures become usable when the reader can see what was multiplied by what, and in a short document a small table does this more efficiently than prose.
Cite in whatever style your task sets out and put the citation where the assertion actually appears.
Competent analysis and returned work
Competent submissions state the problem measurably, gather evidence before diagnosing, work a technique through to completion, evaluate real alternatives against stated criteria, and specify how success would be verified.
Returns follow four shapes. The problem statement is qualitative, so nothing later can be measured. The cause analysis stops at the first plausible explanation. Options are compared against criteria invented after the choice was made. Or verification is missing, leaving a recommendation nobody could evaluate.
Stakeholder involvement is worth a short section even where no aspect names it. The people closest to a process usually know its real constraints, and a cause analysis conducted entirely from documentation tends to miss the workaround everyone uses and nobody wrote down. Saying who you would talk to, what you would ask them and how you would guard against simply adopting the loudest opinion shows an understanding of how these methods behave outside a textbook.
Implementation risk also belongs in the recommendation. A solution that requires a behaviour change is harder to land than one that changes a system, and one that requires several teams to coordinate is harder again. Naming the biggest obstacle to your own recommendation, and saying how you would address it, is the paragraph that turns an analysis into a proposal someone could act on.
A quick test: cover your recommendation and read the analysis. If the recommendation is not obvious from what precedes it, either the analysis is incomplete or the recommendation came from somewhere other than the analysis. Both are worth fixing before submission.
Performance assessment work can be revised and resubmitted with no grade penalty, so submit as soon as every aspect has a real answer, and treat the first submission as a way of buying exact feedback. If your section also carries an objective assessment, WGU objective assessments are proctored and our boundary is fixed: preparation only, with framework drills, cause analysis practice and a candid read on your preassessment result. We do not sit exams for anyone, are absent for the whole of it, and we neither ask for nor accept portal credentials.
Solution arrived before the analysis?
Send the E014 rubric and scenario. We rebuild it from a measurable problem statement through a completed cause analysis, with word targets.
Eight mistakes that cost time in E014
- Jumping to a solution. The framework exists to prevent exactly this, and skipping it is visible in every later section.
- Qualitative problem statements. If the problem has no measure, success cannot be verified.
- Stopping at the first cause. Finish the technique. The satisfying answer is frequently a symptom one level down.
- Criteria written after the choice. Write them first or the comparison is decoration.
- Straw alternatives. Options that are obviously unusable give the evaluation aspect nothing to score.
- Ignoring scenario data. Numbers in the case exist to be used in both diagnosis and verification.
- Suspected causes stated as established. Say which you tested and which you inferred.
- No verification. A solution with no success measure cannot be judged, which is fatal in a problem solving course.
- Skipping the people closest to the process. The undocumented workaround everyone relies on is invisible from documentation alone.
Three questions students ask about E014
Which problem solving framework should I use?
Is 2 CUs enough for a real analysis?
Can I use a problem from my own workplace?
Where E014 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.