Project

Team Charter: Grey, Timothy, and Spencer

Communication Plan

Grey will be responsible for the Communication Plan. Our team will coordinate primarily through email and group chat to ensure rapid responses and accountability. Weekly virtual meetings will be held to track progress, clarify responsibilities, and discuss challenges. All updates and meeting notes will be stored in a shared document repository for transparency.

Conflict Management Plan

Grey will also be responsible for the Conflict Management Plan. In cases of conflict, the first step will be direct communication between the involved parties. If unresolved, the issue will be escalated to the team as a whole during scheduled meetings. For non-responsiveness, a reminder will be sent after one day, followed by escalation to the professor if no communication occurs within three days. Emergency situations will be accommodated by redistributing tasks.

Document Management Plan

Spencer will manage the Document Management Plan. All team documents will be stored in a central shared drive (e.g., Google Drive or OneDrive) with clearly labeled folders for drafts, finalized documents, and reference materials. Version control will be maintained by including dates in file names and only one person at a time making edits to avoid conflicts.

Quality Plan

Spencer will also oversee the Quality Plan. All documents and deliverables will undergo peer review by at least one other team member before submission. Formatting will follow APA guidelines, and a standardized template will be used to maintain consistency. Final review sessions will be conducted prior to submission to ensure accuracy, completeness, and professionalism.

Roles & Responsibilities

Timothy will lead the Roles & Responsibilities section. Work will be divided among the team to ensure balanced workload distribution. Grey will handle Communication and Conflict Management, Spencer will oversee Document Management and Quality, and Timothy will coordinate overall team responsibilities and finalize role assignments. A fictitious customer role will be assumed by one designated team member to provide realistic project dynamics, and this role will be rotated if necessary. Everything will be completed on or before 1 September 2025.

Quality Plan

Purpose and quality objectives

Our goal is to deliver a four-page Team Charter that is fit for purpose and meets stakeholder expectations: clear, complete, consistent, and aligned to the assignment brief. In PMBOK 7e terms, quality activities should both move the deliverable quickly to the point of delivery and prevent or catch defects early to avoid rework, while aligning with explicit acceptance criteria. 

Acceptance criteria and “Definition of Done”

The assignment’s Quality Plan must ensure the final submission:

1. addresses all five required charter elements and fits within four double-spaced pages;

2. demonstrates high-level integration of PMBOK 6e Integration and Scope processes and PMBOK 7e principles;

3. uses consistent voice, APA citations, and polished mechanics; and

4. evidences a coherent team process (communication, conflict handling, roles). We will operationalize these through a simple Definition of Done checklist that includes content coverage, style/format checks, and evidence that deliverables have been “verified” and then “accepted,” consistent with the path from Control Quality to Validate Scope and into Close Project or Phase. 

Standards and sources of truth

Content must reflect the required readings: PMBOK 6e (Scope 5.1–5.6 at the appropriate high-level depth), PMBOK 7e Delivery Performance Domain (focus on value, deliverables, DoD), and the Team Charter instructions (Quality Plan and Document Management Plan expectations). 

Quality assurance (build quality in)

Given our dispersed schedule (Grey in Japan/Philippines; Timothy in Tennessee; Spencer ramping up mid-week), we will design the workflow to surface issues early, reducing the cost of change. Each contributor drafts against the DoD by  Monday 12:00 Eastern (which is  00:00 Tuesday PHT and  01:00 Tuesday JST), enabling an early integrated review and defect prevention before we’re forced into costly late edits. 

Practices:

•  Calibrated outline tied to the assignment rubric and readings before drafting (prevents scope and quality drift).

•  Peer dialog in Signal for ambiguities and edge cases; quick decisions reduce “done drift.” 

Quality control (verification and acceptance)

We will use a two-gate approach:

•  Gate 1 – Verification: Monday consolidated draft is checked against the DoD, assignment guidelines, and references (content coverage, flow, APA, mechanics).

•  Gate 2 – Acceptance: A designated “customer” proxy performs a final acceptance read. This mirrors PMBOK’s flow from verified deliverables (Control Quality) to accepted deliverables (Validate Scope). 

