Premise: The tools are already out there. The tools for project management are, in large part, already developed and deployed. I say this for two reasons – 1) project management is more art than science and, as such, there is a broad and fuzzy domain in which “Project Management” happens; 2) the suites and monolithic solutions provided by vendors/open source projects all pretty much suck so inevitably we make-do with what we have that we are comfortable and familiar with – the applications we use everyday.
Premise: The mechanisms for gluing all these disparate tools together exist and are usable. There are protocols and specifications that are sufficiently mature and open so as to permit their use in a distributed solution.
Functional requirements:
a good project management system has to have some permutation of the following to be sufficient:
- version control and repository for code
- version control and repository for documents
- common calendaring and scheduling
- issue/bug tracking
- budget management
- progress monitoring
- project team/sponsorship information
- communications mechanisms – electronic and real
Practical considerations:
technological solutions alone can’t be successful – there must be a tools & methods approach, and that approach must be easy to use, the technological portion of it must be transparent, and it must scale to hundreds (thousands?) of projects.
scalability: not only must it be able to handle large numbers of projects, but it must be able to slide in functionality from the low to guru users in savvy. The comfort level of the user can’t be a limiting factor when it comes to gleaning information about a project – particularly if that user with low savvy is a sponsor, a funder, or a decision maker. Executives don’t have time to monkey with obtuse user interfaces or clunky, esoteric desktop clients. The key here is a suite of extensions to applications everyone already uses, or new applications that are only subtly more sophisticated than those we are comfortable using (comfort apps might include web browsers, PIMs, word, excel, and power point)
Idea:
begin with a web page for each project – web browsing is easy, everyone knows how to do it, and it is a relatively high bandwidth channel for electronic, one-to-many communication.
From the web page, browser plug-ins can interpret DOAP (Description Of A Project), FOAF (Friend Of A Friend), RSS, and social bookmarking tags contained in header information – this gives a new layer of information from the same URI to the user of a browser through the use of browser extensions (Firefox already has this functionality available).
Version control is important. Using a fully implemented WebDAV/DAVfs document repository, with a rdf-metadata layer built into the open/save dialog routine would be perfect. The possibility for this to be implemented in both Open Office and Microsoft Office exists, through the open source of Open Office and the Microsoft Office SDK. The feasibility has yet to be explored. If accomplished, the extensions could be deployed as extensions to the applications, and not as part of the local filesystem, which seems like a more substantial task. The extensions of the WebDAV/DAVfs protocol to a distributed store perhaps through the use of distributed filesystems on the host servers, would be an additional degree of sophistication that may aid the scalability issue. The document base must include provisions for the storage and display of graphic and multimedia documents as well. Pictures, Sound, Video, and animation are all things that have to be storable in this system.
Version control of source code is a well established discipline, and the use of CVS or Subversion as a foundation, with extensions to IDE’s similar to the proposed productivity applications, to introduce rdf-metadata into the open-save dialog for storage along with the code in the repository would provide a substantial enhancement for the distribution of enterprise code between local sites. A del.icio.us style meta-tag link repository might be an option for increasing the visibility of in-house code in large enterprises.
Bug-tracking should follow two vectors – programmatically reported bugs, and user/admin reported bugs. Both vectors should enter the system at the same point, and rdf-metadata should be applied to the bug report. This does two things – time/user/ip stamping will crate clustering of reports that might be duplicates reported by both human and program, and the report and its resolution can be indexed and searched using the rdf-metadata. RSS feeds, with the status of the report as part of the feed, can be an effective mechanism for reportee status updates. Public disclosure of action also fosters a sense of inclusivity between the developer/administrator and the consumer.
RRDtool graphing of project metrics provides a quick, visual picture of the progress (or lack thereof) of the project. XML based reporting data allows for those RRDtool graphs to also be represented by SVG or in PDF formats for inclusion in documents or in presentation materials. Color Pallets and graphic design elements must be treated as important to the adoption of the distributed project management toolkit (DPMTk) as the integrity of the data visualized, the transparency of the technology employed, or the consumer interface.
Common Calendaring and scheduling – this is a holy grail of sorts. Until such a time as Microsoft creates an Exchange-iCalendar conduit, we will have to create a mechanism that does the same thing. Outlook/Exchange users must be able to have the same functionality as offered by the Exchange calendaring service in this approach. Non Exchange users, particularly those using iCal or other iCalendar tools, must get their functionality as well. There is no middle ground here, all of the desirable features of both systems have to exist, and they have to be provided without adding a calendaring application to the desktop – extensions, server-side solutions are acceptable, another desktop app is not.
Wiki/Blog – This is a terrific way to create a lasting forum, and a good way to chew over ‘things that matter’. Ideally, a consumer would be able to use a word processor to post to a blog – through a simple click & post methodology related to the WebDAV/DAVfs extensions mentioned above. Posting to the blog should be no more difficult than posting to the docbase, and both sould be as simple as saving a file to the local drive. Writing in an HTML textbox is a drag. If that is the best we can do, then so be it, but it had better be ‘as good’ as writing in a text editor or word processor – spelling, WYSIWYG, preview, cut/past, xhtml tags with syntax colorizing and validation, etc. Obviously, this should be stored with rdf-metadata included, and ideally it would be stored as XML in an XML database, it will have the full features of the best blog engines – rss feeds, talkback, permalinks, forums – and it will seamlessly integrated into common enterprise authentication systems, no standalone client databases. In a perfect world, FOAF+WoT would permit authentication at the machine communication level, with no user action required once the local machine login is accomplished.
Authentication – enterprise authentication is often a ridiculous mishmash of cobbled-together systems – Active Directory, database, LDAP, and proprietary application userbases. This isn’t going to be one of those systems. There will be configuration tools that permit the point and click configuration – assisted by searching conducted by the config application, and a central repository for config values for mass deployments – of authentication against all the major authentication possibilities – Active Directory (particularly multidomain forests), SQL databases, LDAP servers (OpenLDAP, Novel, Sun), mail servers (imap & pop3), RADIUS servers. Additionally, importing users from any of these will be supported for the creation of FOAF files and DAVfs users. This will probably require the solving the issue of integrating LDAP and SQL records for a common person into a comprehensive identity profile.
Testing, Training & Deployment: These are the things that projects normally forget. This system must not only remember them, but integrate them into the initial phases of design, so that they are built into the project as it goes along. Resource planning and curriculum development is as important as the application itself, particularly when documentation and initialization training in the enterprise is the ‘deal-closer’ with the consumer for acceptance or rejection of the final product. If the project fails to stick, chances are that it never really struck a chord with the actual users, because they were pushed out by the engineers. In project testing – release early and often – by a group of interested outsiders, and comprehensive documentation along with immersive training at deployment will make a big difference in the stickiness of the end product, and the success or failure of the product.
Communications: we like our email, but it’s a blackhole during projects. Email is delivered to a project team member and it vanishes – no history, no rdf-metadata, no review of internal communication during the post-project evaluation, no archives. We have to solve that – mailing lists for project team members might be one route, serverside rules for making copies to a ‘project mailbox’ might be another, and mail client extensions to execute rules to store all project mail in a commonly named folder might be another. These are ideas, and the best solution isn’t there, or maybe it’s a blend of these and something I haven’t thought of yet. Instant Messages and chat are the same kind of thing, but they can be archived from the server – particularly when a dialog prompts for rdf-metadata when you initiate an IM string, using stored values in a SmartTemplate form (a learning system that assesses the most frequent answers to make educated guesses about what you talk to Joe about, versus what you talk to Larry about. Think spam-filters for rdf-metadata applied to jabber conversations. Voicemail and phone calls are harder to capture – ideally you would record all of your conversations, but that is not always legal, desirable, or feasible. What we don’t really want to do is create a form to be filled out after a phone conversation – paperwork that sucks is most likely not to get done. Voicemail that is integrated into email is treated with whatever solution email gets. Audio should be able to be added to the Docbase, the wiki, and the blog.
The website, redux: This site, and it’s pages, have to be dynamic since we don’t want to wast time updating the actual content of the project page. A templating system that can comb through all the various resources and compile a dynamic webpage is important, as is a web server module that will interact with jabber IM traffic, DOAP, FOAF, DAV, and Subversion activity to create the kind of activity reports that SourceForge and Freshmeat have (most active projects, most frequent contributors, etc) without forcing a user login, but with a greater degree of identity management than cookies. A browser extension that can announce FOAF+WoT URI to the server would accomplish this, particularly if it was sufficiently integrated into the OS login process to be global to the local system, being able to discern between local users and accept their local authentication as proof of ‘something you know’ authentication.