Projects

Articles

On this page

Project Statement of Work Linkage

The Challenge Proposals and Statements of Work are necessarily high-level. Every detail can't be predicted before work starts, and clients don't want to read exhaustive specifications. This creates a challenge: proving delivery when actual work differs from what was originally described.

Project Reality When implementation begins, assumptions get tested. A "simple integration" may require custom middleware. Described workflows may not match actual operations. Requirements get clarified. Scope gets adjusted. This is normal project evolution.

What the Module Provides The module links high-level SoW items to actual tasks performed. When asked "was SoW item 2.4 delivered?", teams can reference the specific tasks that fulfilled that commitment. When tasks change due to new information, the link to the SoW item remains intact.

Business Value

• Creates an audit trail for delivery verification
• Provides evidence for client reporting and scope discussions
• Enables retrospective analysis for future proposal development
• Shows what specific deliverables actually required in past projects

Strategic Benefit Across multiple projects, organisations build knowledge about how high-level commitments decompose into actual work. This data improves estimation accuracy, proposal quality, and delivery predictability over time.

Project Management Issue register

The cs_project_issue module bridges the gap between the contractual reality of the SoW and the operational reality of task execution.

When you commit to delivering something in a SoW, you're making commitments at a level that's necessarily high-level and assumption-laden. The SoW represents what you've agreed to deliver, and from a contractual standpoint, it remains correct. However, as your team begins executing against those commitments, they discover that assumptions were wrong, requirements were misunderstood, technical approaches need adjustment, or scope boundaries need clarification.

The issue module captures this evolution. When a task needs to change because an assumption proved invalid, that's documented as an issue. When a client requests something that seems reasonable but wasn't explicitly in the SoW, that's captured as a change request. When you discover a better approach mid-project, the decision to pivot is documented. When you defer something that seemed important in planning but proves less critical during execution, that parking lot item explains why.

This documentation serves three critical purposes. First, it creates traceability showing why your delivered tasks don't match your original task plan, even though they still fulfil the SoW commitment. You can demonstrate that changes were deliberate, evaluated, and approved rather than arbitrary. Second, it provides real-time visibility into project health by distinguishing between normal execution issues and actual scope changes that might need client discussion or contract amendments. Third, it builds organisational knowledge for estimating future SoWs by capturing what assumptions typically fail, what clients frequently request beyond stated scope, and what technical approaches work better than initially planned.

Without this issue tracking layer, you lose the connection between "what we committed to deliver" and "why we delivered it this specific way," making it difficult to prove delivery compliance or improve future estimates.

Examples

SoW Table (hierarchical)

SoW Table (flat)