Project+ hands-on work does not require expensive project-management software. A spreadsheet, document editor, calendar, Kanban board and one realistic IT scenario can cover most of the current PK0-005 objectives. The practical goal is to create and maintain the artifacts that keep a project aligned while requirements, people, risks and technical dependencies change.
Lab one: write a business case and project charter
Choose a small IT project such as deploying MFA, moving a team to SaaS, replacing a server or launching a help-desk platform. Write the problem, expected benefit, sponsor, high-level scope, assumptions, constraints, budget/time target and success criteria.
Then create a short charter that formally authorizes the project and project manager.
Lab two: identify stakeholders and communication needs
List sponsor, users, technical team, security, operations, vendor, finance/procurement and any compliance stakeholders. Map influence/interest and create a communication plan with audience, message, channel, frequency and owner.
A stakeholder-engagement exercise should reveal that different people need different information.
Lab three: build requirements and a WBS
Gather a small set of functional, technical, security and operational requirements. Define acceptance criteria and break deliverables into manageable work packages.
Use a scope-and-WBS structure so the team knows what is inside and outside the project.
Lab four: create a schedule with dependencies
Estimate tasks, link predecessors/successors, mark milestones and identify the critical path. Add one task with float and one scarce technical resource.
Then delay a non-critical task and a critical-path task to observe the difference in project impact.
Lab five: create risk, issue and change logs
Record at least five risks with probability, impact, response and owner. Turn one risk into a live issue, record an action and escalation path, and submit one formal change request.
Perform impact analysis against scope, schedule, cost, resources and quality before approving the change.
Lab six: build a RACI and resource plan
For major deliverables, assign Responsible, Accountable, Consulted and Informed roles. Compare the matrix with the resource schedule.
If one person is responsible for too many critical tasks, the RACI may reveal a staffing or schedule risk before execution begins.
Lab seven: manage a vendor/procurement task
Create a simple statement of need and compare RFI, RFP and RFQ use. Define selection criteria, cost, schedule, service levels, security/privacy obligations and acceptance.
A procurement exercise teaches that vendor work still needs scope, risk, communication and contract management.
Lab eight: run a status meeting and report
Prepare an agenda, facilitate a 15-minute mock meeting, record decisions/actions and publish a one-page status report with accomplishments, next work, milestones, budget, risks/issues and changes.
Use status reporting to practice concise escalation instead of turning the report into a task transcript.
Lab nine: simulate transition and closure
Obtain acceptance, transfer documentation to operations, verify training/support readiness, close vendor work, release resources, archive artifacts, reconcile budget and capture lessons learned.
Closure should confirm that the intended business outcome was delivered and ownership after the project is clear.
Lab ten: introduce an IT governance surprise
Late in the project, add a new privacy, security or change-management requirement. Decide which stakeholders must review it, whether scope changes, what risk is created and how transition plans change.
Add a project-methodology comparison to the lab. Run the same software rollout as a predictive plan with an approved baseline and as an agile backlog with short iterations. Note which artifacts change and which fundamentals—stakeholders, risk, budget, quality, communication—remain necessary.
Add a dependency-network exercise. Draw tasks as nodes and connect predecessors/successors, then identify the longest critical path and one activity with slack. Change a duration and observe whether project completion moves. This is more useful than memorizing critical-path terminology without a schedule.
Add a simple estimate exercise using analogous, parametric or three-point thinking conceptually. Compare a quick estimate based on a prior project with a more detailed bottom-up estimate. Record assumptions because estimates without assumptions are difficult to revise intelligently.
Add a budget-versus-actual table. As the mock project progresses, record committed vendor cost, labor estimate, actual spend and forecast. Introduce one approved scope change and update the budget baseline so later variance remains meaningful.
Add a quality-control exercise with a small deliverable. Define acceptance criteria, test the deliverable, record defects and re-test after correction. Then distinguish quality assurance actions that improve the process from quality-control actions that examine the output.
Add a change-control board tabletop. Give the group three requests: one high-value urgent change, one low-value feature, and one compliance requirement. For each, analyze impact, urgency, authority and baseline updates. The point is disciplined decision-making, not automatically rejecting change.
Add a communication failure deliberately. Leave one stakeholder out of an early decision, then observe which assumption or rework appears later. Update the communication plan and stakeholder register. This demonstrates why stakeholder management is a project control, not a courtesy.
Add a risk-trigger exercise. Define a risk such as vendor delay with a trigger date. When the trigger occurs, execute the contingency and convert the condition to an issue if necessary. This creates muscle memory for the difference between a future uncertainty and a current problem.
Add a vendor-evaluation scorecard. Score price, capability, schedule, service levels, security/privacy, references and contractual risk. Then choose a vendor and record the decision rationale. Procurement decisions should be traceable rather than based on the lowest quote alone.
Add a requirements-traceability matrix for five requirements. Connect each requirement to a deliverable, test/validation method, owner and acceptance status. Change one requirement and observe which downstream artifacts need updates. This is a practical way to see the cost of scope change.
Add an agile board with backlog, work-in-progress limits, completed items and one blocked task. Compare the board with a Gantt-style schedule. Each tool communicates different information; Project+ expects candidates to know when each is useful.
Add a governance gate before production release. Require security approval, privacy review, change-management approval or operational readiness depending on the project. Record who owns the gate and what evidence they need. IT projects frequently fail because governance is discovered too late.
Add a transition-to-operations checklist containing ownership, support contacts, monitoring, runbooks, backups, licenses, access, known issues, training and warranty/vendor information. Have an “operations” reviewer reject the handoff until required items are complete.
Add a lessons-learned session that captures both positive and negative lessons. Convert at least one lesson into a reusable template or checklist change. A lesson that is stored and never changes future behavior has little organizational value.
Add a final project audit. Check that the charter, scope, requirements, schedule, budget, risks, issues, changes, communications, quality evidence, procurement, acceptance and closure records tell one consistent story. Contradictory artifacts are a sign that project control broke down.
Finish by presenting the project in five minutes to an executive and then in ten minutes to the delivery team. The executive version should emphasize value, status, risk and decisions; the team version should emphasize work, dependencies and actions. This tests whether communication is tailored to stakeholder need.
Add a dashboard exercise using simple indicators for schedule, cost, risks, issues and milestones. Define what red, amber or green means before updating the dashboard. Without agreed thresholds, traffic-light reporting becomes subjective and can hide deteriorating project health.
Add a decision log. Record one architectural choice, one vendor choice and one scope trade-off with date, decision owner, alternatives and rationale. Months later, the log should explain why the team chose a path without relying on memory or old chat messages.
Add a dependency handoff between teams. One infrastructure task must finish before an application team can start. Define the acceptance criteria for the handoff, responsible owners and escalation path. This teaches that a predecessor is not complete merely because its task bar reaches 100%.
Add a project health review midway through the mock project. Compare actual state with baseline, review top risks/issues, assess stakeholder sentiment, verify upcoming dependencies and forecast completion. Decide whether corrective action or formal change is necessary before the situation becomes a crisis.
Add a retrospective or lessons-learned workshop before formal closure, especially for an agile or hybrid project. Ask what should start, stop and continue, then convert one learning into a template, checklist or standard for future teams. Improvement should survive the project.
Finally, keep the applied practice artifacts lightweight and coherent. Project+ does not require a large PMO bureaucracy. The strongest portfolio is a small set of current documents that clearly show why the project exists, what will be delivered, who owns work, when it happens, what threatens it and how completion will be accepted.
Add a simple earned-value-style interpretation exercise without turning the lab into advanced PMP study. Compare planned work, completed work and actual cost conceptually and decide whether the project appears ahead/behind schedule or over/under budget. The purpose is reading project health, not memorizing complex formulas.
Add a project-closure presentation to the sponsor that summarizes objectives achieved, final cost/schedule, major changes, unresolved follow-up, transition status and lessons learned. Then obtain formal acceptance. This makes closure an accountable business decision rather than a silent stop in activity.
Keep copies of the final artifacts as a mini project portfolio. A complete packet containing charter, stakeholder/communication plan, WBS, schedule, logs, RACI, vendor decision, status report, acceptance and lessons learned gives you a concrete reference for nearly every PK0-005 scenario and artifact question.
The current Project+ role is valuable because IT projects are rarely pure scheduling exercises. Applied practice should show that project coordination, governance and technical context have to work together.