Zoho Projects: Phases, Milestones, Dependencies and Templates That Last

Most services businesses build a template after their third painful project and abandon it by the tenth. The usual reason is that the template described one particular engagement in detail, so every new project began with deletion.

Phases, and why they should be client-recognisable

A phase is the level at which a client understands progress. “Discovery”, “Configuration”, “Data migration”, “Testing”, “Go-live”, “Hypercare” — these are meaningful to someone outside the delivery team, which is what makes them useful for status conversations. Internal phases named after activities the client has never heard of make an accurate plan and a useless report.

Dependencies: the part that earns its keep

A dependency states that one piece of work cannot begin until another finishes, and it is what turns a task list into a plan. Its value shows up on the day something slips: with dependencies recorded, a delay of four days on data migration moves testing and go-live automatically, and the conversation with the client happens immediately rather than at the next status call.

Two dependencies matter more than the rest in most engagements, and both cross the boundary into the client’s own organisation: the arrival of data, and the availability of the person who can approve. Recording them as real dependencies rather than assumptions is what makes a slipped date a shared fact instead of an argument.

Milestones, and what makes them worth having

A milestone that cannot be evidenced is a status update. A milestone that can be is a decision point, and in a billing relationship it is often a payment point too.

Timesheets, and the number they produce

Time logged against tasks answers a question no status report can: whether the engagement is profitable. Two figures come out of it — effort against estimate by phase, which tells you where your estimating is wrong, and cost against revenue by project, which tells you whether the commercial model works. Both need time logged at the task level rather than the project level, which is the discipline most teams find hardest and most valuable.

Client visibility

Zoho Projects can give a client a view of their own project — milestones, documents, and the tasks they own. Where that is used, status meetings change character: they stop being a report on what happened and become a conversation about what is blocked. Where it is not, the delivery team spends a meaningful share of its week producing status in a format the client can read.

Frequently asked questions

How detailed should a template be?

Detailed enough that a new project manager could run the project; not so detailed that half of it is deleted each time. If a task appears in fewer than three of every four projects, it does not belong in the template.

Should templates be per service or per client?

Per service. Client-specific variation belongs in the project, not in a proliferating set of near-identical templates.

How are client-side delays handled?

As dependencies with an owner on the client side. Recorded that way, they appear in the plan rather than in a difficult conversation later.

Projects or Sprints for a delivery team?

Projects, where work is planned around deliverables, phases and billing. Sprints, where work arrives as a backlog and is delivered in iterations. The deciding question is whether commitments are fixed by scope or by time.

Where to start

Open your last three projects and find the phase that slipped in all three. That is either a systematic estimating error or a missing dependency — and the template is where the fix belongs.

References

Topic inspiration: the Project Management section of the Zoho Blog. This article is Kelevo Software’s own analysis and wording, written from our implementation experience; no text has been reproduced from Zoho’s publications.