cazh1: on Business, Information, and Technology

Politically Correct Euphemisms in IT - Translated!

I recently attended a professional seminar, and noticed a propensity for politically correct euphemisms to describe life in corporate IT. This was a typical group of IT professionals, representing a variety of companies - small and large, public and private. As with most group meetings, we started with a trip around the table; quick introductions, plus some highlights of "what's hot" for IT these days. The careful language wouldn't fool the experienced; however, a casual listener might see the knowing smiles on the nodding heads and think that we were either participating in a great conspiracy or dazed from too much coffee.

As I aspire on these pages to improve the quality of communication between IT and business, I feel duty bound to provide this partial translation page - what they say versus what they mean.

The project has been a challenge ...

We bit off way more than we could chew, and will probably blow the budget by 50%

We are considering ...

We talked about this one over beers, but there's no chance in heck of going forward ...

... looking at opportunities for SaaS ...

We're under budget pressure, and are desperate to say something to keep Finance off our backs about data center costs.

The database is growing rapidly ...

We massively underestimated growth rates, and are scrambling for capital to buy more disk.

The developer is quite aggressive ...

... they don't have time for documentation, debug in production and have polluted their workstation with multiple versions of component libraries that will cost millions to roll out

We did a pilot in CRM, and now we are comparing to salesforce.com.

... that's gonna stress us a bit ...

Another six months of nights and weekends? Good thing my resume is up-to-date ...

We have managed to create 18 instances of the ERP

We've implemented (insert module name here) - which is ... interesting

This thing has more bugs than a VW convention in a swamp; we're in a first name basis with the core development team, and half the code has our IP in it.

... using the latest and greatest, and some we're still waiting on ...

The rep sold us vaporware, and we've already maxed his voicemail box demanding a delivery schedule (or a refund)

... after a lot of pain, discussion and analysis ...

we are on our fifth attempt at implementing, but the business sponsor can't cancel because he's overcommitted on the ROI

It's a legacy system, home grown, and its old.

We've gone through five lead developers, the original author is playing shuffleboard in Florida, and if the disk crashes we're hosed because we don't have the source.

This is going to drive quite a lot of work.

I'm stunned at how poorly thought out the project plan is ...

[ long list of acronyms and letters]

We are rabid technologists ... by the way, how come executive management doesn't invite me to meetings?

We're revisiting [something] (strategy, software package, implementation approach) after the acquisition ...

We're going through a process of stabilization before rollouts continue.

The biggest challenge is the cultural shift.

Technical implementation is equivalent to C:INSTALL, but we'll be in training classes for months.

We experienced a little bit of a hiccup.

When the install dialog said "Are you sure?", I experienced a giddy sense of optimism that was quickly countered by a suitably horrible sound from within the drive ...

It's a learning opportunity ...

It's a chance to hone our skills at backpedaling, debugging on the fly, and byte-level disk sector editing.

We met our service level objective

Good thing we sandbagged the the target run rate.

... and this is what's going on ROW (Rest of World) ...

We don't like international travel, so our strategy stops at the border ...

... (refers to ) my soon-to-be partner (acquisition/joint venture) ...

Regional translations may vary; I invite your input on additions and variations ...

Previously (on the lighter side) ...

