Warning: file_put_contents(): Only 0 of 8322 bytes written, possibly out of free disk space in system/classes/filecache.php line 154
Warning: file_put_contents(): Only 0 of 303 bytes written, possibly out of free disk space in system/classes/filecache.php line 157
RedAlt

I've had a lot of talk at work, and speculated recently on the usefulness of a tool that would help manage projects for a single developer or small development shops.

It seems to me that there is a great business need for a tool that provides three fundamental characteristics that I have so far been unable to locate in project management software:

  • Free and open source
  • Effective without imposing itself
  • Slick as we are

The first attribute is obvious. While there are tons of applications available on the web from service providers, they all seem to come with a price tag. Every web developer I know runs his or her own web site, and has a host that could probably run their project management tools -- if only an adequate open source tool existed that could be installed. Most of the hosted tools also have a stranglehold on your data, so if you wanted to move to a new tool, you'd likely need to start over completely.

The worst part of being closed source is that no generic hosted project management tool perfectly fits the bill for any freelancer or small company, and it's very unlikely that you can integrate changes into those hosted systems that would better affect your company's management style. This is related somewhat to being effective and not imposing.

I think that being effective without imposing is an important aspect of any project management tool. While there are probably some tasks in project management that everyone can identify as universal - estimation and issue tracking, for example - there are some tools that require you to commit to their own procedure to accomplish those tasks.

For example, FogBugz requires that every task has an owner. There are no tasks that are not owned by someone at any point in the project lifetime. This may not work well for development shops that want to use the Agile method, and pull stories out of the backlog (read "become the owner") to work on, because every task already has an owner. Another example of how this fails is when a client creates new tickets for a development team. The client typically does not know to whom a task should be assigned, yet by entering a new task and requiring an assignment of ownership, this burden falls on the client. And yet, if your process requires that stringent assignment of tasks to owners at all points in the task lifetime, your system should still have the flexibility to offer that. That's part of being effective.

On the "effective" side of things, there are a handful of project management tools that exist that have the basic requisite features, but no interconnection between them. For example, there is no direct correlation between estimated time, actual completion time, and reporting that brings those values back around for use in estimation.

In some of the open source projects I've seen for project management, they strive to emulate paid services, like 37 Signal's Basecamp, which could be sledgehammered into the mold of web project management process, but really don't seem to have been designed with that in mind. Good tools, all, but potentially not directly effective for the task of managing web development projects (especially in my opinion, which I'm sure some don't share). I think that emulation of 37 Signals speaks a lot to the "slick factor" of a product.

We web developers like our knobs and doodads. If I could reasonably code every UI to require the use of javascript (screw that "graceful degradation") I would definitely do so. So there are certainly things that we developers like to see: In-line editing and Ajax being foremost in my mind. And sure, while an application should concentrate on working for its least common denominator, there are some niceties that are required for ease of use.

I think it's not exactly easy to produce project management software no matter if you use cool stuff like Comet or Canvas, but it's certainly easier to produce something without it. I think that's why teams with payrolls (hosted project management) can afford to produce lavish interfaces, and why the open source offerings generally don't look as spiffy. Really, I don't know the real cause. Nonetheless, the fact exists that I've appreciated the design of for-pay sites much more than those of their open source brethren. I'm not just talking about the aesthetic appeal, but the usability; the interface engineering.

If it were for these three reasons alone, I think that would be enough to call for a new plan for a project management tool. I could probably rattle off a few more reasons that a new tool is a good idea. Moreover, I'm not concerned that the marketplace is competitive, simply because even after searching seeming forever (recalling my initial posts about Copper Project four years ago) I haven't found one that works the way I like.

Project Objective

I doubt this part will stick completely, because I have some things I need to do first to make it work (attract working hands and produce user personas, for a start), but I'll record it here because it needs to be done as a diving point.

