On a related note, in an article on February 7th from VentureBeat about Microsoft potentially cleaning house to make room for more technologists on the Executive team, this particular quote from an Analyst in the article resonated with me:

“You see the engineering team ascending because Steve is realizing that there is a need to execute on a vision and in order to do that you have to actually understand how software is built,” said Wes Miller, an analyst at the Kirkland, Washington-based research firm Directions on Microsoft, in an interview with Bloomberg Businessweek. “It’s a whole other thing to be able to say, ‘I’ve been at Microsoft, I understand software, and what you are saying will or will not work.’”

The underlined portion is of particular interest to the Marketing Technologist - in order for Marketing departments to execute on a vision, an understanding of the technological underpinnings for that vision and the end-user experience it delivers is vital.

The Era of the Marketing Technologist

More importantly, you don't have to be a software company like Microsoft to require this expertise. For more in-depth discussion on the topic, read Scott's post on The Rise of the Marketing Technologist.

Making the Case for an Embedded Marketing Technology Team (E-Business)

In my interview, I make the case that Marketing departments should even have their own technology arm - at our organization we call it the E-Business team. E-Business drives multichannel sales, new customer acquisition, brand recognition and loyalty, and customer retention. For more on E-Business, read on.

I was happy to read that Talend secured $12 Million in funding. We've long been a proponent of Talend, beginning in early 2008 completely gutting home-grown ETL and Middleware applications and processes by leveraging the open source tool. With quotes on ETL software from the big boys coming in north of $200K, the open source investment (we essentially pay for a "pro" version of the server along with enterprise support -- substantially less than $200K).

There is a place for open source in the enterprise. As development shops seek to be more agile, budget-conscious, and innovative this year, the ability to move quickly and without the sometimes bureaucratic-funding-approval-process is important. "Do more with less" remains an important mantra in '09 in IT just as it did in '08.

We recently completed our first integration with an external customer website and our e-commerce website. (By "integration," I mean an API in which we pass configured product data from our site to a 3rd party shopping cart.) What ensued was an interesting learning experience for myself and our group of developers on the project.

Everybody has their own development process

Standards are hard to come by in the web application/development world and the process for managing development projects is certainly no different.

Case in point: We created a technical specification for an API and worked with developers on our own team spanning 3 different time zones. Add on top of this that our technical specification was an "ideal world" document which didn't account for specific requirements of the external website we were to interface with. This meant further coordinating our simultaneous development of our API with the integration of the API (as we were building it). This essentially equated to "building the plane as we flew it."

Agile development is great...but falls flat on its face when involving people outside the core team

In an agile software development world, code is written, tested, and released in several mini-stages. This methodology allows for us to be very open, flexible, and speedy with new development on our various web properties.

However, my takeaway from this project is that I would utilize a different approach when interfacing with external developers that are not part of the core team...taking me back to my agency roots when educating our clients about "our process." What we found is that our process didn't at all align with the customer's process for development, testing/QA, and release management. In fact, it caused a lot of tension between the two groups throughout the project -- especially in the home stretch.

Where we normally operate in a lean environment with small release gaps and short testing periods, the external party we interfaced with was accustomed to a more traditional waterfall model of building the entire application up front, test all of it at once, and going through several iterations of testing & debugging of all code at the very last stage.

Lesson learned: Provide a visual map of your process and timing

Multiple lessons were learned on this project:

1.) Provide a "site map" of the intended integration. This allows business stakeholders to visually understand where the API "handshake" occurs between the sites. It also empowers the external QA team to understand the bigger picture so they can see which areas need testing.

2.) Provide a map of the major components of the development project, timing on each, and the order in which they will be developed. Seems simple, but when you don't manage the external developers, keeping tabs on the timeline proves difficult.

3.) Schedule regular daily meetings to check in on status and even if there's no updates to report, it provides a crutch for the collective team to lean on so everybody remains on the same page (in terms of timing & expectations). Morning meetings are important so the day doesn't get away from either party. This is particularly helpful in the final weeks/days of the project.

The B2B benefit

The API allows American Blinds to effectively "shake hands" with our product configurator enabling online ordering of custom draperies from Levolor without having to do any product programming. This enables us as the manufacturer to focus on effectively managing the hundreds of billions of configuration possibilities with our custom product lines while American Blinds focuses on the marketing of the products to their consumers -- essentially the best of both worlds.

