Go To Articles Directory Home Page
To get the current article, - See Below (at the bottom of the page) -.
For top news titles, see below.
Web sites and videos listed in this page are frequently updated.
If you find that this page is useful (quality of web sites, images and videos, ...), you can add it to your favorites.
Bookmark Page !
Why MS Project Sucks for Software Development?
- How is the project going?
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.
What reasons did you hear against MS Project? Here are some of them:
All complains could be divided on three problematic areas.
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.
Reason 3: Isolated tool. It is not integrated with all other software product management tools.
Hummer and Warm Wax
Let's take an average software project with full plan created up-front. It appeast that it is hard to support project plan in actual state using MS Project. It is hard to reflect real progress. But why? MS Project is great software, it should be easy. And it is easy in many cases, but not in software development. MS Project is useful when:
But most software projects have specifics:
No matter what tool you are trying to use. Most managers and executives improperly think that Waterfall requires such detailed plan somewhere in the beginning. Waterfall is not the best way for software development, but incorrectly understood and implemented it becomes a real pain in the neck.
You may say that MS Project is just a tool and all I wrote above do not directly depend on MS Project, but on methodology and process. I partially agree, but, once again, MS Project was not designed to support anything but Waterfall or its modifications. It is used for Waterfall and not so many people tried to use it for something else. MS Project + Waterfall = Hummer, but software development in most cases is not a nail, it is a warm wax. You can't make anything but a flat from wax using a hummer.
As you see, there are plenty more reasons to find a better way. Let's step back and look at another process.
If we can't have fine-grained plan for whole medium/large software project, let's split it on chunks and create fine-grained plan for each chunk when it will be necessary. This idea is not new and called Iterative Development. Whole project splitted on iterations (exact iteration duration depends on many factors, but usually it varies from 1 week to 3 months) and iteration planned just before start.
This may sound astonishing for some executives. "So we don't know project end date??? We don't have a plan??? Our customers will not deal with our company! What the hell you are talking me?" How can anyone answer these questions? There are two ways to go.
On the first road there is no exact project end date and this road called Customer Satisfaction. You respect them, trust them and produce software they want. Feature by feature, iteration by iteration. Exact date of final release is not required since customer knows that you'll implement as many features as possible based on defined priorities. It is real trust and it is quite rare.
On another road there are many signs with a big red "Deadline" in the end. While everyone wants to be on Customer Satisfaction road, most of us are on Deadline road in fact. This is a real world and, while we changing it, we have to drive some projects on this road. Can we apply iterative development? Yes, but with some restrictions, since there is less trust between developer and customer. Customer expects a fancy project plan, so we will create one, but low-grained. MS Project is good for low-grained plans. The plan will contain project phases and major milestones and, of course, it will contain end date. If customer asks why there are no tasks, you answer that you don't like micro-management and fine-grained plan will be developed later. In fact, customer doesn't care about exact plan, it does care about delivery dates and you've already provided them. Then you may break down each release on iterations and follow first road.
Some off topic. The other trick is to leave project/release scope flexible and this is really hard to achieve. It is harder than make a sculpture from warm wax with a hummer. If customer insists that he should get these features till that date without any deviations - you are in trouble. All you may vary in this case are people and process. And often you can't vary people as well. So the process becomes a single life-saver for you and your team. While it is powerful life-saver, it may not help. Once again, do your best to leave scope or date flexible and focus on Business Value whenever it possible. If not, use iterative development anyway and try to release something useful as early as possible. Maybe customer will appreciate your effort, trust you and you slowly turn to Customer Satisfaction road.
"OK, we may use MS Project for low-grained plans. But what should we use for fine-grained plans?"
I can't point Best-of-the-Best solution, but some important things that your tool of choice should do:
In short, the tool should be opposite to MS Project, it should be strong in those areas where MS Project becomes frustrating.
Stop! I Can Plan Iterations in MS Project!
Yes, go ahead and try. You'll quickly discover how it is useful for iterative development and how it is designed for iterative development.
I've planed iterations in MS Project for several projects and it somewhat worked, but this method lacks visibility. Developers don't see plan and don't see progress. You should update actual effort manually and assign tasks using Outlook.
How many features in MS Project you will use for Iterative Development? Gantt Chart, Resources and Tasks. That's it. Tasks will be independent, so critical path is useless and Gantt chart is not very helpful. Leveling… OK, sometimes it helps, but in most cases conflicts may be resolved very easily for one iteration. Reports? Useless in most cases, but you may need something for executives. It appears, that MS Project is too complex and don't bring enough value to justify its usage in iterative planning.
On the other hand, there are many features that you'd better have for iterative planning:
So you really may plan iteartions in MS Project, but it will be not so simple and natural. MS Project just will not help you much.
About the Author: Michael Dubakov is a founder of TargetProcess, tool for agile software project management.