Beyond Blinking Lights and Acronyms

Interviewed On Dice.com About Business Analysts Raising Their Profile

Back in April, Sonia Lelii from Dice.com, a recruiting and career development website for technology and engineering professionals, interviewed me as part of her story, Business Analysts Raise Their Profile in their Technology Today section.  Lelii also interviewed recruiter Christa Baker for her perspective.  Unfortunately, I had forgotten about this until Monday's post on hiring business analysts reminded me.

The article talks in detail about the need for people who can communicate between IT and business groups and what types of background and  skills they need.  Take a look, I'd love to hear your thoughts.

If this topic was of interest, you might also like these:

• Hiring the Right / Wrong IT People to Achieve Alignment
• Jonathon Babcock's post Business Analyst Job Description
• Let's Get Down to Business
<
• Or the posts in the Business Analysts / Analysis category

Agile Programming - A Poor Choice of Words?

Agile Programming is a popular programming methodology.  But it's not alone. There are other methodologies such as the Rational Unified Process, Spiral, and the traditional Waterfall methodology in common use.  Each has it advantages and disadvantages and each is named in a way that describes the process.  However with Agile its very name can tend to cause confusion.  "Agile" gets confused with "agile".  Wait a minute.  Other than the capitalization aren't they the same things?  Well not exactly.  Agile with capitals does mean something different than lower case agile and that's where the confusion comes in.

Agile (upper-case) programming in overly simple terms is a method of developing programs using closely knit teams to quickly produce releasable code in short time frames.  Based on the Agile manifesto principles it has some certain processes.  Wikipedia provides a good overview and a simple Google search will provide a mass of references. 

agile (lower-case "a") programming simply denotes being flexible in our design and adjusting as we go.

The term Agile was no doubt derived from its lower-case counterparts and that's where the difficulty comes in.  When we speak of Agile others often hear agile.  And after all who wouldn't want some flexibility in programming?  So very often you quickly get buy-in to employ this methodology when you use this term.  That is until the realization sinks in that what your user thinks they bought is not what you thought you were selling. 

Keeping Data Accurate

This weekend I got a new windshield on my car.  A few weeks ago a rock chipped the windshield and propagated and 18 inch crack within a few minutes so I arranged for a windshield repair company to come to my house to replace it.  Things were going along pretty smoothly at first.  They removed the old windshield, took off the various registration and safety inspection stickers and prepped the car for the new windshield.  Everything was going well until it came time to put in the new windshield.  That's when they found out that the windshield they brought wasn't the right one for my car.

The repairmen called their office and verified that all of the ordering information was correct.  The problem turned out to be that the database of auto glass parts that they subscribed to had the wrong information.  They finally were able to figure out the right part number, brought it out to the house and installed it.  All turned out well except that it cost them an extra 2 hours of delay.  As they were about to leave one of them commented that they recalled that they ran into this same problem the last time they worked on my model of car.  It turns out they had to work with an inaccurate database that didn't have a good means for them to update or correct when errors were found.  In this case an inaccurate database became a customer service issue.

It's a fact of life that errors will find their way into our databases.  There are things we can do to minimize this but it difficult to entirely eliminate errors.  So this begs the question - "What do we do about the errors?"

Zappos: Integrating Systems and Business Processes

When you run across a company the truly integrates their systems with their business processes it can be an amazing experience.  Dealing with these companies borders on fun because they take the effort to make it easy and have anticipated your needs.  Zappos, an online retailer of shoes and other accessories, is one such company.  Or more appropriately as they describe themselves: "We are a service company that happens to sell ________.

• shoes
• and handbags
• and clothing
• and eyewear
• and watches
• and accessories
• (and eventually anything and everything)"

Since I'm a customer of Zappos I'm surprised that I hadn't written about this before.  Fortunately, Seth Godin's recent post, "Zappos wants you to return those shoes" reminded me so now is a good time to talk about them.

Zappos' service is all encompassing in how it is set up.  It includes: policy, processes, customer perspective, vision, attitude and systems.  Customer service for them isn't just putting a "Contact us" or "Customer Service" link on their web site.  Pete Blackshaw explain this in more detail in "Word-of-Mouth Marketing 101, à la Zappos.com"

Don't believe me?  Then check out these examples:

When Robots Attack

James Taylor over at the smart (enough) systems blog posted an interesting article last week.  It was one of those that if it wasn't so serious it would be funny.  His post iRobot - Elite CRM, stupid returns system details his experiences of buying 3 systems from iRobot and wanting to return 1 of them.   As crazy as it sounds the only way he could do this was to return all 3 and then re-purchase the 2 he wanted.  As Taylor points out this is a poor way of doing business in so many ways.

Taylor notes that iRobot received a 2008 destinationCRM award for their automated customer service system.  However after his experience with trying to return a product Taylor notes " am sure the automated system for which they received an award is wonderful - I have not had to use it yet - but clearly they could do with making their return system a little smarter."  It does make you question how much thought they really put into the design of their system or if they tried to get any customer input into the system.

