I started the Tech Tuesday writing well over a year ago, but a few months back it kind of fell by the way-side with everything else going on. The other night in class we were discussing the lack of documentation in project management, particularly in agile environments and it got me to thinking: Do we really no longer document or has technology changed the way in which we do it outside of the traditional waterfall environment.
Personally, I am a big advocate of documentation. It creates accountability which is desperately needed in the modern era. It creates a record for posterity that when used correctly allows for much more accurate ‘lessons learned’ (something I also advocate for creating a record of life in general).
It seems in a great many cases documentation is perceived as laborious and wasteful when it could be spent on development for the product. However, within an agile atmosphere where decisions are occasionally made ‘on-the-fly’ and bounding through iterative sprints can occasionally result in the documentation spending more time in stakeholders heads than being a shared resource for the team itself. This is where technology actually shines though as another member of your team if you use it right.
1: proper use of code repositories can help catalog base level changes. Not being a coder myself I cannot make bold suggestions on what best practices of these are and how to most effectively use them but I do know they are able to be attached to other project and product management tools to create more effective documentation. Some notes:
* Keep both bad and good code, current and cleaned code, clearly marked in the repository
* When cleaning out old code mark why it’s no longer relevant; when removing bugs and bad code mark what the problem was and denote solutions
* Employ a dating system for respiratory entries; if you use a ticketing system for other documentation management note ticket numbers and other references; if code is referenced to a specific feature set mark it as such
* The more clearly marked up the repository is the easier it is for use in future development, QA/QT & Regression testing; reversions; knowledge transfer between team members, etc.
* Overmarking can make the repository unwieldy and overwhelming so determine guidelines for best practices and stick with them
* Some repositories I’ve worked with include SVN and Git
2: a good product management project system will ensure from sprint-to-sprint, project-to-project, feature set-to-feature set and product-to-product there’s an understanding of what went on. Typically these tools are used for planning, tracking and reporting project progress but many of the programs are broken down into tasks, sometimes called stories, which allows for additional levels of detail to be inserted. As a product manager I can look back at the progression of a task, project and product efficiently during and after it’s completion to see what decisions were made when and by whom all in one place to follow and review the impact. These task assignments can serve as a documentation center, such as:
* A stakeholder describes their need and expectations in as much detail as they can provide and attached to the story
* The task is estimated and the estimation process and concerns can be documented and attached to the story
* Revised scope can be attached to the story and additional story requests created for related future tasks and dependencies – the approval of changes can be attached too
* Task is assigned for production and the engineer, designer or developer notes can be attached to the story
* The task proceeds to QA/QT, UAT and other testing with each of the feedbacks can be attached to the story
* Revisions to the end-product can be attached to the story and approval sign off too
* Lessons learned notes and other final documents can be attached to the story.
* Stories are attached to one another in a matrix of sprints, dependencies and cross-story referencing, allowing for adjustments in momentum and changes in scope to be noted easily
* Reporting on time & budget is tracked inside the story itself and in relation to the larger project with exporting tools available to visualize the data
* Collaborate so each stake holder involved in a story can leave notes or attach assets
* Semi-linear for version control so as documentation is added previous documents are not overwritten
* Archival so old stories can be easily re-referenced to understand why decisions where made or to re-purpose information for future development.
* Easily customizable depending on team needs and experience
* Provides clarity and visibility into status, decision making, etc within the team promoting responsibility and accountability
* Personally, I’ve used Pivotal Tracker and Ace Project extensively as a product manager because I enjoy their versatility but I’ve also run across At Task; Workzone Project Manager; Wrike ; Fend ; On Time; and KForge which all offer similar feature sets.
* Bug tracking programs can also offer a similar usage and be modified in nature beyond the typical bug reporting, allowing anyone within the project team collaborate on a specific task. I’ve used ZenDesk and proprietary ones but FogBugs
BugTracker I’ve found also offer similar feature sets in collaboration, prioritization, task hand-offs and reporting.
3: Share documents to ensure you are sharing knowledge. Potentially everything produced during a project can be considered documentation and most documents aren’t static, they’re living entities through revisions, edits and appendices it is imperative to foster effective ways of both cataloging and collaborating on documentation. Some notes on this:
* It’s all about version control. If you don’t have an internal version control system in place (denoting file name taxonomy, dating mechanism, person responsible for change and edit markup styleguide for example) even with the best software bad things can happen to good documents.
* Back it up, back it up, back it up. Did I mention to back it up?
* Organize your inputs. If you don’t have an indexing system that makes sense you’ll never find what you’re looking for. Find a way to organize everything that makes sense to your team (and within the confines of the project)
* You can include Email Strings exported to text documents, meeting audio and video, desktop publishing documents like Word, Excel & Powerpoint, Art files, screenshots and animations, code strings, URLS and whatever else you deem important to use as references. Your team and your project can help determine what stays and what is a waste.
* By co-producing documentation it empowers team members to feel involved and alleviates the responsibility of a single person dictating it, however, good communication is vital to produce good will, most people don’t take well to editing of their work. Work within these softwares knowing their benefits and limitations
* Repositories for this can include Wikis, Sharepoint; Basecamp; Trac; Trello and others.
* Shared file storage and transfer options can include Evernote, Drop Box, Google Drive, Amazon and others
* Shared document resources include MS Cloud Office, Google Docs,
5: meetings are documentation even without minutes takers. A well structured meeting that has a clear objective, an agenda to outline the progress and finishes with definitive next-steps cannot be replaced, particularly in an age where so many solutions are conspired during them. Meetings a no longer just a place of information dissemination and in as such need to be treated as the potential for critical documentation they really are.
* Record your meetings using audio, or video, even when in a co-located setting. This means less time taking meeting minutes and more time collaborating for everyone. It also means you can look back at the meeting as a manager after to identify tangents and time wasters to make future meetings more efficient (this is an old disc jockey trick)
* Use a transcription software service to pull meeting contents into editable text which can be more easily referenced and utilize A/V editing software to pull out key portions of longer meetings.
* Treat all your instant messenger chats like meetings and when appropriate export the final chat text to a file for future reference both in co-located and distance settings, between individuals or within a chat group. Personally, I also do the same with email strings, so that once the string is closed the conversation is exported and put with all the other documentation regarding the project so it’s in one place.
* Take screen shots or desktop video capture. When there isn’t a formal presentation to be distributed for a meeting screen grabs provide a visual reminder for context of what might happen during a meeting particularly when problem solving such as around bugs, when brain storming referencing competitors or when doing desktop sharing.
* Personally, I like Skype and gChat for their capability to do instant message, voice, video (and with Skype the desktop sharing) the ability to record and export session, and use add-ons to transcribe voice to text, among other things.
* Meeting tools include GoToMeeting; Webex ; Join Me; Ready Talk and a host of others.
6. There’s so many potential solutions available in the cloud right now it can be overwhelming, but as with anything else, investigate what problem you are really solving for and find a solution that speaks directly to that need. I look at it the same way I approach Product management, which is identify the perceived need, analyze how the need is created such as how it fits within a construct like Maslow’s Heirarchy to find out why it has to be fulfilled, draft a value proposition that speaks to the fulfillment of the need, create (or in this case, utilize) something that speaks to the value proposition. It’s not about feature set, it’s about need fulfillment. It’s much easier to get buy in for use when there’s an underlying value to speak to than when it’s just a features within a software suite.
Also, I did debate, is this Tech Tuesday or How Do I: It’s really both, but because I felt like putting it here in discussing the benefits of technology itself rather than focusing on product theory which is what the other column usually does.