Doug Ross @ Journal

DeskLog, part 2

Loyal reader "Not-so-Anonymous" responded to my DeskLog post with some interesting comments. His remarks are in bold with my take interspersed throughout.

Email already has accountability. Turn on return receipt and you will get confirmation of when the email was delivered to their inbox. With all modern email systems, including Exchange, Notes, and simple SMTP, this is non-refutable proof that an email was received. I disagree. If I don't even open the email ("oh, it's from Lester, he's just got some more crap for me to do, I'll read that later."), there's no read-receipt. And, depending upon the email client, it's easy to evade even if you read the message. This is a straw-man argument, and I think I just set the straw-man on fire. Second problem is that a boss like Bob would suck-- someone who micromanaged to the point of walking around to everyone's desk and checking their files (even digitally)? I just don't think a good business would do (or allow) these kinds of actions, and thus, this selling point is also moot. I beg to differ on this point as well. What Pointy-haired-boss (PHB) wouldn't love being able to check through their underlings' backlog? This is the digital equivalent. And, more importantly, the transparency that DeskLog provides is also extremely useful for normal people ("how far back in the queue is my request?"). That kind of transparency is exactly why DeskLog would be so valuable. I would love to have it in my office, for instance, to see how where my expense report is in the queue, to see if a project manager has a high workload or not, etc. On to encryption...or how else were you planning to achieve the "signature" workflow? If you upload a document for someone to sign, they are going to need to put a real signature on it. Never mind the fact that most companies still require ink on paper (not even photocopy is acceptable). Let's even assume that a copy or digital signature is acceptaible-- now your DeskLog product has to have crypto built in (or a scanner at every desk) to perform the signing and signature checking. Now its not server based anymore, which means you'll need client software on the ground at each desk. This is a big no-no in a Fortune NNN environment. I think you're over-engineering this issue. No crypto, no digital signatures, just a "confirmation number" system. Let's say Bob wants to sign off on my request. Since he's authenticated to DeskLog, the system knows it's him. He can request a unique confirmation number when he's ready to sign off. Bob just pastes his confirmation number into the document. There's a record in the system confirming Bob created the confirmation number in case we ever needed to audit this event. It's similar to Avis: they don't digitally sign confirmations. They "sign" a confirmation by giving me a unique number. As far as gathering quantitiaive metrics for the work done by an individual, I just don't think technology is the answer. Some of the smartest, hardest working people I know generate about 10 lines of code per day. Sure, its a super-insanenly complicated crypto algorithm, but its pitiful progress from a quantative metric persepective nonetheless. Also, how do you apply this quatitative metric to a non-technical role (which is obviously what you are focusing on since all your examples are about signatures and workflow)? If metrics are being gathered on managers based on how quickly (or how many) forms they sign, then it will rapidly become a contest between managers to see who can sign forms the fastest. In the end, I think the review quality of their work will suffer horribly under the pretense of efficiency. Thousands of large companies have tried to use metrics...and none of them have succeeded in yielding any benefit to the organization. Yep, I agree, but all of these metrics are still used to some extent. KLOC, compexity metrics, all of the crap that PHB's and MBA's love. Whether or not it has merit, that's precisely why the PHB's would love it. Let's face it, call-centers, support centers, and lots of other business processes already measure everything. Many (not all, certainly) non-technical processes are begging for this type of reporting and analysis. Ok, so we're down to Workflow. For this item, you may be on to something. Existing workflow packages are very complex and difficult to maintain. But both those problems are the price of haveing a truly generalized business routing architecture. Oh, and they are expensive. I'm presuming DeskLog would be significantly cheaper... But, what kind of benefits could it actually achieve in the workflow space? Its not clear to me that DeskLog would provide anything more complex than a simple "next-in-line" workflow, which can done via email in most modern systems. Yes, this is a relatively simple workflow process... but, even though it starts out simple, it could become quite powerful. For example, because DeskLog is 100% LDAP-compliant ( :-), it supports the groupOfNames object-class. Thus, instead of a user's name in the workflow, we could specify a group. Say, "Timesheet-Administrators". The folder would appear in all of their inboxes (say, a shimmering, nearly transparent color that signifies its gone to a team). So anyone on the team could process it. We could grow the workflow functionality substantially from the simple scheme I've described. I wanted to start it off simply - to provide a combination desktop and blog and then leverage the workflow from there. More on that later. My final thoughts: most of what you described would provide no benefit to a real company, and hence is a waste of time. For the one piece that may provide benefit, you need to refine your idea and find a niche before attempting to make it a reality (or sell it).

I disagree. I think the user community would use it because it provides transparency into business processes that -- today -- have no transparency. PHB's would love it for management and quantitative reasons. The users would thus be forced to engage because of the management factor. And IT folks would appreciate the pragmatic workflow capabilities.

Your straw-man's burning. You may want to put him out. :-)