Why MS Project Sucks for Software Development? Part I | Targetprocess - Visual management software

Updated: Maybe it is better to rename the post to "MS Project Sucks for Iterative Development" to stress that I don't hate MS Project, but I think it is not the right tool for agile development.

Part I
Part II

- How is the project going?
- Fine.

[translated]
We don't know what we are doing at the moment and are a little confused because our key clients changed the requirements yesterday. But, don't panic. Last time we got a requirements change we managed to drop off some other requirements so we seemed to be back on track. […] To summarize, no one has gone crazy yet and we are pretty confident that we'll all survive ... so go away.

Part I. So What's Wrong With MS Project?

Microsoft Project is a leading software on project management market. And almost all PM's over the world use MS Project to create plans and track progress. I used MS Project with various successes during three years, but I quit. It is just sucks. Maybe you think I "don't get it", but that's not true. I know how to level resources, create resource pool, analyze Critical Path and track progress over baseline. I even know about Earned Value technique. To be honest, MS Project is quite easy to use and very powerful, but it isn't designed for software development. More precise, almost all business assumptions that lie under MS Project do not work for software development.

Problems

What reasons did you hear against MS Project? Here are some of them:

  • "Things change very often and I spent too much time on re-planning everything. I am feeling like wasting my time"
  • "I use MS Project, but my team doesn't. So no one but me see the plan. They don't "feel" project schedule".
  • "Did you see Gantt chart for large or medium project? With more than 500 tasks and with tasks as "Bug fixing" - 34d? They are so damned complex!"
  • "Oh, it seems I never learn all that features. MS Project is a huge thing, I think I should read really heavy book to get it"
  • "I won't update real progress manually! It is a crap!".

All complains could be divided on three problematic areas.

  • Desktop application
  • Complexity
  • Waterfall as a natural methodology

MS Project based on Waterfall

Waterfall maybe the main disease in MS Project. MS Project fully focused on Waterfall model in all parts. It teaches newbie project managers how to create complete plans up front. It does not mention other approaches anywhere in tutorial or help. Books about MS Project do not mention anything but Waterfall. In fact they did not mention "Waterfall" term as well, but all the details direct to it. As a result, almost all software project mangers start from Waterfall. In general, it is the same as trying to win a motograndprix on a bicycle.

Reason 1: Wrong process. Waterfall is a bad process for most software projects. MS Projects based on Waterfall approach, so it is bad for software projects as well.

MS Project is Desktop Application

Waterfall is not the only reason against MS Project. This tool makes plans almost invisible for team. You likely will not print out the plan on large sheet of paper and put it on the wall. In most cases team doesn't see the horizon, but only some assigned tasks. But even if you will print the plan, things won't change, since nobody will understand that big and complex Gantt chart. Plan invisibility impedances people involvement into project.

And you should do your best to integrate MS Project with any kind of time tracking software. Otherwise you will get stuck on actual effort measurement

Reason 2: Wrong platform. It is very hard to track real progress in MS Project on a daily basis. Only PM can work with project plan.

MS Project is not Integrated

Well, this is not an obvious concern. How many tools you as PM have to deal with to get all important information about project state? Project planning tool for sure (MS Project). What's next? Bug tracking tool to get some metrics about project quality (Bugzilla). Test Case management tool (usually Excel) to know how many tests already passed and what the real problematic areas are. Automated risk management tool is a blue dream for most of us. Often we use MS Word or Excel for risk management, which is not very convenient. Requirements management tool (RequisitePro).

Now it is easier to see the real problem. We have a bunch of separate tools. We spend much time to get real project state. We want something integrated and easy to use. I personally want to get all required stats with several mouse clicks. I am sure such tools will appear in near future. And I don't see how MS Project may stands on this way.


Related Links:
MS Project,
Bugzilla,
Test Run,
RequisitePro,
CaliberRM,
RiskyProject

Reason 3: Isolated tool. It is not integrated with all other software product management tools.