protest: the status wiki


Over the past year or so I arrived at a nice way to report status that finally works for me, and has earned its keep in the protest system.  The way this works is just set up a private wiki page for just you and your management chain.  I am lucky to have access to prerelease versions of Sharepoint wiki support that offers tight access control via NTLM authentication but if you don't have that people-ready luxury at your fingertips you can probably find a way to make do with what you have.

Set up a master status page for the year and then create a list of links to a new page for each week.  Think ahead and use some sort of dating format to identify it in order as that week, with the two categories "DONE" and "ON DECK" inside.  Then list everything you need to get done that week in the ON DECK category and move it up to the DONE area every time you finish it.  I know just saying the word "wiki" makes us all feel 10 years younger and giddy about Web 2.0 to the point we start having delusions of grandeur as the newest kid on the block to be the owner of what has the potential to be the next almighty Wikipedia but try to temper those thoughts and just think about this as a glorified text file. At the end of the week you can cut and paste this into an email and send it to your manager with a corresponding link, or review it right before your weekly 1:1, and relish the fact you are now providing 24/7 access to management at any time they want without any interruption to your schedule.  The next week if there is still stuff left over in the ON DECK list you move it forward to start off the next week, this is often the case for projects that take more than a week to complete so it's not always a bad thing.  And when it comes time for annual reviews you've got an archive wiki page of everything you've done.  


Additional notes, disclaimers, and dangerously bubbly wiki zeal : 

I realize there are ways to use the TFS work item tracking system for this, I use the TFS work item system for this too.  Buy TFS - a wiki is fast and ghetto and TFS is more formal and designed for solid engineering.  I personally feel there is a place for both, kind of like how IM is sometimes more appropriate than email and vice versa.  TFS is extensible enough you could theoretically create some tool that bridged the gap for you, maybe someone already has, but I'm not aware of it.  A personal wiki like this is also a lightweight and flexible alternative to having a hundred yellow stickies overtaking your desk and monitor if that's not your thing.  It's a way to hash something out without the permanence of it lasting forever in the database.  During the course of a week's work you often have to stash notes and hints to yourself somewhere (file paths, configuration tips, install sequences, etc) and this lets you store it there in a way that is tied to the actual work, and that you can quickly pass on to someone else if a new hire comes along, someone leaves the team unexpectedly and you have to realign ownership areas, etc. I'm also lucky to have this wiki on a corporate maintained server with regular backups that's maintained by someone else.  I like rich clients but I always try to find ways to store my real data that way so my office machines can all be flattened and reinstalled at will without me having to worry if I'm losing something important.

Comments (1)

  1. Eric Jarvi says:

    Over the past few years I’ve been putting together a rough collection of ideas that I use internally

Skip to main content