Trello is a new product anounced today, but it looks like it matches your requirements: http://blog.trello.com/launch/

I would start with a question what exactly your problem is. We don't introduce project management methods for the sake of introducing them but to organize our projects better. In environment you describe I believe the first problem is coordinating different projects and not managing any single one of them. If most of your projects are covered by only a single developer most of the time your project management effort should be focused on: planning, as that's what tells a developer what to do monitoring, as that's what tells you how well (or bad) you're going risk management, as that's what helps you to avoid issues In one-man project either of those can be dealt with using very simple methods and rarely project management tools would help you much with them. Good plan isn't built thanks to a tool but is merely written down using one. Monitoring with one person can be as simple as daily water-cooler chit chat. Same with risk management. From what I see the key challenge here is coordinating different projects/tasks among the team. A very simple solution which can help you here is Kanban. You can pretty easily visualize and organize tasks you have among different projects. You can adjust the method to the way you work. Even if you don't apply every principle, like limiting work in progress, Kanban should help you to coordinate team's effort. And the best thing is it costs you nothing as long as you have whiteboard/cork board and a bunch of sticky notes. I assume here that the team is co-located. It you are distributed you will likely need software Kanban board, but that should still be pretty cheap solution.

I used basecamp with scrum for over a year. It was wonderful and I wish I could go back. Excellent writeup here how to do scrumxp with basecamp The key ingredient is the burndowngraph.com tool. With modifications to that, here's how we ran it... I kept one todo list as the product backlog. (When things were very crazy at first, we used a spreadsheet, but use what works for you). For those that required more description we would use the comments to add what we needed. Normally this was acceptance criteria, mockups and "gotchas" that we didn't want to forget about. During each sprint planning meeting, we grab the stories from the top and break each out into its own todo list. Then for tasking we would create a todo item for each task and use the "6h" method of marking the estimate so burndowngraph.com would pick it up. Sprint planning summary, retrospective, and items completed were all logged as messages. For very detailed items, we would sometimes use a writeboard to log the "spec". An attached word doc would work just as well.

For realtime collaboration it doesn't get any simpler and cheaper than Skype. I'd also advise adding some developer productivity measurement software like ProjectCodeMeter.

One Page Project manager is one: https://www.oppmi.com/ I also think status is best done with a cut and paste from an excel as well.

The really important thing not to underplay is that you have a team that has already been successful in delivering a non trivial project. It sounds like there are things that you want to improve, but it should be possible to tweak this process with small incremental steps rather than needing to resort to wholesale changes. Is it a requirement that everything is available on line? Since everyone is co-located I'd suggest avoiding formal management software until you absolutely have to. The lighter weight you can make the tools the more adaptable your solution, this makes it more likely that your tools will mirror your process rather than your process be dictated by your tools. I'd suggest using something as simple as a wiki or an online spreadsheet for shared persistent state with white boards and post its for day to day task management. Daily stand ups for functional team keeps everyone on the same page and provides a quick way to identify risks to the project. What you eventually decide upon will be specific to your situation - here's a description of a light weight method for task tracking using a Kanban board that might give you some ideas. http://fragile.org.uk/2010/01/kanban-in-practice/ Neil

If the budget is a constraints something as simple as Google site can be used. If you have a gmail account explore http://sites.google.com It allows you to upload documents, share information on web pages, create posts for periodic activity and a lot more.

I prefer resource leveling by hand, as well. It may be because I have not worked with a good leveling tool such as the one Trevor is suggesting, but I think it is more about the control of doing it manually. However, that said, I also think the value of resource leveling is best only during the initial creation of the schedule and performance measurement baseline. Chasing a leveled schedule thereafter is futile and I cannot see its value. Proper scheduling decisions can be made simply by looking at the resulting resource utilization after actuals have been entered.

I remember looking into a product called Telelogic DOORS for this type of tracking. It seemed perfect, but I wasn't in a position to recommended it at the time. The product is now a part of IBM's Rational suite of tools, and I would assume has a hefty price tag. IBM Rational Doors

Check out some of the questions and answers on other project management software related questions https://pm.stackexchange.com/questions/tagged/pm-software Consider using start dates as well as due dates when planning so that the blocks of hours have defined time periods to which they belong. This will also help you better schedule and control the work as the number of projects increases. Here is a blog post describing the benefits of using start dates.

My basic instinct has always been to go in light and be open to change - from programming to project management (basis for agile approaches). Get the communications and planning tools in place that are easily used and cheap, integrate only those tools when and if the integration will provide true value NOW. Specific to your questions: mixing vs. purpose built? - mix them and only invest in purpose built as a last resort (let others pay the cost of better tools) risk redundancy? redundant for you or your team? set a standard, but don't enforce it on everyone unless you can ensure they are not losing productivity loose integration - absolutely, just like programming, don't over complicate the tools, the focus is on the project, not on the tools to manage it

Although it's a third-party development, there is a bridge to SugarCRM, which is self-hosted FOSS. I haven't tried it yet, but plan to.

