1

In a discussion about the project plan with my team we collected activities, brought them into order and defined end dates. When we came to defining start dates and durations one of the elder team members (with some PM experience) told me, that it wouldn't make sense to define start dates because we only need the end dates of each action and it is in the duty of each member to start his own action at the right time. Other team members chimed in telling me that each estimation would be a lie. In my opinion this is plain wrong. I agree that estimations of effort are always inaccurate to a certain degree, but this is life and one could try to handle it by time buffers. Otherwise these team members are just telling me that they don't know much about their job or are just too lazy to think about their work. Leaving out the start date and durations for these silly reasons makes it just impossible for me to control the project and ask for a status before actions are delayed. Am I missing something that old practitioners know? Otherwise - how do you get such team members to reliably provide the desired information?

1

There might be lots of reasons why your team doesn't want to give you estimations. Let's discard the ones that imply that your teammates are bad.

You're right when you said: "estimations of effort are always inaccurate to a certain degree"

I would add that the degree of uncertainty depends on the nature of the project you have.

Image taken from: https://www.pinterest.de/pin/232990980699736881/

Image taken from: https://www.pinterest.de/pin/232990980699736881/

If you're project's requirements are really clear and your team has the knowledge on how to do it, try breaking down your requirements and finding out what they need to estimate and then push them to give you an estimation.

But, if the requirements are not clear or your team doesn't have the knowledge or both, then estimations are useless.

In the second case I would use an agile approach, break down the project in small milestones, prioritize them to deliver value ASAP to the customer and set "expected" delivery dates to your team to use them as motivation.

Good luck with your project.

1

Otherwise these team members are just telling me that they don't know much about their job or are just too lazy to think about their work.

I don't know about you and your company, but I haven't seen a single project where the project manager provided enough information to actually make a guess worth calling an estimate. I have seen plenty where the best guess would have been "somewhere between 2-3 and 300+ days". People are told that such an estimate is not acceptable and they are bad at their job for not knowing better, but then are not given better grounds to guess on, so after a while, they resort to saying it cannot be estimated.

If your people tell you they cannot estimate, they are not bad at their job. If they were bad at their job, they'd give you a horribly wrong estimation, because they did not see the uncertainties. They see what is wrong with the data they have. You need to fix that by giving them better information.

If they tell you they cannot estimate, ask them what they need to estimate.

Once you have an estimate (and this might require work on your part first to gather better requirements), the start dates are nothing to discuss in a meeting. Any program worth starting will give you a chart with start dates when you feed it end dates and durations.

  • Thank you! That's a really good point I actually haven't thought of yet. – John Doe IV Apr 26 '18 at 10:45
1

Plannings and estimations on project (or project phases duration) are valuable in both more and less deterministic environments.

In more deterministic environments you will let your company allocate the precise volume of the resources and hence do not waste or freezing ones for actually addressing unnecessary risk buffer of your project but rather put them to support the activities which do really require them. In other words that will help to make the resource balancing more efficient.

In less deterministic environment the value of the estimations which are almost always a lie is to provide some sort the initial approximation for certain types of tasks in certain circumstances of a particular project specific. Having ones a manager works to re-mediate the factors impacting the deviations to minimize the deviation and hence make the environment more deterministic (see above paragraph)

0

Notwithstanding what agile practitioners might think using agile as a method, your thinking is spot in. Without planning values, you cannot measure performance and forecast where you're headed. That's great for your workers so they don't have to answer to any unfavorable variances and can report all is great until it's not.

Stick to your guns.

  • 2
    Estimations are essential in Scrum. You can't plan the sprints if you don't know what you'll be able to achieve. I suggest that you remove the first sentence, because it's irrelevant for your answer. – Christian Strempfer Apr 26 '18 at 6:25
  • I know little about agile and wanted to leave an opening for a possible difference in view consistent with that method. I know there is a "no estimates" crowd, which, as I understand, is a segment of the agile community. I may be wrong there but nevetheless wanted to make a nod to other schools of thought. – David Espina Apr 26 '18 at 12:22
  • Another negative vote with no comment. This is getting ridiculous. – David Espina Apr 27 '18 at 12:13
  • 1
    Don't worry! I appreciate your answer and upvoted it. It will be shown when I have enough reputation. Your answer helped me and encouraged me to insist and to give my team members a reason. They moaned but we managed to estimate efforts and find the start dates. – John Doe IV Apr 27 '18 at 13:26

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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