Yep, Project sucks to manage and estimate projects big time. It doesn't help that the tool overall sucks, with crappy features such as single-level undo, or the "corrupt file occasionally" feature :)

I am old enough to have been tought the waterfall proces model yet young enough to remember how I doubted its use (well at that age, all you really do care about is coding).

I have not used major project management tools, clearly any such would have to contain requirement engineering and change control as well in a modern day agile process. Does any such tool exist and what is the best-practice in the business?

I have just started on McConnell's latest gem of a book but I am fairly certain that he does not provide any tool references.

Thanks for the link! I'm actually do a sequel post on this topic today showing the example of a project that was well-managed, largely because every previously unforseen surprise that popped up was acknowledged, and the project plan was adjusted based on the new knowledge. The project was still managed on MS Project (not by me thank god) but it was adjusted each time something changed.

It's really not that hard if you enforce some basic constraints:

draw a line in the sand on what features must be provided
have the team run this through the estimation process (this requires talent and no fear of repercussions for sizes that disagree with what management may think); break it down into man-days
figure out what things can be worked on in parallel vs. serially
using this model, lay out a sequential plan of attack
Divide the man-days by the number of people you can dedicate to the project (each full time person is .75 of a man-day); this tells you when the project should be done
If the client changes the line in the sand, re-compute
Remember the golden rule: we can do anything you want, but it's time and money

Why do software people make it so hard, and build so many new processes with so many fancy names? Projects are worse off now than 20 years ago it seems...

I was project manager at a dot-com for a year and a half, during which time Microsoft Project was my constant companion.

Due to completely ordinary but endlessly-shifting circumstances, I was updating the .mpp probably three times a day. Otherwise I couldn't keep track of the critical path and recommend adjustments to the dev manager.

MS Project by itself is not to be blamed. Coming from an engineering background I have seen MS-Project used in a lot of construction and engineering projects. Imagine the usefulness of tying up a bill of materials spreadsheet with your project plan. MS-Project also has other techniques like the PERT charts, critical path etc.

For its price, MS-Project is quite a good project management tool. Compare the price of the other project management software like 'PrimaVera' (www.primavera.com) and you would know.

Its a whole different issue of what model you want for your software project management?

I use MS Project to manage my day. Every morning I start off with a Gantt chart on everything I will do this day.

The problem originates in the fact that "Software Project" shares the word "project" with "engineering project" or "construction project."

"Ah-ha!" our hapless software managers cry, as they roll-out the money for a copy of MS Project. And the software developers cry all the way 'til the end of the "project."

Software invention is just that. It has more in common with Mr. Edison's Menlo Park laboratory than the local hi-rise construction site.

Of course, there are far fewer variables on a work site than in software invention. Gravity remains the same, elements don't change and concrete has known properties. Things aren't that stable when operating systems, hardware, software and business processes come together in "the perfect speculation."