Trac is an obvious choice. We provide its "cloud" installation in fazend.com for free, together with Subversion.

JIRA can be configured pretty extensively, including rights to access specific areas and items, and I believe it should cover all scenarios you mention.

See: http://downloads2.omnigroup.com/software/MacOSX/Manuals/OmniPlan-2-Manual.pdf Search for the Resource View. It will allow you to allocate the number of hours worked, start/end times, and can be exported as a PDF or Excel document.

If you have resources already loaded against a package that has a duration value and a work value, then when you change duration, it will adjust work based on the assumption that the resources loaded do not change their utilization level. If you want to alter the duration, then you need to type in the work value again; that will adjust the resource(s) utilization accordingly. The default logic in the tool for fixed duration is for it to automatically adjust work, then resources, in that order. If you do not have resources loaded, and you play around with duration, the work will NOT change, because there is no third variable against which to change the work value. I do not know if you can change the logic in the tool.

When you purchase the fuel, it is spent. If the machine takes 100 gallons and you need it April 12, you load the 100 gallons on April 12 in your schedule at your estimated cost. There is no value tracking the fuel burn because there is nothing you can do with the performance variance. Once the fuel is loaded, it is gone. (I retract this entire answer, above; I was too narrowly focused.) EDIT: My original answer was constrained by thinking only from like an earned value perspective, but after thinking about this more, and the comment below from the OP regarding his attempt at planning, I think I was looking at this through a paper towel holder. For estimation, I would use the data I have already collected around work and duration for labor as an input into my fuel estimation. The manufacturer of the machine ought to have a rated fuel burn for its use, like a car's miles per gallon or a plane's gallons per hour. That datum is also an input to your estimation. If you have historical fuel burn values, then that is also an input. So as an example: If in my work package I estimated 100, 180, 125 hours (optimistic, pessimistic, most likely) of work; and 10, 25, 13 days duration. For planning values, based on my risk analysis, I may choose 135 hours of work and 15 days of duration to load into my schedule. In this particular package, the machine is expected to operate about 80% of the time. So only using this is a guiding principle, 80% of 135 hours might be the planning value I use for fuel usage, or 108 hours. I can reduce or add to that based on other risk factors. Continuing this example, the machine might be rated at 35 gallons per hour and my historical data might show I typically get 30 to maybe as high as 38 gallons per hour. So for a planning value I might choose 33 gallons per hour to load some buffer. 33 x 108 is 3,564 gallons to be used in that package over the 15 days of work. Price of fuel is also variable. I would apply the same logic to the price per gallon and choose the value that is best suited for risk purposes. Loading the fuel into the schedule depends on how you are purchasing it. Are you purchasing all the fuel at once and storing it or as you go? If as you go, I would load a separate control account for materials and underneath this a package for fuel. I would schedule the fuel purchase when I would expect to purchase it, the quantity and the associated cost based on my estimation above. If you run out early or have more than expected at the next purchase, you would load the actuals just like labor and track your variances, which would then allow you to readjust your planning values if and when you replan your work down the line. I hope this helps and good luck!

In the environments I have worked in, new development is green field work where there no existing system in the target software platform. This may be a reimplementation of an existing system, or development of a new system. The scope of new development is usually quite large. Examples: Writing a time and billing system to replace an existing platform. This was a replacement for a system running on obsolete hardware in a language not available on the new hardware. (Significant enhancements were possible due to changes in languages and technology.) Implementing an OCR form processing system. This was to automate the capture of data which was being manually captured. A new feature is an addition to an existing system. The scope of new feature work varies significantly. It may be as simple as adding a new field or button to a form, or require extensive modification to a system to add significant new capabilities. Examples: Adding a new statistic to a data analysis report. Adding selective inactive data archiving to a system where activity occurred in many tables and all related data was to be archived. There are some activities that may be fit both categories such as adding a new report to an existing system. This may be new development as the code doesn't exist, but adds a new feature to an existing system. I would consider this a case where a new feature results in new development. These categories exclude corrective actions (bug fixes). Some bug fixes may require the addition of a new feature, or in some cases removal of an existing feature. In this case, a corrective action results in a new feature.

If by "tentative" task you mean one that is not approved or unclear whether it will be in the scope, it generally shouldn't be in the project plan. It should rather be relegated to another document. Anyway, if you have to do it: In MS Project, you'd be able to color-code the task name or the duration bar in the Gantt chart. This would make tentative tasks very easily distinguishable. Projectlibre doesn't allow color coding unfortunately, so the only other way I can think of, is to add an extra column to your Gantt. You do this by right-clicking one of the existing column names and selecting "Insert column". As "Field" you can just specify "Flag 1". This will give you a column with a checkbox for each row / task. You can then rename the column (just right click the newly created column) to "Tentative" and set a checkmark for every tentative task. This will then be shown in the Gantt chart.

From my expirience Redmine works fine for small projects. Most things you mentioned are quite simple to achieve and it's not overcomplicated in general. Modules you don't plan to use can be easily disabled. It's free and has good plugin repository, so you can add lacking things like budget management.