here it is
https://www.amazon.com/dp/B001KR0AMA/ref=dp-kindle...

"The Mythical Man Month" is also a good reference. Written by a guy who managed one of the largest and most critical projects undertaken by IBM. It uses the word 'software' a lot, but applies to any project that requires the workers to think.

The joke is that there will be cheap flying cars long before there is a suitable method for 'no engineering experience' managers to manage an engineering project. Might as well ask how one can choose the members of a surgical team with no medical experience.

One approach is to make use of historical data. If you have it, and are disciplined enough to segregate costs by the appropriate W.B.S., you can use the historical data to "scale" new projects. This means that you do a W.B.S. for the new project, and assess each of its components against historical values, adjusting for complexity, skill mix, etc. This provides a reasonably unassailable estimate of scope and cost, assuming that you've scaled scope reasonably well.



Then, your management will simply whack 20% off the top and tell you to suck it up.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! https://www.youtube.com/watch?v=BKorP55Aqvg
FAQ731-376: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm

Careful,

You should make a list of your engineering deliverables, i.e. drawings, reports, specifications. Separate the deliverables into categories based on fields of expertise; You will have an engineer for each category. Then estimate the hours required for each deliverable. If the sum of the hours for any of the categories exceeds the working hours available before the deadline, add man-power and divide those hours to suite the schedule.

If you don't know how much time each deliverable would take, meet with an engineer in each field and have them estimate what they think it would take.

Something that is often overlooked by managers is the diminishing returns of simultaneous projects. Make sure you account for time lost to interruptions from project non-stakeholders and the "retooling" time incurred when jumping between tasks.

I used to count sand. Now I don't count at all.

the process is generally

define the scope
define the WBS
define the org chart
prepare a CPM schedule
work with the task managers to define the man-power requirements
resource load the schedule
add resources as needed
add overtime if needed

make sure you address all the risks (complete a risk register)
make sure you allow for reviews, approvals, permits, value engineering, FMEA, etc

iterate all the above as necessary in order to meet the scope requirements, budget and schedule goals

Sorry if I gave the wrong impression, I'm not a manager, and have no scheduling authority. Maybe that's why the fellow who deleted his post found it so humorous. I'm just wondering if there is an accepted format, because they just seem to wing it most of the time.

Sandcounter: Sounds like a good system except if the engineer you're meeting with is also inexperience or if no one is experience in what you're trying to develop because it's new. Just no substitute for experience really, I guess.

To your last point, at my last few positions I've suggested tracking all engineering projects through MicroSoft Project, to develop realistic timelines for multiple projects involving multiple people and/or departments, and see when any particular resource was overloaded. No one in management has liked that idea so far. Wonder why? Maybe because it would point out their unreasonable expectations?

The way I work it from an underling position is to look at available time and then divide my time among my assigned deliverables. The available time drives the level of detail and quality with the assumption that all-knowing management implies the expected level of detail and quality by the allotted time.

Surprisingly, it works pretty well. As engineers we like to see everything ironed out to the nth degree, but that's not what managers are looking for. They value effectiveness over efficiency.

I used to count sand. Now I don't count at all.

Careful34, I've heard a few suggestions about attempting to manage resources using MS Project, and one of the reasons it often falls over is the amount of data entry required (and manipulation of schedule) in order to get it to behave. In order to be able to use Project, you need to be able to track time spent against time estimated on each of the WBS elements. What normally happens is people find they spend more and more time entering data into places in order to fulfill the schedule, and less time actually doing what they're tasked to do.

Add this into the fact that the base licence of MS Project does not do shared resources well, and it becomes a very tall task indeed to get anything useful out of it.

If your organisation runs timesheets, then there's at least some chance that you can get an idea of time spent on particular projects, by using whatever reporting means that may be available from it.
I've also seen people suggest using spreadsheets instead of Project, which generally doesn't work that well either.

There is, of course, the possibility that it would point out unreasonable expectations, but its far from the main reason on why you'd find resistance to the idea.

EDMS Australia

Here is the typical management process:
- ask the experienced engineers to estimate the man hours and schedule required to complete the project (note: if the requirements, deliverables, tasks etc are vague, then the experienced engineers will likely estimate very conservatively)
- sum up all of the inputs
- state "OMG the estimate is way more than the budget"
- arbitrarily cut the estimate by 3x (or more)
- hope the experienced engineers can pull off yet another series of miracles, and/or get promoted/transferred before the inevitable budget overrun panic occurs
- repeat process on the next project learning nothing from the previous ones

Or, the sales department makes the estimate, on the grounds that "This project is just like this other previous project" ... conveniently forgetting the "except they want this instead of that" (and that this forces a complete re-evaluation) and forgetting that there is a big file of "lessons learned" from the last project for things to do differently on the next one in order to avoid the mistakes built into the design of the previous one.

"To your last point, at my last few positions I've suggested tracking all engineering projects through MicroSoft Project, to develop realistic timelines for multiple projects involving multiple people and/or departments, and see when any particular resource was overloaded. No one in management has liked that idea so far. Wonder why? Maybe because it would point out their unreasonable expectations?"