Here are screen shots of the experience:

The American Blinds Curtains & Draperies landing page:

The Levolor Draperies landing page on AmericanBlinds.com:

Now entering the Levolor.com product configurator:

The completed configuration passed back to the American Blinds shopping cart via the API:

The American Blinds checkout process with a Levolor configured product sent via the API:

The B2C benefit

The benefit to consumers is a seamless experience as they are passed unknowingly from server-to-server with no interruption in navigation. To them, it is like picking up another product sample book in the store. At the time of purchase, regardless of products they have in their cart, they still go through the same checkout line for a completely seamless purchasing experience.

In the link above, the same is true for the airline industry. It's as if the entire industry was designed for an ideal world where there are no mechanical malfunctions, bad weather, or delays. Contingency planning and business process optimization go such a long way to improving operational efficiency and most importantly, customer satisfaction. Revisiting pre-existing processes is also a great way to find the low-hanging fruit of improvements.

When building any new business process or system, I find that the following question is helpful to ask over and over during the planning phase: Does this process add value for the end-user?

Such a simple question can go a long way to avoiding a situation like in the above post/link.

A recent article on MarketingVOX about Apple's plan (or lack thereof) for Flash video support offered interesting insight into the relationships of high-profile companies. In another article about Steve Jobs himself, there's background on the CEO's "my way or the highway" mentality. In related articles about the strain between Adobe and Apple (actually, the strain appears to be between Adobe and Steve Jobs), I wonder what the reality of Flash on the iPhone would be if Adobe and Steve Jobs played nicely and were "best friends?"

There's a lot of finger-pointing if you read through the articles...and perhaps the sour relationship is justified. I often wonder how many other kids there are in the proverbial sandbox of corporations who also aren't playing nicely.

The Open Source Dilemma
I'm an enthusiastic supporter of open source applications and development. However, without proper documentation of home-grown applications, the cost savings up front of an open source deployment will eventually come back to haunt you down the road when those original developers leave. This is the exact position we are in. While it won't be damaging to the organization, it will create a rather steep hill for the new developers to climb as they dive into the custom code (and lack of documentation).

When to buy or build?
This had me thinking during the first week in this new position -- where is the line drawn between buying software and building software? I have to bring up a saying I use quite often: "Just because you can, doesn't mean you should." I think this is a perfect application for this phrase. I've discovered a lot of the home-grown applications were built as a cost-savings measure and "because we could." That mentality has backed us into a corner today as we scramble to educate the new hires as quickly as possible before the original developers leave the organization.

Don't view IS as a cost center
In talking with the original developers, it seems as if the mentality of the organization was such that IS was viewed as a cost center, not an innovation center. Therefore, an expenses incurred in IS were viewed as negatively impacting the bottom line. As a result, we ended up with a lot of home-grown applications utilizing different languages and database backends. This strategy works if you never plan to migrate to new technology and never plan to advance your developers.

Future-proof your IS strategy: standardize and document
Moving forward, we will begin to standardize on select platforms. We have a series of consumer websites, internal applications, intranet sites, and reporting spread across a myriad of technologies. Our downfall was this strategy (or lack thereof) which resulted in dedicated employees for managing each of the technologies/platforms. Since each platform was different, development was being handled in silos with very little strategy being shared between the silos. It also made us extremely dependent upon the individuals in charge of the silos.

Standardizing on a few select platforms and technologies will enable the proper cross-training among existing staff to be able to support applications in the event of individual vacation schedules, sick days, or departures from the organization. It makes sense from a technology strategy, business strategy, and also in keeping the sanity of your staff. It's no fun for the weight of the world to be on the shoulders of a single individual.

Documentation seems to always take a back seat to projects in any business. In an enterprise like ours where we rely on reports and data feeds from external vendors, corporate IS, and other departments, documentation can save a lot of time and also prevent downtime. We have the fortune of being forced to start with a clean slate with new developers, so our first several weeks will simply involve documenting existing applications and systems.

