Planview Projectplace: WBS Assignment
Create a workspace. Build a five-phase WBS. Add sub-deliverables and activities. Wire in dependencies. Set two phases to run in parallel — colored purple. Hit exactly 120 days total. Then screenshot everything for submission. Every one of those steps has a specific requirement that can cost you points if you get the sequence or the structure wrong. Here’s how to approach each one.
This assignment has a lot of moving parts. Workspace setup, a multi-level WBS, activity-level dependencies, parallel scheduling, duration adjustment, and a screenshot submission — all in one deliverable. The instructions are detailed, but it’s easy to miss a specific count requirement or build the hierarchy in the wrong order. This guide walks through each section and explains what to focus on so you’re not redoing work after the fact.
What This Guide Covers
What This Assignment Is Actually Testing
This isn’t just a software tutorial exercise. The WBS structure, dependency logic, and parallel scheduling requirements are all grounded in real project management principles from the PMBOK framework. Your instructor is checking whether you understand how a project breaks down into manageable components — and whether you can represent that breakdown correctly in a scheduling tool.
WBS Construction, Schedule Logic, and Project Phase Sequencing
A Work Breakdown Structure is not a to-do list. It’s a hierarchical decomposition of a project’s scope into deliverables — each level breaking the one above it into smaller, more manageable pieces. The activities at the bottom of that hierarchy are the work packages: discrete tasks that can be assigned, scheduled, and tracked. Getting the structure right — project at Level 1, phases at Level 2, sub-deliverables at Level 3, activities at Level 4 — is the conceptual core of this assignment. The Projectplace interface is the vehicle. The WBS logic is the point.
Why the dependency and parallel requirements matter: In real project scheduling, not everything runs sequentially. Some tasks must wait for others to finish (finish-to-start dependencies). Others can overlap or run simultaneously (parallel scheduling). The assignment specifically requires you to model both — sequential dependencies across all activities AND at least two deliverables running in parallel. That mirrors how actual project schedules are built in professional tools like MS Project, Primavera, and Planview.Setting Up the Workspace Correctly
The workspace setup has several specific fields — and each one carries a grading implication. This is the part most students rush through. Don’t. Getting the workspace configuration wrong means your instructor sees the wrong project name, the wrong department, or a missing scope description when they open your submission.
Name Format, Template, Start Date, Department, and Scope Description
Use the UniversityPPM Template — not any other template. This is explicitly required. The project name format is: Your Full Name – Course Code (example: Jamie Rodriguez – BADM-636). Use your actual full name as it appears in your course enrollment and your exact course code. A typo here is visible to your instructor from the moment they open the workspace.
Scope statement under “Short Description”: Two to three sentences. Treat this as a mini scope statement — it should describe what the project is, what it will accomplish, and its boundaries (what’s in scope). Don’t write a generic blurb like “This is my project for class.” Write something that describes the actual project you selected: its purpose, the primary deliverable, and the context. Two sentences that say something specific are better than three sentences that say nothing.Add your instructor as a member. This step is easy to skip because it doesn’t affect the WBS itself — but it determines whether your instructor can see your workspace at all. Go to Members → Invite → search by name → Send. If your instructor can’t access your workspace, your WBS doesn’t get graded.
The assignment instructions are explicit on this. Each course requires a unique project. Reusing prior work — even with minor modifications — is treated as plagiarism of your own prior submissions. Use a new project. If you used a retail implementation project in a prior course, pick a different project type here: an IT system rollout, an office relocation, a product launch, a construction project, a community event — anything distinct from your prior submissions.
Understanding the WBS Hierarchy in Projectplace
Before you add a single line to the Plan view, understand the four-level structure the assignment is asking you to build. If you start adding activities before the hierarchy is clear in your mind, you’ll end up with a flat list instead of an indented WBS — and restructuring it afterward is painful.
In Projectplace’s Plan view, indentation creates the hierarchy. When you add a new line and want it to be a child of the line above it, you indent it using the indent function (usually a Tab key or an indent button in the interface). Getting the indentation levels right is what makes the WBS readable and what creates the hierarchy the Gantt chart reflects. If everything is at the same indentation level, it’s a flat list — not a WBS.
Phase-by-Phase Deliverable Requirements
Each phase has a specific sub-deliverable count requirement. These counts are minimums, not targets — you can add more, but you can’t go below them. Here’s exactly what each phase needs.
Don’t Start From Scratch — Expand What You Already Submitted
Your execution deliverables should come directly from your prior discussion post. The assignment says “expand on them if applicable so that you have at least five sub-deliverables.” That means if your discussion post identified three execution deliverables, you need to break one or two of them into more specific sub-deliverables to reach five. Don’t invent new ones that contradict what you described in the discussion — build on what’s already there.
What counts as a sub-deliverable in Execute? A sub-deliverable is a specific, defined output — something that can be checked as “complete.” For a software implementation project, execution sub-deliverables might be: System Configuration, User Acceptance Testing, Staff Training, Data Migration, and Go-Live Deployment. Each is a tangible output with activities underneath it. If your execution sub-deliverables are too broad (like “Execute the Project”), break them down. If they’re too narrow (individual tasks), roll them up one level.Adding Activities Under Each Sub-Deliverable
Activities are at Level 4 — indented under each sub-deliverable. The requirement is at least two activities per sub-deliverable. Activities are action-oriented: they describe the work being done, not the deliverable being produced. “Develop project charter” is a sub-deliverable. “Draft initial charter document” and “Obtain sponsor sign-off” are activities under it.
How to Write Good Activity Names
- Verb + object format: “Conduct kickoff meeting,” “Review risk register,” “Obtain stakeholder approval”
- Specific enough to assign: Someone reading the activity should know exactly what work needs to happen
- Small enough to estimate: If an activity would take weeks by itself, it’s probably a sub-deliverable in disguise — break it down further
- Distinct from each other: Two activities per sub-deliverable shouldn’t describe the same work differently — they should represent genuinely different tasks
Minimum Activity Count Check
Count up your sub-deliverables before adding activities. Initiate: 1 sub-deliverable = 2 activities. Planning: 5 sub-deliverables = 10 activities minimum. Execute: 5 sub-deliverables = 10 activities minimum. That’s 22 activities at the absolute floor — before you even account for any additional sub-deliverables you add. Make sure your Plan view reflects those numbers before moving to dependencies. Adding activities after dependencies are wired in is considerably more work.
Setting Up Dependencies Correctly
Dependencies go on activities only — not on sub-deliverables or phase headers. The rule is clear: every activity except the first one needs a predecessor, and every activity needs a successor. “All activities except the first have a predecessor and all have a successor” is the exact check the assignment gives you. Run that check before you take screenshots.
Every Activity Is Wired In — No Orphan Activities, No Dead Ends
In Projectplace’s Plan view, dependencies are shown as arrows connecting activities in the Gantt chart. A finish-to-start dependency means Activity B can’t start until Activity A finishes. When every activity is connected — arrows going both in and out — the Gantt chart shows a continuous chain of work from project start to project end. Activities with no incoming arrow are orphaned (except the very first). Activities with no outgoing arrow are dead ends (except the very last).
The visual check the assignment describes: “You can check this by making sure all work packages have an arrow going into and out of them.” In the Gantt view, look at each activity bar. An arrow pointing into it means it has a predecessor. An arrow pointing out of it means it has a successor. If you see a bar with no incoming arrow (other than the first activity), that dependency is missing. Fix it before screenshotting.Cross-phase dependencies: The last activity of one phase should be a predecessor to the first activity of the next phase — unless two phases are running in parallel. This connects the phases sequentially and ensures the Gantt reflects realistic project flow, not a disconnected series of phase islands.
| Activity Position | Predecessor Required? | Successor Required? | Note |
|---|---|---|---|
| First activity in the project | No | Yes | The only activity that can start without a predecessor |
| All middle activities | Yes | Yes | Must have both; this is the check criterion in the assignment |
| Last activity in the project | Yes | No | The terminal activity — no successor needed |
| Parallel activities | Yes — shared predecessor | Yes | Both activities share the same predecessor and both must have successors |
Parallel Activities and the Purple Color Rule
This is the requirement most students mishandle — either by not actually making the activities run in parallel, or by coloring the wrong elements purple, or by forgetting to color them at all.
Same Predecessor, Overlapping Timeline — Not Just Two Activities Near Each Other
Parallel activities run at the same time. In dependency terms, two activities are parallel when they share a common predecessor — Activity A finishes, and both Activity B and Activity C can start simultaneously. In the Gantt chart, parallel activities show as bars that overlap in time rather than running end-to-end in sequence. If your parallel activities are running sequentially (one after the other), they’re not actually parallel — the dependency structure is still sequential.
How to set this up in Projectplace: Identify two sub-deliverables (or two activity groups) that could realistically run at the same time in your project. Give both of them the same predecessor. Their Gantt bars should now overlap in time. Then select those activities and change their color to purple using the color option in the Plan view. The purple color is a visual marker for the grader — it’s how they confirm you’ve identified and modeled the parallel activities intentionally.Which deliverables make sense as parallel? Common examples: in the Planning phase, budget development and risk identification could run in parallel since they don’t depend on each other. In Execute, procurement and site preparation might run simultaneously. Pick deliverables within your project that don’t have a logical dependency on each other — where one doesn’t have to finish before the other can start.
First: they must actually be scheduled in parallel — same predecessor, overlapping Gantt bars. Second: they must be colored purple in the Plan view. Both parts need to be visible in your screenshot. A purple activity that’s still running sequentially doesn’t satisfy the requirement. A parallel activity that isn’t colored purple doesn’t stand out for grading. Both the scheduling and the color need to be correct.
Adjusting to Exactly 120 Days
Your project needs to span exactly four months — 120 days total from the first activity’s start date to the last activity’s end date. If your actual project would naturally be shorter or longer, you adjust the durations to hit that target. The assignment says this explicitly: “If your actual project was more/less, just adjust for the purpose of the assignment.”
Check Your Current Total Duration First
Before adjusting anything, look at your Gantt chart and note the start date and the end date of the entire project. The difference between those two dates is your current total duration. If it’s already close to 120 days, minor tweaks to individual activities will get you there. If it’s significantly off, you’ll need to proportionally scale durations across phases.
Distribute Duration Across Phases Proportionally
A typical project management framework allocates roughly: Initiate (5–10%), Planning (15–25%), Execute (50–60%), Monitor/Control (ongoing), Close (5–10%). For a 120-day project, that’s approximately: Initiate = 7 days, Planning = 25 days, Execute = 75 days, Close = 13 days. Use these as starting points and adjust until your total hits exactly 120. The exact distribution matters less than the total being correct.
Parallel Activities Don’t Add to Sequential Duration
This is where students frequently miscalculate. If two activities run in parallel and each takes 10 days, they contribute 10 days to the total project duration — not 20. Sequential activities stack. Parallel activities don’t. Keep this in mind when summing your durations to check the 120-day target.
Verify in the Gantt View Before Screenshotting
After adjusting durations, open the Gantt chart and confirm the start and end dates. Check that the project spans the right range from the start date you entered in the workspace setup. If activities are overlapping in ways that compress the timeline unexpectedly (due to parallel scheduling), that will show up here — adjust activity durations accordingly until the Gantt reads 120 days start to finish.
Screenshots and Submission
The submission requires two screenshots: one of the WBS (Plan view, fully expanded) and one of the Gantt chart. Both must show duration and start dates. Both go into a Word document. This seems straightforward — but the “fully expanded” requirement is where submissions frequently fall short.
Every Level Visible — No Collapsed Sections
Fully expanded means all four levels of the WBS are visible: project name, phases, sub-deliverables, and activities. If any phase or sub-deliverable is collapsed (showing a collapsed arrow), the screenshot doesn’t show your complete work. Expand every section before capturing. The Plan view should show every single line of your WBS — phases, sub-deliverables, and activities all open.
Multiple screenshots are fine and expected. The assignment explicitly says “You may need to take multiple screen shots if needed.” If your WBS is long enough that it doesn’t fit in one screen, scroll down and take additional captures. Label them clearly in the Word document (e.g., “WBS — Part 1,” “WBS — Part 2,” “Gantt Chart”) so your instructor can follow the sequence. Don’t try to shrink the view to fit everything in one screenshot — the text becomes unreadable and the grader can’t verify your counts or dates.What the Gantt screenshot must show: Activity bars, start dates, durations, and the dependency arrows connecting them. Make sure the date range visible in the Gantt covers the full 120-day project span. Zoom out if needed so the entire project timeline is visible, not just the first few weeks.
Mistakes That Cost Points
Building a Flat List Instead of a Hierarchy
All items at the same indentation level in the Plan view means no hierarchy — just a list. The WBS structure requires four distinct indentation levels: project, phases, sub-deliverables, activities. If everything is at level one in the tool, there’s no WBS.
Set Up the Hierarchy Before Adding Content
Add your project name first. Then add the five phase names indented under it. Then add sub-deliverables indented under each phase. Then add activities indented under each sub-deliverable. Build top-down, one level at a time, before worrying about names or durations.
Missing the Instructor as a Member
A workspace your instructor can’t access is a workspace they can’t grade. This step is easy to forget because it’s done before the WBS work — and then it’s never revisited. If your instructor reports they can’t see your project, it’s almost always this step.
Add the Instructor Immediately After Workspace Creation
As soon as the workspace is created and named correctly, go to Members → Invite before touching the Plan view. Get that step done first so it can’t be forgotten while you’re focused on the WBS work.
Adding Dependencies to Sub-Deliverables Instead of Activities
The assignment says dependencies go on activities — the Level 4 work packages. Wiring dependencies between sub-deliverables or phases creates a structurally incorrect schedule and won’t produce the activity-level Gantt chart the assignment requires.
Dependencies Go on Activities Only
Scroll to the bottom of each sub-deliverable in your Plan view. The activities (Level 4 items) are where you add predecessors and successors. Not the sub-deliverable lines. Not the phase lines. Activities only.
Parallel Activities That Are Still Sequential in the Gantt
Coloring two activities purple without actually giving them a shared predecessor doesn’t make them parallel. If one still finishes before the other starts in the Gantt, they’re sequential — the color is just decoration on a broken requirement.
Verify the Gantt Shows Overlap Before Coloring
After setting the shared predecessor, check the Gantt chart. If the two parallel activities show as overlapping bars on the timeline, the scheduling is correct. Then color them purple. The Gantt is the truth — if it shows sequential execution, the dependency structure needs fixing regardless of what color the activities are.
Submitting Collapsed Screenshots
A screenshot of a WBS where Planning is collapsed to one line and Execute is collapsed to one line doesn’t show sub-deliverables or activities. The grader can’t count your work or verify the structure. Collapsed screenshots often result in partial credit at best.
Expand Everything and Take Multiple Screenshots If Needed
Use keyboard shortcut or the expand-all option to open every level before capturing. If the full WBS doesn’t fit in one screen, take two or three. A set of clear, readable partial screenshots is always better than a single illegible screenshot of the full WBS compressed to thumbnail size.
Frequently Asked Questions
Need Help With Your Projectplace WBS Assignment?
WBS structure, dependency mapping, Gantt chart development, and full project management assignment support — our team works with students across all PM course levels.
Project Management Services Get StartedBefore You Open Projectplace
Watch the three videos first. All three — Introducing Projectplace, Getting Started, and the Assignment 1 video. Students who skip the videos and jump straight into the tool end up discovering how to use features mid-task, which means rebuilding things that were set up incorrectly the first time. The videos are short. The rework isn’t.
Map out your WBS on paper before you touch the Plan view. Seriously. Write down your project name, your five phases, your sub-deliverables per phase, and a few activity names per sub-deliverable. Count them. Make sure you hit the minimums before you start clicking. Fixing hierarchy structure in a project management tool after dependencies have been added is time-consuming. Building it correctly the first time takes fifteen minutes on paper and saves an hour in the tool.
The purple parallel activities are the one visual element your grader specifically looks for. Don’t leave them to the end. Set up your two parallel deliverables, confirm the Gantt shows them overlapping, and color them purple as part of your dependency work — not as a last-minute addition. By the time you’re adjusting durations to hit 120 days, your structure, dependencies, and colors should all already be in place. Duration adjustment is the final step — not the middle one.