Let real fear overrun the heart of the experienced developer when the project manager (read: couldn't program so they made him a manager) whips out Microsoft Project.

When blame is handed out, what do you think? Is the missed deadline Project's fault, or the developer's?

One guess...

I ran a ~$8M engineering tech support project (mainly mechanical engineering, not sw dev) and I can say that Project can be an invalualble tool. I was fortunate to work with an engineer who came from a previous company where the culture supported, and understood the limitations of, reasonable, but detailed project planning. OTOH, I decided that you simply cannot buy training to use this tool that will allow you to deal with the complexities and vagaries of life in the real world - you must have the resources allocated to invest in learning how to adapt the tool to your reality - and you must have a project that justifies such an investment.

Remember - no plan should cost more to care for and feed than the potential costs of not having a plan at all.

I'm sure M$ project can be useful to track tasks and dependencies in a large project to make sure the project is on schedule. After all, the PM is responsible for maintaining the schedule and timelines of the project. I could see Project being used or another viable alternative.

I am not sure why it is so difficult to estimate software development? Is it a mystery, magic, is there a man behind the curtain that every project depends on???

I mean its simple, come on! Its like a designer and general contractor coming over and estimating how long it will take to remodel your kitchen.

Step 1 - Look at Kitchen (Existing Environment). Is it big, small, how many cabinets, etc.
Step 2 - Come up with a suitable design with the house owner (Talk with Business to see what the need is)
Step 3 - Design solutions to remodel. (Architect and Design Prototype)
Step 4 - Pick a solution design based on cost and time to implement.
Step 5 - Implement Design (Write Code)
Step 6 - Owner inspects implementation at various checkpoints.

Are software projects any diffent?? OK, more testing involved. But really, waterfalls, agile?? Somebody help me out....

I am currently on a project with the master project schedule.

Strangely, software is having the least problems with it out of this multidisciplinary project.

I've been constantly modifying it though throughout.

The thing that irritates me is when people use predecessor and successor tasks on software projects, because they're too lazy to resource level the tasks -- so you end up with TASKS THAT MUST BE DONE IN THIS ORDER, for no reason.

@Jon Raynor: The problem, I believe, lies in that writing code is closer to step 3 than step 5. Step 5 in the Software Project is more the integrate all the code that has been written by the software engineers into 1 working system. Then we normally have step 3 and 5 in your model being done at the same time. Imagine moving step 4 between step 2 and 3 and you get the idea of what a software project is like.

Writing code is similar to driving across town. If I ask you how long it will take to get to the airport in the next town, you might make a reasonable estimate. What you don't know, however, is that there are bridges out, accidents, roads closed, detours, and other obstacles on the way. Then, when you're halfway there (on schedule or behind), you get a call telling you it's the other airport, or another terminal. Or that you have to go back because you forgot your luggage.

You try to make a reasonable guess, but unless it's "Hello World", it's just not that easy.

We started to use Project to manage our latest project. However, we found that it required too many hours each week to keep it updated, and we just didn't have them.

"I am not sure why it is so difficult to estimate software development? I mean its simple, come on! Its like a designer and general contractor coming over and estimating how long it will take to remodel your kitchen."

Your kitchen analogy does not relly fit except if you talk about COTS apps. Software is not manufactured, it is grown and matured through time and feedback. If you are building a bridge and is falling behind scheduale, by all means, throw 20 more people on the job constructing those pillars. However, this is not going to work well for you developing a large and complex piece of software.

Remember Donald Knuth? He does not call it "the art of programming" for nothing. Estimation is certainly no exception and compared to programming, it acts more like Heisenbergs principle of uncertainty than art.

not all, but a lot of, folks (here and in the world of coding) want to be called (and foster a self-image of) 'software engineer'. but get all bent out of shape at the merest hint of having to do engineering's primary task: know and state unambiguously what you're doing.

waaaaaaaaa. as to M$-Project; Primavera Project Planner has been around since the 80286/AT machines, and is the top of the heap for PC based planning software. I've used both, and M$-P was always a poor imitation. cheaper too.

PPP has structure for managing feedback, IIRC; M$-P may not.

if coders want to be seen as alchemists, or two bit Edisons. fine. not much future in it. and it also implies that there's nothing to be learned from the giants on whose shoulders we stand. exhibit A -> XML databases. phooey. such knuckleheads should not be taken seriously. I feel better now.

Excellent analogy, Jim!

You know when I saw your Gantt chart and thought you took one of the projects I am currently on. I don't know if it is that project is based in waterfall or if it is the project managers only think in waterfall.

I know from experience project has some good aspects to help keep you focused, but if you don't plan for having the random things come up it comes back to bit you in the @$$ hard. Also Jim I think you hit the nail on the head with your estimate analogy, now if only clients would understand that.

+1 to happy-go-lucky

And then, guffaw!, jrgallagher pipes up and tells everyone how useful Project is for mechanical engineering.

One wouldn't trust a project estimate from an artist, nor would one really trust an estimate for a scientific endeavor. Both such "project" have such a large margins of errors that only ballpark estimates are asked for or relied upon. So too should software estimates be in that same realm.

Software shares qualities with traditional engineering only insofar as it deals with electrical hardware. But so much of modern development is abstracted layers away from the hardware, that the "engineering-ness" of software is ever decreasing.

I giggle every time I hear someone say "what can be so hard about software pm"? Seriously, it is funny.

There is a reason 50% of all software projects fail. There are a zillion reasons, actually. Where does one start?

After four years of being in the thick of it, it is sooooooooooo refreshing to be back coding. PM was the least rewarding and most agrivating thing I have ever done professionally. I'd rather sell hot dogs by the lake. Shot me if I ever do PM work again.

Antony - I agree, stage 3 is really the prototype(s) stage and there will be a significant amount of coding done in that stage. The prototype(s) could be carried forward or be thrown away, but they do serve an important purpose of validating the solution and whether the solution meets the requirements. Now if you change the requirements after the prototype stage, then as you have pointed out, doing steps 3 and 5 at the same time is a bad idea.

Casper - Software *is* manufactured although not in an assembly line fashion, but it is produced by individuals. Estimation is mostly guesswork, but if you have done work before and have some idea of what you are doing, then the estimate should be reasonable. That is the best that we can do and shoot for, reasonable estimates. An estimates are *estimates* not the exact time needed to do the work.

I sure Knuth is a software artisan, but for me the software that I produce either works or it doesn't. If it works everyone is happy, if not then bugs are logged that must be fixed. This the real world. There is no art involved.

Maybe if I were doing pure R&D or coming up with a thoeretical compiler there would be more "art".

Jon,

Nice explaination of software. It can be art in some sense of the word, because programmers do put themselves into the code, but it comes down to if it works or not. If the product looks good but doesn't work the customer isn't going to care. Where as if the application looks ok but works great they are happy.

"Estimation is mostly guesswork, but if you have done work before and have some idea of what you are doing, then the estimate should be reasonable."

There is the real trouble. Most of the time the tasks that I have worked on have never been done before and no one knows exactly what goes into them. If the development was something that had been done before or a set of tasks that one of my developers had worked before then we would likely just use COTS Software (or quickly integrate it). If a company is writing any significant code that usually means they are cutting new ground technologically. New ground means difficult estimations and high volitility.

The reason that project estimations fail is simple: No one has ever done this before.

Engineering projects have better estimates, but only because they have done essentially the same project before. Ask for an estimate on something that has not been done before, and you will get an answer that is only a guess, and often wildly inaccurate.

So, why are all software projects things that have never been done before? This is simple. It is because unlike a bridge, software, once the design is done, is easily produced again and again. I can give a really good estimate of how long it will take to compile code on your machine, but no one can give an accurate estimate of the time or costs to build a bridge from LA to Honolulu.

The principles of Project Management are closer the laws of physics than you might think- the variables of time, resource and deliverable are absolute. You cannot move one without adjusting the others.
It's a mistake to view a plan as predicting anything. Both management and developers are guilty of this. It is simply a snapshot of how we intend to get somewhere. The best project plans change extremely frequently.

If you've ever had to use Primavera's Teamplay or Teamplayer, you would be praying for the days of MS Project. I work for a LARGE insurance company and 9 times out of 10, the problem with project management, is Management and the fundamental lack of knowledge that business folks have of the software creation process. Add a poor job market on top of that and suddenly one must become the Yes Man to the "powers that be" or risk not being able to feed his family. My question is how is Agile development making any gains in big business where estimates mean nothing?

Jon, the reason why I say software is grown and matured rather than manufactured, is that each and every piece of software is unique. Even software that solves the exact same problems, can be drastically different usability wise and have 1000+ various implementation possebilites. Thus, I see development as an art form governed by a process but expressed through engineering.

When I solve problems for my company I try to base my estimates on my analysis. Computable metrics like Cocomo-II I just don't trust and I have rarely done a project similar enough that I can base my estimate on personal empirical knowledge.

Casper - I agree with your points. I think the uniqueness of each piece of software is a big part of the current problems with software development. This makes it difficult to classify programming or coding as an engineering disipline. Software engineer, this job title has always troubled me because if you ask a 1000 "software engineers" the methodology they use to design and code software, you probably get a 1000 different answers and a 1000 different implementations of code they did for a solution, well maybe not a 1000, but the implmentations will vary widely.

I think we still have a long way to go before coding moves from art/science/magician to engineering.

Has anyone tried to print those funny Gantt charts in MS Project? My experience is what you see is not always what gets printed.

When I plan I want to be able to plan one to two years in advance. Is there a sensible software outthere that can help with this?

Back when I used Project more often, I would use auto-leveling to keep the project in order. I would only apply dependencies between tasks if there really was a dependency. The auto-leveling was even smart enough to put the big (and therefore more risky) tasks as early as possible for each team member.

The other feature I used often was the tracking gantt. Each day or few days, you can indicate what's been done or partially done, and Project can let you know if you're ahead or behind of your baseline and by how much. Every once in a while to keep things simple, you wipe the slate clean and eat the overages by declaring a new baseline. Hopefully you had enough of a slush fund of time at the end of the project.

I actually miss Project a bit. Those were great features. I can't believe basically every single PM I've ever seen do that silly every-task-is-dependent-on-something waterfall silliness -- it turns Project into nothing more than a pretty Gantt chart printing program, basically useless for actually managing a project.

Lots of comments already, so forgive me if I repeat what others have already said.

1) MS Project is the tool, not the content. As I have read somewhere, "the problem lies between the chair and the keyboard". MS Project does not enforce waterfall, its just the easiest style of plan to create in the tool

