Engineering Managers: how do you typically track time for your projects?

[nuuvox000]

I'm the lead engineer at a small HVAC/Plumbing company and I was tasked to find a way to track engineering costs to help with future estimating. How do you typically estimate and track your costs? Is it just based on previous projects? One suggestion was that we track our costs on how much time we spend by system (domestic water, duct, waste and vent, etc.). We're small enough that there are only a few of us and so we all spend time on all systems during the day; seems very tedious and inaccurate to break it up by system to me.

In the end, I'm mostly just looking for ideas on what anyone else has done. Thanks!

 

[phamENG]

Are you looking for format or a physical method?

Physical method can be anything from a paid service (if your company has Quickbooks, look into the Time Tracking function) to a custom spreadsheet to paper time sheets. I've done dumb spreadsheets that are essentially just paper with manual entries - those are annoying and easy to put off and get stuck trying to remember what you worked on Tuesday afternoon of last week. Then I built a smart timer (I think I posted on here somewhere) where I enter the project I'm working on and the kind of task and click a button when I start and when I finish. At the end of the day, another button totaled all of my time for each project (so even I switched back and forth, it would give me a single time entry for my time sheet. Now, I have a paid service that's part of my project management software that allows me to track project, task, and other attributes. For something small and simple, look for things like Harvest and Harpoon, and type "time tracking software" into google and explore the plethora of options.

As far as format goes, it depends on your end goals. If you want to see what kind of system is more profitable so you can focus your marketing efforts in that direction or seeing which are least profitable to explore efficiency and/or training improvements (or both), then breaking it up by system would make perfect sense. If you just want to make sure people are working a certain amount, then just having an 'engineering' task would probably suffice.

 

[CWB1]

Typically labor cost and schedule estimating are based on historic data from previous project plans. Each plan should be subdivided into the smallest possible tasks so there is no ambiguity or difference in tasks project-project, and project planning always done by the team members signing up for the work. After a few projects you should be able to very accurately estimate lengthy projects by knowing the time needed for each task and how many times you do a specific task. ie. You know the historic median time per bolted-joint analysis and the new project requires 500 of them, so you know how long to plan for BJAs via multiplication. Add up the time needed for the iterations of each standard task and you have your total project length before team and management reserves (buffer). The hardest parts are setting up a system to collect the data and having the discipline to not create 500 different varieties of basic tasks like BJAs.

This is where a basic understanding of project management practice really shines. A decent PM can quickly/easily show you data on every aspect of the businesss - whether your quotes are low/high, who is/isnt working efficiently, what niches/projects/etc earn more/less profit, etc.

 

[nuuvox000]

Thank you very much for your responses.

 

[dik]

There are 3 metrics that I used to use. Time expended, number of documents produced and their complexity, and the value of the work and I used values based on these factors to keep 'a running total'. Over the years, the values 'stabilised', and I used them for estimating project costs.

-----*****-----
So strange to see the singularity approaching while the entire planet is rapidly turning into a hellscape. -John Coates

-Dik

 

[milkshakelake]

In practicality, people will hate you for making them granularly track each task. Track time by project, not by task. This way, they have to note it only a few times a day, and usually just once. Make it easy to use, and people will use it. We all use Virtual TimeClock (paid app) at my company. It has the bonus of finding out when employees are late. We used to use TrackingTime (also paid) which was great, but had some issues that probably don't apply to you. phamEng mentioned Quickbooks time tracking and a few other options. I've used Excel sheets before but it's a pain in the ass to compile it to something useful. A previous company used printed forms to track time, which was a complete waste of energy and probably is sitting in binders somewhere, taking up space.

If you do decide to break it up by system instead of project, I'm afraid that you'll have people just putting stuff into the program to satisfy you. The info might be inaccurate. To gauge efficiency, you have to actually sit down with people and figure out how much time they're spending on things, and what processes aren't efficient.

 

[CWB1]

In practicality, people will hate you for making them granularly track each task. Track time by project, not by task. This way, they have to note it only a few times a day, and usually just once...It has the bonus of finding out when employees are late.

Quite the opposite. The first two (& prob biggest) takeaways from both lean and agile philosophies are 1. make work visible and 2. reduce work to small tasks common between projects for good reason. With reasonably granular, shared project plans the team/project runs itself efficiently with little/no management. Management and team members can always see each others' progress and provide customer updates, tweak the schedule, hold each other accountable, easily support others, and adjust for any issues without wasting time in unnecessary meetings/discussions/emails rehashing details. They can also plan their personal lives/appointments/vacation well in advance during low-risk periods. Without detailed project plans companies are the definition of poorly managed. Employees end up wasting a ton of time (which they perceive as a reduced paycheck), have little predictability to their schedule/workload, management usually seems controlling/micro-managing due to their frequency and detail of involvement, and fire-fighting unforeseen issues is constant. About the only thing culturally worse than being poorly organized is insulting nonsense like criticizing a salaried employee's hours.

Updating task statuses shouldn't take more than a few minutes daily, usually its done either directly in the project plan or via a third-party app.

 

[phamENG]

Quite the opposite. The first two (& prob biggest) takeaways from both lean and agile philosophies are 1. make work visible and 2. reduce work to small tasks common between projects for good reason.

Depends on what you're doing. If your project is "Design the new F-150"...yes, I would agree that a detailed project breakdown would be crucial to anything resembling success. But if the project is "size a beam and its foundations for a home renovation" I'll spend more time breaking it down by task than I will running the analysis.

So I break things down by high level task - engineering, drafting, 3-D modeling, travel, meetings, field investigations, etc. - for my time/expense tracking. As projects get larger, I'll break out daughter levels to my budget lines. Instead of just "engineering" I'll have X hours for gravity framing, Y hours for lateral force resistance design, etc. So where that sort of granularity has value (how much would the new software to run this or that analysis really save me?, one candidate is great at wood design, the other has been doing steel design for 20 years - which will fill the needs of the firm better?), I track it, but don't waste time on it when it's really just going to be data for data's sake.

 

[CWB1]

I start creating project plans when I need more than ~4 hours. Planning time scales with complexity so at the low end its only a few minutes time. Smaller projects are usually the most time-sensitive and least tolerant of mistakes, so planning them is actually more critical.

 

[phamENG]

Smaller projects are usually the most time-sensitive and least tolerant of mistakes, so planning them is actually more critical.

That's certainly fair. I've had my share of small project budgets blown by unpleasant percentages even though I was only 30 minutes over. But that's also why I've shifted to an hourly service model for my small projects. In my industry/market, I find schedule busts on small projects are often the result of ill prepared clients significantly more than a mistake or scheduling error on my part. So I shift that risk to them. That reduces the importance a bit on detailed planning for those. My threshold for ramping up the detail is usually 8 hours - if I'll spend more than a day on it, I'll start breaking out tasks.

 

[milkshakelake]

@CWB1 How do you track time granularly in practice? I was looking at Cattr, which seems promising. It's also open source and self hosted on Linux, which is right up my alley. No subscription costs.

I haven't really been doing project management in the way you described. I talk to the employees and see where their time sinks are, and see if I can speed it up. It resulted in some things like buying software, making design tables, and developing VBA calculations for things not on the market. I'm open to trying a new way.

One item not exactly related to time management is that I can't see certain processes being sped up without an unattainably significant investment. For example, things like member and column schedules can be automated. But the basic drafting and putting details together is a fixed time thing, once standards and training are in place. The task just takes so much time. I think the only way forward would be something like AI doing it for us. So I just focus on other places I could make improvements.

 

[CWB1]

I always prefer software that I know well and have templates and data for. Given the choice my personal default is MS Project for traditional lean/waterfall and (less commonly) Jira when I am forced to use agile/scrum methods. Regardless, I spend time up front sketching out the necessary tasks, working top-down starting with high-level milestones before executing the plan. Some projects allow 95% of the planning to be completed up-front, others have too many unknowns but will usually allow completing a detailed plan by 10-20% of the project's completion - fairly early.

Smaller projects for me tend to be the most intense bc they have the highest number of unknowns and technical constraints, and no time for mistakes. Rather than new design I'm often brought in to resolve issues when the original engineer is either unavailable or simply unable (often why theyre unavailable). My time and material costs are usually peanuts vs cost of delaying development or production downtime. I don't waste time but I work VERY methodically to prevent making mistakes - sketch an Ishikawa/fishbone, verify every detail of the design, manufacturing, and usage was/wasnt correct, design and test the solution, etc. The project plan is my to-do list so I dont miss a step or get sidetracked by bad logic, and also my record of work/reviews/approvals. If there is a separate but related issue in six months then I can prove my work was thorough, good quality, reviewed/approved, and that we didnt waste customer time/money.

One item not exactly related to time management is that I can't see certain processes being sped up without an unattainably significant investment. For example, things like member and column schedules can be automated. But the basic drafting and putting details together is a fixed time thing, once standards and training are in place. The task just takes so much time.

Work takes time and good processes run efficiently. Consultants will argue but IMHO PM is more about identifying and preventing lost time than improving good tasks/processes. We're in a complex business and its easy to overlook details, with data we can analyze but without we're guessing. Visuals like a project plan often help identify issues, lots of folks track their gym/diet routines and have a cash-budget in envelopes for the same reason. To each their own on effort vs reward tho.

 

[SandCounter]

This is a helpful white paper on the subject:

Whiteside, J. (2005). A Methodology for Estimating Engineering Details. AACE.

https://icoste.org/aace2005 papers/est04.pdf

 

[milkshakelake]

@CWB1 Thanks for the tips! I like the statement about preventing lost time rather than optimizing good processes.

@SandCounter I'm not OP, but that's pretty useful and will read it

 

[rcnrllala]

Haven't you thought of using various types of software or anything like that? I believe it's not a problem to find an app that would allow you to track your activity and calculate billable hours.

 

[IRstuff]

I was tasked to find a way to track engineering costs to help with future estimating. How do you typically estimate and track your costs? Is it just based on previous projects?

If you don't track time and cost, how will you know what previous projects cost? However, tracking does require some discipline, so everyone will need to be assigned specific tasks and "charge numbers" for those tasks. Then you need to keep track of those charges, particularly if there is more than one project at a time

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[geesaman.d]

In practicality, people will hate you for making them granularly track each task. Track time by project, not by task. This way, they have to note it only a few times a day, and usually just once. Make it easy to use, and people will use it.

I'm here to echo this. At my company we tracked no hours per project. Our projects are mostly small (<40hrs Eng'g) but some big ones (100's of hours). Hours by project is enough, if you can get away with that. Or maybe by project phase.

For estimating, we do have an engineering hours list that we use. If a project involves 5 approval drawings, 5 designs of mostly-standard stuff, with 1 design review, then each of those are a line item on a spreadsheet. Then we include adders for extra stuff and hours for those. By and large, this is no better than a very thoughtful estimate from an experienced engineer, but very transparent and takes the same amount of time. (Also, when a project runs over, makes it straightforward to identify gaps in the estimate or execution).

Other factors that matter in hour estimates in my industry: customers. Some customers don't know what they're doing and/or waste your time endlessly with pedantic processes and documentation. In those cases, we try to factor in extra hours or keep a healthy margin to cover the inevitable (and mostly unpredictable) way they will consume more time than the average customer.