What is a qualitative survey?
A qualitative survey or study is where you have a small group of participants who you have carry out tasks on your website in a one-on-one setting. This is most often a usability study ran by a facilitator (or yourself). A group of 10 people over the course of two days will give you plenty of data to determine whether or not the design phase of DMAIC was a success or needs considerable work. The point of these surveys or studies is to do a deep dive with each individual spending 60-90 minutes with them understanding how they navigate the site, identifying their frustrations, and determining whether or not they can even complete the task at hand.

You will pick up a lot of small "fixes" from a qualitative study that will add up to an excellent list of incremental improvements you can make. You should also identify any major disconnects the site has in its navigations or the tasks that individuals are asked to complete.

What is a quantitative survey?
A quantitative survey is more about volume, or quantity of responses. These are going to be questions like, "On a scale of 1 to 5, 5 being very satisfied, please rank your overall satisfaction with this website." You won't get the deep dive like in a qualitative study, but you will get a very good overall ranking from a larger group of participants. Usually, you want about 200 responses to be statistically significant in a quantitative survey.

Perform a qualitative study first.
In my experience, I would recommend performing a qualitative study first. If you do a quantitative study first you may see your overall rankings suffer, but you won't really know why. It essentially reinforces the point that you will need to do a usability/qualitative study anyway. The qualitative study is always going to deliver rich feedback that your team can prioritize and execute. This data is so powerful that once it is implemented, the quantitative study should help identify any remaining problem areas. If there are significant drop-off areas or low rankings, you can individually tackle and evaluate these sections.

Structuring the Measure, Analyze, and Improvement phases of DMAIC
Additionally, the use of web analytics to see how these people from the quantitative study are navigating your site is an added bonus. This is how I would structure the these three phases of DMAIC:

1. Ensure your conversion funnels being tested are fully functional and compatible on the platform in which you will be testing.
2. Execute a usability (qualitative) study
3. Evaluate results of usability study, prioritize development and design tasks, and implement changes
4. Integrate web analytics into your site at this time -- the reason why I say to do this here is because your navigation may significantly change as a result of the usability study and any custom integration points you worked on before may need to be redone at this phase. Hopefully, you've got the navigation dialed in at this point and won't be changing too much more than some interface design components at this point.
5. Execute a quantitative study of 200+ participants. If you work for a large company, soliciting employees from other divisions who are not close to your products is an ideal way to do this. Otherwise, a friends and family test will also suffice. The key is getting people to perform tasks on the website who are not familiar with your products. If you have your own employees do the testing, the results will be skewed because they will not be relying on the website for product information -- generally, they already know enough about your products to bypass any pain points the website may have.
6. Evaluate results of quantitative study, prioritize tasks, and implement any necessary changes. You may be able to launch your site at this point while continuing to implement rolling changes based on the quantitative results.

Ongoing quantitative studies (The "Control" phase)
Consider companies like OpinionLabs to implement an ongoing quantitative study for your site. With their software, you can even obtain qualitative results from people from individual pages or sections of your site. This information is powerful and the ongoing measurement of satisfaction of your site will be an important way to continue to improve overall satisfaction and conversions.

Bricks and mortar retail stores do not just put products on the shelf and leave them for eternity. They are constantly trying new end-cap displays, custom product displays, promotions, and adding/removing products to optimize their layouts. Website visitor's usability experience and requirements will also change over time. The same sites built in the late 90's are laughable today. You need to be able to change with the times and this is why the control phase is extremely critical.

In the "Define" phase of web development, this is where you identify the key components your customers need in order to navigate a conversion funnel. This concept can be applied to many types of websites, but here is an example of how this applies to an e-commerce website:

Defining attributes for e-commerce sites
A primary goal of an e-commerce site is to generate revenue. This means you'll need a storefront, the ability to add products to a cart, and the ability to securely purchase these products online. Compatibility and usability issues aside, this is usually a significant area of oversight for many web developers, marketers, and managers.

How would your online store compare to bricks and mortar?
If you think of a bricks and mortar business, you can associate their aisles of products with your online store. Moving further down their path, you will also find shopping carts to hold products and cash registers to process transactions. What many sites fail to realize is the sales component of a store. A bricks and mortar business has the benefit of sales associates who can help customers with questions about products and with how to find products in their store.