2) Napolean said "A plan is good until the battle is joined." meaning change happens, and MS Project is good for impact analysis.

4) the truth about estimating and planning software development is somewhere between "estimate before and it is must be perfect" and "you can't estimate s/w development".

Here is the definition of 'estimate':
n. (-mt)
- The act of evaluating or appraising.
- A tentative evaluation or rough calculation, as of worth, quantity, or size.
- A statement of the approximate cost of work to be done, such as a building project or car repairs.
- A judgment based on one's impressions; an opinion.

So remind people that 'estimate' means approximate, not exact. Overall, estimates for doing anything are generally more accurate if you have done the same type of work before. Given that s/w development is often to build something never created before, that makes it tough to find previous work to compare to. Enhancements to existing s/w is easier than new s/w, and a package implementation is even easier as the vendor can draw on its previous implementation experiences.

So, tools don't replace thought and judgement, they just make it easier to implement them.

> MS Project does not enforce waterfall, its just the easiest style of plan to create in the tool

And isn't that why it's a problem? Tools do shape how you approach the world. If all you have is a hammer, everything looks like a nail.

Jeff,

I hate MS Project too. If you want to track a project's performance against time and budget, this approach here works _much_ better: https://www.agilekiwi.com/agile_charts.htm

It's compatible with both agile and traditional processes. Agilists will recognise it as a "burn chart" and traditionalists will recognise it as a EVM chart.

