Transitioning Process and Projects

When transitioning projects last week, I realized a nice little payoff for my focus on process and documentation. On the whole, quite an uneventful series of meetings - most of the conversations were around minor tools and systems that never got the level of documentation they might need, simply because they were lower priority.

One big focus of conversation was around the various methods used to prioritize work; we juggled hundreds of open issues with a very small staff. I often stated that the number of open issues was never an indicator of true backlog; there was always a fair amount (maybe 20-30%) of issues that were duplicates, or exceedingly simple to resolve with a short conversation. The challenge, of course, was to carve off enough time to have the conversations - 30 chats @ 30 minutes apiece will kill an entire week, never easy to carve out that quality time for the lower priority issues.

I liked to say during the "triage" process that all the issues fell into three categories -

1. "Stupid" - not an indictment of the person reporting the issue, just saying that the solution is a quick fix, a simple keyboard error, something that is a simple trick of the system (yet, if you don't know about it ... it's magic)
2. "Standard" - if the system is designed to work that way - that's what you get. I like to avoid customizing standard product as much as possible, makes it easier to upgrade.
3. "A Good Idea" - These are really issues / bugs / ideas / requests, and certainly not the minority. This is the meaty stuff that needs to be prioritized and worked.

During the exit process, one person thanked me for implementing "sustainable processes" - to me, high praise indeed.