Archive for the ‘strategy’ Category

A lesson in client servicing an application development project

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.

Business and IT: A Love/Hate Relationship. But why?

As I’ve transitioned from the marketing department as a web marketing manager to the IT department as an application/development manager, to my now current role of senior IT manager, I’ve gradually moved up the food chain of strategy conversations with both the internal business, customers, and vendors. The constant theme in all of these discussions whenever IT is brought up? Resources (or lack thereof) and the roadblock IT is viewed as to growing the business.

Is every IT department eternally busy?

I don’t understand it. Well, actually, I do, but I’ll say “I don’t understand” just to make it sound like I’m in more disbelief than I really am. The underlying theme of every conversation I’ve had with a customer, vendor, or otherwise is that IT is busy and doesn’t have the resources. It seems as if any project requiring IT resources automatically gets held up in the “IT vortex” of priorities. IT departments are really not this busy.

The IT prioritization issue

Something is fundamentally wrong when IT resources are scheduled 9-12 months out. My gut feel is that what the business is being held responsible to do compared to what IT is being scheduled to do is at times, misaligned. This is not necessarily the fault of IT but rather the business leaders (in which IT should have a seat at the table).

From an operations and manufacturing perspective, we automatically know that it’s standard procedure to have a lengthy-but-calculated process for launching new products to the market. Yet, there’s perhaps somewhat less frustration with operations & manufacturing on these timelines compared to the frustration I commonly witness with IT scheduling. How can this be?

The business doesn’t understand IT

Business users simply don’t understand what they can’t see. Operations and manufacturing have the luxury of producing physical products and business users can see the progress of this development and can visually comprehend the effort that’s put into a product launch.

The challenge for IT leaders is to visualize the various IT processes, illustrate how they plug into the rest of the organization, and be viewed as an ally to projects and not a barrier to entry. It pains me to think how many projects are killed in the course of 12 months because IT resources are required.

Business users need a scorecard for IT projects

Business users need help — they can’t be faulted for not understanding IT, their lack of understanding is on the shoulders of IT leaders. Business users need a scorecard to appropriately rate their projects. There will be some things that internal IT cannot do in the amount of time required. But this doesn’t mean “kill the project!” It may mean outsourcing the project to another firm under the guidance of IT.

Unfortunately, many IT shops are one of the following:

  • Run as if all IT-related ideas should be their own. This translates to extended timelines and lost time-to-market as IT puts the stops on a project because it wasn’t “their idea.”
  • Operated under the watchful eye of a CFO. This translates to IT operating under the perception that “spending money = bad”.

What’s an IT leader to do?

  1. Openly share your project pipeline (disguising projects that are sensitive, if necessary). The business as a whole needs to understand what projects are in the pipeline. If they don’t, they will approach you without any context to why your team is so busy — which is a problem.
  2. Openly share the methodology for prioritizing projects with the business users who are submitting the requests. This will help them understand the process so that when they come to you with future projects, they will be armed the right data…and not with a preconceived notion that the project will “take a while” because “IT is always busy.” Knowing the “why” behind project prioritization goes a long way.
  3. Accept the fact that you are not all-knowing. It’s OK for business users to come to IT with a new idea. You’re responsibility is leveraging technology to solve business problems and bringing their idea to life. Without you, it’s just an unrealized idea.
  4. Spending money is not a bad thing. If you report to the CFO, the CFO is not against spending money. The CFO views business differently and is looking at the return on investment (ROI). If you cannot put in requests for money which outline the ROI, then be prepared to have many of your projects denied.
  5. Don’t forget to position yourself as a “go to” person.

Custom Product Configurator API

This month we launched an industry first: we have built a custom product configurator API. We have teamed with American Blinds, the largest online retailer of window treatments, to put the API in production with the launch of our previously-mentioned custom draperies program.

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.

Automatically monitor changes to competitor websites for free