Customer proxy: Assign Spencer as the acceptance authority for this charter (he offered to take on larger sections and is assembling pieces). The instructor remains the ultimate customer; Spencer acts as our internal proxy for formal acceptance before submission. (This also satisfies the “customer role” requirement.) 

Metrics, thresholds, and escalation

We will track three simple measures: a) completeness (all required elements present), b) conformance (APA/style/format), and c) coherence (logical flow across sections). Threshold: zero critical gaps; minor style issues acceptable if corrected by Tuesday morning. If Gate 1 uncovers material gaps, the section owner has a two-hour window to remediate; if not feasible, the compiler makes targeted edits. This satisfies the Quality Plan line items in the Team Charter Guidelines. 

Interface with Scope management

Our quality controls reinforce scope discipline: we will  Validate Scope by comparing the assembled draft to the scope baseline implied by the charter instructions; any material scope change triggers a quick change decision in Signal (major change = consensus vote; minor edit = editor decision). 

Knowledge capture

After submission, we log two lessons learned: one process improvement and one content insight, to seed the course repository. This aligns to Manage Project Knowledge in the weekly lecture. 

Document Management Plan

Repository and single source of truth

We will use a shared Google Docs folder as the  authoring space and maintain a  Master Charter document as the single source of truth. Only the compiler edits the Master directly; contributors draft in their own files and paste into the Master during the integration window. This prevents collisions when “multiple team members contribute to the same document” and preserves integrity, per the Charter Guidelines. 

Access: All teammates (Grey, Timothy, Spencer, plus the fourth member if they appear) have edit access; the compiler owns the folder and ensures backups.  Communications: Signal remains the rapid channel for coordination (already established in the thread). Meeting minutes, if any, are short and posted to the group space, as requested in the guidelines. 

Versioning and file naming

Drafts use the pattern: Team#_Charter_<Section>_<Initials>_v0.1_YYYYMMDD-HHMM. The Master carries v1.0-Submitted upon finalization and is exported to PDF for submission. The version log sits at the top of the Master with date, editor, and a one-line change note. This lightweight configuration control mirrors PMBOK guidance to keep acceptance criteria and WBS-level attributes clear in the supporting “dictionary” for each deliverable segment. 

Contribution workflow and deadlines

1.  Drafting: Each owner produces their section by  Monday12:00 Eastern (00:00 Tuesday PHT; 01:00 Tuesday JST).

2.  Integration: The compiler integrates from 12:00–16:00 Eastern and requests clarifications in Signal.

3.  Gate 1 Verification: 16:00–18:00 Eastern.

4.  Gate 2 Acceptance: 18:00–20:00 Eastern by the customer proxy.

5.  Submission package: Tuesday morning Eastern. This cadence emphasizes early value and interim deliverables, consistent with PMBOK 7e’s Delivery of Value perspective. 

Change control within documents

Minor editorial changes (grammar, local rewrites for cohesion) may be executed by the compiler without prior approval. Substantive content changes (adding or removing required elements) are flagged with a comment and decided in Signal via quick voting. This aligns with the integration/change-control flow highlighted in the Unit 2 lecture: small changes can be handled informally; larger ones should be explicitly decided and traced. 

Referencing and traceability

We will cite PMBOK 6e/7e and the Unit 2 materials directly in text and reference list. A simple trace table (kept in the Master’s appendix) maps the five required charter elements to the exact paragraphs where they are addressed. This brings the spirit of a requirements traceability matrix to a short paper, ensuring every requirement adds value and is verifiably covered. 

Formatting and polish

Style is APA, 12-pt font, double spacing, and consistent headings. We avoid overuse of lists and hyphens to maintain flow and a professional tone, as requested by the instructor’s guidelines for quality and coherence. 

Risk controls for distributed work

Time-zone and availability risks (Grey traveling; fourth member absent) are mitigated by the Monday noon Eastern internal deadline and a single compiler. If a section is not delivered by the internal deadline, the compiler drafts a placeholder to maintain flow, then tags the owner for edits within the verification window. This keeps us oriented to deliverables instead of activities, a distinction Davidson stresses when “laying out your plan.” 