Websites lack the human component. Don't just focus on the tail end of your conversion funnel.
Websites on the other hand lack this human interaction, so it's up to the "Define" phase of Six Sigma's DMAIC process to identify the key components that will help drive consumers to the sales funnel. This is typically going to be a product search engine, product comparison tool, and a product catalog (outlining more in-depth information than the online store). If a customer can't figure out your product or service if it were sitting on a shelf in a bricks and mortar store, then don't expect them to be able to understand it online.

Leverage retail environments when building an online experience
If you have an advantage of selling products online that are also sold in retail stores, you can piggyback off of your learnings from the retail experience. What benefit does a sales associate play and what is the process that the associate walks the customer through the conversion funnel? At which point does the associate hand the customer off to the purchasing portion of the funnel? Use this experience and information and convey it online -- it's a necessary feature.

Failure to define the complete components of a conversion funnel will be identified with qualitative surveys
Avoid tunnel vision from the beginning when building a site. Whether it be e-commerce, social media, etc., don't forget that the majority of your visitors will not be experts in the product or service you are trying to sell them or get them to use via your website.

My next post will discuss quantitative and qualitative feedback for the "Measure" phase of the DMAIC process.

What is Six Sigma?

Six Sigma is a rigorous and disciplined methodology that uses data and statistical analysis to measure and improve a company's operational performance by identifying and eliminating "defects" in manufacturing and service-related processes. Commonly defined as 3.4 defects per million opportunities, Six Sigma can be defined and understood at three distinct levels: metric, methodology (DMAIC/DFSSstructured problem solving roadmap and tools) and philosophy (Reduce variation in your business and take customer-focused, data driven decisions).

Can Six Sigma be applied to web development, design, and usability?
This is a very logical question. Yes, it can be applied, but achieving it is another issue altogether.

Pulling from Jakob Nielson's November 2003 post, Six Sigma engineering relies on a five-step process called DMAIC (Define, Measure, Analyze, Improve, and Control). He was really ahead of his time in this article. A google search does not pull up much information on applying six sigma to web development, design, or usability. This tells me the concept has not been discussed too much and it makes sense -- the web is still in its infancy, and the more experienced developers within organizations today are now moving into upper management where they are beginning to look at the website from a higher view within the company.

As the web becomes more of a vital tool for most businesses today, upper management (who often times knows little about how exactly a website goes together or how to build a successful site) is seeing the value in applying other business practices and methodologies towards the design, testing, and execution of their websites.

Why Six Sigma is difficult to achieve in web development today.
In manufacturing, the amount of variables encountered in an assembly line is not as vast as a complex website. Manufacturing doesn't deal directly with consumers, either, and the manufacturing process has very strict processes and tolerances for how things are assembled.A website is dynamic in nature and also navigated and operated by your customers -- customers who may not know a thing about your product and have had no training on your website. Manufacturing lines are staffed by duty-specific workers, trained to perform specific tasks accurately and efficiently.

A website on the other hand can be navigated in millions of different ways and combinations by millions of different people. Testing each of these combinations is impossible and will result in you testing your website into eternity without ever releasing it to the market. Add on top of this a team of people who are most likely very diverse in their backgrounds: developers, designers, and marketers -- each come with their own education and experiences and often time have no visibility into what their other team members' job responsibilities really entail (how many developers do you know that can truly do graphic design? how many designers do you know that can write complex database queries?).

Accept the variables in web development, and apply the concepts of Six Sigma
The key is applying the Six Sigma mentality to web development, design, and usability so you can get the best balance of accuracy and conversions. The problem most developers and designers have is that they get "tunnel vision" and focus exclusively on just one piece of the entire web application. This is a problem for any type of site which has multiple conversion funnels (sales, registration forms, contact forms, etc.).

Next Segments:

1. "Define" in the DMAIC process

More on this topic over the next several days as I cover each phase of the DMAIC process in individual blog posts in an effort to keep the posts spread out and on-topic, rather than one long, rambling post. I'll provide links at the end of this post as each phase of DMAIC is evaluated.

Freelance, Independent, & Small Business Developers, take note
You or your developers may be the best thing since sliced bread, but if you find yourself working with another team of people with similar skillsets (i.e. developers) as you, learn to properly service your client. I am currently involved on a project where I am dealing with 6 separate vendors, all of which handle individual parts of the project, hand data from one to the next, and are really at the mercy of the talents of everybody else. Due to the volume of work and the timeline, it would be impossible for one person to handle the workload. Additionally, the nature of the project has been that of scope creep, which means where we started over a year ago is many times different than where we're at today.

