Friday, May 29, 2009

Purchasing Enterprise Software

The Technical Evaluation Process

So, your friends on the business “side” of the house have some new requirements? You were just put in charge of determining how to best meet these requirements and have decided that the tools you have in-house aren’t going to cut it and building the solution yourself just doesn’t make sense (I’ll save that topic for another post.) What do you do? I’ll help you walk through a process that is meant to save you time and money by reducing the risk involved in your decision and ultimately picking the right solution.

What Comes First?
First, you need to do some research on who the top vendors are in the space. To help you determine who these vendors are, you should check out what the analysts have to say about this. Garner and Forrester come to mind, and if they have an evaluation already done that addresses the software you are looking into, then you are in great shape. If not, this is going to be a much more difficult process than expected. So, let’s just assume this work has already been done.

Depending on how much time you have available to build a solution for the business, you’ll want to choose the top 3 to 10 vendors in the space to evaluate. I’d recommend taking a look at vendors that are well established (aka the “big boys”) as well as some of the smaller vendors. Most likely you will get a much different approach and vision on how your problem can be solved by looking at it from different sides. Chances are, the big boys are going to have a much bigger vision of the space, but will tend to be less innovative and the smaller vendors will have more leading edge features, but have a narrower scope to the solution. It is important to see both sides of this as your requirements may fit one approach better than the other.

Find Out What the Vendors Offer
The traditional approach here would be to issue an RFP (request for proposal) from all of the vendors you’ve selected from the above step. This would be wrong. Unless you have a long delivery cycle you will probably just be wasting everyone’s time. To build an RFP you will have to go out to the different stakeholders in your company to find out what their requirements are and write them all down as a list of features and functions they want to see. This is a very structured process and will eat up countless hours of your time. At the end of this process you will have a document or spreadsheet with hundreds of questions to send out to the vendors. Those vendors will then put in the minimal effort to answer “yes” to each of your questions. They will do this because they know that to answer “no” or be unable to answer a question at this stage will immediately eliminate them. From the vendor’s perspective the goal of an RFP is to get to the next stage.

So what do you do? Instead of building up a list of features and functions, have your business users describe the current problem and their ideal solution in their own words. Then, you should do the same based on your understanding of the technical environment that the solution will operate in. If the solution requires single sign-on, portal integration, etc. this is where your input comes into play. You shouldn’t feel compelled to rewrite the business’s requirements or ideal solution. This should be as unfiltered as possible so that the vendors have as much understanding about the requirements as possible.

Then, take the compiled problem statement and idealized solution that you’ve just written and send it off to the vendors asking for a written response from them outlining how they would propose to solve the problem and what the solution would look like. Ask them to include which products and services would be required in the solution and ask for them to describe how they’ve solved this problem at other clients of theirs. Don’t ask for them to scope the cost of software or hours to implement because you won’t get a straight answer and frankly, it is not possible for them to estimate this at this point.

If you don’t get a good answer back from the vendors or they are too vague, then push them to be somewhat specific about their vision. Also be sure to mention to them that if they can’t get more specific they won’t be selected to participate in the next round. You should use the written responses as your first method of filtering the vendors. Those that paint a solution that seems to meet your requirements and mention some of their products or packaged solutions should be moved to the next round. Those that don’t seem to understand what you are trying to do (after you’ve helped them by clarifying any questions they may have had) or are so vague you have no idea what they are proposing or have not put any effort into the response (by giving you some marketing boilerplate response) should not be included in the next round.

The Demo
The next round should be a series of phone calls to your down-selected vendors (if you started with 10, you have perhaps 4-6 in the next round) to schedule demos with them. At this point, all you are looking for are high-level, generic, demos of their solution to give you an idea of how they going about solving the problem you presented to them. This is meant to be generic because this will give you the opportunity to see how they view the general problem space and allows them to show you what their vision of a solution might look like, but generically. This is important because by seeing everything the vendor offers in this space might open up other possibilities you hadn’t realized. It also gives you the opportunity to see what they feel their differentiators are.

