Gantt and PERT charts are so straightforward that I can't see why you'd need a book. I did dozens of them with a freeware product called Gantt Project (you'll find it on the Web), which is a slightly stripped down competitor with Microsoft's Office Project.
There also are Excel templates available but I haven't tried them.
Is the project very complex, that you feel the need for a book, or are you looking for the basics of Gantt and PERT? I've heard that the Microsoft Project software comes with plenty of instruction, should you want to try it. You can download a free trial version.
I've worked on many projects that have severely missed their schedules, and a few that came in within 10% of estimates.
The few had two factors in common:
They were tracked with Gantt charts.
_Everyone_, from the top of the management tree to the roots of the worker-bee staff, respected the schedule. On the worker-bee end this meant not overdoing your task and letting the project manager know when things go awry. On the top-management end this means actually believing that people whom you pay tons of money to be competent _are_ competent, listening to what they say, and accepting that the impossible really does take a bit of time. Of the two, the latter is more rare.
Gantt charts are close to intuitive, so those management books from the
60's and 70's are going to be perfectly good at filling in the gaps.
Management buy-in is rare.
You're talking about process, not projects, so the only thing I can add is to draw a corollary to the "management buy-in" problem: don't document the process times that _should_ exist; document the process times that _do_ exist. If you start making it your business to shorten up times, make plans based on the times that do exist while you're expending effort on bringing the times in.
============ After having been there [and tried to do that] I have some thoughts/observations/suggestions.
The major reason for the initial success of CPM/PERT in building the Nautilus submarine was the ruthlessness of Adm. Rickover in enforcing reporting accuracy and action implementation as required.
If you have any friends at work, and they are part of the project, they won't be friends for long. If you do your job right, expect to transfer or to get a new job on the completion of the project, successful or not.
==> Be aware that CPM/PERT is a technique of the 50s and 60s so there may well be a "situation" here you should/want to steer clear of. *THEY ARE*. You will most likely have to repeat this on the hour and half-hour and it still won't sink in. Keep copies of every notification/update memo you send to them.
If you do get directive authority, be ruthless in bypassing the no-loads and dickweeds, as it's your a** on the line.
For example, if you need special packaging, with a 10 week lead time, if the packaging is not on order and scheduled to be delivered on time [check with the vender and don't rely on purchasing and/or the graphic arts department assurances] and if not due in, order it your self and let the nominally "responsible" people scream.
Be sure any extra design or short run cost is charged to their departments. I suggest going to an alternate/new supplier just in case there is an attempt at sabotage just to show you who's in charge.
(1) The WBS [work breakdown structure] / task analysis is critical. Be sure you don't skip *ANY* steps. Any missing items including packaging and instruction sheets, even PN/date stamps for the packaging, will stop you from shipping. Where you must rely on other departments such as product design or production engineering, make they submit *ALL* information, estimates, etc. IN WRITING*. Kick back any ambagious memos, with copies to your and their boss. ==>Check lists and structured reviews are your friend.
Lots of info to absorb, but I've had a little bit of CPM and network stuff over the years.
As to the documentation, the method I've used for over 15 years is to be direct and focused in emails. Email is not your friend.
BUT... email is a helluva way to lay out a train of causality when something crashes and burns. Using email to support one's assertions is sorta dangerous, and I tell folks what will happen if they don't see Jesus. That way, if I get to stand in front of a desk, I can have a clear conscience and stick to facts.
I cannot second this comment too strenuously. About half the engineering projects that I have been on have been within 10% accurate in the original estimate, yet have had that estimate whittled down to meet the date of the next trade show without either adding people, reducing features, or allowing for a not-fully-working prototype to be delivered to the show (this in an industry where you _always_ see nearly a year of lead time between the trade show and the first big rush of orders).
There is something about human nature that seems to compel upper management to dictate schedules by fiat (I'm very virtuously avoiding getting either cynical or mentioning genitive organs here, I hope you're proud of me). You'd think they'd learn, but at the end there's always an excuse other than "gee, that took just as long to do as they originally said -- maybe we should have listened".
I've really only seen the process work well once, and that was because management was over a barrel and we had a new guy who came in after we'd scheduled it. He was in a position to go to upper management and tell them they could choose to do the project as estimated, or they could choose to wave goodbye, but that there wasn't a third choice. Even after doing _exactly_ what he said he'd do on the first project, the second one got talked down halfway through, and we missed our dates.
(I should mention that whatever this guy's popularity was at the upper management level, all of us folks below him thought -- and still think
-- the world of him. He was ruthless in such an engaging, friendly, diplomatic way that we were all proud and thrilled to be working on a successful project rather than bitter and resentful at having all of our little faux pas revealed. And this was for a guy who _always_ scheduled deadlines on a Monday morning so if you didn't get it done on Friday you'd just naturally work over the weekend.)
As I write this I'm thinking of the construction industry, and the fact that some states are writing contracts that give big day-by-day bonuses for getting things done early, and big penalties for coming in late. I wonder if they do better...
-- snip --
There are two ways that I know of to cost things out accurately (really one, but they look a lot different).
One is to look at how long a very similar project took, and copy it's times _as finally executed_. The other is a method called "wide-band Delphi" that lets an experienced group of people break a new project down into know pieces and estimate each piece to get a final estimate.
Of course, to really make this happen you have to suppress your natural optimism. Everyone tends to ignore how long it'll take to _really_ get things done; it takes practices to learn to do an honest estimate. And the estimate is fragile -- at any time, it is all too easy to look at your own estimate, that you know damn well is just right, and pull it in without changing how long it'll take to actually do the job. So when the boss's boss's boss puts on pressure to have the schedule brought in, it does eventually come in -- but the actual times don't change.
Indeed, again emphasizing that the huge majority of cpm/pert "problems" will be internal to the organization/personnel, and not with the "software."
In far too many cases the introduction of CPM/PERT [project management] is simply an attempt to implement a technical solution to non-technical [i.e. personnel/organizational dynamics] problems in attempt to avoid what are generally very unpleasant managerial responsibilities/tasks such as confrontations with and terminations of, long term associates. ===========
========= Be reminded that with the deindustrilization of America, CPM/PERT and the project management packages and texts now stress software development rather than hard product production, with some recognition of building construction.
For some more info on CPM/PERT see
for info on specific project management packages see
other software packages include
for low cost alternatives [but with less capabilities] see
CA's program is (was?) called "SuperProject," and appears to be at version 6 in the UK, but not listed on the CA US web site. Be reminded that CA (Computer Associates) is having problems in meeting their promises/claims, specifically rebates on their software. SuperProject prices appear to be comparable to M/S project, with slightly fewer capabilities.
Unka' George [George McDuffee]
------------------------------------------- He that will not apply new remedies, must expect new evils: for Time is the greatest innovator: and if Time, of course, alter things to the worse, and wisdom and counsel shall not alter them to the better, what shall be the end?
Francis Bacon (1561-1626), English philosopher, essayist, statesman. Essays, "Of Innovations" (1597-1625).
Some folks have done something enough to not feel a need for identifying critical tasks. When they go away, the replacements only know that everything has to be done, yet they have little idea what can slide and what will bite their ass if not kept under control.
Institutional knowledge is a dangerous thing to depend on.
We don't have time to document it - we don't exactly know, and we're embarrassed that someone has pinned us down Everybody knows - Only a few old timers grasp it, and since THEY know it, "no problem" It's in our operating guide - We have nothing in B&W Nobody knows - too damn lazy to find out - or - if nobody actually knows, too damn lazy to produce an 85% product.