cazh1: on Business, Information, and Technology

Excel 2007 is a BOB system (Bag'O'Bugs)

Labels: development, excel, hands on, powerpoint, presentations, technology

posted by James P. MacLennan at 7:11 PM | Permalink | |

Agile Methods in a Waterfall World: Speaking In Code

Labels: application development, design, development, hands on, tech management

posted by James P. MacLennan at 10:50 PM | Permalink | |

Does Excel 2007 VBA have Sneaky Hidden Issues?

I've done a lot of coding over the past few years, on a number of platforms - but since I'm not a full time developer, it's typically limited to VBA, PHP, SQL, some simple web stuff. Still, I've developed some tools that people use - and need to carry forward as the underlying technology moves along. And so, as I've finally made the leap to Office 2007, I had to come to terms with yet another VBA upgrade.

I remember the move from Office 2000 to 2003 - the large number changes in Excel's VBA object model was surprising. I didn't have to rewrite as much this time around, but I did make some interesting discoveries ...

Macro Security

They certainly don't make it easy to lighten up your macro security! By default, Excel 2007 comes with macro security set to High (or harsh, or Suspicious, or something like that). For most of my stuff to work, we need security set to Low - friendly, trusting, etc. The step-by-step process is comical - they are really trying to hide this stuff ...

• From your Excel spreadsheet, click on the Office Button - the nice, round, logo'd guy in the upper left corner
• Click on the Excel Options button (at the bottom of the dialog that pops up)
• In the left-hand column, click on Trust Center
• Click on the Trust Center Settings button
• In the left-hand column, click on Macro Settings
• In the Macro Settings sections, select the radio button for Enable all macros ...
• Exit the workbook, then open it up again - the spreadsheet should process just fine

Workbook_Open()

This is a strange problem - the Workbook_Open() event just does not want to fire. This always worked perfectly for me in Excel 2003, but not in the newest version. I'm not too wrong here - this has previously been seen "in the wild" (here, here, here, and here ... Google your problems away ...)

The Fix: Copy the contents of the Workbook_Open() event into a new Public subroutine, called Auto_Open. All will work as you expect it.

Confusion: this one frustrates me to no end - I haven't found a reasonable explanation of why this happens - but this afternoon, I saw the Workbook_Open() event work as expected in one spreadsheet, yet fail in another. There are some tantalizing clues in this post (something to do with ambiguous names?), or maybe this post (objects copied from one project to another having mysterious interactions?)

VBA cell operations slow down

If you use a VBA procedure to write values to a range, most people would probably create a loop and write the values one cell at a time. This is not the fastest way to do things, and for Very Large Ranges, you will see some performance degradation. (Walkenbach, of course, has the best write up here). Well, I thought my code was reasonable, but my slow-ish code got much worse under Excel 2007. Looping through a range of cells actually slowed down as you progress through bigger and bigger ranges - I put some breakpoint messages in there, and it was sad to see, I was you will be forced to rewrite these sections as outlined in Walkenbach's method - note that his post is many years old, and this method works in Excel 2003 as well. After I did my rewrites, because the slowdown was brutal, and goodness! My routines are an Order of Magnitude faster! I felt the need to drop a quick note to the users, letting them know that the spreadsheets still worked - the instantaneous response time was not indicative of skipping code.

Hmmm: This behavior, combined with the previous problems with Workbook_Open(), plus a few 1004 bugs (mysterious code that never seems to indicate what the real problem is ...) makes me think there are subtle memory management problems in this version of Excel VBA. Nothing that makes me swear off VBA forever - you just need to be smart about your VBA projects. Excel is for light-duty programming. If you think your project is getting unwieldy, consider another platform - don't let Excel be the hammer for every nail that you see.

AutoFilter

Columns that allowed "selectivity" via the AutoFilter command act differently when brought up under Excel 2007. Not necessarily an issue - unless your macros try to manipulate these things programmatically. I do this a lot, but I found I've been overcomplicating things ...

Before

After

Ribbon vs. Menu

