How do you tackle an engineering project? 4

[milkshakelake]

My way of tackling a project is to do the easiest thing first. I think about water going down a rock. It will take the easiest course. So in reality, that's something like opening up the drawings. Pretty easy. Then the next easiest thing to do is to find the area of the problem. And then find the span, loading, etc. Just one small step at a time. When it gets to the advanced stages, I already have an idea of everything so I can look at the codes and calculations from a top-down view.

I used to look at a project top-down from the start, like trying to consider every possible thing and seeing what's important first. 11 years into it, I decided to start with small things first. I basically flipped it around and it's working for me. However, I'm wondering if it's really a good way to do things.

How do you methodically tackle an engineering project or problem? I'm pretty open to suggestions.

 

[CWB1]

Every day I prioritize the current to-do list and work the highest priority task until completed or stuck, then move on to the next highest. I avoid multi-tasking and jumping between tasks needlessly to avoid efficiency loss. I cant say Ive ever heard of managing a project's tasks based on difficulty. Most every project I've ever encountered needed tasks completed in a fairly specific order with varying difficulties throughout, regardless if the project is completed in an afternoon or over several years.

 

[GregLocock]

If I could be bothered i could find a day by diary of what decisions or actions are needed each day on a specific vehicle design project. We go down the V, and then we go up the V.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[Latexman]

Begin with the end in mind! Take the time to Gantt chart it!

Good Luck,
Latexman

 

[mtu1972]

Early in my career I was managed in a way that gave me specific tasks and expected time frames for review by the Project Manager. This helped my get to a project management position at my second job; a design build contractor.

Third job was for a consultant working on commercial projects for Architects. I had multiple jobs with several clients and was totally overwhelmed. A contemporary, that was there before me, saw that I was stressed. He suggested that I make a priority list for all tasks for the next day, and then try to tackle them in order and keep from being distracted.

This really helped me stay on track.

My one problem was having been raised Catholic, I had trouble lying. I kept all active project files on my reference table. When the secretary would let me know a client was calling, I would move their file to my desk, so that I could say “it’s on my desk right now”.

This was before computers and emails, but I continued that process for the rest of my career. I checked emails at the start of the day, before lunch, and at the end of the day so as to avoid the distractions.

gjc

 

[GregLocock]

In another thread I suggested an approach to excessive numbers of projects

1) prioritize them. share this list.
2) work on project 1 for a day or until I find a blocker. Fire off enquiry to resolve blocker
2) work on project 2 for a day or until I find a blocker. Fire off enquiry to resolve blocker
3) if blocker 1 has been meaningfully resolved switch back to project 1, other wise work on project 3 for a day or until I find a blocker. Fire off enquiry to resolve blocker

and so on and so forth.

Typically this means I'll have always looked at 5 projects if not 10 in a week. I'll be able to honestly say I've looked at them and progressed them. Worst case scenario I did this and cleared my backlog in a month. Everyone can see their jobs are being worked on.

I'd only reprioritize every couple of weeks, otherwise I'd spend more time discussing that than working.

These days I rarely take on more than 2 projects at once, but then I can be picky.


Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[milkshakelake]

Thanks for the responses. I was more interested in how to break down a specific project rather than a number of projects, but this is pretty helpful. The main thing I'm understanding is to have a list of priorities. I used to do this and got rid of the practice, but it's probably time to bring it back.

@CWB1 That's exactly what I was conflicted about. If a project takes a long time, maybe it's good to get the easy things out of the way first. For example, I design mid-rise buildings, so I start with the easiest thing. It's usually the top floor and I work my way down. But I guess real life doesn't work that way. Clients want to get foundations done first, which is almost impossible unless the entire building is designed. But maybe I can prioritize that and do a rough design of the upper floors so I can do a conservative foundation design.

 

[Settingsun]

As you mentioned, work out the client's priorities and also find out why they need the info and what they will do with it. A lot of clients don't understand design so don't ask for exactly what they need. You can often help them while also helping yourself by changing what will be provided early.

Tough to be specific with a general question, but you mostly need to start with a sound concept for gravity/lateral/seismic resistance. Use rules of thumb, similar experience or quick calculations to rough-in member sizes. Get a second set of eyes at that point.

If you need to design the foundations early, look at what the result is sensitive to. Refine that input if necessary (eg slab thickness is probably more critical than the column dimensions for dead weight), or be conservative. But it needs the sound concept in place.

 

[milkshakelake]

@steveh49 It's a very general question, not asking about any project in particular. That makes sense though, and it echoes what I was thinking. Do a rough and conservative design for things that aren't a priority, and refine them later.

 

[msquared48]

I initiate the tackle at the foundation, at the feet.

Mike McCann, PE, SE (WA, HI)

 

[Ron247]

For me, it matters whether I am trying to solve a problem a client has or trying to help them achieve a goal. To me, I approach each one differently. Goals can have multiple things to do that help achieve the goal while problems tend to have very few solutions to enact and sometimes only one.

