Clear scope
Goals, boundaries, responsibilities and acceptance criteria should be understandable before execution expands.
Method
A practical method for keeping software projects clear, visible and deliverable.
The method combines Technical Project Management with hands-on software experience: define the outcome, make scope and responsibilities explicit, surface risks and dependencies early, keep progress readable and use technical context to support realistic decisions.
Core principles
Project control starts with clarity, not more ceremony.
The objective is not to add process for its own sake. It is to reduce ambiguity and make it easier for teams and stakeholders to understand what is being built, what is blocking it and what happens next.
Visible progress
Project status should be based on completed work, current blockers, dependencies and upcoming milestones — not optimistic percentages.
Early risk management
Technical, organisational and external dependencies should surface before they become release problems.
Technical context
Architecture, implementation constraints and maintainability matter when evaluating scope, estimates and delivery choices.
Working flow
From project objective to release.
The exact process depends on the project, but the same management questions return consistently.
01
Clarify outcome and scope
Define the objective, what is in and out of scope, the main constraints, responsibilities and what success looks like.
02
Build a realistic plan
Turn the work into priorities, milestones, estimates and dependencies that can actually be managed and revised.
03
Align stakeholders and team
Keep decisions, ownership and expectations clear between business, technical teams, suppliers and other involved parties.
04
Track risks, blockers and dependencies
Make constraints visible early and treat them as project information, not surprises to discover near release.
05
Monitor real progress
Use completed work, current status and validation evidence to understand project health and adjust priorities when needed.
06
Support validation and release
Coordinate readiness, checks, unresolved issues and release activities until the outcome is actually delivered.
Agile delivery
Use Agile practices where they improve delivery.
Scrum, Kanban, backlog management, refinement and iterative delivery are useful when they make priorities, ownership and progress clearer. They are tools for managing work, not an objective on their own.
Priorities that can change without losing direction
Short feedback loops
Blockers and dependencies made visible
Clear ownership and decision points
Retrospectives tied to real delivery problems
Technical perspective
Project decisions should not treat software as a black box.
A Technical Project Manager does not need to write every line of code, but technical context matters when discussing estimates, architecture, integration risk, technical debt, testing, maintainability and release readiness. My software engineering background helps keep those conversations concrete.
AI delivery governance
A shared AI workflow makes delivery easier to govern.
If every developer uses AI differently, the team can still move faster locally while making review effort, rework, estimates and project analysis harder to compare. A common operating method makes scope, evidence and verification more consistent across the team.
TCAF
TCAF is the public framework I built for governance-first, spec-driven AI software delivery — designed for teams, not only individual use.
It implements Task-Contract Development, integrating Spec-Driven Development, Agentic / Harness Engineering and Software Delivery Governance. Repository evidence defines the current state, Task Contracts create shared boundaries for delegated work, working code is preserved where possible, and verification plus developer review remain explicit.
Used as a common team discipline, TCAF reduces the variability of developers using AI in incompatible ways. That gives project management a clearer basis for reviewing scope, rework, verification status and estimation assumptions without prescribing one model or tool to everyone.
Working together
The method adapts to the project. The responsibilities stay explicit.
The useful level of structure depends on team size, project stage, technical risk and delivery constraints. The goal is always the same: make decisions easier to take, progress easier to read and delivery easier to manage.