Midwest IT Survival

Security teams need a louder voice

Yes, I’m a few weeks late commenting on the long awaited release of the FFIEC’s updated on-line banking security guidance to US financial institutions since the last major revision back in 2005. Of course, every security analyst, blogger, vendor and pundit had to offer some perspective on what the FFIEC presented. One particularly analyst, Gartner analyst Avivah Litan, of whom I’ve communicated with in-person and blogged about before here, is critical of the guidance (here) and in general, her critiques are valid from my perspective as she has presented them. One perspective that hasn’t been extolled enough in my opinion is the extra push this guidance gives to security folks in the trenches trying to merge good security with product teams trying to push as many new features as possible on to over stressed IT delivery teams. I’ve described this typical inter-dependent set of challenges in more detail before here. Lastly, for those that didn’t see the comments on my previous post on the recent pressures on banks to secure the on-line delivery channel, I’ve captured a comment dialog between myself and Jim Woodhill, founder of security company Authentify that supports the challenges of this cross-team security prioritization effort.

Again, if you are looking for more focused commentary on what the guidance did or didn’t address well, I urge you to read Ms. Litan’s article or simply Google “2011 ffiec guidance” and you will get a number of returns before you will see a link to the actual guidance itself. But what the guidance arms the “fight the good fight” security and IT teams with is additional ammunition to be heard louder in the cacophony of voices wrangling through the typical corporate IT on-line product delivery project. So before you get caught up in the groundswell of commentary that the FFIEC didn’t go far enough or didn’t account for this risk or this vulnerability, take some comfort that the fact that the guidance was updated to come closer to reflecting the currently multi-channel, multi-threat landscape that wasn’t appreciate back in 2005.

In closing, consider the comment conversation Mr. Woodhill and I had on my previous post on this topic as more evidence that security focused individuals need additional ammunition to wedge themselves into the product set feature and function discussions with a louder voice on baking in more security.

[cut/paste word for word from the commentary]

Jim Woodhill – There is no need for new security startups. The security solutions needed to beat the current-generation commercial-account online banking funds transfer fraud attacks are as much as 12 years old. Taking just two of the security solution layers recommended in most-recently-leaked draft of the FFIEC’s long-awaited 2011, totally out-of-band transaction confirmation and transaction reasonableness analytics, one vendor of the first, Authentify, Inc., was founded in 1998 and one vendor of the second, Guardian Analytics, was founded in 2005. Each has something like a dozen competitors by now. America’s cyber-security problem is one of adoption of long-proven solutions–no innovation required. Just ask Gartner’s Avivah Litan, from whose blog post on the wrongly-decided PATCO Construction vs. People’s United Bank case up in Maine linked to this entry (from a comment you posted to her blog post)–malware-based attacks are a long-beaten problem. (DISCLOSURE: I founded Authentify.)

jfbauer – Jim, You bring up a great points in your comment. I should have been more articulate in my closing comments about a potential influx of new technology aimed at trying to position a product that balances stronger security with minimal impact to the on-line customer experience (if such an appraoch exists). Being a veteran of the last round of FFIEC on-line guidance issuance in 2005 from the financial services (FI) in-house security side, the FI product teams were struggling with just how much change/impact to the on-line experience would customers tolerate. The perception that security is the inverse of convenience was prevalent. The bank that implemented something as significant as out-of-band transaction authentication/authorization where previously not implemented was concerned uneducated/unappreciative customers would revolt and take their banking business to a perceived more “convenient” bank. Plus, the sheer marketing hype and security punditry at the time that fraud was rampant and banks were doomed unless they implemented some crazy, half baked new security “thang” didn’t help. Much repressed in-house security staff jumped on the hype bandwagon for it gave them a seat at the table rather than being pushed to the background. Add in traditional bank IT/security budgeting cycles suggesting an unfunded mandate competing with product road maps and in-flight multi-year product project investments and the pragmatic need for real security enhancement got muted with all this noise. Thus, the device based authentication trend codified by PassMark and Bank of America seemed to be the safe play for FIs, the middle ground for executive decision making. Device based authentication suggested: meet the letter of the guidance, minimize the customer experience impact, increase the security toolbox in case this on-line fraud stuff accelerates and contain unfunded mandate expenditure all in one approach. I am not saying this was massively strategic thinking on the part of FIs, but given all the noise and emotion surrounding the 2005 FFIEC guidance, it seemed the risk adverse play for banks (given ACH fraud was mired in Reg Z, who has to pay for fraud losses which is still being settled in the courts). I had the opportunity to work directly with security technology copies at the time, such as the Arcot and PassMark technical folk but more so with the Bharosa team of sharp folks assembled by Jon Fisher and Thomas Varghese that provided new security technologies involving rules/risk engines and device based forensics with built in integration for out-of-band auth/az services (such as Authentify’s offerings). Hopefully the organizations that were more strategic and invested in these more comprehensive security products will be able to leverage that investment and finally extend into the full transaction out-of-band security space. So maybe one of the current challenges is: Does today’s on-line consumer appreciate the security value of out-of-band transactional auth/az and look for it as a market differentiator in bank product selection/use rather than resist it as onerous/intrusive? Jim, thanks for stopping by and taking the time to share your thoughts. (DISCLAIMER: IF my current employer has a relationship with Authentify I am unaware and I am not actively pursuing a relationship with Authentify on behalf of my employer.)