I have nothing to say and I am saying it and that is poetry (April 6, 2005)
Bug bad, bug good, bug Bug (May 18, 2005)
A blast from my past - game programming for the TRS-80 (October 5, 2005)
Hand writing recognition - harder than colored bubbles (November 19, 2005)
Custom Code Bad, Custom Code Good - Notes for your Software License Agreement (February 26, 2006)
Guidelines for Success with your Skunk Works project (June 19, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
Funny, how techies talk to each other (September 11, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
There's a pony in here somewhere ... (January 1, 2007)
No, you mean Smart as a Bag of Hammers ... (January 9, 2007)
How to Cheat at the PMO Prioritization Game (December 14, 2007)
How to Win at the PMO Prioritization Game (December 18, 2007)
BigDog: Impressive Robotics (March 21, 2008)
Why are those Old Programmers so slow in picking up on the Intarweb? (April 6, 2008)
There ain't much IT in IT Management (May 7, 2008)

Technorati Tags: best practice, business value of IT, CRM, development, innovation

Labels: application development, business value of IT, CRM, development, innovation, people management

iTunes Upgrade Freeze Resolved - and an Enterprise KM Observation

As many of you know, one downside of a career in IT is that we get pressed into [unpaid] service as tech support for the family's troubles with technology. My college-bound daughter has purchased her MacBook, and will soon find out (to her dismay) I have little hands-on experience with that platform. However, for many years both of my daughters have tethered their iPod to the family Windows desktop - I've done or thing or two over there. Fortunately (unfortunately?), I only get the call when the problems are significant, and the last big problems were no exception (two weekends down the drain ...).

They had successfully filled the hard disk to 98% capacity, and performance had slowed to a crawl. I had to chip away at the cruft left behind by months of downloads, ripping, and 'net surfing (BTW - can anybody explain why iTunes insists on making so many hidden copies of these songs?). The Internet is a wonderful thing - I got my crash course in the state-of-the-art for rescue disks and other file recovery utilities and processes - interesting stuff, but that turned out to be the easy part. The time-consuming problems came when I had to reinstall, and then upgrade, iTunes. After applying the latest version (7.6), I started it up - and nothing. No familiar library lists, no album covers - no music.

Being the techie type, I opened up Task Manager and saw all the right services running, but nothing appeared on the screen, So, a-Googling I went, and (consistent with previous experience), I saw I was not alone. I found threaded conversations, troubleshooters in forums, even a number of decent write-ups on Apple's site. Again, I learned an awful lot about stuff I didn't know before - the vagaries of registering DLLs (sccbase.dll slbrccsp.dll sccsccp.dll slbcsp.dll slbiop.dll and, of course, wmasf.dll & wmidx.dll), artifacts like iTunesAddIn.CalendarHelper, and useful utilities like Dependency Walker.

Still, after hours of struggle - nothing; color me frustrated, especially because the helpful folks on the other end of my browser didn't seem to have a consistent solution either. Then at dinner, my oldest daughter mentioned that she's seen this non-starter problem before. "I just plug in my iPod and the problem goes away". No - it couldn't be that easy ...

... but it was. Restart the PC with a freshly installed upgrade - nothing on the screen, but I can see iTuneshelper.exe and iPodService.exe running. So I plug in the iPod and voilà, the crisis is over. Too simple, and I'm not sure if this is the solution that will fix things for everyone, but I want to capture this knowledge here as a favor to the next beleaguered dad who follows in my footsteps (hence all the tech stuff in the paragraphs above - Google search bait).

An Observation: Knowledge Management (KM) in the Enterprise

The ultimate solution was straightforward and simple, and I'm surprised that Apple's upgrade instructions do not indicate any need to plug in the iPod to get things going. I don't know if the plugging-in step is required - plenty of hits from my Google searches, but I didn't get the sense that 80% of iPod users were having this problem.

I also noted that in all of these results / conversations, it's rare to see a final, definitive solution captured. The write-ups are helpful for narrowing in, but I suspect after hours of struggling with iPod and PC, folks are just relieved to be done with it, and don't think to come back to close the knowledge-capture loop by documenting the ultimate solution.

This phenomenon happens in the enterprise as well, especially when working on stressful internal projects or hot bug fixes for extended periods of time. You're so sick of the problem that you don't want to re-hash the process by capturing the detailed step-by-step in a nice, clear document. When you're working on a product your company offers for sale, it makes sense to capture this knowledge - you can expect many users will call in with similar experiences. On the other hand, seeing well-constructed root-cause documentation for internal development or processes is rare.

Mitigation: For the tech going through the problem-solving process, a very effective approach is to keep a log of the things that you're trying, and each dark alley you go down. This will make it easier at the end to go back, clean it up a bit, and put it in the knowledge base as a final document. The other way to drive this knowledge-capture behavior is to simply to require proof of full documentation before something is pushed into production. This is overhead and "bureaucracy" that most techies dislike, but it should drive better quality over the long term.

Previously ...

Bug bad, bug good, bug Bug (May 18, 2005)
The "Army Rangers" model for IT Professionals (January 2, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
The Joy of Programming, the Challenge of KM (May 5, 2007)
Optimizing the Wrong Part of Knowledge Management (March 16, 2008)

Technorati Tags: best practice, documentation, iTunes, iPod, hands on, tech management, technology

Labels: application development, documentation, itunes, Knowledge Management

Desperately Needed Features for eMail Clients/Servers

Via Knowledge Jolt, here's an article from KM world with some interesting statistics about folks engaged in enterprise search - but it was a tangential quote from the author that caught my eye. When asking corporate knowledge workers about using public Internet search engines, she found that ...

... although only 2 percent [of corporate searchers] said they used the company intranet, 13 percent stated that they were looking for internal company information. That's puzzling.

Not puzzling to me! They're looking in their e-mail inbox!

It's a common hassle of IT departments - mailbox management (and the lack thereof). Everyone's inbox seems to have thousands of documents, gigabytes of information, and zero organization or structure. There are a couple of interlocking problems here:

Backup: IT is typically expected to cover everything - and after a few years, a few thousand e-mail accounts, and a few gigabytes apiece, well that's an awful lot of tape. More to the point - your backup window gets smaller and smaller, as you watch tape after tape load up with what you know are incredibly redundant inboxes.
Upgrades: Heaven forbid you try to convert from one mail server to another, or go through a major upgrade. The migration process will go on forever, because you have to convert all of that ... stuff.
Document Retention Policies: Something new from last year - the idea that a company must be able to produce any e-mail / electronic document requested by a court. Please, no eMails (IANAL) - I'm not up on all the details here, I just know this is one of the reasons why we can't simply delete all eMails older than six months.

To solve problems 1) or 2), IT departments will attempt to impose a size limit of a few gigabytes. This will be met with a few typical reactions ...

10-15% of your users will far exceed the targeted max inbox size. This is the typical Pareto situation, where the storage needs of a few outweight the needs of the many. Worse yet, this group is typically composed of the Marketing department (huge attachements), everyone in Legal (never delete anything, lots of document scans) and a collection of significant Executives (including the CEO) who get cc'd on everything and have zero time or interest in organizing ephemera.
Invariably, you'll get pushback along the "disk is cheap" line. Last month I bought 750GB of storage at Best Buy for $180 - why can't you throw some cheap disc in the old data center? Unfortunately, those that have time to provide these helpful suggestions typically don't have the interest in hearing about the growing stack of backup tapes.
Bottom line - there's simply no good business case for taking time away from anyone's busy day to organize their desk; they either do it or they don't. Mailbox quotas are IT's way of trying to tell you to get your life in order - and that is pushing rope, completely ineffective unless the person actually wants to change. It doesn't grow revenue, and it doesn't save cost (well, not much).

Now, I don't have any ultimate answers here, but I am trying to lay out the basic premise behind what I think are two very simple ideas that would have a huge impact on the growth of corporate America's eMail-boxes. I gladly invite someone to tell me why these things aren't features of every mail server; of course, I'd rather have someone to tell me how to get this done!

Proposed: Eliminate the Reply All feature: Or, at least make sure the default option is Reply to Sender, and put at least four mouse clicks and/or keystrokes between the casual eMailer and the option to share their wisdom with their cohorts on the To: line. We've all seen annoying threads expanding in our inbox - it must be the default! I say that only partially in jest - I have accidentally hit Reply All a few times - nothing too embarrassing, but it was, a bit too easy to make the mistake.

Proposed: When replying to a e-mail that sports a file attachment, mail clients should delete attachments from the reply by default. It makes little sense to reply to a note and return the original. If you've made changes, you'll be attaching your updated file anyway. I've seen way too many e-mail responses that say, in effect, "I agree". No need to send it back, just tell me you're OK with this. Of course, they'll hit Reply All (see above) because for some reason, I need to be informed that you agree with a copy of the thing I already have a copy of ...

These two options, I believe, would quickly eliminate the majority of useless duplication in corporate eMail servers. My last suggestion, is less about prevention, more about cleaning things up. Of course, I wouldn't be surprised if something like this already exists; I can even imagine how to write it. I just don't have the time ...

Proposed: I want a utility that scans each mail thread in my account, and selects the earliest occurrence of an attachment. Then, the thread is traversed, and all duplicates of that document are replaced with a text reference to the e-mail that contains the original. A simple concept, this would certainly save me a lot of manual effort needed when cleaning out my own inbox.

Any other simple ideas out there for mail management?

Here are some more recent eMail stuff from my blogroll ...

Lifehacker: Top 10 Email Productivity Boosters
McDonald: Questions to Ask Before Replacing Corporate Email

Previously ...

Another Spam Graph - The Impact of Spammers Changing Tactics (September 17, 2004)
Spam Graph redux (nice filter!), and an interesting meme I stumbled upon (May 24, 2005)
Hopefully, my last spam post (June 8, 2005)
eMail on Blackberry Changes Definition of Acceptable eMail (September 19, 2005)
IMAP Gmail Reinforcing the Drive to Web-based Productivity Applications (November 3, 2007)

Technorati Tags: application, best practice, development, innovation, Knowledge Management, productivity

Labels: application development, business value of IT, development, Knowledge Management, productivity, technology

Stretching Your User Interface Design Muscles

A follow up to my previous post on innovation in user interface design:

If you want to keep up with cutting edge thinking on technology - in a very approachable, effective format - ReadWriteWeb is a must for your feed reader. I'm constantly amazed by the number of solid articles they generate every week. Here's one from a few weeks ago with a series of video examples of imaginative thinking about user input:

User Interfaces Rapidly Adjusting to Information Overload

Another ReadWriteWeb article, and this one relates well to the Stephen Anderson presentation I linked to before. It talks about user interactions (web forms) that empathize with and engage the person working with the site. Excellent examples of usability "in the wild":

Good UI Design: Make It Easy, Show Me You Care

(via Aggregated Intelligence) A very effective way of designing any interaction with data (web form, application dialog box, even a paper report) is by prototyping. I have long favored MS Excel for working out database designs and report layouts; it's very simple way for end users to capture what they want to see, quickly rearranging and adjusting until it is just right. For on-screen dialogs, try PowerPoint; the second link below takes you to a "toolkit" of GUI components that let you work up sample screens / user interactions very quickly, using the comfortable environment of PowerPoint. Another option might be Visio - I've used versions of that package that included shape templates with lots of user interface widgets. Bottom line - it's a lot easier to sketch something out than to have to actually build something "real".

Also from the first article above ... if you don't think there's a difference between corporate IT UI and the consumer Internet - does this ring true for you?

Previously ...

If you want to be more than a programmer, stop programming (April 8, 2005)
Sometimes analogies work amazingly well ... (July 14, 2005)
Fighting with MS Access and version incompatibility (September 26, 2005)
Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
The Innovation Generation and User Interfaces (April 9, 2008)

Technorati Tags: design, development, hands on, innovation, powerpoint, presentations

Labels: application development, design, development, powerpoint, presentations

The Innovation Generation and User Interfaces

I don't intend for all my posts about Millennials joining the workforce to be anti-youth. There are some significantly good things this new generation can bring to established organizations - ways of thinking that foster innovation and forward-progress in how organizations use information.

For example, let's talk about user interfaces (UI). I'm not an old man, but I remember the advent of IBM's Common User Access standard. DOS-based computers and early GUIs introduced UI variety, and the resulting lack of consistency took part of the blame for systems that were hard to learn (and therefore hard to use). CUA promised consistency, greater productivity and information effectiveness.

Fast forward to the modern Internet era, and it's clear that "common user access" is no longer a baseline requirement for effective use of information. Cutting edge web sites pride themselves on their innovative, engaging, and unique front ends. Every website you see is different, yet it doesn't take people much time to figure out how to order a book on Amazon, browse for peripherals at CDW, or bid on stuff on eBay. These are mainstream Internet users I'm talking about; the tech-savvy are just the ones coming up with a new and different clown suits** for the same old services.

And by 'clown-suit' I mean 'innovative dynamic XMLSocket/AHAH/AJAX-based exploitative web 2.0 social mashup,' of course. (props to findmemp3)

However ... isn't it interesting that those mainstream Internet users, productively surfing at home, are the same folks in your office complaining about difficult-to-use ERP systems? In this world, UI consistency is not an issue (okay, except when an acquisition is folded inelegantly into another framework). The challenge is with system designers and developers that lack an understanding of what makes a user interface effective and engaging - something that most longtime corporate system developers have never really been trained in.

Not that the newbies (sorry, Millenials) coming in to our IT departments automatically know how to design an effective interface - they are just more open to it, and they understand it better when they see it. Admittedly, "I know it when I see it" is hard to describe and extremely hard to train. However, now I must link to one of the few presentations I've ever been able to get a lot out of without having the presenter present to me ...

| View | Upload your own

Now, I certainly can't explain Kano Modeling and the more theoretical stuff, but it really starts to click on slide 15 when he showed a hierarchy of needs for user interaction. The slides lay out basic ideas that resonate, and terrific examples that you can recognize from your daily travels through the Internet. These applications speak to you, not at you, and make the act of using them a pleasurable experience. Simple stuff like conversational error / warning / guidance messages, effective use of pictures and words, and the value of "less is more".

I think a critical differentiator between an application accessible via the public Internet and the typical internal, corporate application is a fundamental assumption [on the Internet] that you cannot hold your user's hand through the process. The information presented, and the user's experience, has to stand on its own - because it is impossible to know who, when, and where your stuff is going to be used. This raises the bar for usability and scalability, but it's a great model to emulate for internal development in this lean economy.

So how do you make the jump between internally-focused developer and externally-savvy innovator? I'd start with Anderson's presentation - see if it "speaks to you". I think you'll either get it (and your mind will open up), or not (and you need to burn a few hundred hours surfing websites and experiencing the difference).

Previously ...

Communicating Complex Technical Concepts (March 21, 2005)
Finding shapes in the fog - How to frame a wispy, wandering conversation (September 7, 2005)
A blast from my past - game programming for the TRS-80 (October 5, 2005)
The "Army Rangers" model for IT Professionals (January 2, 2006)
The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
Open Source Insights on Enterprise Software Business Models (March 14, 2007)
Lighten Up, Francis - Loosen Up That PowerPoint (April 14, 2007)
Consarned whippersnappers (Generational Diversity) (May 20, 2007)
Butting In to the Conversation: PM Communication Tools (February 26, 2008)
The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
The Innovation Generation - Communication Styles (April 1, 2008)

Technorati Tags: design, development, innovation, Web 2.0,

Labels: application development, design, development, generational diversity, millenials, tech management, Web 2.0

Why are those Old Programmers so slow in picking up on the Intarweb?

A significant difference between us old-line IT coders and the new graduates is the variety of our platforms and tools. I'm not talking about the large number of languages and tools learned over the course of a career - we all have a healthy collection of certifications and acronyms peppering the bottoms of our resumes. I'm talking about the amazing array of stuff required to get development done on a single project, "right now".

Over the past few weeks, I've been doing a little development at work. This is my idea of fun - in between the PowerPoints and project status meetings, I try to sneak in a little hack or two. Actually, I'm not doing the heavy lifting on this one; I'm working with one of the guys on my team, and we're putting together some ASP code to generate RSS feeds from the SQL database we use to track our projects. He's done most of the raw research and the base coding, I'm just prettying up the final package.

As a department, we're moving towards Microsoft as a strategic platform, but we're certainly not there yet - so this is definitely a skunkworks-type project. For this "fun stuff", we're using technologies that will plug nicely into our general strategic direction, but at this point there are no standard toolsets or integrated development environments in broad use.

So, to get the job done this afternoon, I've been cycling through the following ...

In window #1, editing the .ASP file with Crimson; source files are sitting on the development server
In window #2, testing code using IE ... no integrated debug environment for my ASP syntax, but I manage (just a little trickery - switches flip between RSS and HTML output)
This is just debugging the basic code - to validate the RSS XML, I View Source from IE (opening window #3) and cut and paste into the W3C validator (window #4)
For the SQL queries and database hacking, I've got window #5 for Enterprise Manager and #6 for Query Analyzer
After debugging, I push to the test server manually, using File Explorer in windows #7 and #8
Everything looks great, so I switch to window #9, which has another chunk of ASP that generates custom URLs for the RSS feed (we've added selectivity, aren't we crafty?)
For the final test, I have RSS Bandit open in window #10. I create multiple new feed URLs (#9) and add to the Bandit config, to see what I get
If I made a syntax error in the RSS (missed something between #4 and here), I have to flip back to window #1 to clean it up
Oops, almost forgot ... like any good coder, I've got TFMs open, but it's not just one manual- window #11 is my multi-tabbed Firefox, Googling all sorts of sites to get references for RSS, ASP, and SQL

Sounds crazy, I know. I could/should go out and get Visual Studio or something. But like I said, we're not fully in production in this Microsoft development environment. We're innovating, right?

I've done open source development on my own in the past, and it's much the same thing - multiple different platforms, tools, and languages. For example, when working on my own site, I'm fixing configuration files and writing code in HTML, CSS, PHP, and mySQL. To get things working, I'm dealing with the configuration files for Apache, Eclipse, PHP, and mySQL. Edits in Eclipse and Crimson, pushing around source with FTP, fighting firewalls and routers, developing in Windows while production is in Unix.

This madhouse of multiple tools, languages, and platforms probably sounds quite normal - if you've been working heavy with open source and/or Web 2.0 for a few years. But imagine presenting this to legacy IT folks, working in their version controlled, standardized environments. The typical "road to the future" brings five new technologies, three new IDEs, and one or two basic system architectures that are all very different from tried and true.

Does this mean you can't teach an old dog new tricks? Not at all - most are quite anxious to learn, and have done so continuously over the years. However, this is all starting to feel like the first time we switched from procedural languages (COBOL, RPG, Pascal, Fortran) to OO and event-driven stuff (Visual Basic, PowerBuilder, SQLWindows). We went from offense to defense, from being controlling and orchestrating to reacting and trapping. Not that it was bad or wrong - just different.

Does this mean the experienced coder is washed up, and has nothing to contribute? Ask the folks in Big Pharma, having dealt with the FDA and validated systems. Ask the folks working with Finance in public companies, having dealt with SarbOx. Healthcare and HIPAA. Retail and RFID. Not to mention having to debug a lot of other people's code, and knowing when to step through or just refactor.

Running to the future, juggling multiple multilingual windows, and demonstrated facility with the newest tools is all good, but it's just one of many attributes that determine who on your team is worth 50 others. Have a little patience ...

Previously ...

Things for the DIY programmer to consider (March 14, 2005)
Tracking patent submissions via RSS (June 1, 2005)
Turning a new page, and working on that home development environment (July 27, 2005)
My Favorite Paradox (August 13, 2005)
Analog and Report Magic Log File Formats (September 10, 2005)
Fighting with MS Access and version incompatibility (September 26, 2005)
Digging into open source for a New Big Project leads to Yak Shaving (November 4, 2005)
Code Mover / Transport: Managing source, environments, and deep-diving into multiple technologies (November 6, 2005)
The "Army Rangers" model for IT Professionals (January 2, 2006)
SQL Hack for Reporting Project Phase and Status (December 19, 2007)

Technorati Tags: design, development, documentation, hands on, innovation, tech management, technology, Web 2.0

Labels: application development, development, generational diversity, hands on, innovation, millenials, productivity, tech management, technology, Web 2.0

Tactics for Controlling Project Scope

I wrote about ways to "cheat" at project prioritization [aka trying to figure out what to work on next, when there is more demand (projects) than supply (people to work on them)]. One significant tool you have at your disposal is controlling scope - can you do 20% of the work to get 80% of the benefits?

Easier said than done, sometimes you need tactics, that help identify an opportune place to stop, a run-on project, or a design that is"simple enough".

Apply the Law of Diminishing Returns "in reverse", and front load the benefits. Let's say we're implementing a series of components (people, process, and technology) to analyze and improve promotion response. If I really understand the ROI, can I break it up into chunks? In this case, you might see a basic software package that defines master data, collects transactions, and provides basic metrics for promotion response. Let's say this visibility allows you to realize 70-80% of the benefits, but we want to follow with "phase 2" where we add training, tuning, and optimization to get another 20 to 30% of your ROI. Well, time and resources are short - why not stop at phase 1, let the new processes soak in, and "optimize" later?
Eliminate the 90-percent Done game - Projects that run-on forever sap the energy out of your teams, and destroy credibility with the business units whose projects are getting delayed. Via Vinson, here's an excellent post from Blain that reference's Zeno's Paradox (I'll never get there if I keep traveling half of the remaining distance ...). The primary tactic is to define discrete deliverables (tasks?) and only accept a binary status - it's either done or it ain't!
Keep It Simple, Sir! Feature creep is the greatest enemy of the short-term project. Some features (like quality / testing) are not what you'd want to negotiate out of the project. Thinking about cutting short on documentation? You naughty, normal person ... However, take a look at this post from Sierra, with a great illustration of the idea that usability is optimized right before the user has to reach for the manual!

Click on the picture for a full-size image!

The folks at Big Contacts liked the idea so much, they tout it as a feature ...

With Big Contacts there is no user manual. Because once you create a user manual, you are admitting your application is too difficult and that people need a book to use it.

Let's steal that idea for our projects. No documentation required, because the deliverables (process, technology) are simple and common sense enough that people don't need a manual, a training class, etc.

Ok, maybe it's not "practical", but it's a Worthy Goal that could help keep scope down to a dull roar ...

Previously ...

Challenges when demoing / training / pitching complex systems (May 23, 2005)
Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
Subdivide a huge project list to simplify the prioritization process (October 27, 2005)
Misapplying the Pareto principle (January 7, 2006)
Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Another caveat for the erstwhile agile developer (January 15, 2007)
Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
Defining the Business Value of a Project (October 25, 2007)
PM Anti-Patterns That Increase IT Project Cycle Time (December 7, 2007)
PMO Prioritization - Project Descriptions should be Effective, Relevant ... and Short! (December 9, 2007)
How to Cheat at the PMO Prioritization Game (December 14, 2007)
How to Win at the PMO Prioritization Game (December 18, 2007)

Technorati Tags: business value, documentation, PMO, Project Management, tech management, training

Labels: application development, design, documentation, PMO, project management

Hidden Gold in Automating Recurring Processes

Here's a typical IT scenario: each quarter, you need to check audit user access to a critical application. Your internal security standards require that you revoke access for those who haven't been on the system for over 90 days. I've seen this before, and the process (at the time) had many challenges:

It's manual; we did a quick-and-dirty set of steps years ago to cover the minimum requirements, that involves extracts from application logs, file transfers MS Access and MS Excel, and some emails
It's not drop-dead simple, because there is a list of exceptions - user IDs that were always kept active, even if they haven't been used
The overall process was never documented

Coupled with the fact that this only happened once per quarter, and involved less than five total effort hours to take care of, the easy response was to just get the task done and move on. But I think this is penny wise and pound foolish; there are long-term quality Problems to be avoided, and short-term Opportunities for internal staff development that we were passing up!

Problem: If we continued to just do the minimum, to satisfy the requirement, it was no surprise that over time, steps were omitted. The lack of documentation forced folks to repeat steps from memory, and pass along the process word-of-mouth as roles rotated and/or people turned over.

Opportunity: Simplifying things required some automation; nothing too difficult, but definitely interesting and non-trivial; for example, we needed a custom table for the exceptions. For staff members looking to build technical skills, this was a perfect training opportunity; small risk, small time requirement - a perfect filler when you are burnt out on the big project and need a bit of an escape.

Of course, the push-back was always the same: I Have No Time For This. Most can easily envision a total solution that is simple, uses familiar technology, gets rid of the multiple platforms and manual processes, and is sustainable. In this case, however, it would take about 16-32 effort hours to get done, and who has the time?

The solution was to attack the problem in baby steps; make the overall process a little better each time. For isses like this, you don't need to solve all of your problems now, and it's OK to leave the work unfinished until next time. However, the key is that you must commit to making a small improvement each time you "touch" the thing.

For example - back to the user access audit. For a first pass …

The current task owners walked through the process with me, and I took scratchy notes on paper and in a Notepad text file - stashed on my hard disk
I got the Access database extract and Excel spreadsheet that counted the days. I iterated on the spreadsheet, automating the counts and the formulas for computing days since last log in.
I returned the list of users who hadn't signed in for 90 days, which were then manually matched against the list of exception user IDs.
This work was a one-time add of about three effort hours - a small start, but a teeny platform on which to build.

A few months go by, and it's time for pass two ...

I moved my scratchy notes into a shared document and iterated on the process, mostly just cleaning them up to be somewhat legible
I still received the list of users and their last access date, but this time I got the list of exceptions. I iterated on the spreadsheet to take this into account
I still sent the results back, but note that now (and never again) does the next person in the process need to edit out the exceptions

This work was another one-time add of two or three hours; but we'd already simplified the overall process, and we saw the total effort (including process improvements) starting to decline.

Next iteration ...

We teed up a programming project to build an exception table and automate the log extracts - nothing more than a couple hours of effort
I took a final cut at the process documentation in the shared area, then turned it over to the operational support team

Note that each time you iterate on something like this, you need to feel comfortable with the idea that these works in process, these "interim deliverables", are clearly unfinished, even raggedy. It shouldn't matter, because each time you touch it, it gets a little bit better. Plus, the priority was originally low enough that a totally manual effort was OK, so what's wrong with documentation that is incomplete?

Incremental improvements on the primary goal (automated user audits) with tasty side benefits along the way (mini side projects to keep stretching your tech chops) … win-win.

Technorati Tags: productivity

Labels: application development, productivity

Subscribe

Categories

Previous Posts

Archives

Networks

Online Chat

cazh1: on Business, Information, and Technology

Monday, May 26, 2008

Politically Correct Euphemisms in IT - Translated!

Saturday, May 03, 2008

iTunes Upgrade Freeze Resolved - and an Enterprise KM Observation

Sunday, April 20, 2008

Desperately Needed Features for eMail Clients/Servers

Wednesday, April 16, 2008

Stretching Your User Interface Design Muscles

Wednesday, April 09, 2008

The Innovation Generation and User Interfaces

Sunday, April 06, 2008

Why are those Old Programmers so slow in picking up on the Intarweb?

Saturday, January 05, 2008

Tactics for Controlling Project Scope

Monday, May 28, 2007

Hidden Gold in Automating Recurring Processes