Friday, June 25, 2010

Engaging Vendors

Yes, vendors can be engaging and nice—especially when they invite you to dinner or to all-paid conferences. However, this topic is about how to engage with vendors—a topic that’s often neglected in IT management books and forums.  The more you rely on external products, especially in the context of IT transformation, where large budgets are at play, the more likely you are to have a long line of vendors knocking at your door. This is particularly true when vendors are desperately trying to meet their quarterly sales quotas. Don’t feel pressured. It’s up to you to manage the pace and mode of engagement with them. After all, the vendor decisions you are mulling over are likely to have a significant strategic impact, and ill-advised decisions could put you in a specific vendor prison for years to come. If you recall the section on tenets, I suggested that any technology transformation strategy be architecture-led rather than vendor-led.  You should always be in a position to choose or replace a vendor on the basis of your own needs and strict best-of-breed and cost considerations.
Still, it’s never painless to switch vendors. Nothing completely removes the migration burden imposed when switching vendors or changing the reliance on a specific technology suite.  This is why it is so important to identify early on which choices in vendor selection are strategic in nature, which are commodity led, and which have a chance of becoming too ‘sticky’ or addictive. For example, the choice of a data base vendor for your core data is likely to be strategic.  What about performance profilers? Not so strategic; especially if your tenets have you selecting best-of-breed components.
It goes without saying that the selection of a strategic vendor should be based more along the lines of choosing a strategic partner. It’s more like a marriage than a one-night stand. You are not simply selecting the product but the partner.  As a part of your vendor selection you are also selecting their vision, their culture, and most importantly a business relationship between your respective companies.  I am not going to sugar-coat it: if you’ve decided to go with a strategic vendor for technology transformation, it’s highly unlikely that you will go for a garage-operation outfit (the only exception being when you see an extraordinary value proposition or a potential acquisition play). Chances are that you will be engaging one of the “big-guys”: IBM, HP, Oracle, Microsoft, etc.  No need to apologize for this. You should, however, be wary of completely buying into their “integrated” value propositions.  You should be able to maintain some degree of decoupling and freedom when choosing a particular vendor as a base. Yes, chances are that in the end you will most likely purchase more products from the strategic vendor, but you will be doing so because it makes sense (the add-on product integrates better, it is part of a bundle deal, etc.) and not because you have to.
In the case when you need to select a particular point solution suite (not necessarily a strategic vendor), you will likely pursue the Request for Proposal approach. Coming from someone who has been on the vendor side as well as on the RFP issuer side, I would recommend the following tenets regarding RFPs:
·         Focus the RFP around your needs. Avoid over-elaborating the RFP with too much background about your company or other details not pertinent to the request at hand.

·         Select only those vendors that you truly plan to consider for the selection process. Too often I’ve seen vendors invited to an RFP purely out of political considerations or to meet an imaginary goal of “minimum number of vendors to consider”.  Remember that vendors usually have to spend significant effort and money responding to an RFP and it is not fair to have them go through the exercise if there is no chance in hell you’re going to choose them.

·         Analogously, don’t have an RFP asking for the vendor’s color of underwear. Be wary of assigning an RFP to be developed by someone who is overly technical. This person is likely to request extreme details that in the end might not even be relevant to the assessment. Clearly, the details requested by the RFP should be commensurate with the value of the business opportunity. Even then, discussions about details should occur during follow-up meetings rather than via a response the size of “War and Peace”.

·         Make sure the RFP explains all the key requirements, constraints, and criteria you plan to consider in the selection. Don’t make the RFP so general that vendors  can simply answer with a very high level response (Goldie Locks’ rule applies: “not too detailed; not to generic”).

·          Define the RFP selection process precisely and follow-through on it. Avoid sending the RFP out on Friday expecting a vendor response by Monday.  You may believe this approach gives you a good evaluation element by determining which vendors respond quickly, but I surmise that a vendor’s quick response is not an ideal indication of how well his product will meet your needs.  The purpose of the RFP is to obtain a set of responses that you can compare against your requirements.

