Jon DiPietro is Domesticating IT

Do You Speak “Geek”?

Published on March 27, 2008 by Jon DiPietro in Best Practices, How To

Or perhaps more importantly, should you? I want to explore the very common situation of a manager or small business owner who does not “speak geek” and needs to outsource a software or web development project. I was recently asked by someone in such a position what the “best way to talk to a web developer” would be, since their requirements discussions were ending up in what he described as “Babylonic confusion,” hoping to find a book or course he could take in order to be able to better communicate his needs to the developer.

I don’t know that anyone has found a real live Babel Fish yet, so you’d better figure out another way to get your point across to the geek(s).

It’s Not Me, It’s You

At a moment like this, it’s time go and get yourself a new developer. The project is doomed to fail. While it is your responsibility as a project manager to clearly articulate your requirements, it should only have to be done so in your own comfort zone and business terminology and not involve learning a new language. Here are some inherent problems with taking this approach:

First, this assumes there is a single language to be learned. There are typically multiple technologies involved in any project (e.g. database, server operating system, programming language(s), scripting language(s), hosting platform, external API’s, etc…) and hoping to become conversant in all of them is going to take an incredible effort at best and is futile at worst.
Second, merely speaking the language is not enough and could, in fact, exacerbate the problem. The reason is that there is such a thing as “knowing enough to be dangerous”. Without experience in architecting a solution, talking about the technical aspects of a solution is premature. It would be like specifying what type of tires you want on a new car before even deciding whether it will be a sports car, sedan, or SUV!
Third, this leads to the real possibility that you will end up with what you asked for and not what you wanted. This is quite common in software development. It’s something like asking for a “kick ass” sports car and then getting a car with a mechanical arm on the front of the car with a boot mounted to it. It may be what you asked for, but it’s not what you wanted.

Tell Me What You Want, Then I’ll Tell You What You Need

I’ve sat down with users many times in requirements meetings and asked them what they want the system to do. Often, they find it very difficult to answer because there have not been any boundaries or parameters established for them. It’s like when my wife asks me, “What do you want for dinner tonight?” When I’m feeling particularly sarcastic, I’ll say something inflammatory like “How about Peking duck with an orange glaze and chocolate soufflé for dessert?” and then run for cover. What I’m actually saying is, “What are my choices? What are the parameters? Are you going shopping or do we need to find something in the fridge? If so, what do we have? What about take out?” You get the picture.

When you alter this scenario and instead put a prototype or screen shots in front of users, then you’ll get bags and bags of feedback. That’s because the parameters have been set and they can visualize the inputs, the manipulations, and the outcomes. In the end, that’s what information technology is; stuff goes in to a box, something happens to the stuff, and new stuff comes out the other end. It’s all about defining the inputs, the manipulations and the outputs. But that still doesn’t answer the fundamental question here. How do you deal with a contract developer who doesn’t get it? I’ve already said you go and get yourself a new one. But how do you make sure the new one will work out differently?

Tell Me Something I Don’t Know

Developing a software application is a lot like building a house; it’s the design, architect, build process. You’re the designer and ideally you’d like to find the architect and builder in the form of one person. As a last resort, you are better off hiring both if you can’t find one person to do both jobs. And remember this – you’re a designer, not an architect and certainly not a builder!

The bottom line is to try to find someone with experience in the business arena in which you operate. If you’re the owner of a small chain of sandwich shops, don’t just hire someone who’s developed a web site before, try to find someone who’s developed a web site for a restaurant. And not just one restaurant; a chain. Experience is golden here and there is one rule of thumb that I also mentioned in an earlier blog (Yes, Virginia, You Need a Web Site). When or if you find a developer who can tell you something non-technical about your business that you didn’t know, then you know you’ve got yourself a winner.

Yes, Virginia, You Need a Website

Published on March 12, 2008 by Jon DiPietro in Best Practices, Tech Trends

To web, or not to web, that is the question. Whether ‘tis nobler in business to suffer the slings and arrows of outrageous consultant costs or to take arms against a sea of technological doubts, and by opposing, end them.

Since recently becoming active in the LinkedIn question and answer section, I’ve seen no fewer than four questions in the span of one week asking “Do small companies need a website?” and various derivatives thereof. Most of them were asked by incredulous marketing consultants who obviously run into prospects and clients who do not have one and/or don’t feel they are necessary. My $0.02 = they are as necessary as business cards, only cheaper!

