Please, take a moment to look this very short video, just to introduce the topic of this post.
A project manager reminds a project's supplier the approaching of a milestone, that heavily depends from a work package assigned to the supplier’s team.
Probably you will have noticed by now what these people are doing. They are trying to enforce a milestone that had been set some weeks before. Just that they are not enforcing the milestone that they are thinking about. They are not enforcing the milestone “This year, at the middle of July”, whatever that means, “some work packages will be completed, including WP 121-A”. The milestone they are enforcing is "This year, in July, there will be big troubles".
Let alone the fact that months are not a unit of measure, since they have different lengths, and that the same month contains a different number of working days from one year to the other.
The real problem is that “The half of July” has not a shared meaning at all.
Should it be the 15th or the 16th, since July has 31 days? Should it be somewhere in the week that contains the 15th (or the 16th), since the indetermination of the milestone seems to call an equal indetermination? Should it be the tenth working day of July, since normally we have twenty working days in a month?
This sort of things leads inevitably to problems. It would not be nice gather the sponsor and the main stakeholders in a room one month in advance, just to discover two days before that the milestone will be inevitably missed.
And this is just when all the parts involved are negotiating in good faith. If someone is trying to use this carelessness fraudulently to get some advantage, like the case in our short introductory video, there will be even bigger troubles.
Lucky enough, this is a kind of mistake that the greatest part of project managers would not make...but it can happen.
Especially if you are managing a small project, using just internal resources with whom you feel you have a special relationship, maybe a friendship, and apparently documentation is not a big concern for anyone.
The bottom line is to be extremely precise in setting milestones. Always. No matter the project complexity and size, no matter if it is a project with just four team members and one of them is your brother.
Milestones are just moments in time and have no duration, as a consequence they can be set with an extreme precision, a clock's precision. And they should. 15th of July is not a moment, is a time span, it has a duration and this could be confusing. When will your deliverables be ready ? In the morning, in time for the 4pm o’clock meeting with the sponsor or in the evening, just before everyone leaves the office and they are pretty much useless till the day after?
Set your milestones specifying calendar date and time in hours and minutes. This way everyone knows exactly what will be accomplished and when.
Otherwise…look at this other very short video to see with your eyes what the worst consequences could be…
Bye.
A project manager reminds a project's supplier the approaching of a milestone, that heavily depends from a work package assigned to the supplier’s team.
Probably you will have noticed by now what these people are doing. They are trying to enforce a milestone that had been set some weeks before. Just that they are not enforcing the milestone that they are thinking about. They are not enforcing the milestone “This year, at the middle of July”, whatever that means, “some work packages will be completed, including WP 121-A”. The milestone they are enforcing is "This year, in July, there will be big troubles".
Let alone the fact that months are not a unit of measure, since they have different lengths, and that the same month contains a different number of working days from one year to the other.
The real problem is that “The half of July” has not a shared meaning at all.
This sort of things leads inevitably to problems. It would not be nice gather the sponsor and the main stakeholders in a room one month in advance, just to discover two days before that the milestone will be inevitably missed.
And this is just when all the parts involved are negotiating in good faith. If someone is trying to use this carelessness fraudulently to get some advantage, like the case in our short introductory video, there will be even bigger troubles.
Lucky enough, this is a kind of mistake that the greatest part of project managers would not make...but it can happen.
Especially if you are managing a small project, using just internal resources with whom you feel you have a special relationship, maybe a friendship, and apparently documentation is not a big concern for anyone.
The bottom line is to be extremely precise in setting milestones. Always. No matter the project complexity and size, no matter if it is a project with just four team members and one of them is your brother.
Set your milestones specifying calendar date and time in hours and minutes. This way everyone knows exactly what will be accomplished and when.
Otherwise…look at this other very short video to see with your eyes what the worst consequences could be…
Bye.
Quest' opera รจ distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.