Team Charter: Grey, Timothy, and Spencer

Communication Plan

Grey will be responsible for the Communication Plan. Our team will coordinate primarily through email and group chat to ensure rapid responses and accountability. Weekly virtual meetings will be held to track progress, clarify responsibilities, and discuss challenges. All updates and meeting notes will be stored in a shared document repository for transparency.

Conflict Management Plan

Grey will also be responsible for the Conflict Management Plan. In cases of conflict, the first step will be direct communication between the involved parties. If unresolved, the issue will be escalated to the team as a whole during scheduled meetings. For non-responsiveness, a reminder will be sent after one day, followed by escalation to the professor if no communication occurs within three days. Emergency situations will be accommodated by redistributing tasks.

Document Management Plan

Spencer will manage the Document Management Plan. All team documents will be stored in a central shared drive (e.g., Google Drive or OneDrive) with clearly labeled folders for drafts, finalized documents, and reference materials. Version control will be maintained by including dates in file names and only one person at a time making edits to avoid conflicts.

Quality Plan

Spencer will also oversee the Quality Plan. All documents and deliverables will undergo peer review by at least one other team member before submission. Formatting will follow APA guidelines, and a standardized template will be used to maintain consistency. Final review sessions will be conducted prior to submission to ensure accuracy, completeness, and professionalism.

Roles & Responsibilities

Timothy will lead the Roles & Responsibilities section. Work will be divided among the team to ensure balanced workload distribution. Grey will handle Communication and Conflict Management, Spencer will oversee Document Management and Quality, and Timothy will coordinate overall team responsibilities and finalize role assignments. A fictitious customer role will be assumed by one designated team member to provide realistic project dynamics, and this role will be rotated if necessary. Everything will be completed on or before 1 September 2025.

Quality Plan

Purpose and quality objectives

Our goal is to deliver a four-page Team Charter that is fit for purpose and meets stakeholder expectations: clear, complete, consistent, and aligned to the assignment brief. In PMBOK 7e terms, quality activities should both move the deliverable quickly to the point of delivery and prevent or catch defects early to avoid rework, while aligning with explicit acceptance criteria. 

Acceptance criteria and “Definition of Done”

The assignment’s Quality Plan must ensure the final submission:

1. addresses all five required charter elements and fits within four double-spaced pages;

2. demonstrates high-level integration of PMBOK 6e Integration and Scope processes and PMBOK 7e principles;

3. uses consistent voice, APA citations, and polished mechanics; and

4. evidences a coherent team process (communication, conflict handling, roles). We will operationalize these through a simple Definition of Done checklist that includes content coverage, style/format checks, and evidence that deliverables have been “verified” and then “accepted,” consistent with the path from Control Quality to Validate Scope and into Close Project or Phase. 

Standards and sources of truth

Content must reflect the required readings: PMBOK 6e (Scope 5.1–5.6 at the appropriate high-level depth), PMBOK 7e Delivery Performance Domain (focus on value, deliverables, DoD), and the Team Charter instructions (Quality Plan and Document Management Plan expectations). 

Quality assurance (build quality in)

Given our dispersed schedule (Grey in Japan/Philippines; Timothy in Tennessee; Spencer ramping up mid-week), we will design the workflow to surface issues early, reducing the cost of change. Each contributor drafts against the DoD by  Monday 12:00 Eastern (which is  00:00 Tuesday PHT and  01:00 Tuesday JST), enabling an early integrated review and defect prevention before we’re forced into costly late edits. 

Practices:

•  Calibrated outline tied to the assignment rubric and readings before drafting (prevents scope and quality drift).

•  Peer dialog in Signal for ambiguities and edge cases; quick decisions reduce “done drift.” 

Quality control (verification and acceptance)

We will use a two-gate approach:

•  Gate 1 – Verification: Monday consolidated draft is checked against the DoD, assignment guidelines, and references (content coverage, flow, APA, mechanics).

•  Gate 2 – Acceptance: A designated “customer” proxy performs a final acceptance read. This mirrors PMBOK’s flow from verified deliverables (Control Quality) to accepted deliverables (Validate Scope). 

