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,

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.