If the vendor is smart, they will ask to do some additional discovery before the demonstration. If they ask for this, it shows that they intend to take some interest in you as a client and want to invest additional time in you. Depending on how much time you have, you can invite them in for some in-house meetings to do this discovery where you can be more detailed in describing your requirements. A phone discovery session is also fine as it allows them to ask some questions to ensure that the demo they will be giving you hits the mark. Any vendor that doesn’t do this I would be suspicious of. Either they are so confident that they can meet your requirements in the first demo that they don’t need to ask questions, or they aren’t interested enough in you to go through the effort.

For the actual demo itself, I would recommend spending between one and two hours per vendor. This ensures they have enough time to show you all the features and functions of their product and gives you adequate time to ask all of the questions that come to mind. I also strongly recommend you see the demonstration in-person. Remote demos are very difficult to pull off and often encourage folks to get distracted. As for who should attend the demo, I would recommend that the key members of the decision committee attend, but no more. You can invite others to the later evaluation rounds. After seeing all of the demos you should now down-select your vendors to 2 to 3 and no more. This is because you will be asking the remaining vendors to spend a lot more time on your solution which in turn involves a bigger commitment from you and your organization.

The Custom Demo
At this stage, a lot of organizations would jump right into the Proof of Concept. I don’t recommend that unless the solution you are looking for is so unique and so highly customized that you don’t think the vendors will be able to mock something up on their own. Other reasons why you probably don’t want to do a PoC:
- You will need to be 100% available to that vendor for the entire duration. Typical PoCs last a week, which means you will need to set aside two to three weeks, just to run the PoC.
- You will need to have additional staff on stand-by to support each of the vendors during the PoC. This might mean System Administrations, DBAs, Network Administrators, and your Subject Matter Experts need to be available, on a moment’s notice, for those 2-3 weeks.
- You will need to invest heavily in preparation of the PoC, far more than for a custom demo. You will need to fully build out the use-case as well as define the decision criteria.
- Is your facility setup to have guests on site and accesing your systems for weeks at a time?

A custom demonstration only requires a fraction of the above requirements, but should have nearly the same result. The vendors should provide a glimpse of what your solution would look like using their software and tooling. But, to get here you will need to invest more of your time detailing the requirements as well as providing the vendor access to your business users so that they can do additional discovery. The result of this should be a custom tailored demonstration that the vendor feels will give you a feel for what the solution looks like.

Once you’ve viewed all of the custom demonstrations you may be ready to make a decision. However, if it is still too close to call, this is when you should broaden the audience and bring the vendors back in to present their solutions to the larger audience. This audience should be comprised of only relevant business and technical users of the proposed system.

In Parallel
While the evaluation is going on and you are in the demonstration phase, you should ask the vendors to provide a list of references, use cases, and white papers that describe their solution. This should give you an idea of how their software and services can be deployed under ideal circumstances. Remember, they are not going to print and share the projects that went bad.

When you get to the custom demonstration phase, ask the vendor to setup reference calls with a couple of their customers. This will give you the opportunity to get an unfiltered description of how they implemented the vendor’s software solution as well as find out how responsive the vendor’s support organization is. Again, be aware that anyone the vendor has you speak to is most likely the “best case” scenario, but even still this will give you a different perspective.

Additionally, you should be asking the vendor what their product roadmap looks like for the solution they are proposing. Will they give you access to their product management team to do a call on this? How open are they about sharing this type of information? The more access they grant and the more open they are the better.

The Decision
Ok, so if there isn’t a clear “winner” from the custom demo you will have to start factoring in the non-feature/function areas of the solution to make your selection. What does the future hold for the vendor? Is one more financially stable than the other? Is one more willing to put features in future versions of the product for you? Does one want to make you a reference customer and is offering to go the extra mile to ensure your success? Which product roadmap syncs up with your future direction? Which vendor can help you address other areas in your enterprise down the road? These are all factors that you should weigh when making the decision. At the end of the day, if the decision is too-close-to-call based on how the solutions look then I recommend you go with the vendor you would rather have a relationship with over the next 5 years because ultimately you will end up leaning on them at times and if you have a good relationship your project will most likely be more successful.

Friday, May 22, 2009

