Project Timelines & Milestones

We deliver in milestones, not big-bang surprises at the end.

Digital projects rarely go perfectly according to a calendar.

Requirements evolve. People have questions. New information appears. Third-party services change. Sometimes the best solution becomes clearer only after you can actually see it working.

That's why we prefer to build in clear, manageable milestones rather than disappear for weeks and return with one enormous final delivery.

1. How Milestones Work

Each project is divided into meaningful stages agreed as part of the project scope.

A milestone should have a clear outcome — something you can see, review, test, use, or approve.

Depending on the project, a milestone might involve:

  • Discovery or requirements

  • Architecture or planning

  • Design

  • Initial configuration

  • A working prototype

  • An integration

  • A completed workflow

  • Testing

  • Training

  • Final delivery

The exact milestones depend on the project.

The principle remains the same:

Each stage should create visible progress.

2. Why We Use Milestones

Imagine commissioning a house and not seeing anything until the builder hands you the keys.

You might get a beautiful house.

Or you might discover that the kitchen is on the wrong side of the building. šŸ˜„

Digital projects work the same way.

Regular milestones create opportunities to review progress while there is still time to adjust direction.

This helps:

  • Catch misunderstandings early

  • Reduce surprises

  • Validate assumptions

  • Gather feedback

  • Make decisions progressively

  • Keep complex projects manageable

Small checkpoints can prevent big corrections later.

3. Reviews & Feedback

When a milestone is delivered, you'll have an opportunity to review the work and provide feedback.

The exact review period depends on the project and will normally be defined in the relevant proposal or agreement.

Feedback should focus on the agreed scope and intended outcome of the milestone.

If something doesn't work as agreed, we'll address it as part of the project.

If you want something new or materially different, we'll explain how that affects the scope, timeline, and cost before proceeding.

This distinction keeps things fair for everyone.

Included work is delivered. New work is discussed. Nothing is silently added — and nothing is silently invoiced.

4. What Can Affect a Timeline?

A project timeline depends on more than the work being performed by development.city.

Several factors can affect delivery.

Access & Information

If we are waiting for access, content, approvals, documentation, or other information, the relevant work may need to pause.

This is one of the most common causes of project delays.

Scope Changes

A new requirement can be perfectly reasonable and still affect the timeline.

When the scope changes, we'll explain the likely impact before proceeding.

Feedback & Approvals

Projects move more quickly when decisions and feedback arrive within the agreed timeframe.

Delayed approvals can move subsequent milestones.

Third-Party Dependencies

External platforms, APIs, hosting providers, registrars, payment services, and other providers operate independently from us.

Their availability, approval processes, technical limitations, or changes can therefore affect a project timeline.

Unexpected Technical Issues

Sometimes technology simply decides to be technology.

A previously unknown limitation, compatibility issue, or technical dependency may appear during implementation.

When that happens, we'll explain what we've found and what options are available.

5. Timelines Are Plans, Not Prophecies

A project timeline is a plan based on the information available when the plan is created.

It isn't a guarantee that nothing will ever change.

Our responsibility is to communicate when something materially affects the plan.

If a delay occurs, we aim to explain:

What happened.

What it affects.

What we're doing about it.

What the revised expectation is.

We'd rather give you an honest updated date than protect an old date that no longer reflects reality.

6. Change Requests

Sometimes a project reveals a better idea.

You may see a milestone and realise:

"Actually, could we do it this way instead?"

That's not necessarily a problem.

Changes are part of building things.

When a request falls outside the agreed scope, we'll assess it and explain any impact on:

  • Scope

  • Timeline

  • Cost

  • Dependencies

  • Existing functionality

You can then decide whether to proceed.

No surprise scope creep.

7. Sign-Off

Where formal sign-off is required, milestone approval confirms that the relevant stage has been reviewed and accepted according to the agreed process.

Sign-off may allow the project to move into the next stage.

Depending on the engagement, approval may be recorded through the agreed project communication or documentation process.

The exact sign-off requirements will be defined in the relevant agreement where necessary.

8. What Happens If You Don't Approve a Milestone?

If something isn't right, tell us.

The purpose of a review isn't simply to approve everything.

It's to identify issues while they can still be addressed efficiently.

If the delivered work doesn't meet the agreed scope, we'll work through the issue.

If the requested change is outside the original scope, we'll explain the difference and discuss the options.

A milestone review is a checkpoint, not a trap.

9. The Final Milestone

The final milestone brings the agreed project work together for completion.

Depending on the project, this can include:

  • Final testing

  • Final configuration

  • Documentation

  • Training

  • Handover

  • Launch

  • Acceptance

  • Transition to ongoing support or maintenance

Once the agreed final work is completed and accepted, the project moves into its next stage — whether that's ongoing management, support, further development, or handover.

10. The Principle

We don't believe good project management means pretending everything will go exactly according to plan.

It means having a plan, knowing what you're working toward, communicating when circumstances change, and giving everyone opportunities to make informed decisions along the way.

That's why we build in milestones.

See the progress.

Review the work.

Make decisions.

Keep moving.


The Short Version

Milestones make progress visible.

Reviews catch problems early.

Clear scope prevents surprises.

Communication keeps timelines realistic.

Change requests keep evolving projects transparent.

And most importantly:

We'd rather show you progress along the way than disappear and surprise you at the end.

Build better. Connect smarter. Scale sustainably.

#ForPeopleForPlanet


Was this article helpful?