Hello, World!
As Viget Labs' newest Project Manager, I've been learning the ropes here for the past couple of weeks. I spent my first week at HQ in Falls Church, Va., discussing Viget's constantly evolving project processes and learning the finer points of Viget culture from my new team members. (It's perfectly acceptable to make peanut butter sandwiches at your desk. I'm going to fit right in!)
After that initial week of guided training, I returned to Viget South in Durham, N.C., and continued learning on my own, reviewing successful web projects my colleagues have managed, asking questions about their experiences with different types of client engagements, and taking notes about techniques I admire or helpful tips they've given me. One of the things that impressed me was just how easy it was to go back and review those completed projects, even without the guidance of the project managers who saw them through to completion. Each past engagement was clearly documented with a set of deliverables, making it simple to follow the decisions the project team made at each stage of a web site's life cycle.
One of the required reads for all Viget project managers is Dan M. Brown's Communicating Design, which I've begun to read this week. Brown's book encourages communication about web site planning and development using effective documentation. Since I've worked in user experience design for several years, none of the deliverables he describes are unfamiliar to me; but, it's been interesting to compare some of his document creation and presentation techniques with Viget's real-life examples.
Although Viget's documentation varies based on the requirements, scope, and timeline for each web site, it's always created for the same purpose: keeping all project team members focused on the same goal. By clearly expressing user needs, site design, and strategy decisions made over the course of a project, good web site documentation also allows even uninvolved observers to understand the motivations for designing a site in a particular way, including or excluding features, or writing copy with a certain audience in mind.
Because Viget's project management process is always adapting to savvier clients and adopting better techniques and new technologies, not all of the documentation I've reviewed lately matched our current process. Even if legacy project deliverables were "out of style" or created from gawky old templates, they still did an excellent job preserving the fundamental ideas and decisions necessary to understand what the project was all about and how it progressed to completion.
Documentation has a bad reputation in some circles. Proponents of certain development methodologies argue that it slows down project progress; time could be better spent designing and developing than writing about the design and development the team will need to do. While I'm all for eliminating unnecessary work, I still believe documentation is essential to maintaining the integrity of a web project and the sanity of project team members. The key is learning to make deliverables concise without sacrificing their purpose.
One of the key points Ben brought back with him from Railsconf Europe was the idea that legacy code is the product of developer growth. Code doesn't "go bad" over time, it just starts to look outdated and clunky because the developer who wrote it has improved his skills since the time he wrote it. I believe the same can be said of documentation: we at Viget Labs are always learning as we go.
To help keep my project teams focused, I plan to keep up Viget's standard of solid, organized documentation for the new projects that will be coming my way. I'm also looking forward to seeing my own deliverables evolve over time, becoming ever leaner as I beef up my project management skills.
