Business Lesson 'Impossible'

I generally don't watch a lot of reality TV, (I really prefer NCIS reruns) but I do have a couple reality of shows that I record on the DVR and watch religiously, Restaurant Impossible and Bar Rescue. Both of these shows follow the same format: an expert comes to a failing business and, in a fixed amount of time, resolves all of the issues with the appropriate  TV drama. The entire 2-5 days process is then edited down into a neat and riveting 1 hour package. While I don't pretend to think that I could gain significant expertise on any industry based on a 1 hour reality show (nor should you believe that you could either), these shows do provide some interesting insights

Here's my analysis of each show

Restaurant Impossible 

Businesses Type Fixed: Single Location Restaurant
Primary Product: A meal served
Primary Financial Issue: Food cost
Common Problems: Poor financial management, poor kitchen management, poor  personnel supervision
Common Management Issue (almost every episode): Owner/Manager doesn't understand the the restaurant business

Bar Rescue

Businesses Type Fixed: Single Location Bar
Primary Product: A good time for adults
Primary Financial Issue: Liquor cost
Common Problems: Poor financial management, poor bar management, poor  personnel supervision
Common Management Issue (almost every episode): General Manager (may be the owner) doesn't understand the bar business.

Other Observations:

While a bar and a restaurant may seem similar and may provide the same products (food and liquor), what the customer is buying is very different. In one case it's a meal served to you at your table, in the other case its a social environment and atmosphere. In the case of a restaurant the food is a critical component, at a bar  the atmosphere is critical.

On both shows usually the employees know what the problems are, but the managers won't listen to them.

Some Lessons Learned

1. Understand the business you are in. In just about every case, the person running the business never ran a business of the sort they are trying to run. They are completely lost as to the basics, not because they are incompetent, but because they have no idea what to do. Just because you are a customer of a business doesn't mean you can run it.

2. Solicit feedback from, and listen to your employees. Your employees usually know a lot about whats wrong with a business.

3. Understand the key drivers of your business. What is your customer really buying ? What are your cost and price drivers? What should your staff be doing ?

Stupid Interview tricks

I've been doing a lot if interviews lately, and I have had the opportunity to see a lot of mistakes. Here are some of them.

• Putting stuff on your resume you can't support. Be prepared to give examples/descriptions/details of EVERYTHING you wrote on your resume. Its likely that we chose to interview because of some of those things, If you didn't do them, your probably out.
• Not being able to answer the 'strengths and weaknesses' questions. Yes it is a trite question, but we are going to ask it, so have an answer. If you can't answer that question, all it shows is that you are not prepared.
• Its not about you. We want to know what you did to help your former company and co-workers, not what you did to help yourself.
• Don't come in without doing some research on the company, the more the better, it shows you care. 
• Don't badmouth former employers. We don't like to work with bitter people.
• Don't say stuff like my passion is [something not related to the position you are interviewing for]. We want people passionate about the job we are interviewing for.

I Hate Best Practices

Definition of Best: That which is the most excellent, outstanding, or desirable. (Google)

I don't hate the concept, just the term. Best implies that there is none better, and that therefore it should always be used.

So this means that we should all use this practice. (It would be stupid not to if is the best). Of course this would mean we would all be doing the same thing there would be no competitive advantage.

Besides is there really such thing as a singular best way to do anything ?  If there was, than we would never have to improve upon it. I do believe that leaches were a 'best practice' of medicine in the middle ages.

Ok, so all you Best Practice people are going to tell me "No that's not what we mean, we mean that these are good ideas to look at, to see if you can apply some or all of them to your situation."  So  you are saying  they are not the best. But I guess that good-ideas-to-look-at-to-see-if-you-can-apply-some-or-all-of-them-to-your-situation  practices is too long to put on a business card. They were best somewhere for some period of time so we will just call them Best Practices even if its inaccurate. Besides it will sell more consulting hours anyway.

Who needs clarity in communication.

Thank you Ted Neward (@tedneward) for helping me solidify this train of thought.

Fixing my fence, the ITIL way

I just finished ITIL Foundations training, and wanted to detail how I fixed a fence problem this morning in ITIL Terms:

1. Event--> Dogs barking outside.
2. Alert --> Dogs shouldn't be barking this early .
3. Incident Created with service desk --> Dogs shouldn't be barking this early.
4. Incident Troubleshooting Dog is outside the fence, Fence SLA violated ('5 Nines' Dog Containment)
5. Incident Priority Critical.
6. Transferred to Problem Management.
7. Problem Management identifies a work around --> Put the the dog in the house.
8. Problem Management communicate the work around to service desk to communicate to customer.
9. Dog is put in the house.
10. Since the Fence is a VBF and the SLA is being violated Problem Management convenes the ECAB
11. Problem Management identifies the problem and suggests a solution  --> Fix the section of the fence that dog breached.
12. The ECAB Approves the change and transfers it the Technical Operations.
13. Technical Operations fixes the problem.
14. The Change is noted in the CMDB (My Wife).
15. The Service Desk is notified, they notify the customer.
16. The dog is let back out.
17. During Post incident review by CSI, it's noted that fence inspection should happen more often.

Does Microsoft Really Understand Tablets

Microsoft's Surface tablet is the company's attempt at re-defining their business in the wake of  the changes to the PC market caused by tablets and smart-phones. At first glance, the Surface is a nice piece of hardware with an innovative new operating system and some neat accessories. But, when I looked deeper I found two things that made me question whether Microsoft truly understands that the tablet market is about content consumption and communication.

First, there are no versions of the Surface with a cellular modem. If you use a tablet on the move you know that you need the Internet, without it your tablet is just a great way to play solitaire. You can't consume content without access to the internet  You can't update your status without access to the internet.

Second, a keyboard is sold as a recommend accessory. Laptops are for typing, tablets are for checking the news and  your social networks. Tablets are for typing short replies with the tablet in your hands not on a table.  Even the commercials show the Surface on a table looking like a little laptop. I've never seen a commercial for any other tablet (Android or Apple) where it was being used with a keyboard. Why, because they are not little laptops, they are content consumption and communication devices.

The Surface was designed to be showcase for the functionality of Windows RT, as such I have to assume that the design choices made by Microsoft were made very deliberately. Those choices show that Microsoft is still looking at the world through the model they find most comfortable -- the PC -- at their own peril.

Weekend Reads 11/2/12

Killing the Computer to Save It

Welcome to Windows Phone 8

XML, Just Say No.

I don't like XML.  While its goal was to be be both machine readable and human readable, it does a poor job at both.  Its way to verbose. There are better alternatives like JSON  or just plain old text.

Everyone is an Entrepreneur

I've had the opportunity to travel to Jamaica frequently over the past few years. I have found it a wonderful place with wonderful people.  If you are not familiar with Jamaica, it's a poor country with a socialist leaning government.   In order to survive, though, I've noticed there are lots of enterprising individuals who are entrepreneurs. There are the drivers, own vans to drive around tourists; there are the merchants who retail tourist 'trinkets' by the side of the road;  there are the craftsman-peddlers who sell custom carvings; and there are the boat captains who run tours. Most of these folks probably didn't  wake up saying "I want to be a entrepreneur", more likely they said "I want to eat."  None of them came up with blockbuster ideas, they just filled a need. They are not billionaires with public companies, but they make enough to survive and even grow their businesses. No one told these Jamaicans that they were or were not the right 'type' to run a business. Don't let the society tell you what you can and can't do, because if these folks can do it without benefit of formal business educations, venture capitalists, and government programs, so can you.

Professional Development

I've been working in IT for more than 20 Years. I never intended to do the job I do. I graduated College in 1989 with Business Degree, with every intent of going into some type of sales, then business management. In fact, at that time there were very few degrees in IT outside of engineering. There were  fledgling MIS (Management Information Systems) programs, but what they were teaching never appealed to me.  I ended up in IT because of circumstances outside my control  and a knack for being able to figure out computers and programs.

But one thing that is obviously missing is formal education. For a long time, I figured that formal knowledge really wasn't that important ,as long as I could do my job. Recently, I've concluded that my knowledge is more spotty then I had imagined, And I have begun to to try to fill in the blanks. To be able to talk with my peers, I need not only to know how to do the job, but also the terminology.  Frequently, I have discovered, there are tools and methods that I wasn't aware of, that could have helped along the way, had I actually gone to a class on the subject sooner. I've worked hard recently on professional development,  because I need to fill in the holes.

