3

Virtually everything related to the business core of the company I work for relies on some item numbers being generated sequentially. Unfortunately, a long time ago these item numbers were defined as a fixed point with no decimals and they are running out of possible numbers.

Of course, some departments were smart enough to define these as at least 32bit integers and can easily accommodate the increase.

I am currently working for various data warehouse satellite applications and I know that the data warehouse itself must accommodate the change. Data warehouse developers were asked to estimate the change and they provided a very large effort (about 800 person-days). This information is provided within an internal platform along with the estimations for all involved business units.

Having worked on an application to provide automatic testing for data warehouse I know what they must change (e.g. drop indexes, statistics, alter the column, recreate indexes, recreate statistics, update some proprietary metadata for all involved tables, check and change temporary tables precision in some scripts, test that everything still works etc.) and I think their effort estimation is very large.

To answer some issues in comments/existing answers: I can back up this with facts like number of tables affected, number of metadata files affected, as I am aware that without this there is no point in discussing this issue.

Also, there was an e-mail explaining why the effort, as one of the product owners also wondered about this. The effort is mainly proportional to the number of affected objects (tables and reports) and contains no reference to obscure components or a big reserve for the "unknown".

Why does it matter?

Since we belong to the same business unit and its budget is limited, if this effort is approved, our team will receive a small budget for next financial year. This is important as we are struggling to have an extra member to cover the workload.

Only two persons I can speak to come into my mind:

  • people manager - very loosely connected to data warehouse people and also very busy
  • the product owner for one of the projects we are working on - I have a very good relationship with him, but he is also people manager for some of the persons involved in the estimation, so it looks like a "conflict of interest"

Question: How should I proceed if I suspect about a project being grossly overestimated? (and this affects me and my team)

Improve this question
10
  • 1
    just to clarify on the 800 person days bit: did they say the change in the system will require 3 people working full time for 3 years? maybe it was a typo? – viorel Aug 29 '18 at 12:42
  • @Alex - yes, this is generally a good option. However, there is a poor collaboration between our team and the estimators. They have simply ignored all our past concerns and they are simply not interested in discussing such issues with us. A large effort is very convenient for them as the time/budget can be used to justify delaying other projects. – Alexei Aug 29 '18 at 12:44
  • @viorel - no, there is not typo, as the effort is also accompanied by the estimated cost and I could double check. Yes, that's why I mentioned "grossly estimated". A part of the effort can be justified by the number of affected object as items are a dimension used by many fact tables and by the lack of test automation for reports. Even so, the effort is huge. – Alexei Aug 29 '18 at 12:47
  • 1
    Have you actually worked with this specific codebase or are you evaluating based on some other system? Are you aware of all of the technical debt that may be impacted by this change beyond the work that you described? Be wary of contradicting someone else's estimate if you don't have specific knowledge. – cdkMoose Aug 29 '18 at 12:48
  • 1
    @Mawg - we are talking about SQL here, but it also supports custom types that rely on standard ones. What you are saying makes perfect sense, although some database have some limitations about these (maybe usage in some temporary tables, usage in indexes etc.). Anyway, in our case the design is really strange: they defined an integer value as numeric/decimal(x, 0), that is a fixed-point number with max x digits and no decimals. – Alexei Aug 30 '18 at 7:16
4

A couple of things to consider, are you really looking at the overall picture or just the one you know about? You very well may be in a position that you don't know what you don't know. Meaning that there might be a number of scripts and/or applications that could very well need to be reworked. Some of these could contain a large amount of tech debt or simply be "black boxes" since the devs who wrote it are no longer with the company and nobody's ever had to look at it before. It could be that they don't even know what they don't know and have to build out an environment to test everything and even then they might not know what all will be impacted. Not to mention if there are any customer-facing APIs that will need to be versioned and maybe they don't have a way to vesrion the system so they'll need to build one.

It could be a host of things, that at this point you seem to be basing everything on only what you think you know about there side of the business, have you actually asked them why it's going to take so long?

Improve this answer
1
  • 1
    Yes, you have a valid point here. There was also an e-mail sent to justify the effort, I will add the information in the question. – Alexei Aug 29 '18 at 13:55
3

and I think their effort estimation is very large.

Can you back this up in anyway with facts and data?

How should I proceed if I know about a project being grossly overestimated?

If you can back this up factually, with data, then take your claim to your manager. It will be up to them as to what to do with the information you provide. You may also want to consider what your solution might be.

Be sure you can back up your claim.

Improve this answer
3

Let me start with I am generally the guy that provides the estimates for projects just like these to folks just like you, and even I question the validity of an 800 hour estimate, but I wound't go so far as to accuse it of being grossly overestimated quite yet. There are quite a few things that can make a seemingly simple change like this take much longer and be much more complicated than initially meets the eye (e.g. data set size, current design limitations/shortcomings, technical knowledge, technology limitations, etc.).

Question: How should I proceed if I know about a project being grossly overestimated? (and this affects me and my team)

Honestly, I think you're absolutely allowed to ask for a breakdown of work. You may actually find other tasks you need to accommodate into your project that hadn't been thought of or planned for yet, and you should mention this being the reason you need further details. People hate to be targets, but love to contribute to a solution and feel they are helping out.

Improve this answer
2
  • It's actually 800 days. 8-9 years of work for a single person. I would love to see the breakdown on that. – viorel Aug 30 '18 at 5:32
  • Ha! I guess I'm really suspect now, but maybe the person providing the estimate means calendar days instead of work days? My approach is the same nonetheless, as it should help everyone come closer to a more realistic scope and final estimate. – John Eisbrener Aug 30 '18 at 12:24

Not the answer you're looking for? Browse other questions tagged .