·         Let’s be honest, if you already have a product in mind and merely want to validate your choice, don’t do an RFP. Don’t waste the vendors’ time.  In this case, I suggest that you are forthright with the alternate vendor. Call them up, explain the context of your query, and give them a chance to explain why their product is better than the product you are planning to use.
Treat vendors well and give them the time they need. Their alliance and partnership will be essential to the success of your project.
Given that you are involved with a presumably large IT transformation, chances are that you will also be approached by a myriad of intermediate and smaller size vendors, offering a variety of niche solutions. Now, I’m aware, when you are involved in your day to day activities, busy as hell, battered by the tremendous workload imposed by the running of a major project, those sometimes persistent calls from vendors with their incessant requests to meet, can become a major burden. As a busy executive, there is the tendency to ignore their requests and, frankly, to not treat them with the respect they deserve. I advise against doing this. I’m not saying you should meet with every single one, and risk death by PowerPoint, but I am saying that you should at least give a cursory glance to a vendor’s proposition (or at least have someone on your staff do so) by quickly checking his/her email or web site. My experience is that 99% of the time you will be able to quickly determine whether or not the vendor’s product has an immediate potential for application in your environment. If not, you should politely tell the vendor to check back with you at a later date. Most vendors appreciate this type of response and will gracefully go away—at least for the time being.  Still, there will be those vendors who continue to persist and persist and persist. With pesky vendors you do have moral ground to be a bit harsher in your refusal to engage them.
There will, however, be those cases where you are intrigued by a vendor’s proposition. Perhaps they claim to have a better way of managing services or perhaps they have a way to improve your systems performance that is patented and exclusive? Some of these potential benefits might not be applicable to your project today, but may be needed in the future. You can ask this particular vendor to call back within a specific timeframe, consistent with your project plan, and give them a chance to reengage. There will also be those times when you are sufficiently intrigued to schedule an immediate presentation from a vendor in order to learn more.
It is difficult to provide a general recipe of how to deal with vendors since, as in all human interactions, there will be those who are excellent representatives and others who are in the wrong business and should be selling used cars instead of software and hardware products. Just keep an open mind and take an objective view of their sales style and value propositions. Vendor whose sales tactics are suspect (e.g. badmouthing the competition, giving deceitful datelines, etc.) should be avoided.
Finally, once you have determined that a vendor may be suitable to your needs, have  established the requisite inter-personal trust and relationships with them, and agreed with the overall terms of their proposal and engagement model; it’s time to delegate the handling of the detailed negotiations and engagement to your vendor management team. If you are to preserve the degree of ongoing goodwill with the selected vendor as the project proceeds, other than for key decision selections you may be called upon to resolve, it’s best to avoid direct negotiations with the vendor yourself.
In the end, the best vendors are those who become as emotionally attached and excited as you are about the success of the project. Remember, a good vendor can be your best ally.

Friday, June 18, 2010

The Relationship between Technology and the Line of Business