Don't skimp on professional development, especially if you are a product of early days of IT. You may have a lot of experience, but there are most certainly holes in your knowledge.

The end of paper as we know it.

Back in the '90's there was lots of talk about "going paperless", a utopian vision of a world where we no longer used paper, notepads were passe, and file cabinets were for suckas. That never happened. We still have notepads, laser printers, and lots of file cabinets. But the role of paper has changed since the digital age came upon us.

Since the 13th century paper as been used for record keeping and communication.  Paper has some very unique properties  made it successful for 700 years. It's light, cheap, easy to add data to (writing), data can be retrieved easily by anyone without special equipment (reading), and its durable. These properties made it the go-to method  for record keeping and communication. Its biggest disadvantage was that if you want to see the data, you have to go to it or have it brought to you.  Reports were written on paper, if you needed to collect metrics, someone reviewed the paper, made calculations and wrote it on a new piece of paper. Paper was so important to the successful operation of society, that the governments created agencies to transport paper under protection of the law (postal service), and other laws to protect content (copyrights).

Enter the late 20th and Early 21st century. The ability of computers to process and disseminate information have relegated data that used to be stored on paper to databases and file systems. Information  that used to be disseminated on paper is now transmitted digitally. 50 years ago business records like invoices and customers data were stored in file cabinets, now they are stored in databases. Paper is not just another method to display content.

While this revolution has allowed us to make great advances in almost every field of human endeavor, it has also led to new challenges. Age old institutions are searching for relevance (the postal service); hundreds of years of legal precedents no longer are relevant (copyright). Most importantly, since access to data is governed by technology, as that technology progresses we run the risk of loosing information forever.

We are moving into a new age, we need to start thinking about how we will manage data for ourselves and future generations.

It's The Data, Stupid

I saw a tweet a while back that went something like "I can't believe people still use data-centric design".  It's been festering in my brain and has inspired this mini-rant:

I'd like to remind everyone, that the reason we write, software,  mobile apps, and even have the Internet is so we can provide information (useful data) to users. Social media isn't about the interface its about the data, the interface just improves access. E-commerce is about moving item data to the customer, and order data to the vendor. This blog is about  the information I provide, not the layout.  If we loose site of the data, all we end up with is eye candy. 

Modes of Thinking

Linear Thinkers. Use if A then B logic.  They handle structured and known problems quickly an well. 

Spacial Thinkers. Look at the entire issue, analyze causes and options, to come up with the 'best' solution. They solve structured problems a bit slower, but can solve complex problems quicker than others. 

Chaotic Thinkers. Get distracted by some element of the issue and solve a different problem.  They are able to solve problems that have not been defined yet. 

Examples

A linear thinker walks into a dark room and flips on the light switch. 

A spacial thinker walks into a dark room and observes that it's dark, this may mean that the ligh bulb blew out, the power is out, or the light switch is off.   She takes a metal inventory of light bulbs and flashlights.  Then she flips on the light switch. 

A chaotic thinker walks into a dark room , it  reminds  him of his youth when he used to develop photographs ( old school) in a darkroom. He turns around gets his camera and takes some photos of local landscapes.    He later hangs the photos on a blank wall in the currently dark room. 

What kind of thinker are you?  

6 Reasons to use a SQL Database

There is a lot of hype about NoSQL databases. These databases provide solutions to problems that traditional SQL RDBMS's can't, and they are 'new and shiny'. While these new tools are drawing a lot of attention, I'd like to review the case for the traditional SQL RDBMS.

1. They abstract data the way that we would store them without  a database. A ledger is like a table, an invoice is  a one-to-many relationship. They are easy to understand and apply to real life situations.
   
2. They are structured. Since each row in a table has the same structure, you only have to write one 'piece' of code to deal with it. Less code means faster development times, and less bugs.
   
3. Static Data Types. Each column has a static data type (Or should anyway) so programs don't have to worry about data validation when retrieving data. This means less code too.
   