The objective of Stonepath is to produce a free, open-source project management system for individuals or small companies, with the following advantages:

  • Provides a centralized, searchable system for storing project-related materials - including initiation documents, specifications, wireframes, graphic designs, etc. - accessible to any stakeholder with deference to security.
  • Allows all stakeholders in a project to track progress of the project according to their needs. (These needs will need to be spelled out after the user personas are created.)
    • Issue tracking
    • Time tracking
  • Centralizes communication regarding a project into itself so that it can be scheduled (if required), recorded (if possible), and searched.

  • Schedules and coalesces dates across projects for a bird's-eye view of all required milestones.

  • Presents a view of capacity for production that is useful in planning for both developers and managers.

  • Passes high standards of usability in terms of the ease of accomplishing tasks.

  • Produces reports that are useful for accounting, and also for contributing developers to see their own progress and enhance their abilities.

  • Hints at a flexible, intended procedure for accomplishing project management using the tool -- one that can be strictly enforced or completely ignored without degrading the product execution.

There are two additional components to this initiation document. First, is a timeline. Timelines on open source projects are hard to say. I'm not going to skip it, but I'm going to wait for the next post.

The second component includes the list of stakeholders and their roles. This part should be interesting, and I'll also be holding this one for a future post, since it will likely incorporate some of the ideas I have had lately about the management of a new open source project.

This document is open for comment. I've probably missed some very important points, so indicate where I've gone wrong and I'll see about updating it.

I've been thinking more about what's next for me, regarding personal coding projects. I've been toying with an idea for much longer than some of the others I have had and acted significantly on. I've already named it in my head, and registered the domain for it years ago. So what next?

Some of my projects have been less than stellar in terms of sharing vision. I've been considering whether that is a function exclusively of my poor pre-documentation or the involvement of other developers in the project, or likely a very specific value in the range between those two. In any case, I want to work out some of what I think of as problems in the development process so that this thing can be launched as fluidly as possible.

Unlike all of the other projects I've talked about and done only a little with before giving up, I should have the requisite time for this one. I also hope to drag a couple of developers with me to get it running, perhaps a couple from previous projects, perhaps a couple from outside that sub-group of people I know. I've never mentioned this project before because it was so significant and particular that I knew I didn't have time to do it, but that's different now. So at least I hope this ends up a more significant undertaking than previous efforts.

I've had this book called "Communicating Design" sitting in my office for almost 3 years, and it gives some pretty good advice for starting into documenting the kind of project I'm thinking of building. There are chapters of the book that clearly seem like more fun than others -- the user flows and diagrams chapters seem like a lot of fun, whereas the chapter on creating test cases looks like drek -- but a complete appraisal of the project will probably yield the best fruit.

I have some ideas about license of the new project, the organization of the development community, deployment strategy, framework architecture, and some other things. These fall outside the scope of what the design book targets well. I suppose I'll just note those things as I'm documenting everything else.

It's fun starting fresh. If I can keep myself disciplined enough, it could even turn out well.

I've been considering lately the key components of a certain kind of content management system. I've been conceiving something simple for boutique content management, something that allows a developer/themer to easily erect a simple site to the specifications of a client but is simple for the client to maintain, so that the developer can walk away from routine maintenance until something specifically warrants those skills.

The primary issue I see with software that functions like a CMS, like WordPress or Drupal or Habari, is that they aren't aimed quite directly enough at this market, which has very specific needs that don't include many of the other capabilities that these systems have.

Off the cuff, here are some thoughts:

Database Layer

I'm seeing more leaning away from relational databases. While I think that there is still benefit for a CMS to have these capabilities, it's probably enough to have a simpler database layer, rather than a full-on relational system in the back-end.

I've been thinking of a scheme that uses a simple database structure, like Amazon's SimpleDB, which could be abstracted up to something relational like MySQL or SQlite.

URL Dispatcher

Pretty URLs are not only commonplace, they're expected. One of the useful things that a front controller will allow you to do is dynamically route incoming URLs to specific pages, and pass additional arguments to those dynamic pages. The URL is the physical structure of the dynamic site, if it can be said to have such a thing at all.

Something that people don't seem to grasp about CMSes is that while it's possible to completely mirror the logical structure of a site with the URL setting, it's also possible to have the two be completely different things. Keeping these thing in sync can simplify the system. Perhaps it's worthwhile to marry these two, with an option of relocating the URL for any individual page.

