free project management sofware?

[ersin eser]

are there any of them out there?
thanks

[Ilja Preuss]

What kinds of projects do you want to manage? The type of software you will need (if any at all) will heavily depend on this, especially on the size (number of people involved).

[Mark Herschberg]

I'll jmup in b/c I've bene interested in this two...
I knwo there's bug tracking software out there (Bugzilla), but what about things like:
- scheduling/dependencies
- requirements gathering
- metrics gathering/tracking
- resource allocation
- balanced scorecard
etc
--Mark

[Frank Carver]

And more questions ...
What does "project" management include for you ? budgeting and financials ? "human resources" issues such as tracking training, personal development, leave and sickness? source-code and documentation/content management ? build and release automation ? intra-team communication tools ? team/customer communication tools ? ordering of equipment and consumables ? bid/tender management ?
I can't help thinking that without defining the scope of your question a bit, you are unlikely to get much by way of useful answers.

[Mark Herschberg]

Here's the TOC for chapter 5 of my book: project management:

5.1. Scope
Engineering Triangle
5.2. Planning/Scheduling
Man on the Moon
Buy vs. Build
5.2.1. What is included in an Estimate?
5.2.2. Recognizing A Bad Schedule
5.3. Status Reports
How to deliver bad news
5.4. Risk Management
5.5. Personnel
The Mythical Man-Month
5.6. Support
5.7. Budget
5.8. Process Improvement
5.9. Employee Growth and Development
5.10. External Factors

(The sections without numbers are sidebars.)

Not that the list above is comphrensive. Things like scope are a big topic. There are also issues like managing customers (I talk about stakeholders in chapter 2). I included the list above because I think it touches on topics most people ignore in project management.
--Mark

[Ilja Preuss]

Originally posted by Mark Herschberg:
[...]what about things like:
- scheduling/dependencies

Scheduling mainly depends on two things: business value and development costs. So it seems to me this would best be done in direct collaboration between business and development people. I still have to find a software which beats index cards as a collaborative tool. See http://www.wikiservice.at/dse/wiki.cgi?KarteiKarten/Experiment
Regarding dependencies between requirements, XP (for example) simply tries to pretend they don't exist. It seems to work better than you might guess and has some interesting consequences concerning delivering business value early...

- requirements gathering

Again, I think this is best done in an ongoing conversation. For projects with many distributed users, Bugzilla and the like seem to work fine.

- metrics gathering/tracking
- resource allocation

What kind of software are you thinking about?

- balanced scorecard

What's that???

[Mark Herschberg]

Originally posted by Ilja Preuss:

Scheduling mainly depends on two things: business value and development costs. So it seems to me this would best be done in direct collaboration between business and development people.

I don't disagree. But it often falls to the project manager to write it up, track the schedule, and be aware of schedule slippage. To do this, the manager often uses software tools. I'm not looking for a tool to create the shedule for me, but just to record it.

Originally posted by Ilja Preuss:

Regarding dependencies between requirements, XP (for example) simply tries to pretend they don't exist. It seems to work better than you might guess and has some interesting consequences concerning delivering business value early...

It works worse then you may guess as well. I don't deny that given a good group of small developers, it can almost be a non-issue. (I'm doing a two person project right now, our schedule is created, modified, and tracked primarily by saying "I think I'll get to that on Tuesday." :-)
But given a larger team, or a team with inexperienced developers, or complex distributed software, or software developed by different project teams.... well, you get the idea, in these cases, you need to track this stuff.

Originally posted by Ilja Preuss:

- requirements gathering
Again, I think this is best done in an ongoing conversation.

See if NASA shares your sentiment. OK, mission critical projects aside, there are other cases. While I've yet to see a project sans requirement changes I believe you can be more code efficent requiring ahead of time. Let's even consider that requirements tracking in traditional ways is very costly. Still, a company may be willing to spend extra managerial resources to track requirements in order to make the constrained developer resources more efficent in order to meet a critical deadline.
More generally, I'm going to argue that your points are "out of bounds" for the discussion. It's not that I don't respect them, just that this is a discussion about tool availability. Tool appropriateness is a different argument. While not inseperable entirely, we should try to disengage the issues.

Originally posted by Ilja Preuss:

- metrics gathering/tracking
- resource allocation
What kind of software are you thinking about?

Um, what've you got. I can think of a hundred things I'd like to track, we just can't track most of them in a cost-efficent way. I'm willing to settle for what's out there.
Resource allocation is a variation of scheduling, except your schedule things instead of people: rooms computers, CPU time, training, tool time, etc.

Originally posted by Ilja Preuss:

- balanced scorecard
What's that???