I once attended a project Management training.
I don't remember all the details, but one thing that I will always remember is that

the GANTT chart is an OUTPUT, a RESULT.
You don't do real project management by writing in the GANTT view.
You work on the WBS (Workload Breakdown Structure) - that is the "list" of phases/items/tasks on the left end, you check the critical path, you plan in the resources, etc etc.....
then the GANTT comes out for itself. You don't need to actually *work* with it.
Most projects we see these days are done crap and look like waterfalls just because thet HAVE to be there (i.e. someone REQUESTED that a GANTT be there) but nobody actually knows both the tool and the methodology....

Project is horrible for several reasons, but its greatest flaw is that it assumes a static project structure. The documentation may not do that, but the UI sure as hell does.

You can create a starting plan easily and make it all pretty and straightforward. But then you have to enter actuals. The requirements change halfway through the project, and you have to add a whole section, and the Gantt chart blows up. You end with a project manager who spends a significant amount of time each day wrestling with Project. And they didn't have enough hours in a day to actually do management, to begin with.

Those who don't understand why software project planning is so hard are missing a crucial point. If you are developing in a well-known environment, using known tools and addressing well-characterized problem, you can make a good project plan. Unfortunately 90+% of software development projects involve complex undocumented environments, tools you've never worked with before, new and unstable technologies, and requirements that change daily. The only way to deal with that is to pad the hell out of the schedule, and even then something will screw you up.

This is one of the most interesting discussions I have seen in a long time. I am in the field of web-based PM software, so I can relate to both disciplines: PM tools and SW development.

From my experience and what I have heard from clients, I think there are 2 major issues when it comes to using MSP in Software projects:

1). Project Managers tend to go to granular - meaning they will try to micro-manage every aspect of a goal and end up with gazillions of tasks that suddenly get a life of their own and all need to be tracked and managed.

2). Updating plans with "actuals" quickly leads to situations where MSP will try to reschedule everything according to dependencies.

Thoughts about 1): When you plan a developers time, you should provide for more than ONE deliverable for any given time frame. I am talking about personal experience. Sometimes you just get stuck when trying to solve a problem, and you simply need a break from the mental dead-lock. You move over to a different problem and once that one is solved, your brain is ready to solve the first.

Thoughts about 2): Sometimes we have tasks that need a final phone call or a signoff before you can call them 100% complete. These final activities may be delayed because of absense, vacation, etc. - but they don't really affect the schedule. The judgement of what affects the schedule can only be done by the PM not by MSP.

At my company, we are currently discussing the develoment of a web-based add-on to MSP for the purpose of tracking progress, sub-dividing tasks into deliverables, and providing some collaboration features such as document management and a message board. I don't want to hijack this discussion in any way, but if you are interested in discussing this further, please email me at info@softalot.com and we can setup a seperate list (on yahoo egroups or what have you).