The new Ribbon approach for commands across the top of your documents means the Menu meme is dead. After you get used to finding your way, it's not really a big problem - unless you have coded custom menus for your macros. They won't entirely disappear - they get shuffled off to the Add-Ins tab - just not as convenient.

All in all ...

Am I surprised by the glitches? Not really, but I am pleasantly surprised by the relatively small number of problems my past automation efforts experienced. When they moved from Office 2000 to Office 2003, I had many more problems - Microsoft made some basic changes to some of the Excel objects, and the fixes were not backward compatible. This time, however, folks can use either Excel 2003 or Excel 2007 to use most of the stuff I've created for them - but seriously, shouldn't you get around to converting already? You are running out of excuses.

Guaranteed To Work Under Excel 2007 (?!?!)

What, are you kidding me? I tested my spreadsheets a lot, but it won't surprise me when someone comes up with a use case / scenario that I didn't check for. Just tell your end users to continue with that terrific patience they have shown over the years, and to let you know if/when you see things that don't look right. Hint: encourage them to call you over to their desk when issues occur, so you can take a look at the screen. Screen prints cut and paste into emails, or lengthy explanations over the phone just don't cut it.

• The good and the bad about being a hands-on tech manager (January 25, 2005)
  
• If you want to be more than a programmer, stop programming (April 8, 2005)
  
• Fighting with MS Access and version incompatibility (September 26, 2005)
  
• Code Mover / Transport: Managing source, environments, and deep-diving into multiple technologies (November 6, 2005)
  
• Look your best with little effort - Excel, Project VBA for Page Formatting (June 11, 2006)
  
• 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 Joy of Programming, the Challenge of KM (May 5, 2007)
  
• Stop Thinking, Start Doing - Else Your Career/Skills/Network Will Fade Away ... (January 2, 2008)
  
• Stretching Your User Interface Design Muscles (April 16, 2008)
  
• There ain't much IT in IT Management (May 7, 2008)
  
• Home Development Workstation - Part 1 (May 13, 2008)
  

Technorati Tags: application, development, hands on, vba, technology

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

Labels: application development, development, excel, hands on, technology, vba

posted by James P. MacLennan at 10:18 PM | Permalink | |

Facilitating Innovation: Establishing an Environment of Possibilities

I'm exchanging email with someone interested in establishing a skunk works, and they are asking some very interesting questions about the nature of innovation and the ingredients for an "environment of possibilities" ...

... things are ... [as they are] because someone already tried unsuccessful alternatives ... [This] begs the question: when it is required, how can rapid innovation be achieved?

Rapid innovation comes when the environment allows it and the skill sets enable it.

• An "environment of possibility" just means that folks are given some time to experiment with new technology, and access to the resources required to play around a bit.
Caveat: The challenge, of course, is that many folks expect the employer to allocate x% of their 40 hour work week, and provide training classes and server space to mess around with. Invest a little personal time and capital - in IT, it doesn't take much to build a solid development / test environment and start teaching yourself!
• I believe that the "innovation skills" are in everybody. But just like any other activity, success is 10% inspiration and 90% perspiration - individuals / teams / organizations need to build their innovation muscles by doing.
Caveat: A critical requirement for this piece is has to be ok to fail. The corporate culture must expect a failure rate for new ideas - remember, if it was easy, we'd probably already have thought of it!

... I value both history and future opportunity and am seeking a balance. Is this the same in your experience?

Well, Santayana was right - "those who do not remember the past are doomed to repeat it". But history should tell you specifically what tactics to avoid, but not necessarily what strategies will fail. Opportunity will be a mix of many things, and what was true at one time may no longer be true now. Look at imports from China - recent increases in transportation costs are making that strategy a loser for lower valued goods.

