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.
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.
This has been one of the best blog posts/comment threads I’ve read in a while. Great discussion here! I think a lot of the ideas shared in defense of why estimation in software project is difficult goes right back the book recommended in the original post - Software Estimation: Demystifying the Black Art. Excellent book and I highly recommend it.
I won’t go and repeat a lot of what others have said about frustration with MS Project, but suggest an alternative - LiquidPlanner. I was struggling with project for a few years having the same issues that many others above me did. The biggest thing that attracted me to LiquidPlanner was that it would allow me to build uncertainty into my project schedule by estimating my tasks in ranges, which is exactly what the original author of this post wanted to do. I have not seen any other project management tool do this, so it was an easy decision to shift over to LiquidPlanner. I could go on about the benefits of LP over MS Project in software/web projects. I agree with other comments above that MS Project is handy for specific projects (like construction), but for software/web… it’s definitely not the best solution.
This is a fascinating conversation.
I have to say that anyone who thinks construction or engineering projects are all always turn-key efforts and that only software development is unique each time out may not have had much experience managing a construction or engineering project.
You only have a waterfall if every task is tied start to finish in a single line - that’s not a schedule, that’s a task list. I’ve been scheduling for a few years and have never had a pure “waterfall” because there are always multiple preds/succs for activities and they aren’t always start to finish and - yes - many are worked in parallel. Still, every activity should have a pred and succ so you can calculate the longest path through the project (which, yes, will change multiple times over the life of the project).
I’ve used MS Project and Primavera (3 & 6). I’m required to be a Primavera “snob” because of the industry I’m in, but I find MSP to be a very workable tool. It’s a good place to build the first cut at the schedule because of the ease in cutting and pasting activities to new sections of the schedule.
The purpose of risk management is for those very things that have been put up as reasons you can’t actually have a schedule for a project - you build risk into the schedule the same way you do in the budget.
Nothing ever goes 100 percent right on any project - the schedule is a tool to help the PM keep refining the expected project close date as risks materialize and are addressed. It helps communicate the bad and/or good news to the stakeholders.
I’m curious if you all are PMs or schedulers or developers?
I haven’t had an opportunity to check out LiquidPlanner but I’m intrigued by Dina’s comment about estimating tasks in ranges - that sounds very useful!
Response to Dina’s tweet (because 140 characters is just not enough) about why using three different schedule tools (MSP, P3, P6): When I first started scheduling we were using P3. Last December, we migrated to P6. However, several of the schedules were complex and - based on the manual cleanup effort after importing simpler P3 schedules to P6 - we decided to keep those in P3 rather than expend an excess amount of time on data cleanup after import to P6. So, currently I’m maintaining three project schedules in P6 and two in P3. I had to learn the basics of MSP because much of our engineering work is outsourced and when these vendors are required to provide a schedule it’s always in MSP. Usually the vendor schedule is evaluated in MSP and then the appropriate data is manually transferred into P3 or P6, whichever is appropriate. MSP is also the handiest place to enter activities in the early stages of planning because it’s easier to rearrange activities, make mass changes, and tweak the WBS than it is in Primavera. Hope I answered the right question?
Responding to the comment - "Why it is so difficult to estimate software development, the reasons are:
The software designer is always doing something from scratch or the first time - even if they have had tons of experience.
Every problem is different, every environment (platform, systems etc) is different, every enterprise is different, every set of requirements is different, user needs are different, issues are different, development technologies are different etc.
If the software designer knew how to do something completely, they could finish the project in hours not need weeks or months. The problem is that even the best developer has to experiment somewhat to get the design done right.
Software re-use, software components, software as a service, using packaged software etc are the various ways to cut down trial and error and allow projects to be estimated better. The problem is that seldom are they sufficient or acceptable to customers.
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…
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.
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 RD or coming up with a thoeretical compiler there would be more “art”.
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.
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.
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.