I see lots of advice from professional designers and marketing consultants about leveraging technology, search engine optimization, brand identification, consistency of message, etc… Which is true enough in many circumstances, but I feel that advice like this partially responsible for discouraging small businesses from commissioning a web site. The other (and likely far more common) reason is ignorance of just how quick, easy, and inexpensive it is these days.

Why!? Why!?
Before a discussion of exactly how quick, easy, and inexpensive it is to get a web site up and running, I can hear the “professionals” tearing clothing and ripping hair from their skulls as they scream, “Noooooo! But what about x, y, and z?!?!” Where x, y, and z represent any web design or marketing catch phrase you care to insert. I even saw one designer advise a small business owner to make sure that any designer they select does not use tables for web page layout, or they would be sorry! While there is sound theory behind this advice, it is precisely the sort of technological hyperbole and cart-before-the-horse advice that paralyzes small business owners. My short answer is, “All in due course.” But let’s get this beast domesticated right now with a little more detailed answer…

I don’t mean to make light of the legitimate points made by professional web designers and marketing consultants. They are, by and large, valid concepts that are important in the proper context. However, I think that people too frequently equate “minimally done” with “poorly done” and I submit that they are very different. With that in mind, I’ll suggest three stages of web presence that can all be done either well or poorly, but the amount of money spent will not be a factor.

Stage 1: The Online Business Card

FunnyBusinessCard Yes, Virginia, You Need a Website

That sounds pretty simple, right? In this stage you expect no more from your website than you would from a business card; your company’s contact information and logo along with a quick blurb about what you do and/or what your mission is. The key thing about a business card is the “leave behind” aspect; that you can give it to someone for them to reference later on. Browser bookmarks are the Internet equivalent in this case. If I want to remember your company for some reason, I’ll slap a bookmark to your website in the appropriate category.

Obviously, an online business card can be done well or poorly just like an ordinary business card (I’ve seen some pretty hideous ones). The key here is to keep it simple and visually appealing. For many companies who believe they don’t need a web site at all, this is likely about all they need. And as for that argument, I can tell you two things about my personal approach to finding something I need. First and foremost, if I can’t find it on the web then I probably won’t find it. If your product or service is not on the web, then your competitor’s probably is and you lose. Keep in mind here, I’m not talking about looking for a “high volume widget supplier” or world-class patent and trademark litigator. I’m talking about finding a plumber, dog sitter, yoga instructor, or wedding photographer. Second, if you don’t care enough about your business to have a web site, then I don’t feel like it’s a “legitimate” business. That’s just a personal bias I have, but I think it is becoming more and more common.

This stage is absolutely a “do it yourself” candidate. As an example, GoDaddy.com has a service called “Website Tonight” that gets you a hosted web site with web templates and authoring tools plus a list of features too long to list here for $4.99 per month. All of the web hosting companies offer similar products that allow you to get a web site created literally in minutes.

Stage 2: The Online Advertisement

This is the stage where a small business owner who is not a) technically savvy and (emphasis on the word “and”) b) knowledgeable in marketing will need to get some help. This is not to say that it necessarily needs to be fully outsourced and professionally designed, but it will be important to make sure that certain basic principles of web design and marketing are followed. The goal of a Stage 2 web site is to actually advertise your product(s) and/or service(s) and convince the visitor to take some follow up action.

This may or may not be a “do it yourself” situation, depending upon several factors, none the least of which are the company’s expertise as just discussed. Other factors include the complexity of the product and/or service, the volume of traffic, and technology required (if any) to deliver the message (e.g. streaming video, flash animations).

Stage 3: Launch
This final stage transitions the web site from an information server to an active lead generation and business development tool. Its goal is not just “to be” or even simply to provide a compelling call to action online. Rather, the goal is to generate an online presence that includes a web site. I’m not going to say very much about this stage for a couple of reasons. First, the whole point of this blog was that most small businesses don’t realize they only need stage one or two. Second, it’s a subject that can take up an entire (virtual) library. Third, there are many bloggers out there with much more expert advice on the matter than I could give.