Perhaps you have noted by now that I have repeatedly suggested the importance of having a good and respectful relationship with your business group and that their involvement and support is essential to the success of a technology transformation program. 
Without question, you should expect the business team to be the deeply involved during the early phases of the project. In the early stages you’ll need to work with the business partners to get the project approved (without their sponsorship, the project will simply not be approved), to define the detailed requirements, and to establish delivery commitments. Business should also be heavily involved during the later stages for purposes of project acceptance and delivery. Their role at that point will, by necessity, be slightly adversarial.  After all, they are one of the key players in determining the quality and success of the deliverable. 
The role of the business area during the execution phase of the project is not as clear.  The various business groups involvement during the execution phase will depend upon a number of factors, ranging from the cultural style of your organization to the idiosyncrasies of the individuals in the business teams. Another variable is the type of project, the specific deliverable within the project, and how well or how badly the project is coming along.  You may have a business team, perfectly happy to assume a “laissez-faire” attitude regarding IT as another form of “vendor”, and taking the position that they are your customer, to whom you will deliver the committed product or service.  At the other extreme are those business groups that firmly believe the IT organization to be their butler; tasked to do their bidding. Then, of course there are a variety of attitudes in between these two extremes. 
There are problems with the extreme views. Yes, if you are in a company that views technology as a commodity enabler, the perspective that technology is a “service” function might well apply. However, if you are in this type of company, you probably shouldn’t be involved in a transformation technology project to begin with. Let’s face it, a technology transformation project cannot truly succeed if there is a view of IT as simply a “vendor” or a “service-center” for the company.”  The days when the business could strike IT for being late with “the monthly report,” or could set arbitrary deadlines for those  “immediate changes to the way the discounts are computed”, and then have the IT folk limp away  Quasimodo-like with a submissive, “Yes, master!” are over (I know, many business friends of mine would easily argue that those days never occurred!). There is only one way for the business and technology teams to interact with each other when confronted with a major project such as a transformative project: as partners . . . equal partners.
Establishing an equal partnership view between technology and business tends to be more controversial than it should. Oftentimes this view is opposed implicitly, or even overtly, by certain lines of business.  You often hear, “The business is paying for this, and so it’s our prerogative to decide things.”  Reality is that the business group is not the one paying for the project; the company is the one paying for it, through the business. Everyone has fiduciary responsibility for the well-being of the company; not just the line of business.
The fact is, having the technology team act as an “order-taker” is only feasible under certain scenarios, such as when delivering a stream of tactical initiatives, or when delivering basic support services to the business.  The partnership- as-equals relationship is a better way to establish a decision making framework that will hopefully serve both respective governances.  This type of relationship also demands shared responsibility and the ability of the technology team to understand business needs.  For a trusting partnership to exist between business and technology, the technologists need to become acquainted with the business imperatives, while applying the knowledge and imagination needed to effectively leverage the emerging technology in ways that provide a clear competitive business advantage.  Technology should endeavor to proactively identify business enabling approaches, and to socialize and communicate to business the universe of what is possible, so that the business leadership can enjoy a wider menu of options and be better armed in the priority-setting exercises that are sure to follow.  Let’s not forget that, ultimately, to be deemed successful, technology must deliver a business benefit.
So, where is the line drawn in the decision making? First of all, I have never experienced even the most “hands-on” business team attempt to make detailed technology decisions when it comes to infrastructure choices. The types of router, firewall, hardware, or system management tools to use, for example, are decisions best left to the technology team.  Alternatively, it is not a good idea for the technical team to debate with the business team as to the aesthetic, branding or usability aspects of a user interface. Render to Caesar the things which are Caesar's, and to technology the things which are technology’s. Seriously, you can have your technical staff express their preference, but there are certain decisions that should be made by the business team, as long as they don’t have a true direct or indirect impact on the complexity of the solution.  For example, if the business team demands to use Flash for the interface, you can oblige, but don’t let them force development of business logic within the Flash scripts if it violates established architecture tenets.
 A partnership relation between the technology and business teams entails a balance of the sphere of decision-making, mutual respect (at the very least, the team making the decision should listen to the other team), and ideally should achieve some degree of consensus on the overlapping areas of decision making. This is easier said than done when the impact of a decision spans both the technology and business areas. An example would be the choice of a solutions vendor, or even the decision on whether to develop a certain capability internally or to purchase it externally. Even if you have defined a tenet stating that you will only develop solutions that match your core competencies, there may still exist gray areas open for debate.  For example, say you are selecting a campaign management vendor. Campaign management is an area that will typically have very high visibility for the marketing and sales business group, and rightfully so.  The business will likely have a strong opinion regarding the tools to be used, based upon the analysis of functionality and the perceived friendliness of the interfaces.  Technology, on the other hand, will want to evaluate the underlying architecture and standards used by the vendor, including the schemas used for customer data bases and the integration capabilities offered by the tool. Who decides in this case? The short answer is not “the one that screams the loudest.” Rather, this is a situation that calls for reasoned discussion and consensus building. You should always maintain the business arguments in the sphere of functionality. If your technical team is arguing for a different vendor or solution, you will need to validate if, in fact, the solution favored by the technical team meets the core business requirements (emphasis on “core”).  In the end, this type of debate might have to be escalated in order to obtain resolution. However, even if it is determined that the business preferred option is the one to be followed, you should ensure that the minimum integration objectives can be met. In the case where the business is pushing for an external solution (e.g. A Microsoft based solution when your entire platform is Linux based, or a solution that relies on the vendor’s proprietary architecture, etc), you will be required to explain the reasons why you and your team find this type of solution unacceptable. If you are over-ruled, you should make sure to document the reasons for your team’s position and the expected impact the decision may have. In the end, this latter outcome rarely occurs.  I believe that ninety percent of the time, a viable compromise can be reached. 