This example points out the need for 2 essential elements in good application development - the end user perspective and adaptability.  End user perspective can be obtained in a number of ways.  It can be based on the developers knowledge of how the system is used, input from the sales team,or directly from the end-user themselves.  How you get this input all depends upon the particular situation.

So why is all this important?

Rebate Technology

As is often the case I bought a few things this past week.  And as is also often the case some of the purchase came with rebates.  I don't like rebates.  Don't get me wrong I like saving money which is part of rebates.  I just don't like the concept of rebates.  When you're shopping they quote the price as if you get the rebate which of course you don't cases unless you remember to cut out all the necessary tags, circle the price, mail it all in and wait a couple of months.  What a pain!  Somehow it seems a little be unethical to quote a price "after rebate" knowing full well many people won't get a rebate.

Rebate programs cost companies money to run.  Advertising are rebate processing and significant costs and you would think that companies would find it less expensive to just lower the price.  However, the dirty little secret of rebates is that people will buy based on the low "after rebate" quoted price but end up paying the full price in some cases.  Some people will lose the tags/receipts, some will fill out the paperwork incorrectly and some will simply forget.  And that is what the companies are counting on.

This week I experienced 3 forms of a rebate program, one of which was new to me:

Should We Stick To What We Know?

The Harris Country Toll Road Authority (HCTRA) operates the toll roads where I live (near Houston, TX) and they do a pretty good job of it.  They upgrade the roads quickly and construction is done relatively quickly.

Since I drive on the toll roads almost daily one of the great things that I like is the EZ Tag system.  This is a RFID tag that scans my account number automatically as I go through the toll booth and charges my account without having to stop at the mainline toll booths.  As a result I zip through at traffic speed (which in Houston varies from 2 mph to 70 mph).  There are a number of toll roads across the country that use this and if you drive with any frequency on them you know what a great advantage they are.

Recently HCTRA expanded the use of EZ Tags to allow me to pay for parking at IAH - Bush Intercontinental Airport.  There is no charge for this.  I just pull up to the entrance and instead of getting a ticket, a scanner reads my EZ Tag and opens the gate.  When I leave I go through another EZ Tag scanner and exit while the system automatically calculates the parking fee and adds it to my account.  At least that's the theory.  Unfortunately reality is much different.

An IT Question: Responding To A Request For "Just An Access Database"

It's not unusual for a user with some degree of familiarity of PCs and programming to come to IT with a request - "I need help developing an Access database to analyze ZZZZ".   You know that the Access database could be done quickly and you know that the database would be beneficial.  You also have some concerns about security, documentation, testing, backup and support with these user developed systems.  Due to resource constraints it will be at least 6 weeks before you can provide an IT solution compared to a few days if you help them develop the database on their own. 

How do you respond to this request?

"Help" photo by Cobber99

Got a question you'd like me to post for future discussion?  Email it to me using the "Email Mike" link in the left hand column.

ITs Weasel Words

Last Friday Jonathon Babcock had an interesting post called "You Know It's Getting Deep When .  ." talking about the weasel words we hear from developers in regard to our projects.  He was referencing a post from the previous day by Chris Woodill called "Developer Weasel Words".  Chris has a pretty good list of phrases we often here.  Fortunately, Chris didn't just stop with providing a list.  He also made some excellent recommendations on how to reduce the amount of excuse making.