Process: How does ... leadership successfully position a think tank or innovation team so that it is (a) buffered from mundane corporate operations and politics while (b) it remains sufficiently connected to executive leadership and operating divisions for its ideas to be acted upon? (I'm assuming that the skunk works is outside the normal corporate business structure.)

Ah, this is an incredibly important question. Skills and environment aside, I've seen successful innovation happen only when the team was sufficiently empowered to get ideas implemented. Sometimes this comes from executive sponsorship from just the right person - but not as often as folks think! The cynical or weak of heart prefer to wait until they are granted permission to work on a project or idea.

The "drivers" that get stuff done do so because they have all the rah rah stuff (vision, drive, energy, whatever), but they also typically have knowledge of how things work in a company. Sometimes this means a long-time employee, who has relationships with the folks that control the key people, resources, and decisions. Sometimes this means the uber-techie who already knows how the various pieces of process and technology work, so they know how to call out the resistors when obstacles are thrown in the way (no budget! no approvals! too difficult! systems can't do that! it's against policy! yada ...). And you don't have to be a long-term member of the organization to be successful; experiences from multiple industries, organization, technologies, etc. can all be applied by someone with imagination and drive.

So, leadership needs to stack the deck for their innovation team by ...

• Carving out time in their schedules; don't just add this to everything else on their plate - take something off!
• Provide visible executive sponsorship. You need to be able to pull that card out every once in a while (You need to make this change because the CEO said so ...) - not often, but now and again ...
• Staff the team with a mix of long-term and newer employees
• Identify a team leader that has the right mix of hands-on technical (this cannot be a administrative role only - they have to be able to do something!), business, and relationship-building skills. They must be able to spot the opportunity through the hype, understand how it translates to business value, and then communicate that effectively and concisely to those who need to support it
• Hold their feet to the fire - the team should have goals and objectives, it's not a license to play!
• Let them fail! The most successful baseball players fail 70% of the time!

Also, the skunk works must remain connected to operations - they'll have to implement the "big ideas" eventually, and it's always good to remain grounded in reality. Make participation on the team a part-time thing for most; consider rotating different people in from various areas of the company, so everyone has a chance and all remain connected to the base business.

What lessons have you learned from the skunk works experience that you can apply to the innovation process? What broad, meta-issues and narrower specific issues has your project illuminated and solved (or at least, what questions has it posed)?

Aside from the organizational and change issues mentioned previously, I have found that innovation efforts often target things that are perceived as issues, but they are actually symptoms of more fundamental behavioral or structural problems. Web 2.0 tools and techniques are often lauded as new ways to unlock the wisdom of the crowds, connect with the new work force, or counter the flight of knowledge leaving the company upon retirement. Unfortunately, some of these efforts struggle due to what I call the Law of Large Numbers, which basically says that what works on the Internet doesn't always work at a corporation.

Also, it always seems to boil down to "Change Management" - an overused buzzphrase that just says change is hard (especially from a vending machine). There are many ways to address this (education, repetition, participation), but management always needs to understand that corporate operating processes typically don't catch on like consumer products - here today, gone tomorrow (look how fast the Apple iPhone turned over a new version!)

• Motivating Maintenance Programmers (January 6, 2005)
  
• Moving to Eclipse Ia - Relevance (June 1, 2005)
  
• Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
  
• My Favorite Paradox (August 13, 2005)
  
• Subtle Anarchy (August 22, 2005)
  
• The "Army Rangers" model for IT Professionals (January 2, 2006)
  
• Guidelines for Success with your Skunk Works project (June 19, 2006)
  
• Innovation That Matters - Substance Over Style (January 12, 2008)
  

Technorati Tags: design, development, entrepreneur, innovation, operations, people management, tech management

Invisible Technorati Tags: cazh1, FEI, Front End of Innovation, James P. MacLennan, jpmacl, MacLennan,

Labels: application development, design, development, entrepreneur, innovation, people management, productivity, project management, tech management

posted by James P. MacLennan at 10:39 PM | Permalink | |

Don't Accept Snap Answers Too Quickly

A few years ago, I was working on an interface project, and wanted to have the ERP system send copies of any and all transactions that have changed over the past few days. I've done this before on other platforms, so I asked the lead developer what I thought was a no-brainer request:

Do the transaction files capture a date/time stamp somewhere in the record, each time the record is modified - DateLastUpdated, something like that?

His answer came back almost immediately ... No. Well, I guess this is possible, but we're working with a fairly up-to-date ERP, and I've worked with enough systems and data bases to know that many/most applications timestamp their records when updating, or maybe write changes to a log file of some sort. And the answer came back just a tad too quickly ... so I asked the question again, but this time I took some time to preface my question with an apology (of sorts) ...

I mean no disrespect, I am fully aware of your experience and skill on this particular platform - but I need to be clear, because I think I'm asking for something that's fairly basic.
I just need you to be a tad more specific when you say 'the system doesn't do that'.
Is it more accurate to say 'I have never seen the system do that' or do you know for a fact that that the system cannot do that?

It's a subtle difference, but it's important to drill into this level of detail. Most of us are pushed for time and quick to come up with the fast answers, so we can move on to the next item in the todo list. Answering off the top of our head is a pretty normal response, I do it a lot myself, but this was a pretty important feature request because the lack of it meant a ton of additional work in other areas. Besides, I'm humble enough to know there are many features and functions in any platform I've ever worked on that I don't fully understand - never had the need. Plus, I don't see a ton of wildly original thought and unique features in many of these system that we work with. In cases like this, I'm asking for something that I've seen in another platform, assuming that the author of this platform was a reason intelligent person and has added that same basic functionality.

Truth be told - in this instance, the transaction file in question did not have a DateLastUpdated field, and we had to look at transaction logs to get the information we needed. Still, the developer in question had little problem with my pushback; he readily acknowledged that he did not have the layout of this particular table memorized, and had never heard of such functionality - but the concept made sense, and he was happy to look. Besides, if his snap answer was wrong, it would have saved him a ton of work ...

Drilling into the specifics like this (do you know No, or do you Not Know?) applies to more than just software developers. Engineers lawyers, accountants, sales reps - many folks from across the business are faced with questions that they try to answer from their Experience, hoping for the Quick Answer. It takes some confidence to question the "local expert" - but if the right questions saves a ton of effort, searching for a workaround - well, that's an excellent question to ask.

• Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
  
• Making the internal pitch? Learn from the entrepreneurs (October 10, 2005)
  
• Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
  
• Misapplying the Pareto principle (January 7, 2006)
  
• Beware the Self Fulfillling Prophecy (May 23, 2006)
  
• Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
  
• War Stories from the Change Management front (August 21, 2006)
  
• The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
  
• Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
  
• Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
  
• Communication is the responsibility of ... (August 19, 2007)
  
• Project Management Soft Skills Defined: Emotional Intelligence (October 17, 2007)
  
• PM Anti-Patterns That Increase IT Project Cycle Time (December 7, 2007)
  
• Innovation That Matters - Substance Over Style (January 12, 2008)
  
• Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 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, collaboration, design, development, hands on, people management, project management, tech management,

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

Labels: application development, collaboration, development, hands on, innovation, project management

posted by James P. MacLennan at 9:53 PM | Permalink | |

IT and the Business are Closer Than You Think

A few passing observations from the last few months; contrary to what many (IT/business) folks believe, they are just as good or just as bad in managing processes and projects as their counterparts in (business/IT).

Problem Resolution is Everybody's Problem

A few weeks ago I was discussing issues that came up with one of our systems, and the team was a bit dismayed that the user community was still finding errors (we should be trapping for that stuff!) I pointed out that it's illogical to worry about stuff like this. We've implemented fault-tolerant systems that predict as many problem situations as we can think of, with lots of alerts and doublechecking built-in. If we can think of a problem, we will build a trap for it. It stands to reason, therefore, that the only bugs to appear are the ones that we couldn't anticipate - so the only people that will experience the bugs will be the people using the system.

It's inevitable that end users will find your problems, and that's nothing to be concerned about - we're all testers, and testing never really ends (in a continuous improvement environment). What you should be concerned about - how quickly we can turn around a fix for the problem? What is our total uptime? Do we see decreasing numbers of new problems, and zero recurrence of previously reported problems?

Truth be told, the onus of root cause is just as much on the business. Was this a scenario that could have been predicted? Were the requirements amd/or testing scenarios complete? (... apparently not ...) When projects are well run, and it's a true partnership between IT and the business, misses like these are everyone's problem.

Nature Abhors a Vacuum

Business managers may not understand the details of the technology they work with, but they certainly understand good management techniques. Try working with any manufacturing operations group and not going to them with metrics or KPIs (Key Performance Indicators). This is their bread and butter; they cannot understand how anyone could manage without some form of metrics. And if they see none, they will not only notice the problems, but will proactively look for issues, assuming things aren't under control.

On the other hand, if you have a reasonable set of metrics and are managing to them, they certainly can't accuse you of not following sound management principles. They may provide feedback that the quality of their experience is still not the greatest - but a structured, metrics-driven approach shifts the conversation to towards a discussion about best metrics to manage to, and not whether or not IT knows what they are doing.

In the End, We're All [Bad] Programmers

Check out this article from CFO.com, detailing a number of "worst practices" that folks in finance to see their counterparts doing that make them cringe. Sound familiar?

• Poor Segregation of Data: Mixing critical values with complicated algorithms (business rules) makes for a delicate and hard-to-maintain spreadsheet (application).
• Poor Documentation of Assumptions: when revisiting (cloning/debugging) this report, if you can't remember the original assumptions (design), you may need to rework (refactor) the entire thing
• Poor Documentation of Constraints: complex worksheets with many simultaneous calculations would benefit from interim formulas in key cells (asserts) to test reasonable boundary conditions
• Difficulties in Making Changes: spreadsheets and formulas can and should be structured to allow for foreseeable extensions and modifications (subroutines)
• "Now It's Here; Now It's Not": at times it's too easy to change values in the worksheet to test different assumptions. And then lose track of all the changes made over time (version control)
• The Presentation Readiness Problem: when creating spreadsheets, analysts (programmers) should anticipate their use in final presentations (user interface)

In summary, the author provides this sage admonition ...

Treat the development of a spreadsheet - any spreadsheet - more like writing a term paper with footnotes and a bibliography.

See that? Accountants and programmers should aspire to be ... students?

• Heisenburg KM (July 13, 2004)
  
• Does IT make you productive (or, are you an existentialist or a fatalist)? (February 26, 2005)
  
• Things for the DIY programmer to consider (March 14, 2005)
  
• Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
  
• Sometimes analogies work amazingly well ... (July 14, 2005)
  
• Of course we can pay for that ... if it makes business sense (November 7, 2005)
  
• Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
  
• Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
  
• Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
  
• Stretching Your User Interface Design Muscles (April 16, 2008)
  
• There ain't much IT in IT Management (May 7, 2008)
  

Technorati Tags: best practice, business value of IT, development, documentation, tech management

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

Labels: business value of IT, development, documentation, people management, tech management

posted by James P. MacLennan at 3:37 PM | Permalink | |

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.

The sales team played with it, realize they have to actually type data into the system, and now they're trying to delay as long as possible.
   - alternative -
They asked for a shared contact database, we came with a $3M package implementation, and now we're scrambling to save face ...

... 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

The business can't make organizational decisions
   - alternative -
Our development teams can't agree on a common QC cycle
   - alternative -
We never had a long-term plan, this grew by evolution, and now we need a revolution

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 ...

Awesome! We can cancel this screwed up project and restart it after the new owner settles in!
   - alternative -
The new team runs a pretty tight ship ... good thing my resume is up-to-date ...

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

We hit too many walls and the business is fed up, so the project goes no further.
   - alternative -
Another high priority project came along, and we got pushed down the to-do list.

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) ...

... my soon-to-be subordinate, unless kick him out of his chair ...
   - alternative -
Good thing my resume is up-to-date ...

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

• 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

Invisible Technorati Tags: cazh1, FEI, Front End of Innovation, James P. MacLennan, jpmacl, MacLennan,

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

posted by James P. MacLennan at 12:33 PM | Permalink | |

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:

1. 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.
2. 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.
3. 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

• 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

posted by James P. MacLennan at 9:14 PM | Permalink | |

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".
• UI Design - Prototyping
• PowerPoint Prototyping Toolkit (release 0.2)

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?

• 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

Invisible Technorati Tags: cazh1, FEI, Front End of Innovation, James P. MacLennan, jpmacl, MacLennan,

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

posted by James P. MacLennan at 8:52 PM | Permalink | |

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 ...<