The key aspect to remember is to engage the business as an equal partner; not as an order-taking entity, and to include them in the project as much as necessary; while clearly delineating who is responsible for what decisions. It’s not always easy to engage the business this way, I’ll admit, but the alternative of enduring a dysfunctional relation is would make the success of the project very doubtful.

Friday, June 11, 2010

Culture, Style & Push backs

No, this is not a section best covered by one of those lifestyle magazines, but rather an area that is often neglected in books on IT management. Your leadership is all about imprinting a specific culture onto your team.  Whether your team works with a spirit of openness or secrecy, confrontation or collaboration, urgency or relaxation, depends upon the behaviors you promote as a leader. In IT, more than in other profession, a well-motivated team is likely to deliver greater results than a team that is discombobulated and demoralized.
Once you have set-up the team structure and staffed it with the best resources you can garner, you should strive to do the best with what you have.  Remember that driving a team is not unlike driving a car. You need to know what gear to use when turning or when going straight. Managers with a one-dimensional style fail to realize that a project is a living thing. Projects should be driven with precision and in line with the circumstances. This does not mean that you should relax the speed of delivery. “If you have everything under control, you are not going fast enough,” are the words of Mario Andretti. Not only should you expect to operate to the very limits of your control, but you should also accept that, if you have staffed your team with the right balance of skills and styles needed to achieve success, you should expect to deal with the negative consequences of personality issues, tensions, and frustrations.
And speaking of frustrations. . . Assuming that your transformation effort attempts to establish a corporate wide architecture, you are likely to find significant push-backs—especially in the area of architecture (tenets and standards, remember?)

Following are the top ten favorite push-backs I’ve heard:

1.       We have a time to market issue. We need to deliver this in two weeks. When the architecture is in place, we will migrate to it.
2.       I know you expect us to follow the new architecture standards, but I can’t afford to train people for it just now.
3.       I know you have some of the architecture running, but it has never been tested. We certainly don’t want to be the first ones to use it!
4.       I know you have the architecture running and it has been tested, but we’d feel more comfortable using our better-tested Excel macros.
5.       We are 80% architecture compliant anyway, so what’s wrong with the use of a different programming language?
6.       We like your architecture but it doesn’t really apply to our project.
7.       I not aware of this new technology, so it mustn’t be ready for prime time yet.
8.       I recently read in PC Week that protocol XYZ is better!
9.       You mean you really want to deploy this stuff? I thought it was only meant as PR to impress our customers!
10.   We really want to be compliant, we really do, but we think that sticking with Cobol right now is safer.
How do you handle these types of remarks? Well, tenets and standards are there to provide an overall framework to help align the enterprise as much as possible. But you do have to be flexible, particularly when the business drivers are such that, if you are not flexible, you could become road-kill. It’s best to accept that architecture exceptions are going to take place and codify an appropriate exception-process (even then, there will be exceptions to the exception-process, rest assured!).  Bottom line, evaluate the argument against the exception criteria, which will hopefully include minimum remediation to ensure the architecture process can be brought back on track. Is there a need to sometimes develop a cheap-and-dirty tactical solution to solve an immediate business need? Okay, no problem! Just make sure to fund the on-going work and make certain that this tactical solution is eventually re-factored into architecture compliance; plus take into account the migration from tactical to compliance.  I have discovered that sponsors of tactical solutions will rarely deny this very reasonable request. Other arguments may be easier to dispense with, but you should never, ever, close your mind to them.  Perhaps protocol XYZ is better and cheaper than the one you have been considering! Give everyone a fair shake and allow them to justify their rationale. If the argument was “religiously” motivated, dogmatic, or driven by some other precious self-interest, justifying it will be difficult. Still, if there is reason for considering an alternative, then please do so.
In the end, I circle back to the point of Culture. As long as the team is committed to the success of the project, and the reasons for the negative issues are frank disagreements based upon well-meaning differences of opinion, you should be able to manage the situation to your advantage. Think about it for a moment.  We all know that pressure creates diamonds and friction polishes them. In my experience many successes are brought to fruition under the heat of deadlines and in response to initial failures. If from the onset, you’ve seen to it to create a great team, you will get the results you want in the end. Just be sure to have plenty of coffee and donuts on hand to support the effort!