This is a very good discussion. The problem is not the tool although it does have it's distinct weaknesses (who thought up single-level undo, anyway???). I have used Project for many years and actually have the (gasp) Orange Belt certification and (bigger gasp) my PMP. Project doesn't force a waterfall - its just a natural way *some projects* get put together.

Project is a planning and communicatio tool and its use must be adapted to the specific project. We have projects that have lots of unknowns and I try hard to stress to people that when it comes to durations, dates, etc. we need estimates in order to forecase what will happen but its the project manager's job to INSURE stakeholders understand where the uncertaintities are and what the range of possibilities are. That old phrase "based on what we know right now" must be heard loud and clear! PMI states in the PMBOK (please don't stop reading at the appearance of this acronym) that the project is "progressively elaborated" the fancy way of saying "things change, there are unknowns that won't come to light until later, etc. " It's how that's managed that should be the focus.

Finally, for anyone struggling to use MS Project, I highly recommend the book Dynamic Scheduling with Microsoft Office Project 2003 by Eric Uyttewaal. It is awesome and taks a lot of the mysteriousness out of the tool. It's a good reference book too.

Good luck to all!

(Thanks to John Rusk for the link to the Agile chart!)

One more book recommendation - Agile Estimating and Planning by Mike Cohn. Eye opener and a fun read.

Here's a giant thread on Edward Tufte's site offering alternatives to Gantt:

https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=000076&topic_id=1&topic=Ask%20E%2eT%2e

Scroll down 2-3 screens to see his version.

Ah MS-Project... I have a love/hate relationship with it. I have been using it since the earliest version to manage IT development projects and it has certainly given me cause to detest the day I ever heard of it. But every time I try and manage a project without it I kinda miss it, and I always end up coming back. Over the years I have learnt some basic lessons that are simply non-obvious from the tool or the documentation:

1. Always start off with a new Calendar for the project before you do anything else

2. Always assign each person their own calendar based on the (new) project calendar

Steps 1 & 2 ensure you can book Project non-working days (like Christmas) globally and give personnel their own non-working days in their own calendar.

3. Accordingly, NEVER try and use start/end dates, or adjust project durations or effort to try and cater for personnel being on holiday.

4. Then enter your tasks.

5. Then enter expected Work

6. NEVER add a dependancy if it not a REAL dependancy- you will soon tie yourself up in knots and for anything other than a small project, as soon as you start entering actuals the scheduling constaints YOU have imposed will kill you. You will then give up.

7. Then add resources to the tasks- Never use real names until you have firmed the plan up.

8. Frequently level the resources.

9. Worth saying again, FREQUENTLY level the resources.

10. Treat your first completed plan, before entering actuals, as nothing more than an outline planning and forecasting tool. Good for showing the CEO and the client when you kind of think their project will deliver. Reinforce the view this is a forecasting view only.

11. If you are lucky you might not need to use Project after that and the CEO and the client will trust you know what you are doing and let you get on with it. However, some clients (and CEOs) like to see the plan tracked. So regularly update the estimated completion, but judge it yourself- Don't use the estimates to complete that the developers tell you. They will mostly always be wildly wrong.

12. After every session updating the relevant %age completes, use the Tools->Track Project->Update Project to set every uncompleted task to start after today. Then *LEVEL THE PROJECT* again.

13. Treat the revised delivery dates after all this as approximate delivery dates.

One of the problems is that Project tries to be all things to all people. I've been using it for years and I still haven't got a clue about what a lot of it does. Find what works for you and work on it until you understand what is happening. DON'T try and get to clever, it will kill you every time!

I too have developed a love/hate, but very intimate relationship with MS Project. And like any intimate relationship, it has gotten ugly at times! I've certainly uncovered many of its flaws - it's just too inflexible and completely ignores my needs! And it's brought out the worst of my flaws at times too.

But, I've taken a step back, weighed the good with the bad, and decided that it's worth living with. But, like any intimate relationship that makes it to this point, you get around to getting some counseling.

And for that, I highly recommend a book by Eric Uyttewaal alled "Dynamic Scheduling with Microsoft Office Project 2003". All the good points summarized in many posts here are in there along with wonderful step-by-step, option-by-option instructions for building and maintaining a dynamic - meaning one which changes, moves and flows with your project - schedule that you can live with.

How to create a Microsoft Project plan fo a two day training session for people from different countries. Document everything including preparation, presenter issues, participant issues, accomodations and facilities in the plan. Help I do not know how to do these.

my project template includes four standard "bars":