Menus

Menus are the logic structure of the site. While the URLs are the physical locations of the pages, the menus help you get to those pages.

I've seen even "simple" sites have multiple levels of navigation without seeming to cumbersome. There needs to be a way to have multiple menu sets for site organization, and also a way for administrative users to access all oft he pages in the site. It's not practical to have to type in any page's URL to locate it in the site.

The typical way to do this is to produce a tree structure. Either there would be a separate tree for each menu, or each menu would be one of the root elements in the main tree. Whichever the element, no page on the site would be inaccessible via the configured menus.

Templates

Having some method to output content is essential to the production of a site. Pages may need to be displayed in different ways. If the basic accepted unit of display is a page, and not a "chunk of content", then the templating becomes fairly simple to tie exclusively to a single page.

One important thing to consider about templates in this system is that they should be easy for a designer to produce directly.

Those are some preliminary ideas. I'm not sure if this is going anywhere or just speculative. But I'm thinking about it right now.

I had a much longer post written about the kind of project management software I would like to use, but it assumed that I wanted to work a certain way -- a way I really didn't want to work.

The problem is this: Project management is made hard.

It's not that project management is hard. It's sometimes challenging, but it's not hard. I believe, completely without evidence, that following basic procedures and using tools that fit will most often result in a positive outcome. A tool that would help me manage a project would be more than a bug tracker alone, but that should be a component of the system.

So what does this thing include? Primarily, it should be simple to use. It shouldn't do anything extra than what it minimally needs to get the job done. That's not to say that it should be inflexible, just that these additional traits shouldn't be user-configurable. You should be able to just turn the system on and have it work.