It’s fairly easy to cost-effectively monitor your brand names and trademarked terms (and anything else you’d like to keep tabs on) using Google’s Blog search RSS feeds (and several other aggregator service RSS feeds). When you don’t have the funds (or a low volume of online/blog conversations pertaining to your brand) for a service like BuzzLogic or BuzzMetrics, it’s about as “grass roots” as you can get.

But what if you want to automatically monitor changes to your competitors’ websites that don’t have feeds built into them?

Page2RSS is the answer.

Page2RSS is a free service which creates an RSS feed out of any URL you enter into the site. Their free service creates a cached version of the page every 4 hours. Simply subscribe to the RSS feed and off you go — be the first to know when your competitors update their homepage, product pages within their sites, and so on.

An entrepreneurial evening

I had an opportunity to catch up with a friend of mine this evening over drinks/dinner before he and his fiance move off to Colorado to continue building their online startup: foodzie.com. Foodzie is one of 10 very fortunate and well-deserving startups that will receive seed money and mentoring from some of the industry’s finest all thanks to TechStars.

The premise behind foodzie is to provide artisan food producers with the means for selling their products online with minimal investment. On top of that, foodzie will build a community of “foodies” who will have an opportunity for “one stop shopping” online. Their site will be launching soon (presumably in beta after they settle into their new digs in Colorado) and I’m very excited to see how it will take off.

Not being a die-hard “foodie” myself, my wife and I are certainly more of a “mass consumer” at heart as we purchase based on ease and convenience due to our busy schedules. That being said, foodzie presents an opportunity for even non-foodies like us to indulge in the latest in greatest without having to be die-hard foodies. Whenever business models like these come to fruition and take a complex process, make it simple, and bring it to the masses, it is a recipe for success.

It was a great change of pace to talk entrepreneurial strategy — which is a completely different type of discussion than the day-to-day enterprise strategy discussion.

Good luck to Rob and Emily on their venture!

Pride can hinder innovation

adobelogo.jpg + applelogo.jpg = ?

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.

Building vs. Buying Software

My first week has come and gone (officially) in my new role as eBusiness Manager. Not only is this a new role to me but we are also replacing two people on the team who had previously been in development roles for several years at the company. One is advancing to corporate and the other is leaving the organization. One replacement has been hired and his first week was very challenging, to say the least!

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.

Relationship Management vs. Project Management

What percentage of your time is spent managing projects and what percentage of your time is spent managing people?

As a part of ongoing career development at our organization, we have the benefit of meeting with an outside consultant specializing in coaching leaders, managers, and product teams. The end-goal is to broaden your horizons in the way you approach critical thinking situations related to internal projects and consumer-facing products (ultimately within the team or business unit you are part of).

Relationships management is different than project management
In my one-on-one discussion today, the question was posed to me: What percentage of your time is spent managing projects and what percentage of your time is spent managing people? After I thought about it for a minute, it dawned on me that the majority of my time is really managing relationships, not projects. This doesn’t necessarily equate to direct reports who you “manage,” but simply people/piers who you interface with on projects. It’s an important distinction to make because relationship management is considerably different than project management.

Relationship Management in a large organization
My previous job was at a small business with less than 25 employees (where I worked for nearly 8 years). A larger corporation is different in that you have to deal with a larger number of people (and personalities) to the point where you are focusing on relationship management more than anything. To get any large-scale project done (like a consumer e-commerce site), being able to work with the various departments the website touches is a critical component to success. Taking that a step further and understanding other departments is an important component to relationship management and what separates it from project management.

Managing Relationships is Good for Business
It’s interesting viewing the different styles of project managers in any business. Some are focused exclusively on the tasks of the project and at the end of the day, they measure themselves on their ability to complete those tasks regardless of what it took to get them done. I have seen this lead to major bridge-burning and damaging relationships with individuals/departments. While this may not affect the short-term health of an organization, it certainly does affect the long-term health and the ability to effectively work with each other.

Others are focused on getting what they need to get done while building relationships with other people and departments. Because when it comes down to it, you will probably need their help again in the future. Guess who’s going to be more responsive to helping you out or going that extra mile for you — the person who you steamrolled to get your project completed, or the person who you developed a relationship with? I know I am more inclined to help someone who will return the favor down the road.

