Contracts, Performance, Cost, Schedule, Risk, Responsible data science, Projecting
3.1 Context
Given a project with a performance work statement, students can use a project management life cycle to help them execute the project to meet the performance, schedule and cost requirements of the PWS.
3.3 Project Management and the Project Management Institute
For Centuries, people have found that actively “managing” a project can lead to better results.
One example is the development of the Great Pyramid of Giza as the tomb for Pharaoh Khufu, built over a period of 20+ years beginning in 2580 BCE. (Kozal-Holland 2015)
Great Pyramid of Giza
Over the past 4,000 years, the concept of “Project Management” has continued to evolve to where is is broadly recognized as its own specialty and profession.
Since projects are ubiquitous, understanding what project management entails can help everyone involved in a project put their work into context and improve the probability of project success.
Project management is the process of supervising the work of a team to achieve all project goals within the given constraints. … The primary constraints are scope, time and budget. The secondary challenge is to optimize the allocation of necessary inputs and apply them to meet predefined objectives. The objective of project management is to produce a complete project which complies with the client’s objectives.
Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. It’s the practice of planning, organizing, and executing the tasks needed to turn a brilliant idea into a tangible product, service, or deliverable. Key aspects of project management include: Defining project scope, Identifying deliverables, Managing risks, and Effective communication across teams.
Both of these definitions focus on Project Management as a set of processes about enabling the success of a project, not about the solution itself.
As a nuance, project management is similar but different from managing a team of personnel on a recurring basis to meet a level-of-service criteria. Project management is focused on a time and resource constrained effort to deliver the intended outcomes of the project.
3.3.1 PMI and PMBOK
The Project Management Institute (PMI) is a not-for-profit organization founded in the 1960s to help improve the management of numerous, large-scale projects funded by the US government. PMI (2025)
Many project management methods and tools were developed centuries and decades earlier.
The PMI focused on integrating best practices and tools into a coherent framework and then training and certifying individuals as Project Management Professionals (PMP).
Over the last 60 years, PMI has been become a global leader in advancing the science and practice of Project Management and has extended their efforts to include knowledge development and training/certification for program management and portfolio management.
The integration of the best practices resulted in what is called the The Project Management Body of Knowledge commonly referred to as PMBOK. PMI (2021)
The Project Management Body of Knowledge (PMBOK) is a set of standard terminology and guidelines (a body of knowledge) for project management. The body of knowledge evolves over time and is presented in A Guide to the Project Management Body of Knowledge (PMBOK Guide), a book whose seventh edition was released in 2021.
The PMBOK creates a framework for project management. Figure 3.1 is one depiction of five sets of of activities or processes occur in a project management life cycle.
Each phase focuses on a distinct goal:
Initiation defines the project’s purpose, scope, and requirements
Planning outlines the approach including tasks, schedules and resources.
Executing involves task implementation - doing the work
Controlling requires monitoring progress, assessing risk, and reallocating resources as necessary,
Closing finalizes all activities.
Figure 3.1: Five Project Phases in the Life Cycle (Good 2024)
While Figure 3.1 depicts the phases as linear, in reality they are more interconnected with feedback as seen in Figure 3.2
Figure 3.2: A Dynamic Depiction of the IPECC Model(Good 2023)
3.5 Project Initiation
Project Initiation can begin with the receipt of direction or authorization to start execute a project, e.g., a contract award with a Performance Work Statement (PWS) or Statement of Work (SOW).
The goal of initiation is to understand the project objectives and requirements and any limitations or constraints.
A secondary goal is to understand the larger context for the client based on the client and their organization, and how the project aligns with the state of the practice/state of the art as well as your own capabilities.
In a competitive world, project initiation can begin years or months before contract award to help anticipate or shape the project being released.
If one waits until a project Request for Proposal (RFP) is released to begin initiation, it is probably too late to compete, unless every competitor was also surprised by the RFP.
Performance: The Performance Work Statement (PWS) (or SOW) provides requirements and constraints for the project planning.
A PWS requires specific goods to be created (deliverables) and/or services to be performed (tasks) without detailing exactly how the work is to be performed or managed.
Each deliverable or service will have an associated set of “acceptance criteria” that specify the minimum required level of performance or quality for the good or service.
A SOW focuses on specifying the work to be performed with the expectation that it will deliver the desired goods or services.
Schedule: The PWS may also specify a general sequence of work, e.g., project phases, as well as due dates for deliverables and dates for the conclusion of tasks.
Cost: A PWS usually has an associated budget that provides requirements and constraints on how resources can be allocated for the project.
Other Inputs could include:
Workforce Capacity: What are the required/available people with expertise and what is their cost rate?
Materials: What physical resources are required/available and what do they cost? This could be buildings or facilities, computing power, or software.
3.6.2 The Output: A Project Plan
Project planning converts PWS requirements and guidance into a set of tasks (work activities) to be performed, with allocated resources, over time to complete the project.
Small projects usually have a leader do the project planning.
Large projects may have a dedicated project planning team with expertise in project management, but not in the technical aspects of the requirements or solution.
A technical team of subject matter experts (SMEs) will provide them technical perspectives on the work to be performed.
The result of planning is documented in the project’s Project Plan.
The Project Plan is the guiding document for the manageent of all work to be performed.
It defines the work in terms relevant to establishing the baselines for performance, schedule, and cost.
The Plan is the baseline the team uses to collaborate, synchronize and monitor their efforts.
The Project Plan is a “living document” that can be adjusted over time as conditions change.
The Project Plan should address performance, schedule, costs, and risks as well as the management approach for the plan.
3.6.2.1 Performance Elements
The project planning tean analyzes the PWS/SOW requirements for deliverables and their acceptance criteria as well as all specified tasks, i.e., the “shall statements.”
Technical experts then do their analysis of the requirements.
They break down the deliverables and specified tasks into “bite-size” pieces (component parts or sub tasks) and group them into coherent sets of tasks that produce a “work product.”
These groups of tasks are often referred to as “work packages.”
They then analyze the work packages to identify any “implied tasks” necessary to complete the work and assign them to a work package.
They also look for commonalities across the tasks and create work products that can be developed once and shared across the project.
The output of the requirements analysis is a set of work packages whose work products are well specified and can be combined to meet all PWS/SOW performance requirements without duplication of effort.
The project plan lists all the deliverables, acceptance criteria, and due dates as well as the work packages, their work products, and any other specified performance requirements.
3.6.2.2 Schedule Elements
Once the work packages are defined, the technical experts then consider any deliverable due dates and analyze the set of work packages for technical or schedule dependencies.
They sequence the packages to ensure work a work product is completed before it is required by another work package.
Projects that are longer than a few weeks are often broken into Phases to simplify project management.
A PWS/SOW may specify phases to provide clear check points for progress on the project.
Phases may overlap as projects often have parallel work streams.
The technical team uses their sequence of work packages to align each work package to one, and only one, phase.
The Project Plan will contain a schedule shows the beginning and end of each phase.
3.6.2.3 Cost Elements
Projects consume resources that may include labor, travel, materials, facilities, computing resources, sub contractors, etc.. Thus project planning is a combined effort between the technical experts and the cost experts.
The cost experts typically provide a set of “Labor Categories” which is a list of categories of technical expertise and an associated hourly cost rate for each category, e.g., Senior Data Scientist, $250 per hour.
Note, this will be a fully-burdened rate so is much higher than what an individual may be paid as the burden includes costs for social security, fringe benefits, administrative support, etc..
The technical experts analyze each work package to develop an estimate of the labor categories and hours required necessary to produce the work product with acceptable risk.
They also develop the list of required materials, facilities, computing resources etc that may be required to support the work package.
The cost experts then compute the cost estimates for each of the non-labor cost elements to produce the expected budget for the work package.
These work packages are then aggregated to at least the deliverable level or for each Phase to generate the costs over time and for the entire project.
The Project Plan typically includes cost information that shows the allocation of labor and non-labor costs over time and for each deliverable.
The cost elements are summarized in the project plan with the details in a separate annex given the proprietary and sensitive information inherent in cost analysis.
3.6.2.4 Risk Elements
Performance (quality) is inter-dependent with the time and resources allocated to the work.
Reducing the labor expertise/hours or shortening the schedule almost always affects the achievable quality of performance.
Several well-known sayings capture this dependence:
Cost, Schedule, and Performance – pick any two!
You want it bad, you get it bad!
You get what you pay for!
There is no such thing as a free lunch!
If the minimum weren’t good enough, it wouldn’t be the minimum!
Any project has some inherent risk as assumptions are made when generating the plan, either as part of a proposal for new work, or, after the award of a new contract (which could be a year or more after the proposal). Life goes on, the world changes, and the original assumptions may no longer be valid.
Here are two famous sayings from a military planning context about the need to adapt to changes in the situation.
“Kein Operationsplan reicht mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus.” (“No operation plan extends with any certainty beyond the first encounter with the main enemy force.”)
GIven the assumptions that go into planning and the changes that pccur over time, project planning should account for risks that could affect the project. These risks can occur in the performance, schedule or cost elements.
Performance: A new package does not work as expected or the data is no longer available requiring changes.
Schedule: The sponsor is unable to meet for two weeks due to illness or travel and you need additional guidance or the computing cluster is down for a week for unscheduled maintenance delaying your access.
Cost: Your senior data scientist received a new job offer and you had to raise their salary to retain them.
Each risk is analyzed for both probability of occurrence and the level of effect on the project.
The project plan does not account for all possible risks. The project management and technical team analyzes for risks that have either a high probability of occurrence or a high level of (negative) effect on the project. These then get combined into an over all rating.
A simple approach uses a risk matrix and color codes the risks as green - low, yellow - moderate, and red - high.
Anything that is high risk (red) typically has to have a mitigation strategy - what can the project team do to reduce either the probability of occurrence or the effect of the impact on the project.
The goal is to get the risk to at least medium (yellow) or lower (green).
Table 3.1 is one example of a table used to identify major risks, their probability of occurrence and level of negative impact on the project. Each risk has a mitigation strategy which results in a final status.
Table 3.1: Project Risks
Risk Item
Prob
Impact
Mitigation
Status After Mitigation
H/M/L
H/M/L
Green/Yellow/Red
H/M/L
H/M/L
Green/Yellow/Red
H/M/L
H/M/L
Green/Yellow/Red
3.6.2.5 Management Approach
Project Management is typically a required task in a major project and includes deliverables such as a project plan, weekly updates, and regular meetings and reports on performance and cost.
For large projects, the management approach may include a number of plans in separate appendices.
This could include: Risk Management Plan, Quality Management and Assurance Plan, Procurement Management Plan, Stakeholder Communication and Reporting Plan, Change Control and Governance Plan, Configuration Management Plan, and a Safety and Compliance Oversight Plan.
Projects may also include a plan for managing responsible data science considerations such as an Independent Review Board (IRB).
At a minimum, the project plan should include the management approach for the project (referencing any appendices) and how communications will occur between the performer and the client sponsor.
3.6.2.6 Planning Sequence
The project management teams typically builds an initial project plan.
They use the labor, schedule and cost estimates and risk analysis for each work package to create an unconstrained plan with acceptable risks.
Once the initial estimates are in place, the planner checks for existing constraints. They check, at a minimum,
Performance: Are all deliverables and tasks accounted for in the plan at the level of required quality? Is it complete?
Schedule: Does the plan meet all schedule requirements from the PWS? Are all dependencies addressed. Is the schedule “realistic” or make unfounded (undeclared) assumptions.
Cost: Does total of costs for the planned workforce, level of effort, and other costs generate a projected cost that is within the Price target established in the Proposal and the target Profit established by the organization?
If the answers to any of the questions are no, then the planner has to review the analysis with the technical team and make adjustments to performance, schedule, and cost to get to a final plan.
3.7 Work Breakdown Structures
A Work Breakdown Structure (WBS) is a common approach to capturing the results of the analysis that generated work packages and work products and breaking them down into a hierarchy of sub elements with increasing resolution.
A work-breakdown structure (WBS) in project management and systems engineering is a deliverable-oriented breakdown of a project into smaller components. A work breakdown structure is a key project management element that organizes the team’s work into manageable sections. The Project Management Body of Knowledge defines the work-breakdown structure as a “hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.”
WBS are usually shown as tree structures or hierarchies to help communicate the details of complex projects in an organized fashion.
By breaking down the work into smaller and smaller packages with increasing levels of detail, the expectation iss that the work products in the lower levels of the hierarchy/tree will become similar to work done on other projects.
That means you have more examples with which to identify the details of the tasks to be done which can improve the quality of the estimates for the labor, time, and materials required to produce the work product and thus more precise cost estimates.
Then you sum up all the individual child pieces to get their parent’s required labor, time, and materials and cost, and continue to aggregate all the way up to the finished deliverables.
A WBS is, by design, a systematic approach to breaking down the entire scope of the project so the “Whole” is literally the “sum of the parts” and nothing is left out.
WBS were originally developed to focus on building physical things.
Consider using a deliverable-oriented WBS to capture the work in building an airplane:
Level 1 would be the Airplane Project
Level 2 would be the Airplane itself (physical deliverables) and Program Management (Management Deliverables)
Level 3 elements are the major components of the level 2 elements.
Airplane: engines, body, wings, and cockpit.
PM: Project Planning, Risk Management Plan, Quality Management and Assurance, Procurement Management, Stakeholder Communication & Reporting, Change Control & Governance, Configuration Management and Safety and Compliance Oversight
Level 4 elements are the sub components for each level 3 element, e.g.
Wings: fuel cells, wing shells, ailerons, and fuel tanks,
Cockpit: control system, communication system, navigation system, safety systems, and crew systems.
Figure 3.3 shows how the airplane project might be represented in a level 4 WBS diagram. You would expect the actual WBS for an airplane to have several more levels.
Figure 3.3: WBS for a project to deliver an airplane.
3.8 WBS Analysis
Once the project plan is complete and converted into a WBS, the planning team will analyze each aspect of performance, schedule, and cost to identify metrics, control measures, and risks to support monitoring and controlling progress.
3.8.1 Performance Quality Analysis
The planing team will rely on subject matter experts (SMEs) to analyze the deliverables and services and identify quality metrics they can track to ensure the project testing is adequate and the project results will be accepted with low risk.
At this point, the technical team will also design tests to assess quality against the PWS standards. The test designs and metrics could be incorporated into the quality management and assurance plan or a separate test plan.
The goal is to understand how task interdependencies affect the completion of the overall project.
Given that some tasks cannot start until others are complete, or cannot finish until others are finished, PERT assigns estimates for short possible times, most likely completion times, and longest possible times to help evaluate expected completion time for the project.
It can also help identify the Critical Path *the longest set of dependent activities that will most affect the project length if there is a delay in an activity on the critical path.
3.8.3 Cost Analysis
The planning team will review all cost estimates for the labor and materials to ensure they were correct and reasonable during execution, especially if the proposal was submitted long ago.
Often an initial proposal or plan may be based on lower quantile salaries of a fictional labor force (to get the lowest price) and now the project must work with the actual workforce and their salaries.
Project execution is where the actual work gets done to support delivery of goods or services.
The goal is to perform the work to the desired level of quality within the planned schedule and cost projections.
3.10 Project Monitoring and Control
Project Monitory and control is performed throughout execution to keep track of the progress on the work and identify any major deviations (positive or negative) from the plan’s performance, schedule and cost projections.
It also monitors for the identified risks and for new risks that may affect the project.
3.11 Project Closure or Closeout
Project Closure include the steps to finish delivery of all deliverables and check for completion of all tasks.
This often includes submitting an deliverable acceptance document to support proper and timely payment.
If the client has provided any equipment, data, access badges, etc, they are returned during closeout.
Project closure means the project is no longer active from a delivery perspective. However, the final costs and price elements may not be determined until the client and contractor organizations have completed all audits of their costs structures and finalized all allowable costs and burdens - which can take years.
3.12 WBS Design for Non-Product Work.
While the WBS was designed to manage the development of products, it can also be a useful method for managing research or analytical work.
Developing a useful WBS is a blend of science and art as it is a tool for managing and communicating about a complex project.
WBS developers have to choose the appropriate level of detail for each work package and its components.
They have to identify commonalities across work packages and avoid duplication of effort.
They also have to decide whether and how to incorporate schedule aspects such as Phases into the WBS.
As an example, if the airplane project airplane has phases of design, engineering, manufacturing and testing, they could be incorporate at level 3 with the physical components beneath them or be incorporated into the current level 3 with each phase as level 4 element.
The goal would be to align a deliverable at the end of each phase so one knows when the phase is complete, e.g, an approved design document, an approved engineering specification, a manufacture component, and a final test report.
This hybrid blend of phases and deliverables fits will with projects focused on research or analysis.
One can use the data science life cycle (Figure 1.1) as the basis for phases in an analysis project.
You can tailor the phases to support the complexities of the project.
You can combine steps/phases or expand them in your WBS to support where you see the complexity in the work that needs more intensive management.
If you are combining analysis and development, e.g., a shiny app, you can add a development phase.
There is no one way to develop a WBS as it should be designed for the project and its PWS requirements.
3.13 Project Planning for This Course
For this course the student will be the project planner as well as the technical SME.
Consider the development of the PWS as part of the initiation phase of project management.
Even before the PWS is finalized, you can use it as the basis for project planning and developing the Project Plan.
Once your project plan is complete, you shall use it for tracking your performance on the major tasks and your consumed hours over the project.
You shall make any adjustments so at the end, you meet the requirements of the PWS and can properly close out the project.
The next section shows one example of a WBS for a data science project that has an optional element for development.
The example PWS that follows is generic so is not perfect for any specific project in this course and must be tailored for your project!
The section also shows two different ways to create an in-document WBS as one more more images.
3.14 Work Breakdown Structure (WBS) Diagrams
You can always include a WBS structure in a document or presentation as text using Markdown to format it.
At times you will want to use a diagram to facilitate communication of the WBS structure and validate its completeness and level of detail.
Many tools exist to create WBS diagrams from a variety of data structures e.g., Excel for small projects and Microsoft Dynamics for large, complex projects.
The following examples use a generic WBS for a project that is first presented as text and then using GraphViz and then using Mermaid.
The WBS starts with Level 1 as the Data Science Project. It has level 2 tasks and then level three sub tasks with some explanations.
A real-world WBS may have many more levels on a large project.
The goal of a WBS is to get a sufficient level of detail to ensure efficient and effective program management. This includes:
Estimating (projecting) the time and resources to accomplish each deliverable and task.
Assigning responsibility for discrete deliverables or tasks
Monitoring and managing the work to mitigate risk to performance, schedule, and cost for the project.
3.14.1 Text Outline WBS Structure
1.0 Data Science Project
1.1 Define
1.1.1 Identify problem statement and objectives
1.1.2 Determine project scope and boundaries
1.1.3 Identify stakeholders and beneficiaries
1.1.4 Identify constraints and risks
1.1.5 Identify deliverables acceptance criteria, and due dates
1.1.6 Identify project phases/milestones
1.1.7 Deliverable: Performance Work Statement (PWS)
1.2 Project Management
1.2.1 Project Charter, Planning, and Resource Allocation – Define scope, goals, roles, responsibilities; establish project timeline and deliverable schedule; estimate and allocate resources (staff, tools, budget).
1.2.2 Stakeholder Communication – Identify key stakeholders; develop communication plan (status updates, meetings).
1.5.5 Deliverable: Draft Deliverables Report - (Research and Analysis Projects) – Outline and summarize findings, methodology, implications.
1.5a Develop Application (Application Projects)
1.5a.1 Application Requirements Alignment – Translate outputs from 1.3 Frame the Analysis and 1.5 Model and Analyze into functional application requirements.
1.5a.2 Frontend Design – Create wireframes, user input design, and interface layout.
1.5a.3 Backend Development – Set up APIs, integrate models, configure databases.
1.5a.4 Version Control - Configuration manage data, code and environment.
1.5a.5 Testing and Debugging – Unit tests, edge case testing, performance validation.
1.5a.6 Deliverable: Application Prototype.
1.6 Communicate Results
1.6.1 Storyboarding and Visualization – Select charts, narratives, and dashboards for audience.
1.7.5 Deliverable: Final Application / Final Report, User Documentation.
3.14.2 Generating a WBS Diagram
Quarto works well with Graphviz and Mermaid to generate diagrams in regular HTML documents.
See the Quarto Guide section on Diagrams for more details
Both allow customization as in the examples below.
If you want to generate diagrams in reveal.js slides, use Mermaid since it is also js.reveal based.
Quarto will attempt to automatically convert the diagrams for PDF rendering but it may not always get it right, especially for large diagrams.
If you want to use a diagram in both HTML and PDF outputs, then the recommended approach is to use a separate file to create the image then convert it to png or SVG and then import the same file into both documents.
3.14.3 Example of Using Graphviz Digraph to create a Diagram
There are two sets of diagrams as Graphviz can be challenged to lay out a WBS with lots of elements so it is readable in a small format.
The first layout is a Left-to-Right (LR) layout for the level 1 and 2 nodes. Note the names are shortened to help the fonts be larger.
The second set of layouts is a tab set with one tab for each level 2 to show its level 3 elements.
digraphWBS_Overview{rankdir=TB;node[shape=box, style=filled, fillcolor=lightyellow, fontname="Helvetica", fontsize=12]; // Increase spacing for better readabilitynodesep=0.8;ranksep=1.2; // Root nodeA[label="1.0 Data Science Project", fillcolor=lightblue, fontsize=14, fontname="Helvetica Bold"]; // Level 2 nodes - now arranged verticallyA1[label="1.1 Define", fontsize=12, fillcolor=lightyellow];A2[label="1.2 Program & Project Management\n(Continuous)", fontsize=14, fillcolor=lightyellow];A3[label="1.3 Frame the Analysis", fontsize=14, fillcolor=lightyellow];A4[label="1.4 Get and Shape the Data", fontsize=14, fillcolor=lightyellow];A5[label="1.5 Model/Analyze", fontsize=14, fillcolor=lightyellow];A5a[label="1.5a Develop Application\n(Optional)", fontsize=14, fillcolor=lightyellow];A6[label="1.6 Communicate Results", fontsize=14, fillcolor=lightyellow];A7[label="1.7 Deploy and Implement\nRecommendations", fontsize=14, fillcolor=lightyellow]; // Connect root to Level 2 nodes - vertical flowA->A1;A1->A2;A2->A3;A3->A4;A4->A5;A5->A5a;A5a->A6;A6->A7;}
Figure 3.5: This is a Top-to-Bottom WBS with levels 2 and 3.
3.15 Example of Using Mermaid to Create a Diagram
Mermaid by default arranges nodes top-to-bottom (graph TD). To get vertical stacking under each Level 2 node, you can create chains and avoid linking Level 3 siblings horizontally.
Figure 3.6 shows a complete WBS in a mixed layout with the level 2 tasks left -to-right abd the level 3 taks top-to-bottom.
Show code
graph TD %% Level 1 A[1.0 Data Science Project] %% Level 2 A1[1.1 Define] A2[1.2 Project Management] A3[1.3 Frame the Analysis] A4[1.4 Get and Shape the Data] A5[1.5 Model/Analyze] A5a[1.5a Develop Application] A6[1.6 Communicate Results] A7[1.7 Deploy and Implement Recommendations] %% Level 1 to Level 2 A --> A1 A --> A2 A --> A3 A --> A4 A --> A5 A --> A5a A --> A6 A --> A7 %% Level 3 under A1 (vertical stack) subgraph cluster_A1 A11[1.1.1 Identify problem statement and objectives] A12[1.1.2 Determine project scope and boundaries] A13[1.1.3 Identify stakeholders and beneficiaries] A14[1.1.4 Identify constraints and risks] A15[1.1.5 Identify deliverables, acceptance criteria, and due dates] A16[1.1.6 Identify project phases/milestones] A17[1.1.7 Deliverable: PWS] end A1 --> A11 A11 --> A12 A12 --> A13 A13 --> A14 A14 --> A15 A15 --> A16 A16 --> A17 %% Level 3 under A2 subgraph cluster_A2 A21[1.2.1 Project Charter, Planning, Resource Allocation] A22[1.2.2 Stakeholder Communication] A23[1.2.3 Risk and Issue Management] A24[1.2.4 Monitoring and Reporting] A25[1.2.5 Deliverable: Project Plan] A26[1.2.6 Project Closeout] end A2 --> A21 A21 --> A22 A22 --> A23 A23 --> A24 A24 --> A25 A25 --> A26 %% Level 4 under A26 subgraph cluster_A26 A261[1.2.6.1 Code Repository] A262[1.2.6.2 Technical Appendices] A263[1.2.6.3 Return resources and data] A264[1.2.6.4 Deliverable: Document client acceptance] end A26 --> A261 A261 --> A262 A262 --> A263 A263 --> A264 %% Level 3 under A3 subgraph cluster_A3 A31[1.3.1 Refine the Problem Statement] A32[1.3.2 Literature Review] A33[1.3.3 Gather SME Inputs] A34[1.3.4 Conduct responsible data science review] A35[1.3.5 Define Key Elements of Analysis / Requirements] A36[1.3.6 Identify Constraints and Assumptions] A37[1.3.7 Develop Analytic Approach] A38[1.3.8 Develop Workflow Diagram] A39[1.3.9 Deliverable: Framing Report] end A3 --> A31 A31 --> A32 A32 --> A33 A33 --> A34 A34 --> A35 A35 --> A36 A36 --> A37 A37 --> A38 A38 --> A39 %% Level 3 under A4 subgraph cluster_A4 A41[1.4.1 Define Data Requirements] A42[1.4.2 Acquire Data] A43[1.4.3 Data Cleaning] A44[1.4.4 Data Transformation] A45[1.4.5 EDA] end A4 --> A41 A41 --> A42 A42 --> A43 A43 --> A44 A44 --> A45 %% Level 3 under A5 subgraph cluster_A5 A51[1.5.1 Feature Engineering] A52[1.5.2 Model Development] A53[1.5.3 Model Evaluation] A54[1.5.4 Interpretability and Scenario Testing] A55[1.5.5 Deliverable: Draft Deliverables Report] end A5 --> A51 A51 --> A52 A52 --> A53 A53 --> A54 A54 --> A55 %% Level 3 under A5a subgraph cluster_A5a A5a1[1.5a.1 Application Requirements Alignment] A5a2[1.5a.2 Frontend Design] A5a3[1.5a.3 Backend Development] A5a4[1.5a.4 Version Control] A5a5[1.5a.5 Testing and Debugging] A5a6[1.5a.6 Deliverable: Application Prototype] end A5a --> A5a1 A5a1 --> A5a2 A5a2 --> A5a3 A5a3 --> A5a4 A5a4 --> A5a5 A5a5 --> A5a6 %% Level 3 under A6 subgraph cluster_A6 A61[1.6.1 Storyboarding and Visualization] A62[1.6.2 Draft Report] A63[1.6.3 Stakeholder Presentation] A64[1.6.4 Feedback and Revision] A65[1.6.5 Deliverable: Final Report] A66[1.6.6 Deliverable: Final Presentation] end A6 --> A61 A61 --> A62 A62 --> A63 A63 --> A64 A64 --> A65 A65 --> A66 %% Level 3 under A7 subgraph cluster_A7 A71[1.7.1 Deployment Planning] A72[1.7.2 Implementation] A73[1.7.3 Monitoring & Maintenance] A74[1.7.4 Change Management] A75[1.7.5 Deliverable: Final Application / Final Report, User Documentation] end A7 --> A71 A71 --> A72 A72 --> A73 A73 --> A74 A74 --> A75 %% Styles classDef level1 fill:#add8e6,stroke:#333,stroke-width:2px,color:#000,font-weight:bold; classDef level2 fill:#fffacd,stroke:#333,stroke-width:1.5px,color:#000; classDef level3 fill:#d0f0c0,stroke:#333,color:#000; class A level1; class A1,A2,A3,A4,A5,A5a,A6,A7 level2; class A11,A12,A13,A14,A15,A16,A17,A21,A22,A23,A24,A25,A26,A261,A262,A263,A264,A31,A32,A33,A34,A35,A36,A37,A38,A39,A41,A42,A43,A44,A45,A51,A52,A53,A54,A55,A5a1,A5a2,A5a3,A5a4,A5a5,A5a6,A61,A62,A63,A64,A65,A66,A71,A72,A73,A74,A75 level3;
Figure 3.6: This is a mixed LR-TD layout for a three level WBS (plus a level 4 for the Closeout task).
Mermaid is picky about format.
Node IDs like A11 have no spaces.
Be sure to add a 0 after a number period, so not 1. but 1.0 .
The entire node list in the last class statement is on one line with no line breaks or trailing commas.
Style properties in classDef use commas, not semicolons.
Meraid Debugging
If you have a syntax error in your mermaid code, go to https://mermaid.live and paste the code.
You will see a message for the first error at the bottom of the code with a reference to the line number of what you pasted and a suggestion for what was expected.
