What is the best way to convince my team that we should use project planning software?

Question

I have tried (in vain) to convince my team that we should use Project Planning Software. I see it as a great way to plan out our projects and determine deadlines for deliverables. They see it as a hindrance to productivity.

Is there some grand arguement that I'm missing here? I would absolutely love to see how long we planned for Milestone X, then how much time it took to complete Milestone X. That information is invaluable to me. But, they just don't see the value.

Answer 1

Failure is a great teacher just don't be in the firing line with an 'I told you so' at an indelicate moment ;)

Answer 2

Joel Spolsky wrote a great article for his Joel On Software site:

Evidence Based Scheduling, Friday, October 26, 2007

It's basically an ad for FogBugz, but a pretty good one.

Answer 3

Someone (i think it was Joel, but don't quote me on that) once made the following suggestions: Start use it for yourself and use it in meetings, recaps etc. Eventually, while the rest of your team is struggling, they should see the value.

It's a bit hard to grasp the values of proper project tracking at first, especially because "it always worked without", so creating an island for yourself is one approach to it.

Answer 4

Joel also recorded a Demo of his World Tour:

http://www.joelonsoftware.com/items/2007/10/24.html

There are some really nice bits in there, but it's an hour long.

Answer 5

Your team might be right... but so are you.

First, I think everyone should agree, including senior project managers (I am not a PM BTW) that software is not the important part here. Using the software is not the point, doing the right planning that will match your companies workflows and goals is. It matters little if you use software or not, your argument should be around how your should be working, and then what tools if any you need to facilitate that work.

The use of Microsof tProject for example is in my opinion wrong for most software companies that are usually ~20 developers. The project becomes obsolete by the time you publish it, it is hard to maintain and no one looks at it.

Is your company doing 2 year water fall planning cycles? or is it 2 week sprints? obviously the tools and processes for each case are totally different.

For short cycles, what works for me is having the release just broken into issues (tasks) in the issue tracking software (same one that tracks bugs). Then each issue has time estimate, and when developer works on it, he will also put in how much time it took. The overhead is very small, and you get all the date you need: * How good are estimates * When are you projected to finish this release based on estimates (normalized by the accuracy of previous estimates) * how much time you spend on bugs, features, and on which parts (web, DB etc) * Who did what (how many bugs each dev solved? how much time?)

So the idea is to have very little overhead (like the wasted days you spend creating a MS project), yet be able to have good estimates of where you are and be able to analyze what you did.

I would love to start, but I don't know where. I looked at Microsoft Project, but it's confusing. I just want to be able to create a "Project" where I can attach things like Spec Sheets, diagrams, task lists with time estimates, and reports on progress.

It sounds to me that this is more of a "dashboard" requirement. Look into using a Koweledge management wiki based system like confluence

SMfzKYzmpgTT1bG2Dg&usg=AFQjCNG5vr3GXbq4prtmX9zb_MP8sQGUKw&sig2=_1pzGfjIF61JhlF8mYSrsQ

Answer 6

@csmba: Agreed. The software is not the point. I just assumed that using software would include less overhead than not using software. The actual planning is what is important.

I would love to start, but I don't know where. I looked at Microsoft Project, but it's confusing. I just want to be able to create a "Project" where I can attach things like Spec Sheets, diagrams, task lists with time estimates, and reports on progress.

Answer 7

@Michael Stum: I think this is what you were talking about.

In his article "Getting Things Done When You're Only A Grunt", Joel suggests to just do it. Start using it yourself, and wait for management to notice how much more productive you are (or in this case, how much more accurate your estimates become). After that, you'll have evidence to back up your assertion that it's helpful, and management will be more willing to listen.

Answer 8

I would love to start, but I don't know where. I looked at Microsoft Project, but it's confusing.

It's not confusing at all! Just start MSProject (or the software of your election, many of my colleagues still prefer MSExcel) and write this:

My Project

Under that task create the followings:

Interation N
        Define Requirements
        Design
        Construction
        Test
        Deploy

Don't worry about estimation at first. At first you must do the breakdown of work creating as many task as you need to make your point. Usually, a tasks that last less than two days isn't worth mentioning.

Split your project in various iterations.

All this work of planning is based on previous experience. If you don't have the experencie, ask for required tasks to get a deliverable and ask for an estimation.

When you get a sufficient granularity of tasks, and everyone estimated, make sure to register the dependencies between tasks (you can't start testing comm. classes until comm. classes get constructed)

Assign resources (programmers, users, testers) to every tasks adjusting estimations accordingly (at first MSProject assume a task of 10 hours will get completed in 10 hour by a person, but in 5 hours by two people; when everyone knows it will take 12.5 hours for two people. Resolve overwork. Consider holidays.

Now you get a perfect plan of your project. You know what will be doing everyone everyday, and you know the exact day when the project ends.

Now is time to redo everything again. Because a plan is a map for a flooding river and you'll have to redo it frequently.

But look: that Gantt Diagrams looks so pretty! Your Mama will be proud of you.

Besides that, you'll have the power to foresee how much delay will be introduced if someone decides not to work for a week. You'll have also the power to see what thinks can be reorganized to reduce the slippage from a month to only 3 weeks and 2 days.

Enjoy!

Answer 9

As others have suggested, start with Joel's excellent evidenced based scheduling approach.

At the same time start a simple log of risks and issues. This should include 1. date raised, 2. raised by, 3. probability (for risks) & severity, 4. status (at least open or closed), 5. blurb on the actions that have or will be taken, 6. review frequency and 7. expected or actual close date.

This simple spreadsheet will soon prove invaluable and. to your question, will quickly get unmanageable. The path out of the managability hole for everyone will be the project schedule that you want.

At this point you should be sure to read Joel's views on why the MS Project team doesn't use Project. The key learning is to minimise the number of dependencies that you allow.

Answer 10

IMHO,A plan is much more than a schedule. It contains the resource plan, budget, risk mitigation plan, test planning( Verification and Validation) among other things. It is not about using the software as such, but rather abouut the identification of these aspects.