Going the Extra (100K) Mile(s) for Elite Status on United

Or, Why I Flew to Singapore for the Weekend

If you’ve never been an “elite” on a major airline it will be hard for you to understand why someone would subject themselves to 36 hours in an airplane (not including travel to and from the airports, plus layovers) to go to Singapore and back. For most folks it is probably unthinkable to want to fly 100K miles in a year and do everything they can to avoid air travel. In fact, some people despise travel so much (and flying specifically) that they avoid it at all costs. I am not one of those people.

I enjoy the journey almost as much as the destination. Where else can you totally get away from the immediate problems of every day life? Your boss isn’t bugging you, your spouse or significant other isn’t asking you about dinner or weekend plans and you can sit back (if you picked the right seat), relax (if you’ve brought your own entertainment), and enjoy some relative peace and quite (if you’ve brought some noise cancelling headphones) and have some quality me-time. What’s not to love about that? I get more pleasure reading done while flying than any other time.

But, that’s not what this post is about. This post is about why one would go to such extreme lengths just to achieve the top (non-subjective) tier of an airline’s mileage program. I can’t speak to the other airlines’ programs because I put all of my mileage “eggs” in one basket – with United. United offers three real tiers, Premier, Premier Executive, and Premier Executive 100K which require 25K, 50K, and 100K miles flown in a year respectively, to achieve. Until you’ve made it to Premier Executive 100K (1K for short), you won’t know what you are missing. The Perks, that is what you are missing.

Have you ever had a flight cancel due to weather? Ever wish you could take an earlier flight home? Wouldn’t it be great to ride in first class? Hate paying baggage fees, change fees, stand-by fees, award ticket booking fees, et cetera? As a 1K United has something special for you in all of those cases. Sure, the perks are nice, especially all of the upgrade certificates given out. But, for the business traveler, it is what United does for 1K’s when things don’t go as planned, that makes it worth it.

Stand-by and Confirmed Stand-by
When I get out of a meeting early or one cancels and I want to take an earlier flight home, I can switch to an earlier flight, for free! This is different from standing-by for an earlier flight, which I can also do, but I get bumped to the front of the list. So, chances are, I’ll get home hours earlier.

The Red Carpet Lane
There are a couple of places this comes into play. The first is when you check-in at the airport. If the airport is big enough, they will have a dedicated 1K check in; if not you can check in with First Class. When you get to the security screening area, again there is usually a priority line that gets you through the rubber stamp that is the TSA in minutes. Finally, at the gate there is a red carpet lane that allows 1K members to board with the first class passengers and is open during the entire boarding process. What this means is that from the time you get to the airport all the way to the gate, you get to avoid most lines and always have a place for your carry-on luggage. I don’t think I’ve ever gotten to the airport the 90 minutes ahead of time recommended by the airlines because I know I can go from my car door to my seat on the plane in less than 30 minutes.

When Things Go Wrong
If you’ve ever taken more than just a couple of trips you’ve probably experienced a delay or worse, a cancellation due to mechanical issues, labor issues, or the weather. These things happen. The airline system is very complex involving hundreds of planes connecting to hundreds of cities with flight crews with different labor rules all of which can get messed up for any number of reasons. Delays happen. However, when the real nasty delays happen or if flights are cancelled, this is when being a 1K really helps. Let me give you a recent example:

I was in Salt Lake City on a Friday with a 4:40pm flight. The weather in Denver was really bad due to snow and flights were getting delayed and cancelled all over the place. I started getting text messages from United letting me know my flight was delayed over the course of the afternoon and ultimately got a few messages letting me know my flight had been cancelled and I had automatically been rebooked on the next available flight, the following morning. Within 15 minutes of that last text message I received a phone call from a United employee at the SLC airport letting me know she could put me on a Frontier flight at 5:15. All I had to do was show up at the airport, walk to the United check in counter and get my new boarding pass (with aisle seat assigned)!

If United hadn’t done that for me, they would have put me up in a hotel for the night, at their expense, even though it was weather related.

Another example:

