I've tried the demo, and its a breath of fresh air compared to 99 percent of project management systems out there (hosted). My main issue is that there doesn't appear to be a way to link tasks together, so in the event I need to push one task, I would have to go through and manually edit the due dates for all tasks that follow. Are linked tasks/milestones a planned feature or plugin, or did I just miss it?

Also, I was unable to find documentation on the site, but what would the difference in functionality be between Milestones, Checklists, Pages, and Tickets? They all seem to do very similar things but Checklists seems to be the only place I can add tasks. It seems like I should be able to add tasks under Milestones, no? Let me know, I am interested in a different PM solution for my Company.
-Noelix

I agree with the above posts completely. We need a way to manage task dependencies. Does anybody know of a module or planned feature implementation for this need?

Maybe an artificial linkage would benefit all. Something that merely triggered a status indicator and in the best case notified the person responsible for the follow-on task that the predecessor was complete.

For example: I create a milestone and make Judy responsible. Then I create another milestone assigned to John. I have the option to 'tie' this task to another task with a conditional display:

Tie to task... > Select from the Milestone / Ticket / Task Tree (except a child to the current object) > Select an output action on completion of the tied task > Notify assignee of this object | Mark status as GO (otherwise mark as BLOCKED)...

So when Judy marks her milestone complete, John gets notification that the dependency is done.

Doesn't seem too tough to me as long as it is only indicating and notifying, if it gets into any calculation logic or crazy real dependencies or lockdown controls that gets nuts... I see this as a valuable function. This also assumes that a task / milestone / ticket can only have ONE external dependency.

>There is currently no plan for task dependency introduction.

>The software needs to work like projects work, the project cannot be "bent" to fit like the software works.

I think the above says a lot without further comment.

I've enjoyed aC quite a lot, but have come to have a number of concerns in the past months.

One is that, like many projects of its nature, it seems to have stalled a bit from lack of further steam.

Another is that it seems to have reached the point where it is "too big for its britches."

Looking over the very large landscape of how groups handle projects, the task, ticket, page, discussion, etc., schemas seem to address only a very small portion of 'what and how' workgroups get things done, derived from the limited experience and needs of the aC team, and to ignore a much, much larger base of potential users, customers and clients.

Said respectfully: there is a great difference between using a hammer to pound a nail, and using the heel of your shoe, and if you don't grasp it, try putting a house together with your shoe in the place of the hammer. When I read over six month of issues relating to things we NEED aC to do, I fear aC is tending towards the shoe in place of the hammer.

Equally, from my position as a "Project Manager" or "Leader:" I have fifty-plus open projects, hundreds of open tickets and tasks, and no way to manage them from a simple administrative screen than lets me pick & choose what I need to see to keep those projects on track. (And I could rail off ten or fifteen other smaller issues, such as the lack of a simple "desktop" tool to create a task/ticket/issue and assign it correctly, in seconds).

And equally the project leaders under me, who have quite a few LESS projects, have similar concerns with being unable to view, track, and comprehend the tasks in the system-- and prioritize among them-- given what we have.

I understand your time is limited; so is ours. And I don't wish to focus on "what is wrong" with aC: rather, on what aC <i>could</i> be. It is better than much of the dreck of the 90s-- often filled with simplicity and clarity, where previous products in the market practically required six weeks of training--

But where aC works for the team that build it, -- well, one of the classic errors of product development is building something that works for your needs. In the end, I don't need a product that meets your needs, and I certainly don't need to be told to wrap and alter how we're trying to do things, around the limitations of the product you've produced and the way you expect things to be done.

I need a product that's flexible enough to meet my needs, my workgroup's and my peers' needs, and, in fact, the needs of people and groups who act entirely differently than me-- just in case I need to adopt their business methods, or work with them, next year, next month, or next week.

Practically, I need to be able to reach into the data (tasks list), pull out what I need, display it in the ways (views) I need to get my job done-- and to change that setup if I wish-- and I need that need (headache) solved in hours, or days at the most-- not the weeks, months, or years of the current development cycle.

I am thus suggesting two things:

1) That a closed, limited-team development effort is not sufficient resources to address the tasks at hand, unless you're MicroSoft (and perhaps not even then).

2) That the current "custom, do-it-yourself" PHP base is also insufficient and should be abandoned for a more robust "platform" or "framework:" by this I mean to point out something like "If aC were built in something like Drupal, it would take my team a day or less to build the views they need; a bit more to link tasks to tasks and notifications." (I use Drupal as an example because I know it; there are certainly other 'framework' options, but PHP is not the tool for the task).

Finally, I have fifty or so clients behind those fifty or so projects-- some of them unreasonable, but most of them just common businesspeople, without years of technical training in IT systems. I could go on, but the bottom line is that aC is alien to them, it doesn't solve their problem well. No offense meant.

Build something that does match their needs well, that educates as it is used, and that helps them organize and do what they need to do...