Sure, that and sheer laziness. It takes a lot of discipline to track projects beyond their conclusion and collate the data for future use. I've been at a number of companies, and only one ever even attempted to do what I described. Most of the time, they wing it and base estimates on their vague collective and tribal memories.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! https://www.youtube.com/watch?v=BKorP55Aqvg
FAQ731-376: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm

My experience with MS Project suggests that you need at least one person, full time, just to keep it updated.

Decades before that, I worked for a company that was fairly well run, in retrospect, but I didn't realize it at the time. They had a full time guy, Dominic, who spent all his time keeping track of project deliverables and such, using CPM, on paper, manually, long before computers arrived. I thought Dominic was a major PITA, but he was just doing his job.

As the hardware for a major project started coming together, and it all fit and worked with only a little modification here and there, I started revising the design documents to reflect the 'as-built' condition, so that future iterations would go more smoothly, with fewer markups and fewer phone calls. The Project Manager put a stop to _that_ activity as soon as he found out about it, because it was coming out of his budget, but he wouldn't get any credit for it.

The product was reasonabnly successful; they were installing the second of four units when I was laid off 'for lack of work', but they went on to build about 20 more units. I found out they were doing that because I got a phone call, a year or so after my departure, asking me why I had not revised the design documents to agree with the marked-up prints that had actually been used for fabrication. The PM had conveniently forgotten our interaction, recorded no 'lessons learned', and retired. I think they had also discarded my copies of the markups, too.

Mike Halloran
Pembroke Pines, FL, USA

Project management practices vary by company and which direction the wind is blowing, I've only worked at one company that did it really well. That employer's PM was largely based off previous projects' timelines and recorded in a simple internal program. At the beginning of each project the engineers assigned (not their managers) agreed upon deliverables which the project managers used to create a project template and the usual Gantt chart from a big list of standard tasks. Our office was ~300 engineers and three full time project managers completing 20-30 major year+ projects annually and many more minor product updates, so the standard task list kept everybody on roughly the same page while letting us quickly accumulate a big history of task length for each. After the initial project template was completed the project managers scheduled an hour every week or two with individual engineers to review their portion of the Gantt chart. Using averaged historical task lengths on the initial template kept most folks from nitpicking too many tasks and/or being overly conservative/agressive on those they did, it also kept managers and others from having unrealistic expectations. As scheduled tasks came up, individual engineers would receive an automated email and clicked links signifying work was started or complete. If nobody clicked at the appropriate time, within a day or two the various engineering managers received an automated email to investigate and rally the troops as necessary. It was a rather proud six-sigma company, data driven, so correcting issues was the only real involvement management had in the process. Not sure if it was bc of being data driven or having little management involvement in schedules, but year+ project deliveries were rarely off more than 10% from estimates put together by the end of the 2nd-3rd month, and it was very much an ultra high-speed, work fast/hard or get fired sorta company.

Another thing to consider is change requests and scope creep. Very rarely does the quote match the work that was actually done and the product that was delivered. This can make going back and comparing your estimates to the work performed difficult.

You can get most of the punch you'd get from Microsoft Project or Primavera by simply sitting your engineers in a room, drawing up a critical path diagram on a whiteboard, assigning "days" to each task, precedents, antecedents, identifying the critical path in a different colored marker, and then adding up the hours at the bottom. Take a cell phone photo, email it to your project team, and there's your plan.

BUT, here's the thing a wise manager once told me. Bidding a project is like poker. You don't bet your hand, you bet his hand. When the higher ups put together their fee, it's likely that they're trying to figure out what fee they think will win the job, and the highest fee they can get given the client and the competition. Then they go back and use your hour estimate as a check, to see whether the job is going to be profitable or not. Just going off of an hour estimate could lead to not getting the job, OR it could lead to leaving a lot of extra money on the table, which could have been used to cover a loss on other jobs with overages.

There's another thing too. It's cheaper to do a job at a loss than it is to sit idle. I learned this from my father, who was in heavy construction.

Those two things aren't often understood by folks in the engineering labor pool trying to pull the project together.

In terms purely of your "staff level," however, the initial exercise of doing a simple critical path analysis is very valuable, and doesn't take long.



Hydrology, Drainage Analysis, Flood Studies, and Complex Stormwater Litigation for Atlanta and the South East - http://www.campbellcivil.com

"You can get most of the punch you'd get from Microsoft Project or Primavera by simply sitting your engineers in a room, drawing up a critical path diagram on a whiteboard, assigning "days" to each task, precedents, antecedents, identifying the critical path in a different colored marker, and then adding up the hours at the bottom. Take a cell phone photo, email it to your project team, and there's your plan." - beej67

My primary rational for MS Project was that all the various on-going projects along with the common resources shared by those projects (including personnel) could be combined into one master timeline that would point out if any particular resource was being over tasked. It would also make it easier to access how new high priority projects(emergencies) will affect the time lines of existing projects as they always pull away resources. An emergency on someone else project, or some other department of the plant doesn't mean anything to my project until it pulls away a resource I planned to use and screws up my time line. Scheduling of resources is a decision that people with a high level overview of all on all going projects need to make, but this would make it easier to re-figure new time lines.

