Jan 14, 2006 / Why MS Project Sucks for Software Development? Part I
24 commentsUpdated: 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.
Thomsett
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.
posted by Michael Dubakov @ 9:02 AM
24 Comments:
Thank you for your feedback! I just wanted to let you know that we are listening. I'm a former software development manager, so I've lived the scenarios you've presented.
Based on what I know about our upcoming release, I think you are going to like the changes for Project 12. Stay tuned for updates in 2006.
Treb Gatte
Program Manager
Microsoft Office Project
http://spaces.msn.com/members/evildoctorporkchop
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.
Holly cow!
Big brother is watching you ;)
While I agree that the help and 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.
Brian Kennemer
Senior EPM Consultant
Microsoft Consulting Services
Author of Projectified (www.projectified.com)
It appears this is not only a misinformed position - MSFT Project is based on Waterfall - but a thinly placed commerical ad for the Blogs product.
The Waterfall paradigm was discredited in the late 70's at TRW through the Walker Royce paper. Maybe a bit of research would reveal that MSFT Project and all the other PM tool are based on networks of nodes with work on the node and constraints on the arcs.
This of course does not restrict the tool from describing a Waterfall style schedule. But it most certaintly does not impose Waterfall or for that matter any topology that can be repreented as a connected graph.
2 Brian
Yes, you can do waterfall with any tool, including TargetProcess, but it will be really hard. There is no connections between tasks in TP, there is no Gantt chart, there is no leveling. You will fail if you try to create whole plan upfront.
The same thing with MS Project. It is not easy to manage iterations in MS Project.
There is no product/release backlog. There is no integrated time tracking to measure actual work, there is no "true time remaining", There is no iteration velocity concept and so on.
So you are right, you can do any process in both tools, but don't forget about additional pain in both cases.
Maybe my wording is not perfect, but you've got the idea.
I will address more details in the next post.
Project/Project Server combined with Visual Studio Team System provides a comprehensive set of integrated tools for all roles in a software development project. Users who don't [need to] care about project plans (ie most team members) can work in their respective tools while keeping the project manager in the loop. You should have a look at the white paper and the solution code posted on gotdotnet (http://www.gotdotnet.com/workspaces/workspace.aspx?id=b9f69ea5-ace1-4a21-846f-6222a507cc9c).And, this solution underscores the fact that that MSProject can be used in a variety of software development methodologies - MSF agile/Scrum is the default methodology supported by this app.
Yes, I agree that *IT IS* possible to use MSP Server, but in many cases this is an overhead. MSPS is not an easy and light beast. There are better ways for agile project and I will talk about them in next posts.
Come on!
You've always known a good waterfall-based process is the right way to develop software projects. Come to the Waterfall 2006 conference and see how a sequential development process can benefit your next project
see: http://www.waterfall2006.com !
waterfall2006.com rocks! :)
We have integrated MS Project and Subversion with its optinal locking for our distributed environment. Everyone tracks their own progress and quite easily avoids conflicts to build the "whole picture" out of several projects using a resource pool. In this case, we do not have to use any Web solutions. So, the "desktop" platform is really much nicer when its Web analogs.
Shameless plug time sorry
I agree that MSProject is a poor tool as the plan it creates is a fantasy about 1 week after its made and its to much work to change everything just because 1 task overruns or a person goes sick
We are developing xProcess a project planning tool and process improvement which uses svn for licensed users to interact dynamically.
Please have a look as its free to download for personal use
http://www.ivis.com
I do agree. Our company for a long time use Track for development activities and very happy with it.
thank you
Anna [ http://helion-prime.com ]
thanks for great post
thank you for nice post
I'm affraid MS Project guys are not listerning enough. There's a huge gap between MS Project and the way real life project management is done. Here's a link to a very interesting blog post about this fact.
Hi,
Listen I've been passing through your blog for quite a while now, and since your are in software development, not sure if maybe you offer it as a service or not, anyways the reason I am posting on your blog is that I have a company that specializes in finding leads-customers for companies and we just have lots of leads looking for software developers, and having quite difficulty finding them providers, so if you are intersted please check my website, HotHelpsYouSell.com .
We really do have quite a lot of leads , and we have people specialized in finding customers/leads in your professional area, we only charge $10 per customer we deliver, so might be worth just to check it out.
again the website is http://www.hothelpsyousell.com/
Anyways, thanks for your time, and really nice blog
Cheers!
I think Basecamp from 37signals, is a better suited project management tool for agile development.
Yeah, but with TFS and Project server coming into picture and with the release of TFS-Project Server Connector, managing projects and work items has become much better.
Offshore Software Development
I think your are right that the help and 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.
http://www.cyberdesignz.com/
May be for the increase of capability of the MS Applications
Regards
SBL Software
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.
I was once a project developer. Even people within MS don't like using MS-project for tracking projects. It just doesn't fit the software development model
Very realistic thoughts.. nice views...
Post a Comment
<< Home