Jim Woodhill – Thanks for taking the time to write such a long and thoughtful response to my post. Even greater thanks for your being one of the few people in your generation who writes clearly without the reading “speed bumps” of errors in English usage! Information security for financial services needs a “terminology transplant”. Strong authentication (e.g., RSA token cards before RSA let hackers steal all their “seeds” <sigh>) was the the focus in 2005 because the assumption was that if the online banking server could be certain who logged on, then all transactions done in the session set up at logon time could be trusted. Session hijacking via man-in-the-browser malware has put paid to that happy simplification. Now, if a bank is serious about protecting its depositors’ funds, it will follow the “Krebs Rule” (after the central reporter on the commercial-account online banking funds transfer fraud beat, Brian Krebs of http://www.krebsonsecurity.com/) and employ security solutions that work even if the online banking user’s PC is totally controlled by cyber-criminals. What is need is for our industry to add “transaction confirmation” to its conversation about online security as a necessary backup to “user authentication. Transaction confirmation entails communicating the substance of security-critical online requests to the end user by some means independent of the technology with which the transaction was initiated (because it has to assume that the PC/its browser has been compromised) and then accepting his confirmation of that transaction through that same out-of-band means. Of course, transaction confirmation requires a high confidence in the identity of the person doing the confirmation, but there is more to it than that. > The perception that security is the inverse of convenience > was prevalent. Security is usually antithetical to usability. For example, I find it tremendously convenient to have some of my residences in locations where I never have to lock my door. So the typical question is how much inconvenience to the end users, and also how much cost to the service providers is justified to stop how large a threat? > The bank that implemented something as significant > as out-of-band transaction authentication/authorization > where previously not implemented was concerned > uneducated/unappreciative customers would revolt > and take their banking business to a perceived more > “convenient” bank. This is the great concern of your typical community banker, at least among those who have even *heard* of cyber-attacks against banking customer accounts. However, security measures can *enhance* customer satisfaction, as Jim Van Dyke, CEO of Javelin Research presented at the September 22-24, 2010 meeting of the Online Trust and Cybersecurity Forum. According to Javelin’s research, financial services customers prefer to be “touched” out-of-band by their financial services institution occasionally rather than never hearing from it. An example is a phone call to check on the validity of credit card charges. Such “touches” give the customers comfort that their F.I. is on top of things, as long as they are not so frequent as to impair the usability of the service. Authentify’s real-world experience shows that Javelin is right about totally out-of-band transaction confirmation in online banking and the conventional wisdom in the financial services industry is wrong. Of course, this would not be the case if the end user had to take a phone call for every payment he initiated, and taking a voice call just to log on would be beyond the pale. Fortunately, only the addition of a new payee (or employee) and certain very rare account-control transactions (e.g., change of the address on the account) need be “Authentified” (to coin a term <grin>) to prevent theft. The cyber-crooks cannot make away with a company’s money by sending it to a valid, established payee. The must add new ones–domestic money mules or just accounts they control overseas. For the typical American small- and medium-sized enterprise, the addition of a new payee is a “rare” transaction. For example, in the infamous PlainsCapital Bank vs. Hillary Machinery, Inc. case, Hillary did fewer than one such transaction a *month* during the life of its banking relationship with PlainsCapital. One of the central points in making the trade-off between the dollar cost to the service provider plus the hassle factor for the users vs. the cost of the attacks is that this is a decision about how much *crime* should be allowed, and it is a maxim of public policy that “decisions about crime are always and everywhere political decisions.” This is especially true for a crime like commercial-account online banking funds transfer fraud, where the proceeds are flowing to foreign organized criminal gangs, if not outright enemies of the United States. Thus, only the elected representatives of the people can legitimately decide what should be done. Hence, Avivah’s recruiting me to get this issue before the Congress. (Anyone who has followed her writings on this issue will know what she would like the Congress to do!)

jfbauer – Jim, thanks for the kind words on the effort I’ve put into the level of professionalism in my blog. I appreciate knowing readers find more traditional/formal language enjoyable. “Information security for financial services needs a *terminology transplant*.” I couldn’t agree more with your statement. Upon reading your response, I was wondering if one of the things the FFIEC, BITS, ABA, FDIC, OCC, NIST or other universally perceived as authoritative in the industry organization could benefit all involved by establishing a common vernacular that business, product, security, technology and customers could all use to have healthy discussions about on-line fraud. I recall the FFIEC issuing a follow-up glossary-like clarification document but for some reason it didn’t resonate well since I can’t even recall any details other than it didn’t become helpful in the ensuing regulatory compliance morass that was post Q3 2005. Without clear terminology, I believe one of the challenges is the preponderance of terminology thrown around in mixed stakeholder conversations. Security folks tend to throw out obscure domain terms like “cross-site forgery” as if everyone knows the exploit and its impacts. Or worse, in an attempt to confuse others or achieve a level of arrogance that creates barriers to continuing a healthy conversation. Security professionals do themselves a disservice in the enterprise when they conduct themselves in this way. This approach leads to their further frustration when the rest of the organization doesn’t perceive them as open and credible. I aways found significant success in be open to be challenged and being open to having real, fact based not fear based discussions to arrive at more understood and appreciated security solutions. With well agreed upon terms, Bank product teams could help educate and raise the level of awareness in their customer base thus calming their own fears that they will be challenged for creating a perceived negative user experience surrounding security features which leads to your comment: “ security measures can *enhance* customer satisfaction”. I do recall the FI I was working at on FFIEC compliance fretting over changing the look/feel of the login process. The FI was adding some “user personalization” changes to match what BofA was doing when they implemented PassMark. Yes, “what is BofA doing? (consumer) or what is Wells doing? (corporate/TM)” was a common theme at this institution among product teams. The fretting reached a high enough level that they felt they needed to preview the proposed changes with a customers in a focus group setting. They went to decent length to explain the changes, what the security benefits were and were not (helped with avoiding being phished but didn’t prevent it, etc.) Much to their surprise, and exactly what you described, once the customers were informed of the enhanced security of the changes, they were completely on board. In regards to your position that “Fortunately, only the addition of a new payee (or employee) and certain very rare account-control transactions (e.g., change of the address on the account) need be “Authentified” (to coin a term <grin>) to prevent theft.” , do you/Authentify have any research/published material to help support this? There is a competing approach that suggests that analyzing the transactions themselves for fraudulent or unusual payment patterns/characteristics coupled with out-of-band confirmation only inconveniences the user at the extreme minimum yet still stop fraud compared to more frequently as payees and payee details change. Of course, this based on the supposition that on-line customers would make odd payments less frequently than add/change payee details and (big and) the FI would have the level of sophistication to determine, quickly, that a particular transaction is abnormal. I just recently ran across Avivah’s articles. I’ll need to spend some time reading her past posts to better understand her position on these topics. I doubt I can, but if there is anyway I can assist with your/Avivah’s efforts to educate congress on the real security needs I will make myself available. Lastly, is Authentify participating in the Gartner Security and Risk Management Summit 2011 (http://www.gartner.com/technology/summits/na/security/)? I would enjoy participating in any Authentify sponsored presentations/events as well as talking with any Authentify individuals at the conference.

The challenge to integrate Architecture and Agile

Recently on Simon Brown’s blog “Coding the Architecture”, Simon posed are interesting challenge of which this article provides my response. I enjoy Simon’s blog for he presents very well thought out articles on the challenging overlap between Agile software development and the value of architectural principles in providing software solutions. As those that frequent my blog have seen, I’ve written about the challenges of integrating pure Agile development methodologies into non-Agile organizations such as legal services, manufacturing as well as financial services. I’ve approached the topic of work estimation here which is a frequent challenge in non-agile organizations that make project and resource prioritization decisions based loosely on the estimated work effort. I’ve tried to successfully blend Agile story and blacklog project management with the preponderance for waterfall-esk program management here. Based on the comments to that article I didn’t succeed in my goal. I’ve even broached the Agile versus architecture question before here but the focus was on the Agile reducing over architect-ed solutions rather than taking Agile versus architecture head on. I’ve even discussed budget challenges before.

Simon’s challenge: Given a four month window to deliver a new software project in an Agile shop, how would one go about doing so given some interesting constraints? The below graphic is from his blog post that captures the unique constraints for this challenge:

Based on my multiple years in the financial services industry working for more than one bank, I feel the need to outline some immediate assumptions that pop into my mind that are tainted by my direct banking experience:

1. Design Firms – Simon’s challenge involves the bank undergoing a new branding effort. In my experience, a bank’s internal marketing department partners heavily with an outside marketing firm for larger banding initiatives. Additionally, new branding efforts usually involve getting that new brand message out through a variety of channels.
2. Middle-ware/SOA capability – Given the overall growing maturity in the service oriented architecture space and the relative IT budgets of most financial institutions, I am going to assume there is some middle-ware, messaging and/or enterprise service bus-like capability to leverage.
3. Content Management System/CMS – Given the explanation of the current state online banking system, I am going to assume the bank does not currently have a mature content management platform which can be extended to provide online banking functionality.
4. Backoffice – Also, I am assuming that the bank currently has a backoffice transaction system that currently performs the bank’s core bank product transaction needs. For the sake of this exercise, a “legacy” mainframe set of applications are in place that run the core bank transactional services that has some capability to expose those transactions to the middle-ware/SOA platform.
5. Build versus Buy – A classic challenge for banks has been the decision to put the focus on building in-house capabilities versus buying mature vendor solutions and integrating those into the technology portfolio. Depending on the financial health of the bank itself as well as the predilection of the CIO, the build versus buy pendulum can swing to either extreme. Add the frequent turn over of senior IT leadership and this can be a real challenge for enterprise architectural patterns. For the sake of this exercise, the assumption is that the bank is willing to invest in the middle-ware transactional capabilities in-house as well as the supporting online banking application user experience but prefers to purchase a new content management solution to host the UI.
6. Big Bang versus Functional Sequence based rollout – I am also assuming product management is risk adverse and open to sequencing in the new functionality rather than demanding a big bang approach. More on the sequencing later in this post.

Given the architecturally significant changes requested in 4 months, specifically the read-only to real-time transactions and the complete hosting re-platform need, I would convince management that it would be infeasible to deliver everything in 4 months. Yes, the project management side of my brain says don’t over commit given the technical complexity involved and the linkage to a significant customer impacting change.

Thus convinced, I would then break the effort into multiple parallel technical efforts:

Re-brand current site = I would spin up an Agile team including the online banking product management/manager to focus on re-branding the current site between now and the 4 month end date. The team’s priority would be:

1. Integrate the new branding into the current site working heavily with the outside design firm
2. Make changes, assuming no conflict with #1 above, to improve W3C compliance

Create re-useable transaction services = I would spin up another Agile team that has the mission of exposing the backoffice transactional services as “enterprise” consumable web services through the middle-ware platform. The stories would mix both the technical needs such as “Develop a way for the middle-ware components to authenticate to the mainframe components” as well as business capabilities “have the ability to transfer unlimited funds, subject to current available account balances, from one customer owned account to another account owned by the same customer”. The prioritization of the stories would be as follows:

1. Architecturally needed stories such as component to component authentication, high availability, etc. Basically, everything needed to support #2 below.
2. Transactions needed in the new online banking product based on the roll-out schedule.

One of the challenges for this team is the likelihood that the mainframe platform participants are not familiar with Agile practices. Thus, extra coaching is probably a must for this team.

Purchase Content Management Product = I would task the architecture group to work with procurement to select a vendor’s content management product that will become the framework for the new transactional customer user experience. The classic steps would be undertaken: RFI/RFP, product evaluation, proof of concept, vendor pricing negotiations and ultimately product selection. This needs to be completed in enough time for the next team to be able to deliver some functionality in the new CMS product.

New UI Development = Finally, I would spin up another Agile team to map out and build the new transactional UI. Their first challenge would be to reverse engineer the customer authentication system to determine how the system authenticates users and then links them to their accounts and products with the bank. They would need to work closely with the re-branding Agile team to determine the most seamless way to add navigation to the current site to link over to the new site for the real-time transactional capabilities. Additionally, this team would also have to work with the middle-ware team in order to understand the re-usable services being created and how to consume them. Lastly, this team would also have to keep tabs on the content management team to follow the procurement process and start to understand the framework capabilities of the new CMS product and how to link those to the navigational needs and transactional needs of the final online banking product.

This last team would have a heavy architectural staffing up front and transition to a more development heavy staffing towards the end for delivery. In a perfect world, the project management resources from this team would be the most senior in the organization and consistently work with this team as the skill-set transition occurs.

The below Gantt chart reflects the multiple parallel efforts and when they ultimately need to come together to deliver the final product.

The functional roll-outs would be linked to the customer marketing campaign in order to provide sequential customer communication on new product features as well as permit the new technology “kinks” to be addressed. Also, this allows call centers to ramp up temporary staff to address the increased call volume due to the changes impacting customers familiar with the prior system.

The actual sequence would need to be agreed upon by IT, product and call center management, but potentially the following sequence might fly:

1. Launch the old site with the new branding.
2. After a brief window of time to let the call center call volume return to normal levels, replace the link to current “account balance” information in the read-only system to the same “page” in the new system that requests that same balance through the new middle-ware services. The customer experience would be marginally impacted in that instead of seeing yesterday’s balance details they would be seeing their current account balances. Lastly, address any negative performance or functional kinks.
3. Add account transfer links to the old site that take users to the new site to perform the transactions [first real new customer functionality]
4. Same call center pause.
5. Repeat the sequence for additional transactions such as external account-to-account, bill payment, bill presentment, etc.
6. When all transactions are being handled both UI and middle-ware by the new site and the old site is essentially a set of static pages with links, cut the login process over to the new new site and disable the old site when web logs show no stray bookmarked pages are being accessed. Porting over the authentication system was part of the deliverables of the third Agile team.

Sure, this sounds like a full program of interdependent project activities, but from my experience, banks want to provide highly available and reliable services to their online customers which tend to be their highest revenue generating customers as well. Thus, all of the incremental functional roll-outs which come with the additional cost of testing and program management overhead deliver on the risk adverse, reliable and measured change.

I look forward to all the alternative approaches to this challenges Simon has presented. How far am I from the response norm? Any fundamental flaws?

Don't give up on the Gantt!

I’ve written before that I am not an “Agile” nor “agile” development nor project management expert. I’ve previously proposed that one by product of “agile” development and project management in general is a reduction in over architect-ed software solutions. With project requirements being represented as stories and tools such as Kanban boards for lean software development to show the flow of work through a process, one might think the classic waterfall project management work and schedule reporting tool, the Gantt chart, is obsolete. Before you abandon this tried and true project schedule reporting solution for the more transparent status inherent in agile project management, you may want to keep reading.

So, you have succeeded in transitioning your IT project management and delivery methodology to one that is more aligned with “agile” than “waterfall”. Your non-IT stakeholders are more engaged than ever in the project requirements definition, prioritization and sprint/release scheduling process. You are tempted to stop trying to use MS Project or other tools to represent schedules in Gantt form. In a word: “don’t”.

One of the main criticisms of complete agile project management is: “The dangers are the loss of recognition that systems/solutions change continually over time as well as team members” Put in more direct, bullet point form from my experience of this criticism expressed by product or management stakeholders:

• What is the big picture?

• I have the big picture in mind, when am I going to get X?

• At the current burn rate, how much time will be invested before I get Y?

• If I add/subtract resources, what will be the impact on the big picture?

These are all criticism subsets that can be directly addressed with the data collection associated with producing a classic Gantt chart. So don’t throw away those Gantt chart creation disciplines just yet.

What is the big picture? I have the big picture in mind, when am I going to get X?

Let the sprint/release iterations continue, but don’t let too much time go by past the releases to meet with the product stakeholders and update your rendition of the product road-map. (You have your road-map, right? You aren’t letting the business surprise you with all requests, right?) This is a great opportunity to get an early indicator if product stakeholders have become caught up in their immediate needs and lost sight of the “cost” of those features. By “cost” I mean the investment in features now means pushing out the product road map. You can gently remind them how the “cost” appears graphically in a Gantt. The Gantt view of their product can clearly show “milestone 45” getting pushed into the next quarter due to their recent feature bonanza. It is much easier to have the “hey, I thought I was getting milestone 45 this quarter” discussion as soon as the schedule shows initial signs of slippage rather then at the start of the next quarter.

At the current burn rate, how much time will be invested before I get Y? If I add/subtract resources, what will be the impact on the big picture?

Here again is where your mastery of tools such as MS Project and the Gantt chart view of the product road map are exceedingly important. If you are working for a MidWestern company, rather than say, a start-up, you can’t ignore traditional budget and resource management constraints. As a start-up in growth mode, your focus is getting your product out the door with the resources you have or your resources plus the on boarding of additional resources. In a MidWestern company, you are most likely trying to maximize the resources you have or being asked to reduce your head count while still meeting project expectations. Thus, prioritizing features to be delivered against a shrinking resource pool is a given. You need something beyond the agile sprints/releases under way to manage project stakeholder expectations on what can be accomplished when.

The Gantt view of the work allows for a graphical view of “if this is more important, what else is impacted” realities. Additionally, add in the need to manage a fixed pool of resources across multiple agile projects and you absolutely have to have some way to represent a view of the prioritized work across all resources. In addition, you may need additional tools to help represent the “what if our team member Sally gets assigned to the VP’s ‘special project’, what does that do to our resource model and what can get done when?”

Conclusion

As an IT manager or IT project lead in a MidWestern company that is moving towards more agile project management and technology delivery, you may be tempted to relax the project management disciplines that come with the more traditional waterfall approach, specifically tracking project schedules in a Gantt chart. In order to avoid the inevitable product stakeholder expectation mismatches as well as pending budget cutbacks and/or uncontrollable resource re-allocations, keep collecting that “program management” data. Continue to have re-occurring meetings to review the “big picture” Gantt chart view of the work and use other tools to reflect “what if” scenarios and their impact on the big picture.

Over Architected?

First off, I am by no means an “Agile” (nor even “agile” with a small “a”) software development expert.  There are many more individuals out there that are way more experienced and in a much better position to speak authoritatively about the Agile methodology and its associated principles on driving efficient and effective software development.  A few blogs where I consistently find great Agile perspectives are included at the end of this article.  But as I’ve participated in Agile and agile-like development efforts over the years, I’m finding an interesting pattern.  Agile and agile-like approaches have a positive by product of reducing the occurrence of over architect-ed software solutions. Over architect-ed solutions put stress on the delivery of a software application project as well as drive up the cost of software development and maintenance, in general, disproportionately to the business value produced.

As an example, a sample development effort starts out with:

Product: “We need a super widget in the product by next release, can we have that?”

Project: “We are going to need detailed requirements for the super widget in order to start developing it.”

Product: “Oh, it needs to be able to interface with the dry cleaners to know when it is time to pick up the laundry as well as make coffee for the customer before they get out of bed in the morning.  Basically the same features as our competitor’s recent release, but with these additional benefits. <Or some other description that is actionable at a high level, but lacks the detailed requirements needed to feed a development team with actionable development tasks>”

Development: “Ok, we’ll get started since we don’t have much time before the code freeze for the next release.”

… Time goes by …

A project status meeting occurs sometime in the future.

Product: “So, where are we with that super widget?”

Development: “We have the basic framework setup but it isn’t going to have all the features working by the next release.”

Product: “But I thought …”

Development: “But you said …”

Project: “What happened?  How come we are X days from the code freeze and we don’t have a viable solution?  I thought …”

Now sure, this isn’t the most perfect example of capturing how the requirements drift between stakeholders leads into an over architect-ed solution, but hopefully you get the scenario.  Or possibly another example would be when a solution is developed and released into the production environment.  Extending the example above, weeks later, when enhancements, tweaks or feature extensions are requested, a tense conversation occurs around:

Product: “But I thought the super widget would do X?  How come I am hearing it will take 30 hours of development to get X?  The testing cycle is already elongated due to the complexity of the super widget thus I thought it included X?”

Development: “But we said that the framework would support X, but we never said X would actually function without more development!  We developed the super widget to do W, Y and Z but only stubbed out X.”

Project: “But according to the requirements, it says X should be …”

And yes, an argument can be made that if:

• more effective requirements gathering occurred
• more effective project management captures more depth of what would be developed and available when
• more effective product management defines a more exhaustive product feature road map that more clearly outlines what would be available and not available when, feature-wise

… These problems wouldn’t have occurred.  But the nature of an agile-like approach puts a tighter focus on all the stakeholders:

Product: They can share the “overall vision” of what they ultimately desire the product to do, but they are forced to consider what they really need within the shorter duration of the agile-like release schedule.  Thus, product walks away with a clearer picture of what they are really getting in the next release.

Development: They get the benefit of the product’s “overall vision”, yet, they get to quickly dive into the critical features and start the dialog of how long different feature components will take to develop.  Thus, development knows exactly what they need to do now for the next release, yet they benefit from knowing where this product feature is going in the future.

Project: As long as they keep the product and development stakeholders talking about granularly defining what needs to really be built by when, the project management function has much greater clarity into what is going on and what details to track.

From what I am observing, all of the above create a stakeholder forum of information sharing that reduces the likelihood that an over architect-ed application will get developed. Most importantly, instead of leaving the feature set open and vague enough to allow a creative and motivated development team to start building and building and building only to re-surface with a highly complex solution to a loosely defined problem or need, it brings more cohesion between what is really needed first.  Once the “first” has been built, the “seconds” and “thirds” get built inline with the product roadmap.

In researching this theory, I wasn’t able to find any articles that linked agile-like development efforts to a direct reduction in software over architect-ing.  This article entitled “Agile Architecture: Strategies for Scaling Agile Development” had some interesting content on baking architecture into an agile-like effort.

Anyone else have any direct experience in agile-like compared to waterfall-like development efforts yielding less application over architecture?  Can anyone share any links to good web articles on this topic?

Agile related blogs I follow:

David’s Software Development Survival Guide

http://softwaresurvival.blogspot.com/

NOOP.NL

http://www.noop.nl/

Software Project Management

http://blog.brodzinski.com/

fragile

http://fragile.org.uk/

Regular Geek

http://regulargeek.com/

Critical Results

http://criticalresults.com/

Get sales to speed your support case to resolution

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Category

• How to Leverage Tech Support

In the previous article, we looked at the importance of opening a vendor support case for technical issues and following the process to the letter to avoid process fumbling to reflect poorly on you and your team.  In this article, we look to engage the Vendor Sales Cheese when the vendor technical support case isn’t getting resolved effectively and how to turn this around to drive beneficial pricing.

Drag the Vendor Sales Cheese into the technical support problem

One thing a good Vendor Sales Cheese is effective at is getting folks within his or her organization to move quickly to close a sales deal.  Why not leverage that ability to your advantage to put more pressure on solving your technical support issue so you and your team can move on to more important work?

If you haven’t had your technical support case solve the problem, your technical support case probably looks something like this:

Day 1 = Your Team: problem reported, steps to re-create the problem shared, log files capturing the error shared.

Day 2 = Vendor: “Try changing setting <blah>.<blah>.<blah> from TRUE to FALSE and provide the log files if it doesn’t fix the problem.”

Day 2 = Your Team: Setting changed, problem still exists, support case updated, log files capturing the error shared.

Day 3 = Your Team: request status on case

Day 4 = Your Team: request status on case

Day 4 = Vendor: “Please download patch 3498345, apply and provide the log files if it doesn’t fix the problem.”

Day 4 = Your Team: Patch applied, service now crashes immediately upon starting, support case updated, log files capturing the error shared.

Day 6 = Your Team: request status on case

Day 7 = Your Team: request status on case

Day 8 = Vendor: “Please uninstall patch 3498345 and download patch 3498350, apply and provide the log files if it doesn’t fix the problem.”

Day 8 = Your Team: First patch removed, second patch installed, problem still exists, support case updated, log files capturing the error shared.

Day 9 = Your Team: request status on case

Day 10 = Your Team: request status on case

Day 11 = Vendor: “Please download patch 3498351, apply and provide the log files if it doesn’t fix the problem.”

Day 11 = Your Team: update the case with “we are not even running that version of your software on our technology platform as already indicated in the case and thus we cannot install that patch.  Now what?”

Day 12 = Your Team: request status on case

Clearly, you and your team are burning hours on this issue and not making much progress and worse, not getting quality service from the vendor without any real resolution in sight.  Time to get the Vendor Sales Cheese involved:

Boss: “Hey, Vendor Sales Cheese, it is Boss from ABC Company.  Can you take a look at support case number 596784 we just opened?  I think we are getting the run around after the case has been opened for 12 days.  Heck, the last entry from your support asks us to install a patch that doesn’t even match our technology platform which is clearly needed to open the case in the first place.”

Vendor Sales Cheese: “This doesn’t sound right.  Let me look into this right away and get back to you.”

Boss: “By the way, we need this issue fixed otherwise it is going to be brought up in our license renewal discussions next week/month.  I can’t believe it is time to talk about new licenses already.”

Vendor Sales Cheese: <with even more urgency> “Don’t worry; I’ll get to the bottom of this straight away.”

The key to this whole exchange is to link the need for this technical support case to be closed to the next sales opportunity.  Besides being in the Vendor Sales Cheese’s positive relationship interest, now, more importantly, it is a barrier to a sales interest.  You now have a highly motivated sales person to put pressure on the technical support arm of the vendor’s organization to clear through the process morass and get the problem resolved as quickly as possible.

Finally, how can consistent tracking of vendor technical support cases drive beneficial pricing?

By keeping an accurate track of each poorly handled support case and creating a plausible story that suggests a consistent struggle with the existing support arrangement can pay dividends.  Those dividends may not be in explicit price reductions, but thee could be.  Rather, you may find you have leverage to get an improved support arrangement for the same price.  The Vendor Sales Cheese may be able to add in something similar to:

• Ability to use a “priority code” to have your tickets skip the first level of support and go directly to a stronger second tier
• Ability to use an inside “customer advocate” that you can drag into cases the minute they start trending negative or as soon as you open the case and want to impress upon the vendor the urgency or severity of the issue and need for fast resolution
• Improved SLAs which actually improve your ability to get cases routed to experts rather than just artificial improvements such as “response time for a new case from 24 hours to 12 hours” which look good on paper but only provide case acknowledgement slightly sooner and no change to resolution expectations

Thus, not usually direct dollars off the top, the ability to negotiate an improved support arrangement without impacting the price ultimately benefits you, your team and your company with lower overhead involved in getting product technical issues resolved more quickly.

In addition to these perspectives on achieving beneficial pricing, can anyone share additional techniques to link poor technical support case experiences to squeeze out the best pricing scenarios for your company?  Look for the next article to pick up where this article left off with more MidWestern IT perspectives on the topic of the “Product Versioning and the Upgrade Cycle” in the spectrum of vendor management.

How to get to the light at the end of the support case tunnel!

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Category

• How to Leverage Tech Support

In the previous article, we looked at techniques such as “Good Cop”, “Bad Cop” to drive more beneficial pricing for your company.  In this article, we take yet another angle at the Vendor Management topic with a look at how to leverage the vendor’s technical support for results and pricing pressure.

Bob the Engineer: “Hey, we are getting the FlimFlam backend service throwing error 57’s again in production?  Anyone want to bet me the phones are going to start lighting up with everyone concerned about system stability?”

Joe the Engineer: “Can’t we just restart the service quickly?  No one would know.  We know the error will go away for awhile.  It is probably a memory leak of some kind.”

<ring, ring>

Sally the Engineer: “Too late, the panic is already starting.”

Boss: “Can I have a volunteer to capture those log files and open a case with FlimFlam tech support?”

Sure, the temptation is there to immediately restart the service and hope the problem goes away.  Sure, once you start down the path of resolving this annoying yet not life threatening problem you have to see it all the way to resolution otherwise you are even worse off.  Worse off in that you have lost the “surprised and confused” defense option (see previous article on this defensive topic).  You can’t be surprised by a system error that you already opened a ticket with the vendor’s technical support.  Thus, how can you leverage this support problem into a positive of service quality and vendor beneficial pricing?

First step, you have to open a support issue or ticket with the vendor through the vendor’s product technical support process.  Make sure you follow the process of entering a support issue into the vendor’s product technical support system to the letter.  The last thing you need when participating in a “root cause analysis” meeting is to have the vendor brought in to the fray only to cause grief with a procedural miss step such as:

Vendor Support Representative: “Why did it take us more than 24 hours to respond to your trouble ticket?  Let me see … ah, your company has an Yttrium Support Contract.  But, in order to get that fast response, you need to flag your ticket with your Yttrium Support Resource’s name ‘Bob’.  According to the ticket history, it never got assigned by your engineer to ‘Bob’ …”

As you probably can imagine, the vendor support engineers probably have all kinds of internal as well as external SLAs (service level agreements) and metrics to meet.  Thus, the vendor support representative that gets assigned your ticket is looking for the fastest way to change the status of the ticket to stop the clock on their metric and move the ticket to a status of “waiting on the customer”.  Thus, be prepared for typical responses such as “please provide current version and patch level by running the <blah> command” or “please provide a system log file and a screen shot of the error”.  You might as well coach your team to provide as much of this information up front when creating the ticket to reduce the back and forth delay between your team and the vendor in order to get the vendor working on the problem as quickly as possible.

Now, as painful as it might seem or as much of a waste of time as it might seem, if the vendor support rep wants additional log information or they want your team to try a patch or updated product or component version, you need to follow through.  Sure, your lead engineer knows that the problem doesn’t magically go away with the mythical vendor software patch, but you have to still go through the process, otherwise:

Vendor Support Representative: “You are still getting error 57?  Let me check your case … ah, I see we asked you to try applying patch number 39483 to your system because that fixes the problem.  Did you try that patch?”

Thus, in the root cause analysis process you will be at a disadvantage for not following through the technical support ticket process and battling back with “we know that patch won’t fix the problem because we know …” is a challenging argument to win against peers that have no first hand confidence in your lead engineer’s expert analysis.

By completing the vendor’s technical support process, you should be left with steps to take to eliminate “error 57” from ever interrupting your team’s work again and reducing your face time in the root cause analysis process.  But what if you are making no progress in resolving the issue?  Here is where the Vendor Sales Cheese can be exceedingly handy.

Drag the Vendor Sales Cheese into the technical support problem

In addition to these perspectives on the importance of leveraging the vendor’s technical support process, what other experiences have people had to suggest this arduous process is needed to deliver quality services back to your company?  Look for the next article to pick up where this article left off with the role the Vendor Sales Cheese can play in driving efficiency and how to turn this whole situation around to drive beneficial pricing.

Time for some Good Cop, Bad Cop to save some coin?

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Category

• Sales Cycle and Pricing

In the previous article, we looked at some possible value of being direct and to the point with the caveats that one still needs to maintain an up to date relationship with your Vendor Sales Cheeses.  Some of that value being related to pricing which is where this article picks up the Vendor Management discussion.

There are a number of good sales cycle and pricing articles out there that help give some context as to how technology products are priced to the customer keeping the sales cycle in mind.  I recommend Joel Spolsky’s article “Camels and Rubber Duckies” or for a brief specific example, David Cummings’s article “Software Pricing Proportionate to Sales Cycle”.

How do these apply to the average MidWest company?  In my experience, the sales cycles are rather long in the average MidWest company.  The time it takes a vendor to go through the procurement process at an average MidWest company is exceedingly lengthy with all of the request for proposals and product demos upon product demos upon product demos.  Throw in some security reviews and contract language disputes and it could take months with no guarantee the company will actually buy the product.  All it takes is a re-organization of some key group or groups related to the vendor’s product during the procurement process and a whole new approach can be born that doesn’t involve the vendor’s product anymore.  Unless someone very high in the organization that is less likely to be significantly impacted by a re-organization is creating the urgency to get this vendor’s product in house and implemented, the more likely the sales cycle will be long and drawn out.

So, how does a manager of an engineering team within a large MidWest company have a positive affect on pricing for their company given this morass of process and bureaucracy?  The technique presented below suggests one can indeed have a positive impact on pricing even given the lengthy and arduous procurement process:

Traditional “Good Cop, Bad Cop”

One highly effective mechanism I’ve scene is when the manager of the engineering team comes across as the “Good Cop” and essentially the vendor advocate and their management fills the role of “Bad Cop”.  “Bad Cop” in the sense of giving every indication they don’t believe the vendor’s product is the right product for the company for some reason in addition to the product costing too much.  Maybe they give off every indication they have a preference for a competing product but you, as the engineering manager, really feel the vendor’s product is the right fit.  You and your management have concluded that the vendor’s product to be the right fit, but you agree to take this approach to motivate the vendor to provide additional incentives above and beyond the core product offering that will benefit the company and not destroy the profit margin the vendor is trying to achieve with the sale.  Maybe the vendor is willing to knock the price down even more than the “lowest possible” previously communicated price.  Maybe the vendor is willing to throw in two days of free on site training.  Maybe the vendor is willing to include additional licenses to products under the same maintenance cost structure.  Whatever the “maybe” might be, your roll in playing the “Good Cop” helps to give the vendor there is a high probability that the sale will complete, but it isn’t a done deal until something sways the “Bad Cop”.

Any side or longer term benefit to playing the “Good Cop” role?  Absolutely by being viewed by the vendor as a product advocate within the company.  This will significantly help you when you need to get timely technical support from the vendor as the Vendor Sales Cheese will link you and your role as “Good Cop” in helping him or her complete the sale and thus will work harder to get you the support from within the vendor that you will need down the road.  See this previous article [] for more details on how this need for technical support is critical and how the Vendor Sales Cheese plays an important role.

Another side benefit to appear as the vendor advocate within the company is access to early information on the vendor’s product roadmap as well as the ability to get customer feedback into that product roadmap process.  This doesn’t guarantee you will get that much needed feature into the vendor’s next release, but it sure increases your chances of getting more ear bending of the vendor’s product management that otherwise possible.

Is there anything else you can do to have a positive impact on the product pricing?

Remember the sales cycle from the last article?  Well, knowing the vendors quarter ends and most beneficial, year ends, target any budget license upgrade or renewal discussions around those important dates.  As an example: look to discuss yearly license purchases to coincide with the vendor’s year end if you represent a product that has a per user license.  The Vendor Sales Cheese will have the most leverage to come up with creative pricing prior to his or her year end compared to any other time of the year.  Couple your vendor year end license upgrade discussions with some “Good Cop” and “Bad Copy” technique and you can help drive some very beneficial pricing.

How about another take on driving beneficial pricing?

This can be a powerful one, thus use it sparingly, you may only get once chance to use this one.

Hint at pressure from somewhere in the organization that there is momentum building to replace the vendor’s product with the competition’s product.

Sales Training 101 says that it is way cheaper to keep an existing customer than it is to get a new customer to buy your product.  Thus, the Vendor Sales Cheese does not want to lose your business and can use the threat of potential loss to break the possible log jam within his or her sales organization to get rock bottom pricing.  Why is this only a one time technique?  After successfully using this technique to get super discounted pricing, coming back for a second round is likely to put you in the “our margin is now so slim, any lower and they might as well go switch to the competition … or they are out right fibbing” category and lose any credibility or priority attention points you have accumulated thus far.

By the way, this technique works even better if within your company, two competing products are being used.  It is completely plausible that a procurement group focusing on reducing the number of vendors to manage would have a business case to reduce the duplicity down to one vendor for a given service.  Thus, playing one vendor off of the other to see who is willing to really stretch their margins to keep your business can be extremely effective at maximizing the beneficial pricing.  As the perceived vendor advocate, you can even use the plausible angle of: “Hey, I need you guys to stay here otherwise why do I need to be employed anymore if the company goes with the other product” to support your claims for added plausibility.

In addition to these perspectives on achieving beneficial pricing, can anyone share additional techniques to squeeze out the best pricing scenarios for your company?  Look for the next article to pick up where this article left off with more MidWestern IT perspectives on the topic of the “Leveraging Technical Support” in the spectrum of vendor management.

No such thing as a free lunch

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Categories

• Sales Cycle and Pricing

In the previous article, we looked at the perspective that you are in no position/need/want to buy anything at this time yet the next sales cycle is rapidly approaching.  The following options were presented:

Option:

1. Answer the phone with: ”Go away, I’m busy.”
2. Everything goes to voicemail with no follow-up
3. Scam free lunch: “Sure, let’s go to lunch and talk about whatever and then I’ll mention I don’t/can’t buy anything.”
4. Direct and to the point: “Appreciate the call, but I’m not interested in anything at this time.”

We concluded that Option 1 and 2 hurt your ability to leverage the Vendor Sales Cheese’s assistance in the future when you might need quick access to senior, competent vendor technical resources due to the Vendor Sales Cheese placing a high value on people and relationships over logic.

Option 3 = Scam free lunch

Recommendation = avoid option 3 unless you have a high degree of confidence you will be buying something in the near future or have some useful customer information to share with the Vendor Sales Cheese

Sure, getting out of the office for a brief escape with all expenses paid by your Vendor Sales Cheese including the added sense of elevated importance as you are treated like a real customer sounds great; especially after being kicked around by the typical MidWestern IT political bureaucracy.  Part of the relationship maintenance burden that comes with being a Vendor Sales Cheese is to keep tabs on how their customers are doing.  Doing in the sense of looking for any opportunity to inject them selves into the pain reduction, “we have a solution for that problem”, drumming up another deal capacity.  Even if the Vendor Sales Cheese pitch is “hey, not looking to sell you anything.  I just want to get together and see how things are going …”, be prepared for the conversation to steer towards “the deal”.  You can’t fault the Vendor Sales Cheese; it is their job to bring in new sales.  But, you will quickly get labeled as “Bob, the free lunch guy” if you develop a pattern of getting together for the free lunch without having anything to offer the Vendor Sales Cheese in the meeting exchange.  As “Bob, the free lunch guy”, you will under mine your priority in the vendor’s mind as a strong customer resource and thus reducing the ability to reach out for extra technical help from the Vendor Sales Cheese when you critically need it.

Sure, a free lunch now and again isn’t going to solidify you as “Bob, the free lunch guy”; but make sure you have something useful for the Vendor Sales Cheese to bring with you to the lunch meeting.  What are some examples of something useful?  If you have knowledge of a current or pending re-organization plan, share the high level details that gives the Vendor Sales Cheese an up to date understanding of how the customer is positioning itself to leverage the vendor’s technology.  Note; don’t spill any specifics that you can’t share with anyone at the office or outside the office.  If you have knowledge of recently announced marketing plans that will drive up customer usage in a particular product that is leveraging the vendor’s technology, again, feel free to share the externally approved marketing details.  Get ready for the sales cycle discussion, especially if your licensing model is user count or user seat based.  Make sure you are clear to the Vendor Sales Cheese that these are marketing projections of increased sales and until the sales are real, no formal new licensing discussions can occur.  In this knowledge sharing example, you both win.  The Vendor Sales Cheese gets some positive news to take back to his sales management on potential future sales.  You legitimately have indicated the very plausible need for additional licenses in the near future if, indeed, the marketing projections turn out to be correct.  In short:

You = raise your level on the Vendor Sales Cheese’s priority list

Vendor Sales Cheese = useful information to take back to his sales management as well as a placeholder for possible future sales projection

Option 4 = Direct and to the point

Recommendation = Unless you have information that can directly translate into real, useful information for the Vendor Sales Cheese, this is your best option

I can’t count the number of times I’ve received positive feedback from Vendor Sales Cheese that  I’ve worked with over a good portion of time (multiple yearly sales cycles) that have shared with me their appreciation for the “direct and to the point” response to the “catch up” query.  The closer to the end of the sales cycle, the more pressure the Vendor Sales Cheese is under to bring in as many sales as possible.  Many have shared the frustration of thinking they have a lead and after investing a good amount of energy, get frustrated at seeing their investment disappear into a “Bob, the free lunch guy”.

So, you pass on the free lunch, you don’t waste the Vendor Sales Cheese’s time, so what else makes this a solid response?  In a word: respect.  Any strong, experienced Vendor Sales Cheese will recognize that you respect their role in the vendor management spectrum and will return the favor with equal respect.  They may offer some insight into what is driving the pricing constructs behind your next proposal or other bits of inside information for “the next deal”.  It may not be earth shatteringly helpful.  It may not be 40, 50, or 60% off the next order.  But, you will find your discussions and negotiations will be ever more direct, matter of fact and to the point rather than slick and filled with confusing sales speak.

Ok, respect the Vendor Sales Cheese role, how does this really factor into pricing in any way?  Look for the next article to pick up where this article left off with more MidWestern IT perspectives on the topic of the “Sales Cycle and Pricing” in the spectrum of vendor management.

About time to get a call from your Vendor Sales Cheese

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Categories

• Sales Cycle and Pricing

In the previous article, we concluded the perspectives on the role of the sale representative closing with the IT manager dividends that get paid from the Vendor Sales Cheese’s retained earnings if you permit me to use a weak accounting balance sheet analogy.  We stopped short of how the Vendor Sales Cheese responds and reacts throughout the sales cycle and their role in pricing.  This article will dive into this aspect of Vendor Management.

Vendor Sales Cheese and the Sales Cycle

If you have had any Vendor Sales Cheese interaction, you’ve probably noticed a slight pattern to the timing of the communications.  Do you notice you get more email chatter and messages on your voicemail to “catch up” or “hey, how about we get together for lunch” around the end of the month?  How about the end of the quarter?  Ever wondered why there seems to be more artificial urgency at certain times compared to others?  This pattern of communication timing all resolves around the “sales cycle”.

When I refer to the sales cycle, what I mean is the periodic deadlines, created by the vendor, that establish when sales activities get measured.  If you are familiar with application development, it is a parallel to a code freeze.  A point in time when all the <sales> “hey, I almost have customer X signing on the dotted line to buy a 1,000 user license of product X” and <application development> “hey, I have just a few more lines of code to write and feature number 375 will be ready for testing” have to stop and be counted.  For the Vendor Sales Cheese, who is always working on “the deal”, there comes a point where if there isn’t something in writing confirming the sale will be made at a fixed date, the “the deal” doesn’t equal “a sale”.

Now, I have always been representing the customer in the vendor/customer side of “the deal”.  I would appreciate if someone who has been on the vendor side of the equation to provide more depth and support for what is going on over on the vendor side of the equation.

From what I have been able to determine from my customer perspective, these “sales freeze” occur primarily at the end of the quarter and then again at the end of the vendor company’s fiscal year.  Note, not every company has the same fiscal year end.  Year end being when a company says “my year is done as of X date, start closing the accounting books on the current year.  Now open new books for the next year”.  Thus we come for the first recommendation for this topic:

• For every vendor, establish when their “sales freezes” are as well as their fiscal year end.

Once established, you will pretty much be able to predict when you will get a phone call from the Vendor Sales Cheese from each vendor.  The calls will come in a week or so before the “sales freeze” date with some predictable push to try and determine if you are in any position to buy something the Vendor Sales Cheese is selling.  As the calls come in, and they will, you will most likely be in no position to buy something, but before you go about your daily routine, consider:

Perspective = You are in no position/need/want to buy anything at this time

You have absolutely no need or want or desire to buy anything from anyone at this time.  Thus, the Vendor Sales Cheese calls, which you know are going to start coming in from various vendors as a “sales freeze” approaches, can be handled in a variety of ways:

Option:

1. Answer the phone with: ”Go away, I’m busy.”
2. Everything goes to voicemail with no follow-up
3. Scam free lunch: “Sure, let’s go to lunch and talk about whatever and then I’ll mention I don’t/can’t buy anything.”
4. Direct and to the point: “Appreciate the call, but I’m not interested in anything at this time.”

Option 1 and 2 = “Go away, I’m busy.” + Everything goes to voicemail with no follow-up

Recommendation = don’t use option 1 or option2

Sure, this might be the first response that comes to ones mind that is full of more pressing day to day technical issues.  But, remember a few articles back where the Vendor Sales Cheese role was introduced.  Once you have purchased and integrated a vendor product or solution into you and your team’s service back to the business, you, whether you like it or not, have entered into a symbiotic relationship with the vendor to some degree.  As much as you may think: “hey, I can just toss out vendor X and get vendor Y’s solution in here tomorrow”, know it just isn’t that easy.  Swapping in vendor Y’s solution means going through the procurement process, pulling resources from in flight efforts to your replacement effort, getting people to test something that seems to be working already and ultimately implementing the new solution which just replaces what is already inexistence.  You know this pain.  The vendor knows you know this pain.  Depending on the depth of the vendor’s solution integration with your critical business functions, the higher the switching cost and the Vendor Sales Cheese knows this as well.

Potentially more important, when you run into a technical jam that your team can’t work around, you really need the vendor to provide some expertise.  You’ll need the Vendor Sales Cheese to pull the strings needed to get you quick, expert help.  Sure, you might think no matter how hard you beat up on the Vendor Sales Cheese every minute, they still have to drop everything and give you top service the next minute.  But consider that the Vendor Sales Cheese has a big custom list with varying revenue streams and technical competencies.  If you aren’t the top revenue stream with a potential for additional new sales volume within the next sales cycle, you may lose out to the customer that better fits that profile.  The Vendor Sales Cheese is going to put energy into the customer that provides them the most potential new sales opportunity.  Most likely, you are not constantly buying from this vendor, thus you won’t perpetually be within this high potential customer range continuously.  Constantly blowing off the Vendor Sales Cheese will put you far down in the list of customers worth putting any additional effort towards and could come back to bite you when you need the Vendor Sales Cheese to step up and help you out in the future.

Not convinced?  Consider how much sales is the juxtaposing of your highly technical world.  Your highly technical world is based on logic, binary systems connected to other binary systems with a guaranteed root cause to every problem if you just dig effectively.  “Sales” is completely people and relationship based.  People and relationships are the opposite of predictive and logical.  You are content with a system that handles spikes in transaction volumes across varying payloads with statistically insignificant changes in CPU utilization.  The Vendor Sales Cheese is content with a potential customer who has a strong need for a product or service the Vendor Sales Cheese is representing who has revealed his or her emotional hand that they are “sold” on the product or service to the point that they are putting pen to paper, signing a letter of intent to purchase.

So, more convinced Option 1 and 2 hurt your potential future needs from the Vendor Sales Cheese?  Which remaining option is best?  Look for the next article to pick up where this article left off with more MidWestern IT perspectives on the topic of the “Sales Cycle and Pricing” in the spectrum of vendor management.