4. SQL. They all run a dialect of SQL which cuts down on the programming learning curve.
   
5. They are reliable. ACID transaction handling means that there is less chance of data corruption. And we all know corruption is bad.
   
6. They are mature. Oracle and DB2 have been around for over 30 years, SQL Server for more than 20, PosgressSQL more than 15. Most of the bugs are out of the system, and there is a lot of documentation available. 

Don't jump into the NoSQL pool, unless you need too. SQL RDBMS's still provide the an excellent solution to most data storage and retrieval issues.

Valid vs Accurate

If I were to tell you to guess my electric bill from the following two choices, $146.78 or $150.00, which would you chose? I'd bet the a majority of readers would chose the former rather than the latter because it wasn't a 'round' number, and what are the odds that an electric bill would be a round number like 150. Of course the truth is my electric bill is just as likely to any number with a reasonable range as any other, but that 150 doesn't look right, why, because it looks inaccurate. Why does it look inaccurate, well because it doesn't appear valid. But in reality you cant assume a value is accurate because it appears valid.  In fact, you you need to separate the two concepts from each other when you look at data.

Validity in terms of data, means that it fits fits the definition for a particular type of data, for instance, in the case of US dollars it is a decimal number with two places of precision after the decimal point, an US phone number with area code is minimally a 10 digit integer. The other notable  property of data validity is that it can be checked with a self contained rule, there is no need to compare it to outside data.

Accuracy, on the other hand, means the data is correct. For instance, the actual value of my electric bill. Accuracy has to be checked by comparison with an outside value, so accuracy checks cannot be self contained. While accurate data is usually valid it does not have to be. If my actual electric bill was 150, it could conceivably presented  as in integer instead of a decimal thus making it invalid.

When dealing with data, make sure that you deal with validity first, followed by accuracy. This is especially true with weakly typed languages and variant data types.

Getting out of your programming comfort zone

I've been working with  with TSQL (MS SQLSERVER), lately and 'learned' a lot about it recently. Don't get me wrong, I've been writing sophisticated SQL reports for more than 10 years, and I know a lot about SQL and I'm quite familiar with it. But that's what I was doing writing  reports. 


As you may know if you are writing a basic report there are three key parts of a SQL statement the SELECT clause, where you output goes, the FROM clause where your table and table relationships go, and the WHERE clause where you choose what data you want to display. (Yes, I know there's ORDER BY, GROUP BY, UNION, etc, but I'm trying to make a point not teach anybody SQL.) What I have discovered is that I've been subtly trapped in this paradigm. If it needs to be output its in the SELECT clause, if it needs to be chosen its in the FROM clause, I may nest SQL statements, but in the end I'm stuck in this single statement framework

I've been able to continue on in with this narrow perspective because, if I may say so myself, I'm pretty good at improvising and finding work arounds, so why should I try something new (its not like I don't know about this stuff), when this works. And besides multiple statements, table variables, where loops, if-then statements, and the like are for something more sophisticated than just reports. And doing it this way does work, but sometimes it's slow, confusing, or just downright frustrating. This week I got past that and wrote a report  with multiple statements, table variables, a where loop, and an if-then statements, and it was quite enlightening. I'll never look at SQL the same way, and hopefully I'll remember that there may be more to whatever language I'm using at the time then what I'm working with now. So, perhaps I should climb out of my comfort zone and  look around.

P.S. Yes, I'm know I'm a geek because I get excited learning new programming language elements.

A Little Data Validation, Please?

I've been working on an implementation where part of the process is importing about 2 million lines of  data using a tool developed by the software vendor. A large part of their data is stored in the database as a sql_variant (dynamic data type). Once the data is imported , the program processes some of this data and expects a specific data type. Unfortunately there is no data validation during the import process, so, when a bad piece of data gets into the database you get a nifty cryptic error line 'unable to convert nvarchar to int'. (Better error  messages would be nice, too.) The root cause of this problem, however, was ignoring data validation. When you use dynamic data types you have to do your own input validation, you can't count on database or the user to do it for you. I know this is very obvious but apparently it was missed in this case. Because of this the database is currently unusable, and someone will have to spend a significant amount of time figuring out where the bad data is.