All my projects are in house stuff, no outside bidding, but if you Were dealing with customers it seems like tracking would be even more important.

Careful34,

Never manage something you have no prior work experience in the field of which you are managing. Generic business managers with no experience in any occupational field EQUALS worthless idiots that do not belong managing anything. Business management theory without any education/experience in a particular occupational field should NEVER manage.

If you don't have a grasp of what goes on, how can you manage? You don't need to be an expert but you need to know what goes on because even a fresh out of college graduate of an engineering school has more competence to manage than you do even if they never took a single business management/administration course. Don't manage projects unless you have a little bit of experience working as an assistant to a professional engineer and essentially "job shadow" how engineering work is done for at least 3-5 different size/types of projects. Usually, 2-3 projects of each kind. This way, you have a minimal statistical basis to go from on estimating hours. Collect information about how many hours they spent doing different tasks, etc. You'll need to learn the vocabulary but you don't need to be a engineer or graduate but it can help if you gain the understanding of the language. It's kind of like it would be at an architecture firm or any business.

It is why most business administrators takes it as an MBA *AFTER* they got their undergraduates degree and work in the field of their undergraduate studies or closely related fields. A person may co-major but then one degree is business administration and the other is in a particular occupational field. If you took a major in business administration and a minor in another subject then maybe consider business managing/administration in the field of the minor. Find a role there. Otherwise, you have an uphill battle to learn the field because they vary too much to give you a simple answer.

I apologize if I sound harsh but this isn't a personal attack on you. It is that you are fooling yourself if you think you can manage anything without some understanding of the field of the 'business' or project.

How about work as an assistant to the Managing Project Engineer whom will oversee the actual project and you observe the tasks people do and how long. Learn the vocabulary, and so forth. In professions (often ones where licensing is customary), the project management is handled by experienced professionals in the field who often has taken project management and/or business administration/management as their graduate level or through continuing education or something along the lines including self-study or through someone who had who they worked under. In any case, YOU don't know the field enough by your own admission. It would be insane for you to try to manage a team of people without any fundamental understanding of the field. It is kind of a recipe for disaster.

I'm sure there is a book out there.

Another book... more applicable to architecture but sometimes might apply to some engineering practices:

Design Office Management Handbook by Fred Stitt.

https://www.amazon.com/Design-Office-Management-Ha...

I'm only pointing to it as a reference not to promote it other than a suggestion of possible sources of reading material that can be helpful.

ASTORIA BUILDING DESIGN, LLC. |
Building Designer | Architect/Engineer (Sweden,Norway, Finland, and Denmark [including Greenland])

Rick, thanks very much for your insightful reply most of which I agree with. Further up in this thread I clarify that I'm Not a manager nor do I have scheduling responsibilities at this time, I'm just curious. So no need to be concerned.

So if I understand your perspective correctly, it pretty much gets down to no substitute for experience. Would that be correct? There's no popularly accepted tomes documenting anything?

Thanks again.

Yes, Careful34..... There is no substitute for experience but some of that experience can be through educational studies in the subject matter of the occupation. For example, in an engineering practice, having some education in engineering (the basic fundamentals stuff) would be handy. There are some things that you can not attain without some experience. There maybe some tomes documenting but in reality, each office will have variability. The hours it takes their employees to do specific tasks, it isn't exactly talked for any number of reasons. There are few books that could give you some general ideas but ultimately you have to adjust with how actual firms operates because there maybe differences of opinions on how to do a task to reach specific results. It isn't like it is cookie-cutter. Ultimately, there is no substitute for experience but any education or book material and other information you can get along the way in written form or other recorded medium can be helpful but don't hold to it like gospel.... You have to factor some float in whatever you do and over time, you can get a better picture from where you work at.

ASTORIA BUILDING DESIGN, LLC. |
Building Designer | Architect/Engineer (Sweden,Norway, Finland, and Denmark [including Greenland])

Careful34,

Yeah, you and I are talking about different types of operations entirely, different scales, and different pressures. I was referring to an engineering project that might take a month and a half, being done by four to six engineers, and needing several inputs from outside. For that, a whiteboard should handle it. If you've got 12 guys working four different projects simultaneously, I could see the benefit of MS Project. If you're a construction superintendent, then you're living and dying by that Gantt Chart, and it better be updated daily.

Hydrology, Drainage Analysis, Flood Studies, and Complex Stormwater Litigation for Atlanta and the South East - http://www.campbellcivil.com

"If you've got 12 guys working four different projects simultaneously"

Four guys each working 12 different projects simultaneously, would be closer to reality for the places I've worked. And in some saying "4 guys" would be stretching the truth.

From the management perspective.. as few as possible Jim

Managing Professional Service Firm - David Maister

Link

One of the biggest pitfalls I see in project planning and scheduling is this: if I tell a project manager that a particular task will take 8 hours, they would expect me to have it completed the next day. What they don't understand is that in a perfect world when I am not working on anything else that would be the case. The 8 hours is of course actual work time that could be spread over several days, depending on my availability. Its a losing battle.