- Politics (%10)
- Obfuscation (%10)
- Dealing with "We-Don't-Do-Email" people (10%)
- Dealing with "We can do this in Excel" people (5%)

This way, client can easily save 35% of time cost upfront.

As of kitchen analogy, kitchen remodeling does not have any of these four "bars".

Micosoft Project doesn't support iterative protyping lifecycle. Therefore, you have to amend the project plan from time to time to reflect the reality. The thing is: you can always change your tasks but you can never bring yesterday back. Microsoft Project was designed like a calendar!

"It can be art in some sense of the word, because programmers do put themselves into the code, but it comes down to if it works or not."

Whether software works or not is usually refered to as "meets its functional requirements". What is about non-functional requirements that all add up to the software quality?

Why is software not like kitchen remodeling?

Well, it could be. When you remodel your kitchen, do you know exactly what questions will come up ("how much draw does the vent hood need?", exactly what decisions you'll need to make ("would you rather pay $X more or wait Y weeks for replacement material?", and what unexpected facts will be uncovered ("I thought it was an 8" duct and I had no idea about the dry rot under the floor").

Is it acceptable to get the kitchen 80% done, then have the homeowner come in and say, "Now that I see how the frameless cupboards look with that style of door, I'd really rather have the kitchen island redone."?

Or after the job is ALL complete and you just have the last guy mopping some dirt off the floor, "Those tiles clash with the cabinet color, I want the tiles ripped and the cabinets retextured with a metallic finish."? Or even, "All the walls need to be moved out 3 feet."? Does that ever happen? No, it rarely or never does, because there are tough guys with power tools in their hands explaining to you why that's a bad idea. And the homeowner runs into a hard, pragmatic wall known as NO MORE MONEY.

I guess MS Project Works best with Prince style projects - where you know what your raw materials are and you have a pretty stable product breakdown structure and product flow diagram to start with. For example, say building a bridge or implementing a network.

Software development projects; however, are more geared towards an Agile style of PM and are less suitable for MS Project. Afterall, it doesn't really matter, when designing a computer game if you suddenly decide to pull down a wall, build your bridge out of plastercine instead of bricks e.t.c. Plus there's less calendarising - you can drop a module or add a module without necessarily worrying too much about sticking to project phases too much.

If you use the task relationships feature in MS Project, you can avoid using the waterfall approach. To me, when I take a quick look at the snap-shot of your schedule, it's your project life-cycle that is waterfall like.

The real issue is with estimation, and most people are simply guessing and pulling numbers out of thin air.

We've had very good luck with estimating lately becuase we hacve a good historical database of the time tracking records which show how long it has taken to complete tasks on various projects.

Each task in our time tracking database gets assigned a budget value (example: 10 hours), we then track the actual amount of time it takes to complete the task. So, we have this long history of time entry and budget records for tasks.

Now, when we start estimating a new project engagement the first thing we do is list all the phases/tasks needed to complete the project, we then go into the timesheet database and create a report looking at tasks that are similar in nature to tasks with this new project. We take the number of resources and time it took to complete each task and add 10% for slack. We also look at what it cost for each of those tasks to be completed (different resources have different rates). Viola! We now have as good of an estimate as you are ever going to get. No, it's not perfect, but it's typically pretty close overall. Yes, some tasks hit snags, but other seem to go a little smoother, and in end the end the overall estimate of time, resources, money, etc. almost always falls in line with our original estimate.

We use Microsoft Project for created the Gantt Chart for the customer to see, because they like looking at it. However, our real tools are Office Timesheets and Microsoft Reporting Services.

Use TargetProcess instead :)
MS project really sucks.

I do agree and always hated MS Project. If you exposed your services throgh web services (or REST) and create a Win32 application, which is much more responsive and interactive than a web app, you'd have a killer application.
documentation should be broadened to talk about other methodologies, including agile methods, I have to most strongly disagree that Project is in some way "based on waterfall". It simply is not true. While waterfall has been the most popular and common method it is by no means the only method one can use.

Saying that most PMs use waterfall because it is the only one covered in the Help is a bit like saying one can only drive ones car in a straight line because the manual did not tell them how to turn the steering wheel. :-)

As far as being standalone I would point you to Project Server or for that matter the host of other server based tools that integrate MS Project files with server based team interaction features.

Also look at what David Anderson (of www.agilemanagement.net) is doing with Visual Studio Team tools and with the MSF framework if you want to see how a tool like Project can be integrated into a suite of development tools.