Tying it back to online strategy
As online strategists, marketing managers, and even web developers, it’s important for “us” (I group “us” together as the people that build/manage/maintain/oversee websites) to communicate what websites can do for the company and develop relationships with internal departments so they keep the website top-of-mind.

A business that operates with the website top-of-mind values the efforts of the online team by viewing them as a strategic department, rather than a cost center. Strategic departments have the perception of adding value to an organization. Cost center departments have the perception of costing the organization money. Operating under the umbrella of “strategy” is much more healthy (and fun) for everyone involved as opposed to a “cost center.”

Positioning yourself as a “go to” person for your department or team

Recently, a post on the CIO advice and opinion forum posed the question about working your way up the IT food chain. This made me think more about advice for IT, developers, and general “tech” people and how they can break the mold of IT and advance up the department ladder. Some developers or engineers find themselves working for managers who “have no clue.” What they don’t realize is the managers have the ability to work with internal stakeholders effectively and translate business problems into requirements for the technical team to implement.

Here are some examples of how you can position yourself more effectively with other departments in your organization so they look at you as the “go to” person not by just the title on your business card, but by the value you bring to their business functions.

The title on your business card defines what you do, not how you do it
The title on your business card does not always mean you are viewed as the “go to” person for your functional area — I have experienced plenty of people in business who are avoided at all costs due to lack of strategic and/or big picture thinking within an organization or on a project. Your title defines what you do, but how you go about doing it is another game completely.

In IT, understanding the needs of another department is extremely important when they come to you with a question or request. Nobody likes feeling stupid, and this is one area where IT typically falls short — fail to understand the problem, provide short, non-descriptive answers to questions, and allow the uneducated business person to craft the design requirements for a (web) project that makes little sense. This then results in an application or solution that underdelivers due to poor planning and creates a customer (the employee in the other department) who is unhappy.

Picture yourself bringing your car to a mechanic for service…how do you want to be treated?
(This is often times an easy analogy to make, so if you already understand cars, then pick another area where you are not as knowledgeable in and put yourself in the position of that customer.) You drive your car into the shop — it’s vibrating whenever you “drive it” and you obviously want it fixed because A.) it’s annoying and B.) it seems very unsafe!

Now, there are two ways to approach this: probe deeper, ask questions to help you navigate the troubleshooting process with the customer face-to-face, or take the car and run a series of tests that run the risk of looking at an area of the car that is not broken (and in the end not be able to find anything wrong — we’ve all experienced this, and it’s frustrating!). Vibration in a car can be a number of things — bad brakes, unbalanced tires, unbalanced driveshaft — the list goes on, and can be varying degrees of technical explanation depending on the customer’s expertise on the matter. A “go to” person asks questions because they genuinely want to help.

Sometimes the problem described is not the source of the problem at all
Odds are the customer doesn’t know exactly what the problem is, but they may suggest a fix because they don’t want to appear stupid in front of you. This happens countless times in business! They could say “the tires feel out of balance” but in reality, it could be that the vibration only occurs during braking, which generally points to warped brake rotors (among other things). Being the responsible businessperson you are, you would always start this process by going back a step or two to understand the customer’s needs and a description of the problem.

This will ultimately lead to a more accurate and timely resolution to a problem and a solution that hits the nail on the head. Part of being the “go to” person is providing that guidance that other departments lack — knowing they can come to you with an idea and you can help them make the most of it without making them look incompetent is critical in business. You will turn them into repeat customers.

Your customers (fellow employees) don’t really care about your deadlines
Another problem area in IT is the ability to turn on a dime or the tendency to paint a dreary picture from a resource standpoint. Just like bringing your car to the shop, you don’t really care to hear about all of the other work the shop has queued up, so spare your own internal customers (fellow employees) the details. Explain that you want to help them, understand their timeline, and fit their project into the mix where you can. If you make other departments feel like you’re doing them a favor for every request they come to you with and that it feels like pulling teeth just to get some time, you will lose your position as the “go to” person. Likely, they will look elsewhere or even outsource — at which point you’re cut out of the process completely.