A Client who says they want to be the best at something in town (a goal) is not the same as one who says they want to know why they are no longer considered the best (a problem).

In either case, I want to first address any item that is a must versus criteria that are flexible. It does not matter if I design a really great structure that cannot be built by the end of the month if the end of the month is a must.

How easy some portion is has never been my starting point. When I do PEMB foundations, I always do wind load first which is much harder than DL+LL. That is because I have learned over the years that where I practice, Wind almost always controls a "typical PEMB" foundation. I do all the resizing for wind and generally only have to provide the checks for DL+LL. I have never had to resize my foundation for DL+LL for a conventional PEMB. That is not true when there are mezzanines and cranes but it is true for the stereotypical PEMB.

 

[drawoh]

My way of tackling a project is to do the easiest thing first...

I do the hardest thing first. The hardest thing is where my approach is most likely to fail, forcing me to re[‑]think my approach to everything. The inherent nature of easy things is that there is more than one way to do them.

--
JHG

 

[271828]

I start by studying the emails or other correspondence and the drawings for a while and accumulate a list of questions. With this first list, I'm trying to get as many questions in the pipeline as possible. After that, I'll prioritize tasks that get other people (subconsultant engineers, detailers, etc.) working so that we're working in parallel as much as possible.

 

[dik]

Bob Cameron, a manager of one of the offices for one of the companies had a method for his mail... He'd put them in three piles... one for urgent, one for pressing, and one for of little use... he'd throw the latter two piles into the trash and look after the urgent... next day with the mail, some of the items in the second pile would move to urgent and some would move to 'of little use'... he'd deal with the new 'urgent' group...

Rather than think climate change and the corona virus as science, think of it as the wrath of God. Feel any better?

-Dik

 

[CWB1]

milkshakelake, sorry but it sounds like our work environments are vastly different so my advice may not be meaningful. Task difficulty never enters my prioritization bc its irrelevant and would quickly get me into trouble. If the first or last task of the day is either the easiest or most difficult then its purely coincidence. If I work on both the easiest and most difficult tasks in my current backlog then its a truly special day. Over the course of a project, task difficulty fluctuates up and down greatly. Simultaneous to design I'm often completing the required DFMEAs, on some projects the design is easy and the documentation difficult and others its the opposite. More often than not, my prioritization is driven by the team or customer's needs, not my own choices/whims/methods.

dik, your mention of trash-sorting reminds me of another division's President at a former Fortune 50 employer. He recommended sorting your email inbox into project folders 2-3x daily and not viewing any of them until after sorting. Not only does that keep the inbox clean and help locate old emails, but working within a specific project folder keeps you focused on that project so you're not losing time jumping between projects constantly.

 

[skeletron]

I use the "inbox sorting" method described above. It helps puts everything in the assembly line of tasks, and reminds me when to bill projects too...which, I guess is also important.

My method, based on the type of projects I have, is usually based on whichever fire needs to be put enough faster than the other fires. If they are all blazing pretty hot, I'll do the easy, straightforward ones first before taking a deep dive on the more involved problems.

 

[milkshakelake]

To all the commenters, I forgot about this post. Sorry about that. It was one of those situations where I had a ton of work coming in at once and started to ignore other things. But I appreciate all of your responses and am always trying to understand your advice and improve.

@Ron247 Where I practice (NYC), lateral is a concern of course and is usually the first point of focus. I haven't done PEMB for about 7 years so I don't know much about that. I agree that DL+LL controls foundations. Lateral tends to control shear walls and/or bracing, so it's good to get that out of the way first.

@drawoh The reason I do easy things first is because it's a good way to get the project started. If the hardest thing might end up screwing the project, I need to be able to identify it as soon as possible. It's difficult sometimes because it doesn't come up until a late stage of design, but it's definitely something to keep in mind.

Another point is that hard things take a lot of mental energy and nobody has unlimited amounts of that. So I could get myself or an employee to tackle a hard idea, but it could end up costing a lot of hours for both of us. If we start with an easy aspect, me or my employee can get used to the project and get a feel for it. But at the same time, if I miss something that could drastically change the design, that could be bad for the project and cost more hours overall. It's a tough business and not straightforward. Still trying to figure it out. But I agree with your advice overall.

@271828 Agreed, this is a good approach.

@dik Nice, I need to start doing that with the mountains emails I'm getting.

@CWB1 I get that, thanks. I'm still trying to figure out an optimal approach because I understand that not everybody can do difficult things all the time and that's why it's okay to relegate work methods to someone's whims sometimes. For example, I got like 20 RFIs and NCRs in a week and each one takes hours to resolve, and all are important, including other projects that are still in the design phase. It's also hard to tell someone that they need to "get this done right now." I've lost three employees with that mindset. Holy crap, maybe I'm a bad boss. I'm trying to soften up but maybe I'm taking a totally wrong approach. Maybe I'm just taking on too much work and getting burned out and burning out my employees. But I don't have to make decisions right now, and I appreciate the advice. Just ranting and unloading a bit.

@skeletron Agreed. It's better to put out hot fires first.