The one set that Chris had that has always been a pet peeve of mine (it also made Jonathon's favorite list) is:

It Worked on my Machine!: programmers use this excuse to downplay a bug. The reality is actually the opposite - it means that you have an intermittent bug which is by far the worst kind of bug to have in your application. You want bugs to fail quickly and consistently - any variant such as "That's Weird", "That didn't happen yesterday", "That must be a data problem", etc. is admitting you have a bug that cannot be easily duplicated.

This is such a classic that it's gone beyond just the developers.  For example, calling the HelpDesk and reporting problems accessing the Internet or starting a package program and a getting a "It works okay on my machine" just sends me through the roof.  I guess the problems are all in my head.

I do have an additional one I'd like to add to the list:

What can we learn from our favorite technologies?

The other day I over heard someone talking about Tivo, the digital recording device that allow you to easily record your favorite TV shows.  They excitedly proclaimed how much they liked it.  It was easy to use and allowed them to watch their favorite TV shows whenever they wanted.

That got me thinking about what were my favorite technologies.  The ones that I really think work great and appreciate the thought that went into their design.  The ones that really help me accomplish what I set out to do.  Two came immediately to mind.

The first is the Hertz NeverLost system.  This is the GPS navigation system available in Hertz rental cars.  There are a lot of GPS navigation systems available and admittedly I have not tried them all but for me the NeverLost system is the standard I'd judge all others against.  I love it.  It is easy to use.  The graphics are simple and easy to follow and the the directions are timely and accurate.  What more could you ask for?

A few years ago I rented a car from Avis and got there system.  It was horrible.  It use a Nextel cell phone and the screen was hard to read the audio was garbled.  Looking at there web site it looks like they've changed systems but I don't know how there current system compares.

SaaS and the End User Experience

CIO Magazine had a rather interesting cover story, "Get Smart About SaaS" by Galen Gruman in its June 1st issue.  It gives a great overview of SaaS (Software As A Service) and answers many of the basic questions about SaaS but like so many other articles I've seen on SaaS it is eerily quiet about one aspect.

• It describes what SaaS is - "With SaaS, there’s just one code base for the software, used by all customers, in what’s called a multitenant architecture. While the software might be configurable by users to their individual needs, the code itself is the same for all and is not customizable for any individual customer."
• It describes what SaaS isn't - just any hosted application accessed through the Internet
• It describes where SaaS does and does not make sense. Gruman present a good analysis of things to consider such as integration, strategic functionality, the need for rapid deployment in deciding if SaaS is appropriate.
• It discusses issues of service levels, security and risk management that all have to be considered in a SaaS implementation.
• It provides insight from an number of CIO's on their experience with SaaS.

I liked Gruman's article.  It is actually one of the better ones that I've seen on this topic.  But like so many of the other articles it noticeably seems to be quiet on the end user experience with SaaS.

Using Grandma's Quilt to Explain Your Systems Environment

I love the way that graphic elements can often convey information and concepts with a minimum of words.  In fact they often do it more completely and clearly than even well written explanations.  A couple of simple well-known examples include the Movado watch.  A quick glance and you know what time it is without any numbers.

The other example is one you typically see on the televised baseball games.  It the scoring banner that you see at the top of the screen.

A quick glance keeps you up-to-date and you know that you now is not the time to go raid the fridge.  Using graphic can also be a very effective way to describe your systems environment. 

Letting Users Set the Business Tech Agenda

A couple of items in a  recent article at Information Week called "IT Departments Will Set Less Of The Business Tech Agenda, Survey Suggests" caught my attention. 

"Business users want more innovative software faster and will bypass the IT department if necessary to get it."

"In some cases, the research also shows IT organizations turning a blind eye when business units take risks with smaller, more innovative approaches to software."

No doubt this is a worrisome trend for many in IT.  We sit back and say sure the centralized, integrated approach may take a little longer but if we do it we can have better information, we can have a more complete insight to our customers, we can . . ., we can. . ., we can . . .

What this brings to mind is the old riddle about 4 frogs sitting on a log. 

Q. Four frogs are sitting on a log.  Three frogs decide to jump off.  How many frogs are left on the log?

A. Four frogs.  Deciding to do something and actually doing it are not the same thing.

Likewise, software that can provide what is needed is not the same as software that does provide what is needed.

Are Your Execution and Delivery Processes Ready for the Internet?

The Internet is a wondrous thing and has significantly changed the way we live and work.  It has also changed our perception of time.   We can send an email around the world in the blink of an eye and expect a response just as quickly.  We can shop online, check the status and for some product download our purchase instantly.  As a result anything we do on the Internet comes with an expectation of speed.

In the rush to meet or beat our competition and to better serve our customers it tempting to add a customer interface via the Internet.  However, this mean more than just putting up a website and slapping an "e- "  or "i- " label on something.  Because of the speed expectation that comes with the Internet you also need to take a careful look at your execution and delivery processes.

Are We Creating Problems By Design?

Mark Graban over at Lean Blog had a post this past Sunday that was an "Ah Ha" moment for me.  His post, "That's What We're Here For" struck a chord with me.  He relates how he when he registered for access to a web site he was given an Owner Name, Owner Number, Conference Code and Leader PIN.   However, when he tried to login it required an Owner Name and  a "Password" instead.  I won't relate the whole story but it involved needing a User Name which was not the same thing as the Owner Name and it gets worse from there.  No doubt you can see the problem this can cause.  Graban called Tech Support which was able to get him going.  He then relates:

I said to the tech support rep, "You know, the website is very confusing. I'm good with computers and I couldn't figure it out because things are labeled wrong on screen and it seems every new user has to make a tech support call, which costs us all money."

The tech support rep was sort of irritated and said, "Well sir, that's what we're here for."

A situation that could have been easily avoided with consistent wording and clear instructions.  Yet this is not all that uncommon.

Are You Ready To Throw Away Your Safety Glasses?

Jon Miller in his blog on Lean methodologies, Gemba Panta Rei has a very thought provoking post where he suggests Safety Glasses Are a Sign of Unsafe Processes.  Most U.S. factories require you to wear safety glasses whenever you go out on the factory floor.  The reason for this is to protect you from flying debris.  However, if you had safe processes in place, adequate machine guarding to be specific, you wouldn't have flying debris and you wouldn't need safety glasses on the factory floor anymore than you would need them in the office.

Miller goes on to explain:

The Japanese consultants I worked with always puzzled at why American and European factories had such inadequate guarding at the source of the debris. They used to say that safety glasses are a sign of unsafe processes. I think of safety glasses as an sign of a process that is far from ideal, just like inventory is a sign of a lack of flow or forklifts are a sign of disconnected processes.

It is hard to refute the logic of the argument that you wouldn't need safety glasses if you had a safe process, and yet . . .   So while all this is an interesting mental exercise what does it have to do with IT?

Are Your Sales Tools a One-Way Street?

It's all about your customers.  Sales drive the company's profitability and growth.  We have to get closer to our customers.  These are some generally accepted universal truths for success in business.  These concepts are