It's software to calculate the complex equations for balancing a score card from a major sporting event on edge. Seriously

http://www.toolpack.com/scorecard.html

A balanced scorecard is a central list of numbers, which show each key part of an organization's success, such as financials, people, operations, suppliers, customers, and support systems. The numbers should measure not just important outcomes, but also the factors which influence, or drive, those outcomes.

The one's I've seen/built include things like HR (employees, training, experience, turnover, allocations), finance (the usual stuff), project status, customer relationships, company metrics, RIO projections, etc.
--Mark

[Tim Holloway]

I believe that "MrProject" is actually bundled into the Red Hat 8 OS release. It's an open-source equivalent to MS Project, I believe.

[ersin eser]

Sorry for the late reply. I have been extremely busy.
As you might have realized my question was obscure as i did not know what i was really looking for, Actually I did not know how to call the tool that I am looking for .I am looking into budgeting, intra-team communication, team/customer communication, time tracking type of tool.Not a software development oriented tool. I am working for a company that specializes on advertisement, media production, and pr. There are only two developers (including me) and the rest are people that I have to deal with, artists, designers business managers,business managers, business managers bosses. . I am going nuts. And I really don't want to write a web based program, which I am never going to be able to finish with the schedule that I have , to keep track of their budgeting, intra-team communication, team/customer communication, especially time tracking, Doesn't have to be free but I am never going to be able to convince them to buy something expensive. The company is not a software development house everything comes in and goes out the door within 2 weeks. Extremely heavy turn around. I usually write code for existing systems, add few functions etc. Everything is web based, no standalone applications.In my current job Full life cycle means: "web-site" from scratch :roll:

[Mark Herschberg]

