What shapes a software project's cost and timeline?

Define a result, rather than a feature count.

Two products can have the same number of screens and require very different work. A booking flow with one service and a requested time is different from one that calculates availability across staff, locations and resources.

Describe the user journey and the rules that make it work. Include unsuccessful states, corrections and what staff need to manage. These details help distinguish the essential first release from later improvements.

• Who uses the product, and what must they complete?
• Which rules affect prices, availability or permissions?
• What is included in the first stage, and what is outside it?

Make existing systems and unknowns visible.

Existing code, data quality and external integrations can change the work required. An interface that appears simple may depend on an undocumented service, an unavailable API or data that needs checking before it can be moved.

List these dependencies early. Where a material question remains unanswered, a technical assessment or planning stage may be needed before an implementation estimate is useful. The estimate should state what it assumes, rather than hide uncertainty inside a single number.

• Available source code, documentation and account access.
• External API capabilities, documentation and access conditions.
• Data sources, formats, quality and any migration requirements.

Include the work around implementation.

Design, content preparation, testing, deployment and handover all affect delivery. An app also needs a defined distribution route and the relevant release materials. A website may need content management and agreed metadata and indexing configuration.

Identify the responsibilities for content, review, accounts and decisions. A project plan needs to reflect both the development work and the input it depends on. External platform review or third-party access is a dependency to account for, rather than a date the development team can guarantee.

Use stages to make the next decision manageable.

A first stage can focus on a complete user journey, a high-priority improvement or a specific investigation. It should have clear deliverables and review points so you can decide what to do next.

If a new request changes the work, assess its effect on the scope, cost and timing before adding it. It may belong in the current stage or a later one. Post-release improvements and support also need explicit coverage and responsibilities.

What to bring to an initial discussion.

You do not need a finished specification. Share what is already known and identify what is still open. A short, concrete overview is more useful than an extensive feature list without priorities.

• A short description of the business, users and main task.
• Product links, sketches or materials you can share.
• Existing systems and the connections or changes you need.
• Any known budget range, target date or operating constraint.
• The outcome that matters most in the first stage.