2

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?

  • 3
    Is the fundamental problem that the client wants to control the schedule format (manageable; work to your schedule, provide client their format), or that the client refuses to pay on schedule (danger!! danger!!) – Mark C. Wallace Sep 22 at 11:37
  • Is the client objecting to the use of milestones in general or the specific things that you have identified as milestones? – Thomas Owens Sep 22 at 12:42
  • @Thomas Owens: The client states that there is nothing in the schedule that concerns me.For example we defined "provide hardware" as a milestone (a task with duration zero) because its delivery is the responsibility of the client. – user42766 Sep 22 at 12:48
  • 5
    I just want to make sure I understand. You added milestones to represent points where the client is responsible for something that, if not done (or not done on time), will have an impact on downstream activities in the project. The client wants these milestones removed from the project schedule. – Thomas Owens Sep 22 at 12:53
  • @Thomas Owens:Yes. – user42766 Sep 23 at 5:14
8

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.

| improve this answer | |
  • 5
    David makes a good point: Perhaps the use of the term Milestones is the sticking point, and if so, could the word "Dependencies" be used instead? A dependency is, in effect, an "input" which allows the plan to progress, whereas a milestone is arguably an output resulting from the completion of tasks in the plan. – Iain9688 Sep 22 at 18:32
5

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).

| improve this 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.

| improve this answer | |
  • The client claims that nothing should be defined for him to do. Even a milestone. We are now looking for a document/evidence/standard to show that using a milestone is common. We are looking for a reference that explicitly allows the contractor define milestones. – user42766 Sep 22 at 9:48
  • @user42766 why do you want to define milestones? Have you considered using Scrum / time-boxed iterations instead? – nvogel Sep 22 at 9:52
  • No. For example, the provision of hardware by the client. – user42766 Sep 22 at 9:55
  • 4
    So, the provision of hardware by the client is a dependency, not a milestone, in my view. You are dependent on him providing the hardware and if he doesn't do it, you can't progress to the next stage in your plan. – Iain9688 Sep 22 at 18:34
  • 1
    @Iain9688 I have seen dependencies represented as milestones often on schedules before. It's bad practice, but appears common. – fectin Sep 23 at 16:04
2

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.

| improve this answer | |
  • Is there no need to provide a milestone in a schedule? milestone that will be done by the client should not be explicitly listed in the schedule.For example, if a piece of hardware needs to be provided by the client on a specific date,No need to express it in the schedule? My Question is "Where it is explicitly stated that some jobs can be defined as milestone for the client." – user42766 Sep 22 at 11:02
  • To me a milestone is a given state of the project, with length 0hours, and "provide hardware" is a task. Will that ease you client? Then you will have no milestones for the client. As to where it is explicitly stated, have no idea. – HarrySolsem Sep 22 at 11:50
  • As i know " Provide hardware" when its delivery to the contractor is the responsibility of the client can be used as a milestone.Activities that are committed by the client and are required as a prerequisite for the activities of the contractor to be performed, they need to be defined as milestone. – user42766 Sep 22 at 12:38
1

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.

| improve this answer | |
0

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

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.