3.2: Plan of Attack
- Page ID
- 49219
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\dsum}{\displaystyle\sum\limits} \)
\( \newcommand{\dint}{\displaystyle\int\limits} \)
\( \newcommand{\dlim}{\displaystyle\lim\limits} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\(\newcommand{\longvect}{\overrightarrow}\)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)Plan of Attack
Milestone 2 – Chapter 2
Title: Project Scope, Architecture, Approach, Deliverables, and Structure
Client Context: UCMS System Modernization
Role: Planning Consultant at C-Bay Inc.
Textbook: Project Planning and Control: A Practicum
Milestone Purpose
You’ve completed the Charter, aligning the client and your planning team on purpose, goals, and early risks. Now begins the deeper strategic phase of project structuring.
In this milestone, your responsibility is to architect the project itself:
- What will be built
- How it will be built
- Who will be responsible
- What major checkpoints define progress
- And how your client (UCMS) can trust the process from start to finish
This chapter requires strategic writing, systems thinking, planning leadership, and clarity of structure. You’re building the scaffolding for everything that follows.
Structuring the Work: What You’ll Create
Your final output will contain five sections in this exact sequence:
- Project Scope
- Architecture Overview
- Project Approach
- Project Deliverables
- Project Organizational Structure
Each section should be presented as if it were going to UCMS for approval. That means no placeholder language, no vague statements, and no filler. Each decision must be justified and aligned with client needs.
What You Will Do in Each Section
1. Project Scope
What it is:
This section defines the actual work to be performed. It clarifies what the project will include, what it will deliver, and what is out of scope.
What you’ll do:
- Use the charter as a foundation
- Expand on scope to include technical development, integration, testing, and rollout
- Declare exclusions (what the project will NOT do)
- Reference any client dependencies or assumptions
Goal: Define a scope statement that supports effort estimation, stakeholder agreement, and future scheduling.
2. Architecture Overview
What it is:
A conceptual description of the future system—the components, modules, integration points, and how users interact with it.
What you’ll do:
- Identify major features or modules (e.g., scheduling, reporting, user roles)
- Explain how those modules will interact with each other and with external systems
- Describe interface types (browser, admin tools, offline sync)
- Include assumptions (e.g., integrations to be handled by internal UCMS team)
Goal: Demonstrate architectural-level thinking without needing technical documentation. Show the client that you can see the whole system, not just parts.
3. Project Approach
What it is:
The delivery strategy—the model or methodology your team will use to manage planning, design, development, and deployment.
What you’ll do:
- Choose a primary approach (e.g., hybrid, phased, agile)
- Justify why it fits this client and project
- Define key phases (e.g., Inception, Elaboration, Construction, Transition)
- Clarify when the client will be involved
- Present a fallback strategy if the preferred method becomes unworkable
Goal: Inspire confidence that the delivery method is both structured and flexible—adapted to the UCMS environment.
4. Project Deliverables
What it is:
A structured list of all major outputs the project will produce and the milestones that define progress.
What you’ll do:
- List each milestone (e.g., Charter, Architecture Spec, Release Candidates, QA Signoff)
- Define who originates it and who approves it
- State completion criteria for each
- Group deliverables into phases if helpful
- Describe dependencies and success conditions
Goal: Build visibility into what UCMS will receive, when, and why it matters.
5. Organizational Structure
What it is:
The team design for execution. Who’s doing what, who reports to whom, and how governance flows.
What you’ll do:
- Define roles (e.g., Project Manager, Architect, QA Manager, Business Analyst)
- Group roles into units (e.g., PMO, Development, QA, Client Stakeholders)
- Specify who holds decision authority
- Describe how escalation and communication happen
- Reference any external parties (e.g., vendor teams)
Goal: Show how your team is designed for coordination, responsibility, and rapid issue resolution.
Key Skills You’ll Practice
- Strategic writing and systems thinking
- Justifying planning decisions in a client-facing voice
- Creating alignment between scope, structure, and sequencin
- Demonstrating technical awareness without overpromising
- Building an execution system—not just a document
Submission Expectations
Each section should be:
- Professionally formatted and clearly labeled
- Written as if submitted to the UCMS leadership team
- Structured to stand alone (each section must be understandable on its own)
- 1–2 pages per section (may vary depending on diagrams or tables)
- Fully aligned to your Project Charter and assumptions
You may include visuals (optional), but your writing must carry the argument.
All five sections should be submitted together as one milestone package, labeled as:
UCMS_Project_Structure_YourLastName.docx