Have you ever wondered what our engineers actually do all day? This year, we’re sharing some details through our “Day in the Life” series. Each quarter, we will feature someone in a different position within the firm who will provide insight into their typical day. First up is Project Manager Douglas Walker, PE, who has been with Applied since 2001. Doug is a mechanical engineer who works mostly with our industrial clients. He recently led our engineering efforts on the award-winning Rolls-Royce Banded Stator facility.

—

7:50 AM

On a typical morning, I arrive at the office, sign myself in on the computer, check my emails, and fill in yesterday’s timesheet. Some regularity in the morning helps me kick start the day.

I’m managing or tracking ten different projects currently. The clients are manufacturers who make electronics, pharmaceuticals, transmissions, fiberglass insulation, and aircraft engines. The projects are all in different phases of completion: a study of utility systems, calculations for safety relief systems, construction of a utility plant, and testing newly installed air handlers at a client site.

As much as I use the computer, I still print a schedule every other day and re-write my task list. This makes me consciously think about my work – who needs information, what decisions are pending, and what deadlines are coming up. Also, project tasks rarely are checked off as complete. Rather, they evolve into something else. Write report becomes add tables, which becomes review formatting, and so on. Rewriting my tasks every couple of days helps me to track the evolution of the projects. I prioritize my schedule so that other people can keep moving forward with their work.

8:30 AM

I review CAD drawings for a piping project. Reviewing a drawing means looking at every pipe connection, every component, every note, and making sure we – as the design engineering firm – have painted a complete and coherent picture of the system we want the contractor to build. On this project, the client was specifically interested in easy access to several important components in their new piping system. After I complete my review of the drawings, I talk through my comments and questions with the designer to brainstorm some ways to make components more accessible.

9:30 AM

I report to one of Applied’s several principals (owners) on each of my projects. I generally check in with my principals informally a couple of times a week to make sure we’re up-to-date. Depending on the project, the principal-in-charge may be heavily involved or may leave most of it up to me. I let them know what project work has been completed recently, what may be holding us up, and whether there are any budget or schedule issues.

10:30 AM

Consultants sometimes get random questions that we know nothing about. A contractor may ask me about the nosing dimensions on a set of stairs, but all I can do is get him in touch with an architect who can help him. Today, an engineer from a site/civil consulting firm calls to ask what kind of valve I would put in a small open sight drainage line. Her client’s idea was to shut off the valve if they want to make piping modifications later. The answer: “Don’t install a valve; wait until the drain dries out.”

11:00 AM

I prefer to leave the office at lunch time. It gets me outside for a little while and I can avoid the phone and email for an hour or so.

12:00 PM

I have a meeting this afternoon with a client. We issued a preliminary report last week. He wants to review his comments with me today. Whether a meeting is a waste of time or productive often depends on how prepared you are to meet. For this meeting, I print a copy of the report, pack some backup materials, and review the main issues before I leave.

12:30 PM

I drive to the meeting early to allow time for parking, badging into the site, and walking to our meeting room. Between meetings and site visits, I spend approximately 20% – 25% of my time out of the office, on average. Getting out of the office to client sites is one of the built-in perks of consulting engineering. With a broad base of clients, I could find myself in three different manufacturing plants in the same week.

1:00 PM

At our meeting, we discuss several issues from our report, including a campus cooling water piping system, a vent gas reclaim system, and electric motor starters on pumps. Most of the client’s comments on our report are to clarify the existing condition of the systems. Contrary to popular belief, good communication skills are essential to engineers. We can analyze, research, and calculate as much as we like, but if we cannot effectively communicate the results to others – often people who are not engineers – then our work adds no value.

2:00 PM

Back at the office, I address the comments I received at my meeting – some of which are simple wording changes; others require more discussion with the engineers who contributed to the report.

I also have a meeting to set up for next week on another project. This one will be another site visit. It’s tempting to just go by myself to the site. It’s cheaper than bringing along a design engineer as well. There won’t be much to see. But no matter how many pictures I take, there is no substitute for a design engineer seeing the worksite for himself. So I decided to schedule two of us to attend.

I have a few extra minutes today, so it’s a good day to check on project budgets and hours. Applied generates a weekly in-house project sheet that summarizes the project funds available and the total charges to date. It’s helpful to look at the raw data occasionally to know who in the office has charged time to my projects and see what parts of the project are in or out of the original budget.

3:00 PM

Last week, one of my projects issued a package of drawings and specifications (narrative descriptions of structural, mechanical, and electrical systems) for general contractors to bid on (provide a price for). The project is a new utility plant for a client’s manufacturing site. There were 122 drawings and over 150 specification documents. With a large package, it is typical that contractors reading the documents will inevitably need clarifications on what the documents say. When we answer questions, we must send them to all the contractors providing bids so that everyone has the same information. I answer some of these questions this afternoon and issue a formal response to all the contractors.

4:00 PM

One of our engineers asks me about the pressure setting for a relief valve. A relief valve provides a safe outlet for the system fluid if the pressure in the piping system rises high enough to damage components. Our project is providing calculations for existing systems.

The engineer’s question is how to approach a relief valve calculation for a system with multiple components that could each have a different pressure rating. Questions like this are fun to dig into: how does the system work? How do people interact with it? These kinds of questions make us find what I think of as bedrock. What is it that officially determines or documents the limitations of a system? In this case, bedrock might be a section of the code (official government requirements), the client’s internal procedures, or a manufacturer’s stamp on a vessel.

As interesting as the question might be, part of my job as a project manager is not to answer it. I need to help the engineer working on the project arrive at an appropriate answer himself. I encourage him to check the code references, verify the raw data, read the client’s operating procedure. Knowing the source will give the engineer confidence in his conclusions.

5:00 PM

Head home. Check myself out. Today was busy, but calm. Tomorrow could be entirely different.