Diving into someone else's code is very easy to do -- and it's just as easy to point out holes in the code that you may see at an initial glance. Unless you're being hired to do this, I would advise against making it a point to belittle or criticize the work of others during the project.

If you see a problem with someone else's work, learn the "how and why" before jumping to conclusions.
A good developer is one who can develop code on their own time, quickly, and efficiently. A great developer is one who can develop code with others and work quickly and efficiently with others. The biggest piece of wisdom I can pass onto developers who own their own company or who freelance is to be a great team player, and be sensitive to your client's (in particular, the project manager's) needs. There are good times to point out faults in someone else's code, and there are bad times as well.

Any project manager should be open to hearing of issues about someone else's work. However, keep in mind, particularly in the programming world, there are many different ways to accomplish the same thing. Since I'm a "car guy," I always like to
relate my experiences back to automobiles. Look at a Ford Mustang vs. a Dodge Charger. One engineer may say, "Wow, that Charger sure is slow compared to the Mustang. What a joke!" Another engineer may say, "That Mustang can't seat 4 people comfortably. What a waste."

The moral of the story is these two vehicles, at their highest level, perform the same function: transport people from point A to point B, and back. This scenario can also be applied to application, web, and database development. Knowing the intended use can save you from an embarrassing attack on someone else's code. Optimizing a database is next to impossible without knowing how and why it's being used. It's wise to learn the how's and why's before jumping to conclusions. In the end, if you do find a flaw, by all means, point it out -- but only do this after doing the proper investigation. Blanket statements like "that's bad design" offer nothing positive to the team, the project manager, or your image as a vendor.

You may want to build a Mercedes, but all your client needs is a Honda.
I cannot stress this point enough. It is very frustrating to specify project requirements only to have a "know-it-all developer" explain reasons X, Y, and Z for why it should be done another way. Theory is great, but it's just that, theory. The real world, budgets, time constraints, and project scope sometimes mean breaking theory. The sooner you accept this, the better you will be at servicing your clients. Learn to provide the best balance of value and insight when working on a development project with your client. They will come back to you again and again if you work with them, not against them. Your clients are very busy with other projects, too, they don't want to have to feel like working with you is time-consuming, and they certainly don't want to explain themselves. They may even be wrong! At the end of the day, you need to be creative with how you shape your message to the client so that they aren't offended.

No news is bad news.
Never assume that because you haven't heard anything that it means there's nothing for you to do. Great client service means checking in with your clients when you're inbetween projects, in the middle of projects, or just because. Be there for them, make sure you are meeting their needs. The last thing you want is to deal with fires that could have been prevented if you'd just spent an extra 15 minutes to check in with your client.

Obviously, you'll need to weigh your time between clients. The clients who are spending more money with you should get more time devoted to them -- in terms of hours worked and client service. Don't take their money for granted because they can easily find other vendors. As good as you are, these days, it's easy to find developers who have the right programming and client service talents.

Old cliche: The Customer is Always Right
There is nothing worse than arguing with a vendor. It is a pet peeve of mine when a vendor questions the way something needs to be done. Keep in mind that your clients know their business better than you do. You are there to offer a supporting tool to their business needs, not a tool that defines their business or defines how their customers shop their products. This is a very important distinction. This is sometimes a difficult concept if you work with a new client that does business in a different industry than you're normally used to. Beware that you'll need to approach projects like this with more of an open mind, particularly if you're dealing in the consumer realm. Consumer behavior varies considerably between industries/markets and just because it's one way in market XYZ, absolutely does not mean it's the same in market ABC. Leave that up to your client to give you this insight. They'll know their customer best and should be able to provide this type of insight to better arm you as you dive into your code.

Client Service is critical to your business
Create value for your clients by providing excellent client service. This is one of the intangibles that's hard to see when viewing a resume or a company profile online. Great client service will keep your clients around for years to come. This will further solidify your company's position as a vendor with your client's organization. Don't be afraid to check in on a regular basis to "babysit" your more valuable clients. This will pay off in the long run. We like to feel important (even if we don't have a current project with you!).