Client doesn't agree to put milestone in project scheduling

Question

When our company has been sent project scheduling to client (which included some milestones like:Advanced Payment , Approval of Phase I, ...), Client rejected the project scheduling and said "Remove Milestones from it" or Provide a document stating the use of the milestone!(Like PMBOK). Is there a reference that mentions the use of the Milestones(related to client) in the project schedule?

Answer 1

Here's one source: https://project-management-knowledge.com/definitions/e/external-dependency/

Simply research "external dependencies in project scheduling." Your schedule will simply be incomplete if you do not have identified in your schedule the dependencies upon which your schedule is based. Your best argument is the word, "dependency."

Your customer wants it hidden for political reasons but he is destroying the credibility of your schedule, which is PM tool. It is just like dulling the blades of the various carpenter's saws.

To get passed the politics, filter the dependencies out for your client's review, but keep them in there so the schedule is working for you the way it is supposed to. That being written, I would only do that after I made an argument why they need to be there and visible to all stakeholders.

Answer 2

You're not communicating well with your client

...and possibly also using your schedule incorrectly.

You're asking about milestones as though they were a pure schedule artifact. However, every example from your question and from your follow-on comments shows that "milestones" are something that your client provides. That is undesirable for at least two reasons:

First, it looks like a sneaky way to modify your contract. (Example: does your contract include an Advance Payment? If so, does it specify any schedule linkages?)

Second, that's not what a milestone is. Here is a more formal definition, but milestones are instantaneous and effort-free points in time, and are usually inflections where the nature of a project changes or where some major line of effort has completed. You will often see milestones used to signify external dependencies, meaning approximately "I don't know what Company X's timeline to baz the foo is, but we assume they will hand us a neatly bazzed foo on March 18." This often hides significant risks, as well as removing your ability to manage that part of your schedule (or your entire schedule if those points are on or near your critical path).

So. The specific feedback you have received is a little weird, in that "don't include milestones" is not normal scheduling practice. However, since your schedule has a flawed approach to milestones, I suspect their direction is more about trying to get you to hand them a useful schedule quickly. If so, arguing about whether including milestones is a normal practice will not be beneficial.

You have given very little information on the project, the company, the client, or your relationship with them, so it's hard to give solid advice on how to proceed. Without more context, the best advice I can give you is to do as they request: Build a schedule based only on activities and delays, like a traditional Gantt chart. If it's based in some software like Project, consider whether the level of detail you are working at could be represented as tasks and subtasks. If you're working with easily-encapsulated phases or lines of effort, consider making them "super-tasks" at an even higher level of indenture. Once you have a schedule that looks good and includes only tasks, look for any points where something major changes (e.g. if there's a Phase 1, the end of the Phase 1 task is likely to be a good candidate). Once you have a list of these points, you can internally track your progress towards them as though they were milestones (or however else your company policies recommend).

You may notice that I have in essence just recommended that you sneakily identify and track milestones. However, there is a difference: if you do this in the order I suggest, you will no longer be using them wrong. You will also be complying with your client's request, and doing so in a way which will hopefully not lead to further rounds of bring-me-a-rock (which is likely if you just turn all your current milestones into zero-duration tasks or whatever).

Answer 3

Two things you haven't mentioned that will have a bearing on this: What kind of project? What is the purpose of the document you are sharing with the client?

The fact that you have mentioned advanced payment suggests you are defining some form of contract. If it's a software development project then many customers may prefer to avoid phase-based milestones because phasing used in a contract can introduce some commercial and practical difficulties. I suggest you could focus instead on prioritised deliverables and iterative delivery.

Answer 4

Why do you need to share the milestones with the client? You could keep the milestones for yourself and present whatever plan you have to the client without them.

Answer 5

The major project Milestones should reflect what is documented in the Contract. Do not even start work without an executed Contract. Look for Contract items like:

1. When does your client want to kick off?
2. Does your Contract specify 10% payment up front
3. Are there any client reviews, meetings, progress updates, risks, contingencies, acceptance tests etc specified?
4. Some client are totally hands-off, but basic interaction and Contract 'intent' must be in place.

Maybe ask your client, how they expect to establish progress payments, how they want to deal with contract variations, how and when are you to be paid, how does the client 'accept' the work, and who validates the deliverables?

Reading a Contract can be mind numbing, but is absolutely crucial when building a task list and schedule.

My approach to detailed scheduling is to 'roll-up' the project milestone summary into the top 10 lines of the schedule, and then have the detailed bulk of the schedule in place below, with Start-Start and End-End dependencies from the schedule body into the roll-up. That way the milestone items can be collapsed independently from the main schedule.

Answer 6

call it checkpoint or payment time or whatever but make sure the contract says you get paid when that item is accepted and also specifies detailed measurable way to show that it was satisfied

for large projects milestones are just waypoints that are hoped to be hit at the time shown so as to help with planning and seeing what parts of the project may be late or having problems