Friday, June 4, 2010

The Leadership Team

Let’s be realistic. Your resume notwithstanding, you are not Superman (Batman, perhaps, but not Superman!). It’s one thing to keep a pulse on the status of the transformation and to be aware of the skill sets of your team, and another thing entirely to have more than twenty-four hours in a day to manage the minutiae involved. If there is a single element needed to ensure success, it’s to surround yourself with a great leadership team—a group of direct reports, fully attuned to your objectives and capable of working cooperatively amongst themselves and with other corporate constituencies.
Mad Magazine once published a cartoon showing the Lone Ranger with his Indian sidekick Tonto, surrounded by attacking Indian warriors. The Lone Ranger turns to Tonto and asks, “What do we do now?” Tonto replies, “What do you mean by “we” kemosabe?”
Amusing because, well, it highlights the importance of being surrounded by a team that shares your challenges and whom you can trust in order when delegating. It also works the other way around. Your direct reports should feel comfortable when coming to you with any problem that requires resolution, knowing they have your trust. Still, a former US President used to say “Trust, but Verify.” From time to time you should reach out to the base levels in your organization in order to assess the morale and effectiveness of the entire team. If you are the type of manager who “walks-the-floor” (and you should be), you will be able to do spot-checks to directly determine whether your organization is running like a well-oiled machine or an episode of a bad reality show.
Beyond trust and alignment of purpose, you should also try to establish the right mix of skills in your leadership team.  Multidisciplinary teams will ensure you receive a variety of perspectives rather than the same, repetitive advice. Singularity of purpose does not entail singularity of opinion. Within this multidisciplinary framework it would be ideal to have a balanced combination of management and technology skills.
Be prepared to mentor your direct reports to ensure that, in the end, you have a team that is congruent with the values you wish to imprint. Intrinsic elements, such as excellence, satisfaction, work attitude, commitment and integrity, need to be defined and enforced in practice and not merely on laminated sheets or through mug-imprinted company mottos. They should be established by example and should be measured (sensed, more than measured) on a day-to-day basis.
When it comes to organizing your direct reports and setting governance, make sure to assign their roles to match their skills with the teams they will be overseeing. If you have a highly technical, self-motivated team, don’t have them managed by someone whose style is to micro-manage activities. In this case, you’ll do best to have a manager who’s not so highly technical and has a hands-off style.  Highly motivated,  technical teams need only a manager who can serve as a facilitator; someone who will remove obstacles and then get out of the way rather than someone who will try to direct them on a day-to-day basis.
Alternatively, some teams may benefit from a more technical-style manager rather than an administrative manager. If you have the kind of team whose genetic makeup requires they be more closely directed (traditionally, teams involved in the day-to-day operations tend to fit this profile), you will want to chose a manager whose style is more hands-on and more procedurally oriented.  Teams formed by junior programmers who are competent and yet inexperienced (these teams are usually put in charge of maintenance, but should not be), can benefit significantly from a manager who provides technology direction and mentoring.
Think of building your team in terms similar to a sports team coach focused on bringing in the right player and using him or her in the right context. In the end, most successful working teams, like most successful sport teams, become so primarily by the way they become unified under a shared culture.