I was recently flying to San Francisco and after takeoff the plane experienced a mechanical issue. We ended up circling for about 45 minutes before finally landing so the ground crew could look into the problem. I had a really tight meeting (meaning I didn’t have much time upon landing to get to the customer) in SF and could not afford to be late. Upon landing back in Denver, I went to United’s mobile site on my cell phone, looked up the next available flight to San Francisco, then called the dedicated 1K phone line and requested to be put on that flight. I was confirmed on that later flight by the time we hit the gate. I walked to the new gate, picked up my boarding pass and boarded the new flight and made it into San Francisco in time for the meeting. If I had stayed on the original flight I would have missed the meeting.

Dedicated Phone Line
That phone call I mentioned in the above paragraph is always routed to call centers in the US first. This means that the employee has probably been with the airline for a while and knows how to deal with complicated issues. I also don’t usually have a hold-time of more than a few minutes and the employees who work these call centers actually seem happy to help.

Hotel for Any Reason
That’s right. If I miss a flight due to mechanical issues or even weather issues, United will put me up in a hotel at their expense.

Proactively Rebook
As show above in the Salt Lake City example, they will search for the next available flight with seats on any airline to try and get me to my final destination. I might be a miles-whore, but making a meeting on time is more important and United will go out of their way (at their expense) to get me there.

Getting Treated Like a Human Being
From the reservations agent, the ticketing agent, gate agent, to customer service, they employees treat 1Ks better than the rest of the population. I know, that is a terrible business model and alienates the 99.5% of the flying population, but that is why I choose to keep this status.

Upgrades
Ok, I know I glossed over this above, but this really is a great perk. 1Ks get more upgrades (confirmed “Regional” and “System-Wide” upgrades) that allows me to sit in First Class (domestically) or Business Class (Internationally) when there are seats available. And there is almost always a seat available. Flying coach sucks, so being able to upgrade is a great perk and the fact that my upgrade will “clear” before everyone else’s means that I will get a seat up front more than the rest of the Premiers and Premier Executives. You might be thinking, “hey, coach isn’t so bad.” And you are right; it isn’t if you only fly a couple of times a year. But if you are flying every week, or internationally, coach is for masochists.

In Conclusion…
And that is why I flew to Singapore for the weekend back in April. Keep in mind that I flew to Singapore in Business Class (because I used one of those upgrade certificates) and enjoyed 35 hours to myself to read, watch movies, enjoy the decent airline food, drink, sleep all while ensuring that I can keep up the status through next year. Crazy? Probably. But once you’ve hit 1K, there’s no going back!

If you are interested in learning more about my trip to Singapore, here is the link to my website.

Wednesday, May 6, 2009

Your Enterprise Software Implementation is Going to FAIL!

And here’s why…

(Note: This is not intended to be a profile of any one customer I’ve worked with. Nor are the examples here verbatim of what I’ve seen. These are just general patterns I’ve encountered.)

I’ve been in enterprise software for 7 years now and although I’ve seen a number of really cool success stories using a number of different software solutions, it is the failures that seem to stick in my mind. Perhaps it is because I like to learn from failures to help my customers succeed where others could not that I tend to cling those memories of disaster. Often times it is not possible to pinpoint the source of failure, although most folks try to do so. Failure usually occurs for a number of reasons, many of which can be detected right at the beginning of the implementation. In fact, projects that fail are usually setup to do so (although not intentionally) from the start.

In the spirit of redneck comedy (or “blue collar”, although I think that term is more offensive, but I digress) you know your project is going to fail when…

If you are trying to implement more than one piece of enterprise software that isn’t “pre-integrated” or doesn’t have out of the box integration…

you are in for a world of hurt. The pain increases exponentially with each additional product in the mix. I’m not saying that you shouldn’t implement multiple pieces of software to form some sort of composite application. I’m saying that if you try and do this on the first release you are taking on a lot more than you can probably chew. Why not break the project into several iterations? Breaking down the implementation by doing a short release cycle with one product first, then adding a second component in the next release followed by incremental enhancements until everything is integrated is much more pragmatic. I know this sounds obvious and I can’t tell you how many heads bob up and down when I mention this approach. However, very few organizations actually do this. Why? The thinking goes that if you try and integrate everything at once then all of the bugs will be discovered early on in the process so you’ll then have plenty of time to fix them along the way. It never happens this way because the complexity is non-linear. For example, the complexity of combining 3 applications isn’t just 3X, it is really 9X (man-hours, cost, etc) because application A and application B are twice as complex on their own and integrating them adds two more levels of complexity. Add a third product into the mix and you add one more product complexity plus two more integration points When you get to that level of project complexity (and the long timelines and huge cost associated with it) you’ll find that either you have the worlds most patient project sponsors, or the project gets cancelled.