Minimally, the system needs to track a few separate things:

  • Projects - Projects are larger tasks that have a well-defined begin and end condition that involve achieving one or more goals. Projects are made up of the definition of starting and goal states, and also list the stakeholders of the project, the communication plan for the project (including who to call when a decision needs made, and how often communication should happen), and other miscellaneous details that don't have specific tracking components.
  • Deliverables - Deliverables are the fruits of the project that you deliver to the client. A project can have multiple deliverables, although simpler projects might have just one. Projects should include a deliverable when and only when something should be given to the client, and it should be reasonable to associate delivery dates to these deliverables. A deliverable could be a report on progress, or it could be an actual component of the system.
  • Tasks - Tasks are the things that need to be done to produce a deliverable. The deliverable would have one or more high-level tasks associated to it by a project manager (which might be one person, if they're just a freelancer), and all of the tasks usually should be complete before the delivery to the client is made. Tasks should have some loose times/difficulty ratings associated to them so that they can be used for estimates, and each task should have someone who is specifically accountable for its completion, even if they're not responsible for completing it.
  • Issues - Issues are discrete unit of a task. Some tasks are simple enough by themselves. Others have multiple pieces. A developer might like to break down tasks into these smaller units to better handle larger tasks. If someone is accountable for a task, then they might assign multiple issues under that task to different people, delegating the work. Issues may also enter the queue externally, usually submitted by clients, and would be associated automatically to a generic task under the current deliverable, then reassigned by the project manager.

So that's the, um, small feature set for the project manager/developer user. There's also a client actor that needs to have a dashboard to keep track of progress, meetings, deliverables, etc. They should also be able to submit the aforementioned issues there to enter an incoming queue that is later sorted by the project manager or lead developer.

There should also be a place to manage project files. Inevitably, you've got a designer working on the project who's producing photoshop images. These things need to live somewhere central, where the participants can find them. There should be a place to put documents, too. I think this is separate from project notes recorded by the developers.

Projects notes are also important, since at the end of the project, you want to be able to deliver not just the project, but the documentation for the project. There should be a way to document project notes that can be either public to the client or solely for internal use. For example, you might want to note for the client's end deliverable the name and contact info for the host of their live server, but you would not want to include the steps of the import process for their data, which might be useful to other developers working on the project.

Some additional features that qualify in the "might be nice" category include svn integration, so that you can specify a repo or two for the project and associate commits to specific project issues in the system. I know some people that would like to incorporate time-tracking into the system for hourly billing. It might also be nice to include a CRM component so that you could keep contacts separately from the project itself. This wouldn't be interesting to me personally, but it might interest others because it could make the system useful for industries outside of IT/development.

Eventually, it might be nice to track things that are not projects, but ongoing, like maintenance. After you deploy a project, you might want to keep regular tabs on the client and the project to make sure it's up to date. While this is partially a CRM feature, it would also be somewhat project-related, since you'd have specific tasks you'd need to accomplish on every periodic check of the deployed project - like "update server" and "check for HTML compliance", or whatever.

The above is a lot of stuff, but I think a truly integrated package that makes it easy to access all of this information can be simple and effective as a project management tool.

I was complaining yesterday about the login process that Contenture uses on its member sites to gain visitors. Rather than just complain, I thought I would give some constructive response to their request for feedback, which is coincidentally one of the topic areas that I like to study on this site.

Doing It Right vs. What We Actually Do

We developers talk a lot about how a project should be done "right", and hardly ever are they done that way. There is a very wide gap between what we should do (the stuff they make you take classes on in college, but you never do in real life) and what we actually do (the stuff we end up doing to make things happen in time and budget, but nobody ever bothers to teach in a class). I think that every developer cuts corners on either end, some more on one side than another, but there is someplace in the middle that makes it work. I like to think of this area as the back of the napkin.

Attached to this post is a flash applet showing something I drew depicting my impression of the Contenture login process. We've basically got two types of site, and three types of visitor. The first type of site is the content producer, someone who uses Contenture to remove ads and potentially display premium content to Contenture members. The other type of site is the affectionately named, "Affiliate Whore", whose only current business with Contenture is to make a quick buck from a new user signup.

There are three types of visitors to either of these sites:

  1. Visitors who are not Contenture members
  2. Visitors who are Contenture members but are not logged in
  3. Visitors who are Contenture members that are signed in

Of the three, the last is the easiest to figure out. The affiliate site doesn't really need to care who you are - it can display an affiliate link whether you're a member or not. The content producer will probably need to know that the visitor is a member and then display appropriate content for that user. That part is actually pretty easy with the way things are now.

User Stories

For visitors that are not Contenture members, both sites need a way to tell these visitors that they should sign up. When they choose to do so, they would be taken to a page that allows them to register for the program. Optionally, when the sign-up process is complete, they could be returned to the originating page. The affiliate-only site isn't going to care too much about the return, but the content producer is. An instant return visit from an new registered user guarantees at least one content-based hit on the site for the purposes of tracking payment to network members, of which that site will be one.

For visitors that are Contenture members but are not logged in - which happens in the case of users who roam between computers, use multiple browsers, or are developers that dump cookies every few hours - things are a little trickier. A site can't know that the user is a member if they're not logged in. They'd probably need to see a standard-looking "this site uses Contenture" banner/button/logo somewhere that they could click to get the standard login.

My premise is that the same link that you use the same affiliate sign-up link to go to a page that is both the new user sign-up form and the existing user login form. Even if the "join our program" link on the content publisher's site doesn't say "Contenture" in it (even though it should, for reasons I'll mention in a minute), they'll still arrive at the Contenture login page and will respond accordingly.

The Affiliate Link

The "join our program" link should definitely say "Contenture" somewhere in it. The reason is that if a visitor encounters a site that has a program described only as "Pay $X to avoid ads and obtain premium content", then he's already considering the money he has paid to Contenture and wondering if it's worth it to join a new site. Whereas if the banner/button says "Contenture" on it somewhere, the choice to continue with the login for an existing user is not an issue.

contenture_banner.pngAlso, my thoughts on what the button should say lean more toward providing an advantage to the visitor. So unless it's the only benefit, it shouldn't say "Support This Site". Supporting a site monetarily is an obvious benefit of paying for premuim content. What it should say is what the visitor gets from the site in exchange for signing up. My thoughts resulted in something to the effect of "Fewer ads and more premium content -- support this site with Contenture".