Customer proxy: Assign Spencer as the acceptance authority for this charter (he offered to take on larger sections and is assembling pieces). The instructor remains the ultimate customer; Spencer acts as our internal proxy for formal acceptance before submission. (This also satisfies the “customer role” requirement.) 

Metrics, thresholds, and escalation

We will track three simple measures: a) completeness (all required elements present), b) conformance (APA/style/format), and c) coherence (logical flow across sections). Threshold: zero critical gaps; minor style issues acceptable if corrected by Tuesday morning. If Gate 1 uncovers material gaps, the section owner has a two-hour window to remediate; if not feasible, the compiler makes targeted edits. This satisfies the Quality Plan line items in the Team Charter Guidelines. 

Interface with Scope management

Our quality controls reinforce scope discipline: we will  Validate Scope by comparing the assembled draft to the scope baseline implied by the charter instructions; any material scope change triggers a quick change decision in Signal (major change = consensus vote; minor edit = editor decision). 

Knowledge capture

After submission, we log two lessons learned: one process improvement and one content insight, to seed the course repository. This aligns to Manage Project Knowledge in the weekly lecture. 

Document Management Plan

Repository and single source of truth

We will use a shared Google Docs folder as the  authoring space and maintain a  Master Charter document as the single source of truth. Only the compiler edits the Master directly; contributors draft in their own files and paste into the Master during the integration window. This prevents collisions when “multiple team members contribute to the same document” and preserves integrity, per the Charter Guidelines. 

Access: All teammates (Grey, Timothy, Spencer, plus the fourth member if they appear) have edit access; the compiler owns the folder and ensures backups.  Communications: Signal remains the rapid channel for coordination (already established in the thread). Meeting minutes, if any, are short and posted to the group space, as requested in the guidelines. 

Versioning and file naming

Drafts use the pattern: Team#_Charter_<Section>_<Initials>_v0.1_YYYYMMDD-HHMM. The Master carries v1.0-Submitted upon finalization and is exported to PDF for submission. The version log sits at the top of the Master with date, editor, and a one-line change note. This lightweight configuration control mirrors PMBOK guidance to keep acceptance criteria and WBS-level attributes clear in the supporting “dictionary” for each deliverable segment. 

Contribution workflow and deadlines

1.  Drafting: Each owner produces their section by  Monday12:00 Eastern (00:00 Tuesday PHT; 01:00 Tuesday JST).

2.  Integration: The compiler integrates from 12:00–16:00 Eastern and requests clarifications in Signal.

3.  Gate 1 Verification: 16:00–18:00 Eastern.

4.  Gate 2 Acceptance: 18:00–20:00 Eastern by the customer proxy.

5.  Submission package: Tuesday morning Eastern. This cadence emphasizes early value and interim deliverables, consistent with PMBOK 7e’s Delivery of Value perspective. 

Change control within documents

Minor editorial changes (grammar, local rewrites for cohesion) may be executed by the compiler without prior approval. Substantive content changes (adding or removing required elements) are flagged with a comment and decided in Signal via quick voting. This aligns with the integration/change-control flow highlighted in the Unit 2 lecture: small changes can be handled informally; larger ones should be explicitly decided and traced. 

Referencing and traceability

We will cite PMBOK 6e/7e and the Unit 2 materials directly in text and reference list. A simple trace table (kept in the Master’s appendix) maps the five required charter elements to the exact paragraphs where they are addressed. This brings the spirit of a requirements traceability matrix to a short paper, ensuring every requirement adds value and is verifiably covered. 

Formatting and polish

Style is APA, 12-pt font, double spacing, and consistent headings. We avoid overuse of lists and hyphens to maintain flow and a professional tone, as requested by the instructor’s guidelines for quality and coherence. 

Risk controls for distributed work

Time-zone and availability risks (Grey traveling; fourth member absent) are mitigated by the Monday noon Eastern internal deadline and a single compiler. If a section is not delivered by the internal deadline, the compiler drafts a placeholder to maintain flow, then tags the owner for edits within the verification window. This keeps us oriented to deliverables instead of activities, a distinction Davidson stresses when “laying out your plan.”