I've been thinking lately about the project process, and how software that manages the process tends to focus more on certain aspects than others, sometimes leaving important elements completely uncovered. To look at an example, Trac is a well-known ticket tracking system. It has built-in case tracking, revision history review, and documentation via the wiki. There are many plugins available that enable different minor features, but these are the basics of what Trac provides: Timelline, Tickets, and Wiki.
These features are important, but they do not encompass the whole project. A small development shop needs more than just these items as tools that are essential to their work. A very simple example is a design/document review and distribution system. Maybe this is not explicitly essential, but I've found over my time doing web development that there is too often a need for this than to let it go unchecked.
In such a feature, stakeholders would upload documents - whether designs, contracts, specifications, or whatever - to the tracking system. This would make them available to other project members as needed. This basic type of dropbox functionality is useful for accepting content from clients, making it available to the project team centrally rather than through unreliable email forwarding (especially for attachments of any useful size for designs), and having some accounting of when and by whom the files were provided.
In essence, this feature seems like a "nice to have", but rather than figuring out which 3rd party tool provides each individual feature of a full project process, shouldn't there be a single tool that does everything? From that perspective, there are a few significant feature that need to be added.
If you look at the project process from the point of view of a small web development shop, the project starts at the pitch. There should be a way to track bids and proposals in the system, so that those documents can ultimately be moved to active project status. This type of feature would also be useful to schedule and maintain contact with those potential clients.
An idea that has been growing more as I consider the full project lifecycle is that of a CRM, which ties nicely in with the bid process. Small web firms need to be able to efficiently manage time. Everything runs on a schedule, otherwise the next project will be delayed, or a bid will be lost due to time constraints. If part of your bid/proposal process included scheduling follow-ups wouldn't that be useful?
Consider also how CRM features could improve the ticketing and revision process. Rather than subscribe people individually to tickets, the system would leverage the CRM to obtain contact information and potential demand/desire for specific kinds of contact. Automatically send messages when milestones are reached or delayed. Notify the proper stakeholders of changes in planning and design. When documents arrive into the dropbox-like review system, make sure that the right person not only sees them, but has signed off on them, and keeps getting notifications that this must be done to complete the process.
One of the most frequent places in the project process where things get held up is during content creation. Too often, clients think that after they get to a certain point, the developers will simply make the site go. Without content, there really isn't a site, and the client is responsible at least for providing the content, if not entering it themselves. A CRM would be able to manage that process automatically, where developer who are busy creating features and making the working of the site perfect will often forget to remind the client - and the correct contact - of that obligation.
Another component of the problem is overall project scheduling. Unless you're able to work on only one project at a time, and only for a specific length of time, and meat your deadlines exactly without fail, you're going to need a way to schedule personnel resources against the projects that exist. You're going to need to know who is available, what skills they can apply, and how long it would take them to complete components of the project that have been assigned so that their work can be scheduled with the work of others on the same project, and with their other work on other projects.
This is a complicated problem, because there are so many aspects driving the needs of the scheduler. On one hand, assuming you had a definitive number for how long it would take each specific person to accomplish each specific task, you would be able to schedule all tasks with a simple calendar. Allow enough time for task-switching and thought organization, and that could work pretty simply. But we know that teams and workers don't work this way, so the scheduler needs some way to account for this, otherwise the schedule will be seen as useless very quickly into the project.
The schedule needs to account for risk in a way that makes sense. Some systems will calculate a worker's prior estimates against their prior actual time taken, and use that as a factor for multiplying out future estimates. There are so many things that could affect this computation, the simplest one being the worker himself altering his estimate based on prior performance! There is also the possibility that the work is completely different, such that the estimate has a different level of expected accuracy.
The challenge in building a system will need to include that there are many methods and processes for producing more accurate estimates, and that the more complicated these methods are, the more time they'll take as part of the project planning task. Some tools like Agile look at acceleration and story points as potential ways to estimate time for a task. Some processes include full-blown estimation and risk assessment. The ultimate project planning tool will make it as easy as possible to produce as reasonably accurate estimate, rather than dispense of accuracy for ease, or dispense with easy for accuracy.
It should be easy to determine what methods will work best simply by applying a one-page approach. That is, what information can be computed and conveyed with enough accuracy on a single sheet of paper that it is useful? This is likely to include many manual processes that might be tedious on paper, but more easily done with the computer. In most cases, things that work well in the real world that are made better with a computer end up being great solutions (see also: word processors). If the software can reduce the complexity to that level, then I would expect it to be successful.
It seems like my next step should be to outline a basic project workflow and identify the components that a computer could help with by demonstrating how they could be done on paper (or via mail or phone or in person, eschewing the computer completely). Using this process, I will have produced a list of useful components to project management success, rather than producing a set of features with no target. I do run the risk of targeting the end software at too specific of a process, which is something that I want to avoid. But if I'm careful to be very generic about the kinds of projects that this software will address, that shouldn't be a problem.