Crew Size feature request - Page 2 - D-Tools Forum

David_Haddad · 12-31-2009, 01:23 AM

Originally Posted by ekalpakoff

Considering that D-Tools as a cost estimation software package I fail to see why something that could be utilized to better cost estimate or catch an "i got ya" in a project would be an "excessive feature"?

There's actually a term in the software field that addresses this issue - "software bloat". Software companies constantly have to balance what features are truly needed versus adding tons of features may make the software more and more cumbersome to use.

I don't mean to rain on your request, I just happen to be of the opinion that adding really frivolous features can be dangerous, and from my perspective this is frivolous. If I have a 50" TV being delivered I don't need the software to tell me I need (2) techs to do it.

Have you considered using one of the other options that are already available that could accomplish this such as phases, or one of the customer number fields? For instance, you could make one of the custom number fields be "# of techs needed".

ekalpakoff · 12-31-2009, 01:39 AM

To dig deeper into the concept, Since D-Tools is estimating labor on a project, there are certain projects that will require a larger crew count than others. There are also individual items that require it. In places like the project summary, if would be nice for the summary to show a line saying that 2 or more crew members are required on site. Maybe in D-tools -> Options there could be a field for "Crew Size" that would talk to the Work orders section to better schedule out crews. Also, if there was a "Distance to job site" field in D-Tools -> Options then when you added items like travel, lodging and per-diem in to a project it would account for the "required crew size".

I'm not saying that this would be the right way to do it but I can speak for our firm, and probably a some others, in saying that we have estimated a project for one crew member including that one crew members travel, when the project really needed two or three people and we had to eat that cost. (my own admission of guilt). To me it seems like a lot of information/features could be build from this little field.

grichards · 12-31-2009, 05:32 PM

Originally Posted by ekalpakoff

To dig deeper into the concept, ...

i can understand where you're coming from on this. we have a similar need, not so much to determine if we need more than one tech for a particular item, but for estimating the travel time, duration of install time on site, per-diem/lodging amongst other things.

I've used project custom properties to input miles to the job site, number of crew, etc (as David_Haddad suggested) and written a report that crunches all these numbers for me. Its still a little clunky, but it produces the rough numbers i need.

you could probably utilize the product weight field (or the dimension specs) to determine the need for multiple techs and produce a report that will highlight these items. I still think using a phase for items that need multiple techs would be a viable solution as well. This will show up in your project summary (as you requested), and you can easily pick them out to build your work orders.

sure, it would be nice if the software had all this setup internally and it all worked well without bugs or gotchas, but it doesn't and it won't anytime soon if more and more keeps getting piled into this program. I'd prefer the development team get the basic mechanics working PERFECTLY* first: a fast bug-free PDM, quick versatile integration with drawing tools, TRANSPARENT OPERATION WITH DRAWING TOOLS, data fields that are accurate/consistent/meaningful and have their info considered throughout all aspects of the software (i.e. the OFE giving-away-free-gear bug).

if only %10 of feature requests get fulfilled and %90 of the bug incidents get handled (and that means regression tested a.k.a. no new bugs introduced) then we would be very happy end-users. as of now we're considering porting our data to something else and dumping this bloated software.

all that said, if you find a workable solution for this i'd love to hear what you end up with but i'd still vote nay on the added field.

*understanding no software is perfect, but if it operates transparently with my task at hand i would call that perfect.

**Dave Kirn** · 01-01-2010, 02:32 PM

I really like the idea of adding a phase that would indicate the necessity of additional techs. However on the data side it would either need to be adopted by all users or you would need to "groom" all of your data and change the required phase