If you choose to “go it alone” because you have “plenty of smart people” on your team to implement the software…

you are fooling yourself and setting your team up for failure. Because of this attitude you’ve only given your team one option; to succeed. When they don’t this will cause major backlash with finger-pointing going in every direction (mostly at the software vendor) and will cause some of your best people to leave your organization out of shame or frustration. As a manager, how can you have possibly gotten this far in enterprise IT without spending money on software implementation beyond your fixed labor costs? Hey, I get it, enterprise software I hard, really hard. That is why most software vendors have consulting services and have extensive partner networks. We want you to succeed and recognize the fact that you are going to need help, if just on your first implementation. Please take it. If you don’t, I’m really going to want to say, “I told you so,” but that would be in poor taste. Chances are, you’ve taken the training and read the documentation (more on that below) but in my experience that simply isn’t enough. Asking for help isn’t a sign of weakness, it is a sign of maturity.

If as part of the sales cycle you’ve only seen me, the only product expert you are going to meet (because you aren’t using professional services or an SI), twice, and the contract is already signed…

you are already weeks behind the knowledge curve. Generally, IT organizations are curious to learn as much about a piece of software as they possibly can before they have to go off and implement it. They will also try and take as much free knowledge as they can get their hands on. The smart organizations will figure out that I (and my peers) am a free resource to use and abuse until the sales cycle is complete. This means product demos, deep dives, workshops, sessions of stump the chump, and even proof of concepts (the latter being a blog post for the future) are all fair game to learn as much about the product, and my experience with implementations of it as, as possible. If the natural curiosity to learn is not there, or you are too busy to deal with this now (see below), or any of the many reasons why you choose to remain in the dark are keeping you from getting a brain-dump, you are in trouble.

If during the two meetings we had together (see above) you spend most of the time “fighting fires” or dealing with “production issues”…

you probably don’t have your ship in any sort of order and adding another piece of complicated software to the picture is only going to make things worse. What makes you think you can maintain a new application if the old one(s) keep breaking? Adding one more layer of duct-tape is only going to cause more stress to the already overtaxed system that you and your poor staff will have to deal with. Chances are, you’ll be fighting these existing issues all through the implementation of the new software, which means your team won’t be as focused on the new implementation. Today’s botched implementation is next week’s “production issue”, thus creating a downward cycle that will be very difficult to get out of.

If, after having explained to you the best practices for implementation and choose to go with a fully custom, non-standard, and non-recommended implementation on your first project…


then I hope you have deep pockets; because to actually get that beast into production you are going to end up paying a whole lot more than you initially budgeted for with a lot less delivered than was promised. Did you run that use-case by anyone with extensive product experience? Did anyone warn you not to make things so complicated on the first project? Do you have cotton in your ears or do you think you just have “really smart people”(see above)? The very first time you implement any software the KISS principle should apply. Keep It Simple, Stupid. What is wrong with getting that first one out the door, even if it has limited functionality that you can improve upon later? Won’t the quick win on your first implementation buy you more leeway down the road when you want to do more complicated things? I know I’m being rhetorical here, but I see this far too often and it just doesn’t make sense to me. I’d opt for a guaranteed quick (if simple) win over a potential disaster any day.

If you’ve asked me where the documentation is and actually intend to read it. Or, if you’ve asked me how to setup a comprehensive test framework to run the software through its paces before you start implementing…

