MGT2 is IT Project Management, listed in the WGU catalog under the CCN ITM 5000 and worth three competency units. The catalog describes it as Project Management Institute methodology applied through case studies to plan an information technology project. Two words in that sentence carry the course: applied and case. Applied means the methodology has to do work on something rather than be described. Case means your evidence is already supplied, and the strongest submissions are the ones that use the case's own names, numbers and constraints in every planning artifact instead of writing about projects in general.
Working a case instead of summarizing one
The commonest weak submission in this course opens with two paragraphs retelling the case. That is words spent on something the evaluator already knows. Start instead with what the case did not say and what you have decided about it, because planning is a series of decisions taken under stated assumptions.
Build a fact sheet from the case before drafting anything. Pull out everything that constrains the plan: dates, budget figures, staff counts, systems named, dependencies mentioned, stakeholders identified, and anything described as a problem. Then list the gaps, which are the things a planner would need and the case does not provide. Every gap becomes a stated assumption in your plan, and stated assumptions are what turn an invented number into a defensible one.
The applied test is easy to run on your own draft. Take any paragraph and ask whether it would survive being pasted into a plan for a completely different project. If it would, it is methodology description rather than application, and it is spending budget that the schedule, the risk register and the stakeholder analysis need.
Cases in this subject usually hide their real difficulty in a detail that reads as background. A sentence about a department that has already been through one failed rollout is a stakeholder resistance problem. A passing reference to a system nobody has documented is an integration and discovery problem. A stated deadline tied to a fiscal or contractual event is a hard constraint that changes what sequencing is possible. Read the case twice, once for facts and once for the difficulties nobody named, and mark them. Those marks become the most valuable content in your risk register, because they demonstrate reading rather than recall, and they are the parts a generic plan could never have produced.
Working from the scored aspects: estimation as the worked example
Schedules are where IT project plans get marked down, because students write single numbers with no derivation. Use a three-point estimate and show the arithmetic once, in the document, so the evaluator can see the method.
Take a work package such as building an integration between two systems. Optimistic is six days if the interface behaves as documented. Most likely is twelve days. Pessimistic is thirty days if the source system's data needs cleaning first. A weighted estimate that counts the most likely case four times gives you six plus forty-eight plus thirty, divided by six, which is fourteen days. Now do the same for the other packages. Suppose a plan of nine packages produces weighted estimates of 14, 8, 21, 5, 10, 16, 7, 12 and 9 days, totalling 102 days of effort. That single number lets you argue about the schedule instead of asserting it, and the spread between optimistic and pessimistic on the integration package tells you exactly where your largest risk lives.
For the writing budget, size sections by planning artifact rather than by aspect. If the rubric holds ten scored aspects across a charter, a scope and work breakdown, a schedule, a resource and cost plan, a risk register and a communication plan, give the schedule and risk sections the largest shares, because they are the two that carry the most scoreable reasoning and the two students routinely underwrite.
Where IT projects fail, and the plan element that catches it
| Failure mode | What it looks like | The plan element that catches it |
|---|---|---|
| Requirements churn | Scope grows quietly through informal requests | A change control process named in the plan, with an approver |
| Integration surprise | Two systems that were assumed to talk do not, or not cleanly | A discovery or spike task scheduled before the dependent work |
| Data quality | Migration or reporting fails because source data was never profiled | A data profiling package with its own duration and owner |
| Resource contention | Named specialists are committed elsewhere at the moment they are needed | A resource plan by person and period, not just by role |
| Testing compression | Testing absorbs every delay because it sits last | Test effort estimated as a proportion of build, protected in the schedule |
| Cutover and adoption | The system goes live and nobody uses it correctly | Training, support ramp and a defined cutover plan with a rollback |
| Vendor dependency | An external party controls a critical path task | Dependencies flagged with lead times and contractual escalation |
Evidence craft in a case-based planning course
Your primary evidence is the case itself, and using it well means quoting its specifics: the named system, the stated deadline, the budget figure, the department that objected. A plan that never uses a proper noun from the case has not been anchored to it.
Your secondary evidence is methodology, and it should be cited rather than paraphrased loosely. When you name a process group, a knowledge area, an estimation technique or a risk response strategy, use the term precisely and apply it in the same paragraph. Precision in this vocabulary is a visible marker of graduate work, and looseness in it is equally visible.
Every estimate needs its basis in the same sentence. Fourteen days, derived from a three-point estimate with the pessimistic case driven by data cleaning, is defensible. Fourteen days on its own is a guess. Use APA unless your task names another style, and where a diagram or table appears, number it and reference it in the text.
What separates Competent from a return
A performance assessment task passes at WGU when every scored aspect reaches at least a 2, and this course returns most often on two things. The first is the plan that could belong to any project: correct methodology, no case anywhere in it. The second is the risk register that lists risks without triggers, responses or owners, which satisfies an aspect asking you to identify risks and fails one asking you to manage them.
A third, quieter return is the work breakdown that stops too high. Packages described at the level of build the system cannot be estimated or assigned, so the schedule that follows is decorative. Decompose until each package has a duration you could defend and one person or role who owns it.
Performance assessment work at WGU can be revised and resubmitted without a grade penalty, so a return costs time rather than standing. Repair the named aspects, then check that any changed duration still adds up in the schedule and the cost plan.
Six mistakes that cost time in MGT2
- Retelling the case. The evaluator has read it. Spend the words on decisions instead.
- Single-point estimates. No derivation means no defensible schedule and no visible reasoning.
- Work packages too large to own. If nobody can be assigned to it, it is not a package.
- Risks without triggers or responses. Identification is the easy half; management is the scored half.
- Stakeholders listed, not analyzed. Influence, interest and what each one can block is the part that matters.
- Testing and cutover treated as afterthoughts. In IT projects these are where the schedule actually breaks.
How we work this course with you
Send the course code and your task instructions and you get back a fact sheet extracted from the case, an assumptions list for everything it leaves out, a decomposed work breakdown with three-point estimates shown, and drafting support across the planning artifacts so you can rebuild them in your own voice. Where an objective assessment sits on your plan, our contribution is preparation and nothing else. Objective assessments at WGU are proctored, so the help stops at scheduling: we never sit, take or assist during an assessment, and we never ask for or hold portal credentials.
Questions MGT2 students ask
Do I need to know certification-level project management content to pass?
How detailed should the work breakdown be?
How precise do the cost and duration numbers need to be?
Planning the MGT2 project?
Send the ITM 5000 task instructions and the case. A fact sheet and an estimated work breakdown come back.
Where MGT2 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.