Conclusion
In summary, I don’t accept that a simple, template-based web site is worse than no web site at all. However, that’s not to say that a poor web site is better than no web site, because I don’t believe that is true. It’s important to follow the Hippocratic Oath here; first, do no harm. Aside from the obvious advice of not making glaring mistakes (i.e. spelling, factual, copyright violations), it’s important not to bite off more than you can chew. For example, don’t put a news section on your site if you aren’t going to update it frequently. And don’t ever, under any circumstances, use the words “under construction

People Versus Process

Published on March 8, 2008 by Jon DiPietro in Best Practices

Today I answered a question on LinkedIn regarding a fledgling company’s pursuit of a software development firm in order to commercialize their idea. I was fascinated to read the other answers, which predominately focused on the process whereas I focused on the people. That’s when it struck me…

People solve problems, not processes. I know this sounds like I’m trying to make an obvious observation sound like some brilliant and ironic commentary on mankind. But after you’re done rolling your eyeballs, hear me out.

Throughout my career, I’ve been dismayed and disappointed to encounter regularly customers with huge software development messes left unfinished. Incidentally, that’s not to say that I haven’t been responsible for any. Like everyone else, I’ve learned from mistakes and improved over the years. But as I consider the landscape today and assess how it is that organizations continue to struggle with domesticating the IT animal, it seems to me that many of them confuse people with process.

I see evidence of this in the job market for contract software developers nearly every day. To begin with, there is typically a lengthy and detailed list of requirements for expertise with this language and that technology. Next, candidates are frequently subjected to pre-screen quizzes and online assessment testing to determine their knowledge of programming minutia. My contention is that this only confirms the process and not the person. In other words, the person can string together these particular commands without referencing the help file. Ergo, they must have done this before. Ergo, they are a knowledgeable programmer.

Another example is the reliance upon and prescription of complicated specifications and/or rigid methodologies. Don’t get me wrong here; I think standards and best practices are a good thing. However, rigid and complicated processes tend to prevent people from seeing the forest through the trees, as the focus necessarily shifts from the project’s goal to making sure we didn’t skip step number 12 in section 2 of the first volume of the third edition of the Hitchhiker’s Guide to Project Implementation (with apologies to the late, great Douglas Adams).

If it sounds like I am not sympathetic to the plight of project and hiring managers, I am. If it sounds like I am condemning the use of accepted methodologies or detailed specifications, I am not. What I am saying is this. Most of the time, a great process will not save you from bad people. But most of the time, great people will save you from a bad process.

It is rare that major undertakings in life go strictly according to plan. At which point, I take the advice of on Gunny Sergeant Highway from the movie Heartbreak Ridge; “You adapt. You overcome. You improvise.” By their very nature, processes tend not to be adaptive or improvisational. This is where the problem solving skills and experience come into play and the “blank sheet” guys and gals earn their pay.

What is a “blank sheet” person? In my experience, employees can be categorized in two ways depending upon how they react to being given a blank sheet of paper; those who are exhilarated and those who panic. The former represent good modelers and problem solvers who can turn concept into reality. They are the “problem solvers” and “inventors”. The latter represent task-oriented, linear workers who can take a set of inputs, effective use their tool set, and stamp out results. They are the “doers”. Each has their advantages and disadvantages. Sometimes the inventors are too busy contemplating, designing, and conceiving to actually get any work done. Other times, the doers run out of inputs or break a tool and are stuck until someone shows them a way out. They key is to know how many “inventors” you need (and/or have) and how many “doers” you need (and/or have).

dilbert2008026112009 People Versus Process
This brings me full circle to the impetus for this blog entry. The process of selecting the right software developer or consulting firm to undertake a major project is very difficult. I have walked many of those mine fields and passed the corpses along the way. I am a firm believer that high quality software development requires programmers who have some amount of subject matter expertise. The one nugget of practical advice I’ll offer here is to search for a consultant who can tell you something non-technical about your project that you didn’t already know. Then you’ll know that you have someone who has more to offer than stamping out lines of code. If you ask a user what they want a program to do, they will generally struggle to articulate an answer (it’s a rare and beautiful thing when they can, believe me). When they actually get their hands on something, however, you will not be able to shut them up! They will generally be more than happy to tell you what’s good, what’s not, and what’s missing. The best programmers will know much of this ahead of time and, by all means, be able to adapt, overcome, and improvise. Otherwise, you could very well become one of the many who have uttered the phrase, “You built me what I asked for, but that’s not what I want!”