you are on the track to success. Software vendors don’t staff teams of people and spend thousands of man-hours writing documentation just for giggles. Everyone knows engineers hate writing docs, so why do software vendors go through all of this effort? So that their customers actually read them to gain a better understanding of how the system actually works, what the best practices are, and what to avoid. It is amazing how many support tickets get opened that turn into documentation questions as opposed to real product bugs. By actually RTFM you will be in much better shape to not only implement the solution, but also so ask the right questions when problems arise.

Additionally, if you have the foresight to plan for QA on your implementation before promoting it to production (you do have a sand-box, test, and staging environments, right? Sigh.) you are probably going down the right path. Thinking about QA doesn’t actually mean you are doing it right though. Did you spend 90% of the implementation time doing development and are saving the last 10% for QA? How firm is that go-live date? Well, either your “firm” date is going to slip or you are going to release one buggy application. Ideally, you are doing test-driven development. But short of that you should plan on spending at least 1/3rd of the project in QA and performance testing (you do know how to performance test, right?) before promoting to production. If not, well, those bugs aren’t going to fix themselves.

There are a number of other reasons why it implementations fail, but I’ve already ranted for long enough. Keep in mind that any one reason is probably not enough to bring a project down, but when you start combining several of them together the snowball of failure really starts to grow and that in turn has the same chance of success as, well you know…

Friday, May 1, 2009

Social Networking for the Masses

Why numbers on the homepage (or the lack thereof) equate to inclusiveness or exclusiveness

It was this (http://tinyurl.com/c3a3la) article that got me thinking about why some social networking sites are more popular than others. What makes Facebook or MySpace more popular than say, Twitter? It would seem that Twitter is easier to use, less intrusive, and less time consuming than the other sites out there, but why is it not as popular as the others?

Because Twitter is a community for geeks, by geeks, and nothing but geeks whereas sites like Facebook and MySpace cater to the masses. One very important and overlooked feature all of these sites are lacking is a numerical user ID which I think corresponds to more inclusiveness. How? When sites dole out numerical user IDs they are automatically creating a hierarchy of users where the lower ID’d users feel they have a sense of authority, entitlement, and superiority over other users. This quickly turns the non-geeks off (and by contrast either doesn’t bother non-geeks or actually encourages them) and ends up attracting only the sort of person who cares about that sort of thing. Just look at the threads that show up on Slashdot from time to time doing a roll call for the lowest active user ID. Or on flyertalk (online discussion board) where folks do the same but for frequent flyer numbers. To the average, non-geek user this is exclusionary, which in turn turns them off of the site. Those users that are part of the popular, in-crowd at the site stick around and those that aren’t quickly leave.

Look at any site that has discussion forums (like flyertalk, vwvortex, or even tuckermax) and you’ll see interesting interactions between users with higher post counts and those with lower post counts. Often times there will be arguments (after all, who doesn’t love to argue in anonymity?) between the veterans (those with higher post counts) and newbies (those with lower post counts) and inevitably the argument will turn ad hominem with the veteran dismissing the opinion of the newbie based solely on the fact that the poster obviously doesn’t know what they are talking about because they haven’t posted enough. This, of course, is a catch-22 because how can someone get “experience” if they are so discouraged to post in the first place?

Facebook has avoided this whereas Twitter has not, although Twitter does this in a different way. When you log into Twitter, under your username (hey, at least there isn’t a numerical user ID) there is a count of “following”, “followers”, and “updates”. This is your defacto rank as a twit (tweeter? Twitterer?). Facebook hides (i.e. not on the main page) how many friends you have and doesn’t track how many times you’ve posted or updated. This, in my opinion, allows for a more open and inclusive community where everyone is truly equal.
Now, I’m sure that the creators of these sites didn’t intend to exclude or alienate users (ok, maybe not in the case of Slashdot), but perhaps it is human nature to want to compare ourselves to one another. After all, society as a whole is hierarchical in nature, so why shouldn’t our online communities be? I think the social networking sites allow folks to ignore those social norms and just connect without the pressure of being on top or ahead of someone else.

Of course, this post ignores all of the technical reasons why one social networking site is better than the other as well as the social reasons. And, one can’t discount all the features, apps, etc that come along too. But, I wonder if the numerical user ID, post counts, etc prevent some sites from reaching that tipping point?