Software project planning starts with reducing uncertainty. I want the business and engineering team to agree on what to build, what to investigate first and what to leave out. We do not need every detail resolved, but we do need to identify assumptions that could change the scope or prevent delivery.
The discipline applies to designing an API, connecting a data pipeline to a CRM or examining why an AI project fails before production. I describe the work and its constraints before choosing tools.
Start with a workflow and a decision owner
I ask someone to describe the last time they ran the process: what came in, who took part, where an exception occurred and how they knew the job was finished. This separates an observed need from a feature that sounds useful in a meeting.
- Who uses the system and who accepts delivery?
- What input does it receive and what output is needed?
- Which decisions will remain with a person?
- What existing tool or manual workaround works today?
- Which constraint would force a different approach?
The owner needs authority to resolve priorities. If operations, sales and management expect different outcomes, I make that disagreement visible before turning their requests into development tasks.
A record of decisions, evidence and open questions
For each decision, I keep a short record: question, available evidence, outstanding assumption, owner and a trigger for review. I mark each item as confirmed, pending or blocking. A vendor statement or an isolated screenshot does not establish that an integration works under the project's actual conditions.
| Decision | Evidence I would request | If it is missing |
|---|---|---|
| Job and first delivery | A journey reviewed by its operator, with a start, finish and exclusions. | Observe the workflow before committing to scope. |
| System access | Documentation and an authorised check with the required permissions and data. | Verify access before committing to the integration. |
| Data ownership | A sanitised sample, field definitions and an owner for resolving discrepancies. | Agree rules before copying or overwriting records. |
| Exceptions | Examples of missing data, failures and decisions that need review. | Define a manual path before automating it. |
| Operations | An owner for alerts, access, recovery and launch acceptance. | Do not assume continuity is solved by delivering code. |
A minor unknown need not stop the whole project. An unknown that could invalidate a design should pause the work that depends on it. Other work can proceed within clear boundaries if the owner accepts the remaining risk.
A hypothetical example: requests that end up in an ERP
Imagine a company receiving requests by email and entering them in its ERP. The business wants a portal to remove transcription. Before designing screens, I would check whether the problem lies in capturing requests, applying approval rules or correcting records later.
Assumption: the ERP allows new requests to be created. Evidence needed: an authorised check in a suitable environment confirming mandatory fields, permissions and the response to a repeated request. Owner: the ERP administrator. If access is read-only, the portal cannot promise automatic writes.
I would then propose a first delivery that prepares requests for review and manual entry, or investigate another integration route. We would record who accepts that limitation and what evidence would allow us to change it. This is not a client case or a reported outcome. It illustrates a decision worth making before pricing the complete workflow.
What to resolve before commissioning development
The useful output of planning is a set of reviewable decisions, not a long document nobody maintains. Before committing to a build, I want to walk through these points with both the buyer and the future operator:
- Problem and current alternative: what needs to improve and why adapting an existing tool is insufficient.
- Journey and exclusions: what the first delivery includes and what remains manual.
- Verified dependencies: checked access, samples and capabilities; open questions with named owners.
- Architecture decisions: the chosen option, a rejected alternative and the condition that would make us reconsider.
- Delivery evidence: how the journey will be demonstrated and who will accept it.
- Operations and next step: who handles incidents and whether to build, investigate or stop.
This does not guarantee a price or timeline. An unresolved dependency belongs in the proposal as an uncertainty. A bounded technical investigation may resolve it; commissioning the whole product is not necessary to obtain that answer.
When the missing piece is technical leadership
If decisions conflict, several suppliers are involved or nobody can explain the consequences of each option, adding developers may increase the coordination work. The immediate need may be my fractional CTO service: aligning scope, architecture and responsibilities with the team. The problems I can help solve as a technical CTO provides context for that support.
Once the decisions are clear enough and you need to build, review my custom software and SaaS development service: the delivery scope, acceptance checks, handover and maintenance responsibilities we would agree before starting.
Plan for operational evidence too
A failed workflow should leave enough information to identify the affected step and decide what to do next. I define which states, records and alerts the operator needs, avoiding unnecessary sensitive content. That decision affects the design from the beginning.
The Adslyfy case, with execution history, failures and screenshots, documents that operational layer. It makes the idea of evidence concrete; it does not establish savings or outcomes for the ERP example.
Bring the decision that is blocking the project
For a planning review, bring the current workflow, a sanitised sample, the systems involved and the unknown that prevents a decision. Do not send credentials or customer records. That gives us a basis for deciding whether the next step is product definition, a dependency check or preparation for development.
If you need that review before committing to a project, tell me what you want to solve and what remains unverified.