I'm also doing a two man project for an organization which isn't very technical. Of course, oral communication is fine for us. I used Word for requirements gathering and Excel for the schedule. What's lacking in general productivity tools which you want to get in these team tools?
The reason I ask is because those tools usuall ahve a high startup cost. Word processing programs, for example, are a good tool in that you can generally use them productively within minutes. As you get more experienced, you can make use of more features. Contrast this with say, an EJB server, which has a high cost of understanding, and learning the tool. (Yes, they are apples and oranges, but it's the properties of the fruit's we're looking at, not the fruits themselves.) Most project managerment software that I've seen has some basic startup costs. Is it worth it?
--Mark

[paul wheaton]

Have you guys looked at XPlanner? See www.xplanner.org
I think it might help with what you are talking about.

[Ilja Preuss]

Originally posted by Paul Wheaton:
Have you guys looked at XPlanner? See www.xplanner.org
I think it might help with what you are talking about.

It's certainly an interesting tool! For intra-team communication, a wiki might be worth a look, too.
Just be aware of the fact that it's not the technique which is critical, but the communication in the team (including the customer). So it might be even more effective (by magnitudes) to come together in one room and use low tech/high collaboration tools like index cards, white boards and the like whenever possible.
It might even be worth the effort to *make* it possible...
[ January 11, 2003: Message edited by: Ilja Preuss ]

[Ilja Preuss]

Originally posted by Mark Herschberg:
Scheduling mainly depends on two things: business value and development costs. So it seems to me this would best be done in direct collaboration between business and development people.
--------------------------------------------------------------------------------
I don't disagree. But it often falls to the project manager to write it up, track the schedule, and be aware of schedule slippage. To do this, the manager often uses software tools. I'm not looking for a tool to create the shedule for me, but just to record it.

I think it would be better for the whole team to be aware of the schedule - and I'd think it is more effective to use something like a big "scheduling wall" in a prominent place, where everybody updates the state of the current task and where everybody always could see tasks done, in work and to be done for the current iteration, for example.

Regarding dependencies between requirements, XP (for example) simply tries to pretend they don't exist. It seems to work better than you might guess and has some interesting consequences concerning delivering business value early...
--------------------------------------------------------------------------------
It works worse then you may guess as well. [...]
But given a larger team, or a team with inexperienced developers, or complex distributed software, or software developed by different project teams.... well, you get the idea, in these cases, you need to track this stuff.

What does happen if you don't?

- requirements gathering
Again, I think this is best done in an ongoing conversation.
--------------------------------------------------------------------------------

I guess this was misleading...
I didn't mean to suggest that you never should write something down. I rather wanted to suggest that it should be done in a direct discussion between those who know the requirements and those who know how to implement them.
You certainly need to write something down for doing the planning (some words written down on index cards make up good planning tokens, for example), and later a more concise and unambiguous specification (in the form of executable acceptance tests, for example).
I guess I am still wondering what kind of software you were thinking of here...

More generally, I'm going to argue that your points are "out of bounds" for the discussion. It's not that I don't respect them, just that this is a discussion about tool availability. Tool appropriateness is a different argument.

Is it? Don't you think the original poster was searching for an *appropriate* tool???

- metrics gathering/tracking
- resource allocation
What kind of software are you thinking about?
--------------------------------------------------------------------------------

Um, what've you got. I can think of a hundred things I'd like to track, we just can't track most of them in a cost-efficent way. I'm willing to settle for what's out there.

There are some products listed at http://pharos.inria.fr/Java/query.jsp?cids=c_2212
Notice though that metrics are most effective if used very specific - manually updating a Big Visible Chart with the two to three currently most important metrics might be better than flooding the developers with dozens of metrics on an automatically generated web page...
Don't know much about resource allocation, sorry...

http://www.toolpack.com/scorecard.html

Very interesting, thanks! Are you using this approach?
I noticed that the description seems to suggest the biggest benefit of balanced score cards is that trying to implement them forces the organization to think about (and align) priorities. Do you agree?

[Mark Herschberg]

Originally posted by Ilja Preuss:

I think it would be better for the whole team to be aware of the schedule - and I'd think it is more effective to use something like a big "scheduling wall" in a prominent place, where everybody updates the state of the current task and where everybody always could see tasks done, in work and to be done for the current iteration, for example.

You're reading too much into what I said. That the project manager writes up the schedule does not mean only he sees it. You can postit on the wall, or a web page, or send weekly updates, or even have some program similar to what Outlook offers so that everyone can see it. Nevertheless one person must be the owner and/or gatekeeper, to control changes. A point of contact if you will. You can't simply have every engineer adjust the schedule at will.

Originally posted by Ilja Preuss:

What does happen if you don't?

If seen cases where untracked requirements lead to fundamental design flaws at a late point in the project. It cost a lot of time. I saw it kill one project.

Originally posted by Ilja Preuss:

didn't mean to suggest that you never should write something down. I rather wanted to suggest that it should be done in a direct discussion between those who know the requirements and those who know how to implement them.
...
I guess I am still wondering what kind of software you were thinking of here...

Well, I've tracked requirements using MS Word. Others use notecards. Others need formal, cross linked specifications with a dictionary of definitions. Others want a set of use cases. While there's no golden hammer, I'm wonder if there may be a decent tool belt out there with one or more of these tools in it. My generla preference (w/o any knowledge of the particiluar project) is something about the size of a 3x5 card, but online, allowng easy cross-referencing to other requirements, and some way of prioritizing and weighting them.

Originally posted by Ilja Preuss:

Is it? Don't you think the original poster was searching for an *appropriate* tool???

I guess I was just worried about the discussion getting side-tracked into a process discussion.

Originally posted by Ilja Preuss:

Notice though that metrics are most effective if used very specific - manually updating a Big Visible Chart with the two to three currently most important metrics might be better than flooding the developers with dozens of metrics on an automatically generated web page...

I agree completely, although I also think the manager might be able to handle more metrics.

Originally posted by Ilja Preuss:

Very interesting, thanks! Are you using this approach?
I noticed that the description seems to suggest the biggest benefit of balanced score cards is that trying to implement them forces the organization to think about (and align) priorities. Do you agree?

Actually, in fairness this may nt be appropriate. I know about these mostly because I have built some. but they are generally use dby senior management. (We built a system for partners at a big six firm.) It's not generally used for, say, a 30 person project. I do think a similar idea is applicable at this small scale.
I agree with what they said about it at an organizational level.

--Mark

[Ilja Preuss]

That the project manager writes up the schedule does not mean only he sees it. You can postit on the wall, or a web page, or send weekly updates, or even have some program similar to what Outlook offers so that everyone can see it. Nevertheless one person must be the owner and/or gatekeeper, to control changes. A point of contact if you will. You can't simply have every engineer adjust the schedule at will.

Of course, I totally agree to the point of the gatekeeper!
Just wanted to suggest that it might be a good thing to have the whole team responsible for *tracking* the schedule - that is, publicizing wether a task actually got done in time and noticing when it starts to slip etc.

If seen cases where untracked requirements lead to fundamental design flaws at a late point in the project. It cost a lot of time. I saw it kill one project.

OK. The way XP seems to handle this is by requiring all the known requirements to be estimated to the size of a couple of weeks (you need to have *some* idea of how to implement it to do this), by implementing the most important requirements first and by holding the code agile via extensive decoupling ("merciless refactoring").
IIRC, we were talking about tracking dependencies between requirements here. I thought this meant something along the lines of "before we can do B we need to do A". How does this fit into the picture?
I agree with most of the rest of your post - thanks for the interesting discussion!