A “go to” person follows up.
Ever brought your car to a mechanic, the expected due date comes and goes, and you never hear from the service manager? Avoid this situation at all costs. Manage your customer’s expectations, and provide reasons for why you’re going to be later than promised. Things happen, deadlines change, but how you manage the situation will also improve the satisfaction and perceived value you bring to a project and will ultimately paint you as a “go to” person. The “go to” person gets things done and follows up when they have or haven’t been accomplished. It’s just that simple.

Work through the process and/or problem, don’t work around it or point fingers
Many times IT is looked at for solutions to sharing data or information with other internal departments or external customers. This often times means creating a new process for the application or implementation you’re building on behalf of a department. If the success of your project implementation depends on the actions of another person or department, then work with them until their job is finished. Unless explicitly told to do so, don’t “pass the buck” and assume your work is done when another department has to get involved. Part of being a “go to” person is finding the answers to problems that are outside of your current knowledge or your functional area’s expertise.

Your internal customers may not realize the amount of collaboration involved, so don’t hesitate to give them a high-level (notice the phrase “high level” — avoid the technical details!) overview of what’s being done throughout the project. This is what will make them look to you in the future for other projects and view you as a “go to” person.

Disruptive Innovations May Lead to Tunnel Vision

This post over at Brand Story got me thinking about how similar this topic is to strategic inflection points (from Only the Paranoid Survive by Andrew S. Grove). I work in an industry where competition from product imports (from China) are a serious threat to our business. The discounts at which their products are sold are very challenging to compete with. Fortunately, we think we have disruptive innovations in the works, but reading the post at Brand Story really got me excited — primarily because what we’ve got coming up over the next couple years is really exciting, and we’re doing it right. There are however, downsides to new innovations that must be taken into consideration, namely tunnel vision.

Fortunately for our industry, competing profitably at much lower costs is not the end-all, be-all of business strategy. Driving costs down is certainly always top-of-mind when competing with imports and when dealing with retailers who private-label imported products to directly compete with your brand-name products. At the end of the day however, and this may be the case for several other industries, you’ve got an industry with a plethora of products and brands, all similarly priced, but giving the consumer serious information overload and confusion (ever tried shopping for blinds and shades in a retail store? :) ).

Avoiding tunnel vision: Consumer insights are your friend!
Disruptive Innovations, while game-changers, cannot get away from the fact that consumers still need to understand how to shop your category and ultimately make a decision to buy. A lot of new product development may lead to tunnel vision — being so focused on that great new feature, huge cost savings, adopting a “me too” product (playing “catch-up” to other competitor innovations), or a new type of product altogether, that sometimes the “big picture” is lost for consumers.

Tunnel vision is really hard to see while you’re in development mode. You may begin to see it after the product is ready for consumer testing and you are able to take a moment and step back from the nitty-gritty and see just how consumers respond to what you think is an innovation. From a web development standpoint, it’s very easy to get lost in the cool, new features of a website and completely forget that the consumer must actually find their way to your site at first, be aware of the new technology, and know how to navigate to this area of your site.

Don’t forget the marketing
Worse yet, consumers may respond quite well to the innovation itself during the consumer insights session, giving you the reinforcement you’d be hoping for — but your innovation may tank in the marketplace. The branding, marketing, advertising, and/or overall awareness will help bring your disruptive innovation to its full potential.

Sometimes, this is the most critical component. You may have the best product in the world, but if nobody knows about it, or it’s buried in an aisle of other similarly confusing products, then you’re back to square one. Don’t forget to think “big picture” when it comes to consumers — it’s very easy to get lost in the industry competitiveness. Consumers insights and evaluating all aspects of the innovation are critical to success. This applies to many businesses, not just manufacturing companies — web companies are just as guilty (Google is a major offender: I just discovered Google Browser Sync, nearly a 1-year old product and I love it! But where’s the marketing for it?).