I've been using Microsoft Project quite a bit recently with a certain customer of ours. They bleed Gantt. I hadn't used Project in years, and after being exposed to it again, it really struck me how deeply the waterfall model is ingrained into the product. Take a look. What do you see?
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 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.
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.
@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.
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.
Excellent analogy, Jim!
+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.