THE CTO CHRONICLES

Entrenched Project Managment: The Dangers of Powerful PMOs

2011-06-22T15:52:00.001-04:00

I am speaking rhetorically here about the need for project management - of course there is a need. Think of the consequences when large projects are left to their own evolution (or devolution as the case may be). What I am really speaking of is deeply entrenched project management organisations where, in many cases, project managers become the star players rather than the people sponsoring the projects. The term "Scope Creep" is fairly well known, but I want to coin a cautionary phrase here - "PM Creep." This is where project management organizations become so powerful in an organisation that the project managers dictate time frames and deadlines instead of project sponsors and business unit executives. Nobody likes to talk about this, but it does happen. I like to think of it as Project Management's dirty little secret.

Entrenchment
So how do these PMO's become so powerful? Seriously, how often do you ever see a Chief Project Management Officer or the like? Alright - once in a while you do find one, but even then their power within an organisation is usually so limited that they are there to merely manage the overall portfolio of projects and ensure that symmetry and synergy are maximised. One term - "Entrenchment." PM Creep occurs because of entrenchment. Back in my business school days we studied the social phenomena surrounding managerial entrenchment and how it gains a foothold. In a nutshell the major driver behind entrenchment is defensive - in other words justification against takeover, reduction in power or influence, and an overall sense that by becoming more important security will ensue. And, to a certain degree that is true. The more valuable any employee, or group of employees, becomes the less certain their demise will be. But in most organisations this comes from a display of competence, effectiveness, and efficiency rather than trying to gain power. However, as more and more organisations adopt project management strategies, and even internal project management offices, many are discovering that PMO can, itself, lead to inefficiencies.

The Lazy Side of Life
Aside from the entrenchment paradigm there is another reason for Project Managers to become overly important - and this stems from organisational laziness. Shocked? Well, take a look around and see who volunteers to head up a project during your next staff meeting. You will find that many people are leery of doing so - some because it will interfere with their jobs, but most because it just scares them to death. So, the shining knight (also knows as the Project Manager) comes to the rescue. They have the skills to organise, and keep on track, the project that you are handing them. To some their organisational skills are mysterious, they have all sorts of charts and reports, and they speak in a strange language.

So after a while the default solution is "turn it over to project management, they'll get it done," or some such sentiment. And, eventually laziness is replaced by one time efficiency where the PMs help to get it done. But, over time, the PMs start to dictate the terms instead of responding to the situation and now you are hooked on the sweetest opium known to executives everywhere - project management.

The Good and the Bad - and the Ugly too
Now, don't get me wrong, I am not down on project management - far from it. In fact, I love it, and I think it is essential. But, just like external consultants I treat PMs as, well - consultants. I never let them dictate to me what my project is going to look like - I am, after all, the client and my time lines are often not of my making. Good project managers will understand this and work with, and around, it. Better yet, the best will divine ways of maximizing events to gain additional time, or slack.

But, it is those select few that become entrenched and forget why they are there in the first place. They become more interested in scoring political points, something that should be absolutely VERBOTEN in the world of project management. Once this happens a PMO becomes virtually ineffective, but sadly other areas of the company like to use it as a political tool. This is done, most often, to exercise a modicum of control over an area that they traditionally have little. Some CEO's also like to use a PMO as a means of tightening the reigns, but there is a fine line between reign tightening and killing morale or stifling creativity.

The Give to Get
Surrendering management over a project isn't something we should fear. After all, these PM's are specialists who perform a very important task - keeping targets in check and on within sight. However, it is important that we keep what they do clearly defined. As mentioned previously my preferred method is to treat the PMO as I would an external consultant. This keeps the line of responsibility much more clearly defined and it also makes for a better relationship. I am looking to the PMO for expertise, not control. After all, the project is still mine and so is the overall responsibility for its success.l

Market Data, CRM, and Business Intelligence - A Winning Combination

2011-06-22T15:35:00.000-04:00

For organisations in the financial services industries there are a number of options when it comes to acquiring market data. Some of the key players are well known names (household brands of a sort): LAVA (a CITI product), Bloomberg (possibly the premier provider of market data globally), IDC (another major player) and a few others. But one of the greatest challenges facing organisations in our industry that use such products is the integration with our sales platforms and, more importantly developing pricing information, and the integration with our business intelligence mechanisms.

As a large scale user of CRM and Business Intelligence our focus, as a business in the financial services industry (namely insurance, lending, stock trading, currency trading, and bond trading) is to not only obtain market data, but to place it into the hands of decision makers via a format that makes it possible to absorb the information quickly and make rapid decisions. It is here that integrating your products separates the heroes from the zeroes. And here is the kicker - you only get one shot at this or your credibility becomes a zero along with your career options.

This is going to be too short for a case study or white paper, but it can give you some insights into how you can easily tackle what can be a rather daunting problem.

TARGET RICH ENVIRONMENT

So we have three rather high profile systems that we are dealing with: CRM (Customer Relationship Management), EFDP (Electronic Financial Data Provider); and BI (Business Intelligence). To focus this discussion we are going to assume three key products that are highly commonplace in the market: Salesforce CRM, Bloomberg Terminal (the EFDP), and COGNOS (the business intelligence software). The next step is to focus on what it takes to integrate all three platforms, the process, and the end results.

As you can see these are all very critical platforms for any business, but when you talk about integration the possibilities for bringing down any one of these systems increases tremendously. That is enough to not only make you cringe, but it should frighten you into petrification. This is not for the weak of heart.

START AT THE MIDDLE
Let's look at the overall problem that we are faced with - there are two systems that are deployed in house (COGNOS and Salesforce) and one system that is essentially a service that you use to download information (Bloomberg Terminal). If you are reading this article and wondering what a Bloomberg Terminal is then you are likely not in the financial service / trading industry and should read no further as this won't apply to you. Since we are dealing with two in-house systems we are going to start in the middle by working on the components for integrating Bloomberg Terminal data into our Business Intelligence System (COGNOS).

Bloomberg Terminal (BT) is a bit different from many of its competitors and so there are a few things to know. One, information that comes across on BT is uploaded to an internal UNIX server that then feeds data across to end users. In some organizations the end user has a separate terminal and keyboard, but in others (such as ours) we use a toggle (or KVM) that we developed to enable end users to use a single or dual monitor configuration.

TAKE IT TO THE GOAL
The robustness of your infrastructure (in this case software) makes all the difference. In this quasi cloud world that we live in the push to virtualise everything has to be questioned more and more. For one thing you cannot virtualise a Bloomberg Terminal (although as of the date this article is being published that statement is true - the near future might turn that on its ear). Secondly it is all about performance stupid. Regardless of whether you follow football (soccer to some of you), hockey, or polo everyone knows that you have to punch the ball through the goal. The near miss phenomena abounds with horror stories where you get 99% there and crash - you are still D.E.A.D. dead!!!

Integration on this scale is no different. You need to focus... So, here are the key elements to get your integration punched into your goal:

Make sure you have a sponsor high enough in the organisation that heads will roll if a milestone is missed or if cooperation is short in coming (this is basic project management ladies and gentlemen).
Know what the limitations are up front - it is a fair question to ask your vendor to prove that they have completed an integration of this type, scope, and scale and to provide examples of their work (don't be the test subject unless you really want to be).
When it comes to financial data such as this you are talking about sophisticated client lists - many of which are proprietary and some of the portfolio information is INCREDIBLY SENSITIVE. So, make sure that you have your security in-line with what you want to accomplish.
Give yourself time to get each component aligned so that you don't end up rushing a deflated ball into play. There are no second chances in many cases - if you bring down your trading network you will be PNG - Persona Non-Grata in a very big hurry.
Know what you are going to do with this new configuration after it is set up. It is great to say you want these platforms integrated and talking to one another, but you have to know what you expect out of this excercise. Is it better performance, better information, more built in automated analysis??? There are a plethora of reasons to do something, but finding the one that drives decision making is the one that matters here.

The flow of information in terms of pricing and how we deliver a message to our clients that keeps us competitive as well as responsive makes all the difference. Gathering pricing information that makes sense to us internally is irrelevant unless this new integrated framework can help us deliver the same information to our clients so that we can drive sales. You have to focus on what the overall target is and that, my friends, is to increase our transaction closure rates.

Expand your universe with IPv6

2010-04-07T19:00:00.004-04:00

The internet is running out of addresses. That is what they keep telling us. The IPv4 block is simply inadequate - and given the expansive nature of internet adoption this might be true, but are we really running close to the end of the internet?

Most Regional Internet Registries have said that 2010 or 2011 would mean the end to IPv4 with the vast majority saying that their allocation of IANA ip addresses would be exhausted in early 2012. But is this really true? Honestly - the answer to that question is really moot because IPv6 is coming whether you want it or not.

So - let's talk about what plagues IPv6 implementation. Having done several of these conversions I would like to share my insights into how to make your IPv6 transition a headache free event.

The Dual Stack
Until IPv6 becomes a reality there is really no getting around the fact that IPv4 is still the standard. So, you have to allow for that. The only way you can manifest IPv6 and IPv4 is to "Dual Stack" your configuration. But understand that you have no options here - IPv6 is coming and you cannot wait until it is a reality or you risk being shut out of the internet altogether.

So, what does "Dual Stack" mean to you? Simply put it is the operation of IPv4 and IPv6 in a single environment using both IPv4 and IPv6 hosts. By adopting such a hybrid implementation programmers can write code that operates on both IPv4 or IPv6. Such software would use hybrid sockets which would accept both IPv4 and IPv6 packets. Used in conjunction with IPv4 communications, a hybrid stack would use IPv6 internally and the present IPv4 addresses as IPv6 addresses in a specially masked format.

This specially masked format is essentially an IPv4-mapped address with the first 80 bits set to zero, the following 16 bits set to one, and the final 32 bits are filled with the standard IPv4 address.

There are pitfalls to the IPv4-mapped address. One is that some O/S's don't support the hybrid format due to security issues or protocol issues. So - look at your O/S on a case by case basis. Microsoft O/S uses IPv4 and IPv6 in separate implementations so a separate socket has to be opened to support each protocol. Linux O/S use the IPV6_V6ONLY socket thus making a hybrid dual stack somewhat problematic.

Tunnelling
Without going into all of the various methods and techniques, tunnelling is a viable option for those who look at dual stacking as an overly ambitious project. Tunnelling is basically using a device or software to translate IPv4 addresses into or from IPv6 addresses before any packets are transferred to the internet.

There are various tunnelling options - Automatic Tunnelling (i.e. Teredo), Configured Tunnelling (formerly known as Configured and Automated Tunnelling), and Proxying. All work in similar ways, but differ in the approach taken (translation of IPv4 into or from IPv6, but the procedure for doing so changes).

The Box
Your equipment is going to be the first place you must look to making a change. Basically put, you have to contact the vendor who supplies your routing and switching equipment and see if your current version will support IPv6 and, more specifically, if it can perform any IPv4 / IPv6 translation. If the answer is no then you need to be prepared to upgrade either the device operating system or replace the device altogether.

Best practices for IPv6, for most early adopters, is going to be the use of devices as a translation mechanism. Think of it as IPv4 to IPv6 NAT. That might sound a bit simplistic, but it is essentially just that simple (don't get bogged down in the complexity behind the scenes).

The Provider
Contacting your Internet Service Provider is also critical - find out from them (in very tedious and specific detail) what their plans are for IPv6 adoption and discuss with them what you must do to ensure ZERO interruptions in your service. Don't take "I don't know" or "nothing" as an answer - somebody there knows something so escalate until you get a satisfactory answer.

If you don't feel as though your ISP is being forthright with you, or if you feel that they are unprepared, you should consider making a switch (if that is an option).

VOIP can kill you
With the introduction of vast VOIP networks IPv6 is being adopted as the standard by many carriers (especially 3G and 4G networks) as the standard. Internally VOIP works well across IPv4, but, as VOIP networks expand universally (especially in the mobile telephony space), IPv6 adoption is becoming an absolute necessity.

The End Game
Making the decision to adopt IPv6 isn't really going to be yours. At some point it will happen and your organization needs to be prepared. The hype of IP addresses running out on the internet should not sway you (CIDR and NAT have delayed the run-off of IP addresses), but preparedness is part of business.

Preparedness aside, there are benefits to IPv6 implementation that can be a boost to your business: Security (it will be easier to detect the sources of malevolent activities); Scalability (device to device communication can be greatly expanded); Cost (IPv6 has significant cost advantages for current networks, and for developing larger scale networks required by industry).

Overall the move to IPv6 is a growing reality. Being an early adopter doesn't need to be your goal, but having a plan should be.

The Art of the Deal - Lessons in Successful Vendor Negotiation

2010-02-08T21:35:00.008-05:00

Negotiation is part of life. If you don't believe that then you've never had kids, a job, siblings, nor parents for that matter. My son understands negotiation. At three years of age he already tries to deal - tell him he can only have 1 of anything and he quickly moves to his primary negotiating tactic of "I want three." We sometimes settle at two, other times he loses that second in favour of an alternative - a song, a story, or maybe just some of my time during a busy day. Did he win? Yes, but only sort of. Winning while giving the perception of losing is a fine art - one that the best CXOs understand very well.

Vendor Strength - The Great Lie

Without getting into the various scenarios that can impede or complicate negotiations, it is safe to assume that most vendors tend to approach any new deal from the standpoint of being in the driver's seat. This is even more true when you contact them for information about their product or service. No matter what the situation is, these lessons can help you shift the balance of power in any negotiation to your favour.

Lesson 1 - Know when to Hold'em

The vendor wants a sweet deal, you've been placed on a short leash in terms of spending, and you need to get the product/service/upgrade plan in place before year end (all cards that you play very close to your vest). Lesson 1 in the art of the deal - never, and I mean NEVER, put all your cards on the table. This is important because the only tool you have in negotiating with a vendor is knowledge - knowledge about your company, time table, budget, etc... The old adage "knowledge is power" is 100% true. Deciding when to divulge your knowledge is critical. My favourite tactic (but by no means my only tactic) is to figure out how much stall time I have before I need to present a decision and then I use as much of it as possible. Making them wait is often a key to ultimate success, but you cannot let them know when you need to make a decision - NEVER PLAY YOUR CARDS UP FRONT!

Lesson 2 - Them that have the Gold

Them that have the gold make the rules!!! In negotiating you always have to figure out what the gold is and who has more of it. In many cases it is, pure and simple, CASH! For the vendor their gold is the services they perform or products they deliver. They put a value on their treasure and it is up to you as the negotiator to help them see that they need to surrender some of it. If this sounds like war that's because it is. Some wars are fought till the utter defeat of your enemy, other wars are fought to a stalemate, and still others are fought over turf / ground / land etc... My strategy is to always (and I mean always) play down the other side's hand even when they call your bluff. Also, you should try to keep other options open so that, even if you end up paying a little more this time, you can come back later and renegotiate with the same set of vendors. At some point the cost of something, on a marginal scale, has to make you look at walking away and trying a new tact all together.

Lesson 3 - Go to the Mattresses

In Godfather parlance this means getting ready to do battle. Negotiation means you have to study who you are up against. A common mistake is to invite a vendor in to speak with you without studying them ahead of time. When you are thinking of buying a new car you do some research and try to find the best deal. Well, vendor negotiation is very much the same. Don't be afraid to ask to speak to references beforehand - and tell them you will be wary of any reference that is too glowing. Part of Going to the Mattresses is respectfully undercutting the quote to a somewhat ridiculous level (if you ever get to that point with a vendor). Some might say that this is insulting, but there is nothing insulting about cold hard cash and you only get one chance to get a rock bottom price - so you have to ask for it.

Lesson 4 - Playing Hard to Get

It is alright to play hard to get, so long as you understand that at some point you will want to dance with someone. You cannot let your emotions get carried away and never under any circumstance get to a point of feeling sorry for a vendor or their representative - this is business and if you allow emotion to sway you then you can kill your own career in a hurry. That doesn't mean that you don't want to develop a relationship. Like I said, eventually you want to dance with someone, but keep in mind that the vendor is going to be looking after their bottom line so you had better be looking after yours.

Le Coup de Grace

Once you are at the point of signing on the dotted line you cannot forget that this is but one battle in a never ending war. Now, don't get the impression that your relationship with the vendor needs to be venomous or toxic, quite the opposite is true - you need to develop a keen relationship with your vendor representatives and people in your vendor's back office. It is these relationships, often built during hard fought negotiations, that will largely determine the success of a partnership - not just the technology, product, or service to be delivered. Much respect can be earned for being a tough but fair negotiator, on both sides. At the end of the day you need to be able to work with those you have contracted with.

Also Published on The CTO Forum

Virtualization: Factors for Virtual Server Adoption

2010-01-23T10:37:00.006-05:00

Many of us understand the nuances to server virtualization - you take a server, you replicate the server into a hosted environment using some sort of Virtual Machine Software and then you retire the physical machine from it's former purpose. Sounds simple, and for the most part it is. Software products like VMware have made the process very simple and have made virtual server utilization a very commonplace event. But, in the mad rush to virtualize everything there has to be an evaluation of what to virtualize.

Everything is Beautiful
I recently attended a conference where virtualization was the hot topic. One CTO even boasted about how many physical servers he had retired - it was impressive. But, when I asked him what his effective throughput rate or transaction rate was with the new virtual environment as opposed to his physical server infrastructure he gave me a very blank look. It is not an uncommon occurrence - many top IT professionals don't look at their metrics before they do something, and then have no idea how they have helped, or hurt, themselves.

The obvious positives of virtualization are clear - lower power consumption, simpler server duplication/replication, easier server management, simpler IP address and VLAN management, etc. The Aberdeen Group conducted a study in 2008 which outlines some of these issues. In it they found that organizations experienced 18 percent reductions in infrastructure cost and 15 percent savings in utility cost by virtualizing their server environments.

But, there are times when other performance measures need to be considered. There is a quantitative aspect to everything - that is a given, but there is also a qualitative aspect to most things - and that is often more important.

Honey, I shrunk the server!
So - this CTO took his server environment from 180+ servers to fewer than 60. What did he virtualize? In his own words, "everything." And he did, I followed up with him and they have virtualized everything, but after our meeting at the conference he began to think more on what we had discussed about performance and throughput. Since he had no metrics prior to virtualizing he had to use a more ad hoc method - user feedback. This is often problematic unless you have vetted the responses objectively.

To his chagrin he noticed that trouble tickets related to his BES (blackberry enterprise server) had risen by 25% in the 30 days since that environment was virtualized. A huge rise given his company has more than 1300 Blackberry users. If only his people had done their homework ahead of time they would have realized, based on other companies experiences, that BES can be virtualized, but there can be some sever IO penalties and performance can (and most often does) suffer.

To P2V or not to P2V : that is the question?
E-Commerce systems were some of the first to be virtualized because of their, typically, web based components. Web servers, typically, do very well in a virtualized environment. Some will argue that virtualization was made for web servers and internet application servers. But is this a global truth? There is a great deal of evidence that virtualization can muddy the waters when it comes to performance.

The Aberdeen Group's June 2008 report shows that organizations can experience up to a 9 percent loss of overall revenue if issues exist with business-critical application performance. Seventy Four percent of the organizations surveyed also reported problems with application performance which coincided with a significant drop in customer satisfaction.

A key challenge for organizations adopting virtualization is effectively managing application performance in virtualized environments. The capabilities required in a virtual environmetn were not necessary when these organizations were looking to achieve the same performance goals in physical environments.

So, it isn't just technological hurdles that need to be overcome, it is also mindest and personnel factors that need to be upgraded when making the move from P2V (Physical to Virtual).

Full Speed Ahead...
One of the biggest uses of virtualization is server consolidation. Many larger companies had, for the longest time, multiple data centers that interacted and interfaced continually (or using batch processing). Users in each location logged onto their local servers which then exchanged data between sister servers in other locations. WAN traffic was, thus, consolidated and data greatly compressed.

With virtualization, many companies have opted for more centralized computing environments. So, users in Europe now have to log onto servers in the US, whereas before they logged onto servers locally. WAN traffic then starts to increase and system bottlenecks become more common. These are not abstract observations or "what-if's." They are real life occurrences that companies have experienced. Because of the increased WAN traffic, the end user experience, for internal and external users, was not improved and actually degraded.

Thus the moral to this story - PROPER PRIOR PLANNING PREVENTS POTENTIALLY POOR PERFORMANCE. Your choice, when dealing with bandwidth issues, becomes larger pipe or better use of it. For many companies, the gains they see in virtualization can be quickly wiped out by the need for larger internet or network bandwidth. Thankfully, for many, WAN accelerators can be put in place, but it is always better for this to be considered as part of the initial virtualization plan instead of being an afterthought.

Recap
Here are only a few factors to consider when making the move from Physical to Virtual environments:

Obtain performance metrics for as many aspects of your physical environment as possible so you can actually see what has improved and what has not as a result of virtualization.
Identify, in advance, what technologies are not suited to being virtualized.
Consider what you are consolidating and look at bandwidth as a factor - you can recover from poor planning, but you only get one chance to make a good first impression.
The WAN is often more sensitive than the LAN - look at what impact virtualization will have on your Wide Area Network.
Ensure that visibility into your entire transaction flow is not lost by moving from a physical to a virtual environment. This is one of the areas where individual server statistics can be obscured in a virtualized environment.
Measure the quality of your end user experience before you start a virtualization project.
Identify ways of managing your Service Level Agreements around applications hosted in a virtual environment.
Anticipate performance issues in the planning stages of your P2V project. The more you think of ahead of time the better the overall experience will be for all involved.

This list is by no means definitive, and best practices would be the forum for another article. However, these factors are meant as a beginning point and as a means of initiating the thought process before engaging in a virtualization project. It is the minutia that will kill you (or your career) when it comes to high profile projects of this magnitude.

Also published on THE CTO FORUM

The Language of a Leader: the modern CIO

2009-12-13T17:41:00.010-05:00

The modern CTO/CIO doesn't often get the luxury of being misunderstood. Their peer group requires well thought out, coherent (perhaps even elegant) language that is long on detail while, at the same time, short on technoese. Those of you who have experienced technical conversations between those speaking fluent technoese and lay business people know of what I speak.

Such conversations go something (albeit not always exactly) like this. The technoese speaking person starts off and the lay businessman/woman listens intently for the first 2 minutes hoping to become wiser and more in tune with technology. Soon, the blank stares appear followed by the glazed over expressions in their eyes, and finally a confused (if not angered) look on their faces. The techie has just lost their audience, but also their opportunity to gain buy-in for their idea or proposal.

Enter the CIO
This is where the modern CIO earns their money. Conceptually a CIO is hired to implement, manage, expand, streamline, and promote the best use of technology for the company. For many years though there was a hidden reason behind the CIOs vital role - to translate for their peers and provide a communications barrier between the technoese speaking minority and the business majority. That role is no longer a secret.

CIO job descriptions routinely include explicit language about their role as a top-level communicator. In fact, some larger corporations hire CIOs less for their technology skills and more for their ability to communicate, influence, sell, and manage others. Such a non-technical CIO/CTO can be dangerous also. The lack of deep seeded technology background has led to some very costly business decisions (I would like to use RBS as an example) - solutions are often sold that are not needed and, in reality, do detriment to the organization. In some cases the CIO/CTO lacked the technical background to understand the fine points involved in delivering on plans sold to a naive peer group.

It's the Audience - Dummy!
Having come into technology through the back door (I was a businessman before I was a technician) I learned, early on, the value of communication at all levels. One of the precepts to excellent communication is knowing your audience. Always make the assumption, when you are communicating with others (unless you can guarantee otherwise), that your audience knows less about the topic than you do, and that your audience is less technically conversant than you are.

Not to make your peers seem like morons, because they aren't, but you have to dumb down the technoese a little bit. Ease them into it, define your terms along the way into easily digestible bites. Remember, if you were in a room of actuaries you would probably come away feeling as ignorant of their lingo as they would be of yours.

Play it again Sam
Another key communication tool is to repeat what you just said. I actually refer to this as a reiterative tool. You don't need to become redundant in your conversation, but after you make several key points it is a good idea to put forward a quick summary of what you just said. In many presentations I actually paint high value targets 3 times so that at the end of my communcation everyone at least knows the main points.

Another reiterative tool is the follow up. If I am trying to get a plan or initiative put forward I find ways of tying it into other communications. Having stressed my points before, I subtely drop them into future emails, presentations, proposals and discussions.

In this way you will find that people pick up on the importance of a topic without feeling beaten with it. Remember, subtlety is key!

Killing the Messenger
If you have not heard this expression then you need to be aware that there are times that you will be communicating with hostile audiences. In ancient times when kings were sent messages that included unpleasant news they would often kill the messenger out of rage - thus the term "Don't Kill the Messenger" was coined. Such situations are unavoidable at times and you need to prepare for them.

Now - there are shades of gray here. In some cases the people in your audience are just simply not interested in what you have to say. In such cases you have to lighten the conversation, make it personal for them, and give them a sense of fellowship in your cause. An example of this would be going in front of your board of directors with a proposal requiring a bunch of treasure to expand your infrastructure. You should expect or anticipate a bit of ambivalence. The way you bring them to your point of view is to actually know them a bit - what are their key priorities for the company, what are the key initiatives they are discussing and how can your proposal help to accomplish them?

For the truly enraged audience there is little you can do but make your points and try to escape with your career. It seems blunt and a bit cynical, but sometimes you cannot calm people down. A case on point - giving a speech to a bunch of employees and telling them that this is their last day on the job and that you are closing the plant. If you expect cheers and hooray's then you must be heavily medicated. Sometimes there is just no good spin on things. Do you think that telling them "we are sending you on a very long unpaid holiday" will really make a difference?

Follow Through
Your communication is built on history. By that I mean when you have a dialogue your effectiveness is based on whether you have a history of delivering on what you have discussed and whether or not you appear knowledgeable in your prior communications history. People will remember the most amazing things - many of which are not what you wanted them to remember. So, keep in mind that everything you say will, at some point, come back to you - even if you change companies.

Once you become known as a person that paints a tainted picture you lose credibility. In this game we call life credibility is really one of the few things we have to offer. So, prepare yourself and be knowledgeable. You will require information from individuals and there are times you will have to trust that information, but due diligence is never to be abandoned for the sake of a quick response. It is better to delay what you want to say than to rush something into production that has a questionable amount of truth to it.

The old adage "it is better to be silent and thought a fool than to speak and remove all doubt" has a great deal of truth to it. So, be clear, be concise, review what you want to get across, be truthful, be effective, be sincere, review what you want to get across, summarize, emphasize, and you should review what you want to get across!!

Also Published on THE CTO FORUM

The Critical Path - Right Thinking, Right Decisions

2009-12-10T21:07:00.005-05:00

Failure, in most endeavours, is a matter of effort. If that doesn't strike you as odd then you are one of the few who sees that while success is a matter of effort, so is failure. Look around you and you are likely to see a number of examples where projects, people, or companies purposefully fail. It isn't their fault, they just don't understand that their efforts can dig their graves as easily as build a foundation for success.

Chopping Wood

The first time I heard this term was during my first year at university. The professor who extolled the virtues of hard work cautioned us against working hard without also working smart. In his analogy he used, as an example, woodsmen.

Two woodsmen go out, each with the same type of axe, in the same forest, and each select a tree of comparable size. The first woodsman comes to his tree and begins chopping at a furious pace. No preparation needed, just slam at the tree with the axe and keep going in hope that, at some point it will be felled. The second woodsman comes to his tree and the first thing he does is look at the way it is shaped, which side it is weighted on, and then he does something unexpected - he sharpens his axe. Quickly felling the first tree he moves on to a second, and then a third - returning to the lodge reconciled with the accomplishments of the day.

Which do you think achieved the better result? In truth they both felled trees, but the first woodsman returned back to the lodge well after dark having sent chips flying everywhere with a single tree felled. Exhausted, he sees the first woodsman relaxing and is nonplussed by the fact that he worked so hard to accomplish a lesser goal.

The purpose behind this professor's story (and one that I have never forgotten) was to provide students with a fundamental truth - preparation for the task has an impact on the overall success of the task. Merely tackling the work is not a guarantee of success, and we can see that the definition of success is relative - clearly each of the woodsmen felled trees, but the second had a far better outcome.

The Road Not Taken

In 1915 Robert Frost wrote a poem called "The Road Not Taken" in which he described how following the road less travelled made all the difference. It is one of my favourite poems and is an expression of unbridled individualism. What does this have to do with finding the critical path? It has everything to do with it.

Many of us feel more comfortable treading the same path that others have taken - in most cases it has more to do with the perception that we are building on the success of others. In reality it gets us accustomed to being the next mule in the train, rarely thinking and often just duplicating the work of others.

While it isn't a requirement that you be a trailblazer in order to create (or identify) the critical path, you cannot be afraid of it. In fact, you have to be willing to embrace it. Part of being successful on any mission is finding ways to do things that have never been done before - that is how technology has advanced so rapidly in the last 150 years. Innovation can follow only two paths - finding a way to do something better than anyone has ever done it, or creating something new that nobody has ever seen, considered, or tried.

The Critical Path - Defined

So what is this critical path - I suppose that it is important to define what we are discussing, but most of you (if you have been in technology for any length of time) know what I am talking about. The critical path, put simply, is the chain of events - from beginning to end - where all of the crucial markers exist. It is like a journey of sorts - if you miss a key milestone you end up taking a detour that prolongs the journey. Such a prolonged journey diverts vital resources from other endeavours - money, time, personnel, equipment, and so on.

Sometimes the milestones are not clearly visible. A keen manager is aware of this fact and pursues the identification of such markers. Seasoned project managers (and the ones most valued in any organisation) are experts at seeing the road signs hidden among the thickets.

Consistency of Purpose

At school as a boy I read a quote by Benjamin Disraeli that set my path in life (http://www.britannia.com/bios/disraeli.html) - "The secret of success is consistency of purpose." This applies perfectly to The Critical Path. The goal should define the purpose which in turn defines the actions one takes. It is, after all, a chain of events that defines life, but in a less general way ultimately defines success for any task. Stray too far from The Critical Path and you find a jungle teeming with unknown perils. That doesn't mean that you have to follow the same path as everyone else, and it does not mean that The Critical Path is the most safe. What it does mean is that The Critical Path is the most efficient as well as the most productive chain of events in the process of task completion.

Staying on this path is difficult, and so Right Thinking is crucial. So what are the keys to Right Thinking:

Know your own patterns of thought - some of us are quick on our feet, others require pondering to make good decisions. Understanding how you think will help you make better decisions.
Be aware of what you are truly being asked to do. Understanding the ultimate goal is fine, but understanding the subset of goals is just as important. Break down a task into key components and prepare your tools for each.
Every stage is important. Think of flying an aeroplane - you took off safely, had a perfect flight, but the landing was terrible and everyone dies. Two thirds of the flight went perfect, but that doesn't mean you were 67% successful.
Borrow a brain. You cannot be expected to know everything, and thinking this way is not only arrogant but it often ends up in self destruction. Bring people on board who can add value and mental resources to accomplish an individual or overall goal - and don't be stingy with credit for good ideas.

Synopsis

There is no easy road to victory. Polybius (http://www.hup.harvard.edu/catalog/L138.html) said it best more than 2000 years ago - "Those who know how to win are much more numerous than those who know how to make proper use of their victories." As true today as it was then, your critical path is not just the road to success or victory, it is the methodology by which you build on one success after another.

Succeeding at one point along the way doesn't mean ultimate victory - it is merely one milestone toward ultimate success. The Critical Path in any project is not only the whole, but the sum of all the parts.

Everything as a Service - The Future of Cloud Computing

2009-12-06T05:49:00.009-05:00

As IT professionals there are very few of us who have not heard of SaaS (Software as a Service) or AaaS (Application as a Service) and now the ultimate acronym EaaS (Everything as a Service). If you are an IT executive and haven’t heard of at least one of these terms you might want to reconsider your role in the realm of technology. These cloud computing solutions are here now, and it appears that they are here to stay.

THE MARKET
Much discussion has taken place about the future of cloud computing, the types of applications that can be turned into outsourced or hosted solutions, or even the complete dismantling of the current technology environment by virtualizing everything. HP, and other companies, are betting heavily on the future of cloud computing. Over the past few years HP has acquired more than 10 different software companies in an attempt to position them as the market leader in the EaaS market. Such venerable institutions now under the HP banner include Mercury and Opsware.

But what is the true future of cloud computing? Thinking long term has never been a strong suit of large companies like HP or IBM. They are positioning themselves to capture market share, not to expand the realm of cloud computing service offerings. The true pioneers in the EaaS market space are smaller companies like Evolution CE (specializing in Open Source Cloud Computing) and researchers (such as those working on solutions like SnowFlock http://www.scs.stanford.edu/~rumble/papers/LagarCavillaEurosys09.pdf), who are taking cloud computing solutions to the next level.

THE FUTURE – SORT OF
The ability of software systems to intuitively predict user behavior, or assess corporate computing needs, is indeed the future of cloud computing. Running applications or software across the internet, even across secure pipelines / VPN / SSL is being done and has been done for the past few years. ADP (the world’s largest payroll solutions company) has had a cloud computing solution across VPN for at least 3 years and it is widely used. But, the real future for cloud computing is the true virtualization of scalable systems across geographical boundaries. Intuitive in nature, such systems would be easily replicated, duplicated, or failed over by design. This “cloud clustering” concept is in the proof of concept stage in test facilities in the United States.

Not only would such systems be available as a human interface, but manufacturing systems could be operated globally. Via complex and intuitive intelligent computing General Motors could simply allocate that 25,000 of a certain vehicle be built and the system would instantaneously calculate which factories around the world had the capacity and would then analyze cost data to determine the overall cost (including logistics) for distributing such vehicles from the various locations. An incredible feat that is currently handled manually because the global computing systems do not exist which can control robotics, MRP systems, shop floor systems, etc… in a seamlessly integrated worldwide solution.

GLOBAL CLOUD COMPUTING
Think of a cloud environment as a single computing center and then combine various virtual computing centers around the world where resources are drawn as needed – computing center “A” is too busy so computing center “B” is chosen as the next resource in line. It is the ultimate in virtual load balancing. Likewise, virtual storage centers can be set up as virtual “SAN’s” across the globe. Instead of load balancing one hundred servers in an operations center you end up load balancing one hundred cloud computing environments. The end result - Everything as a Service, available around the globe, all of the time, with literally unlimited storage and computing power. This creates a seamless interaction between end-user and application in which available resources can be allocated globally.

Such geographically dispersed environments have tremendous advantages. For one, disaster recovery becomes moot. Unless the entire planet is stricken by some malevolent force or a global catastrophe wipes out all life on the planet it would be virtually impossible to destroy the computing needs of a going concern. And, if such events did occur there would be few of us left to really care about whether or not Tata Motors could still operate its robots.

THE PIPELINE

That sounds idealistic and even unrealistic, but when you think about it the technology nearly exists today to make such systems a reality – the right combination of innovation and investment could bridge the gap quickly. There is only one problem that has yet to be solved, and it has been the bane of internet based technologies at every level – BANDWIDTH. The truth about cloud computing is that no matter what service you offer, nor how large the operations center, getting information to flow is based on bandwidth and it comes at a premium.

Need more storage capacity in your operations center – go buy another NAS. Need more processing power – go buy another server or upgrade. However, you cannot just add another internet connection. At some level you simply run out of pipe – the fiber is completely utilized, there is no more copper, and satellite bursting is very pricey. It is an infrastructure issue that can only be solved by laying more fiber-optic cable, adding additional routing, and finding more efficient ways of streaming packets of data from point “A” to point “B”.

REBELLION
Archaic laws also need to be beaten into the dust. Data storage laws that prohibit information from transcending national boundaries need to be re-examined. The old way of thinking whereby “They that control the data control the power” is outdated. The true power comes not in owning the data, but in doing something with it. Truly distributed and virtualized data architecture actually fosters the integrity, security, availability, and redundancy of data.

Under the pretense of protecting confidential information, governments around the world – yet again – fail to tackle the actual problems of securing data. A hacker is little deterred by the fact that data sits in France instead of Thailand. And, there is little evidence (ok there is no evidence) that shows any one country does a better job of securing data than any other country.

TRUE INNOVATION
Innovation in cloud computing cannot just stop at providing software to a customer; it has to expand into providing “A SERVICE.” If we truly are reaching the point where there is an “Everything as a Service” offering then we must expand what we mean by “Everything.” Currently most companies like HP really mean ALMOST EVERYTHING as a Service.
Virtualization of existing client-server platforms is far from innovative and in this race - the cloud computing race - it will be the innovators with the best products on the most diverse platforms across the most dispersed area that ultimately succeed.

Also published on THE CTO FORUM

Risk Management & the Cloud

2009-11-19T09:47:00.006-05:00

Recently I engaged in a conversation with other top level IT executives about the nature of cloud computing and some of the challenges and opportunities they’re facing regarding risk management. Some in the group felt it wasn’t appropriate for their environment while others embraced SaaS (Software as a Service) as an opportunity. No matter what, at the end of the spectrum you find that regarding cloud computing there is a risk management component that each enterprise must address.

What is cloud computing - In a nutshell? It is simply a dynamic environment where scalable and virtualized resources are provided as a service over the Internet (SaaS for instance). It sounds simple – create an application, build a virtual architecture to support it, and offer it as a service over the internet. The reality is far from simple and can be one of the most challenging service delivery mechanisms in information technology. But, the topic here isn’t focused on security per se, nor on the ROI concerns or even operational prerogatives. Instead, I want to limit the topic strictly to risk management as it relates to the cloud.

What is Risk Management?
In practice few organisations have formal risk management processes, or at the least they have an overly optimistic view of what their risk management assessment process is. If this is true, and it most likely is for many organisations (speaking with risk management experts the consensus is that it is true), how do you break down the components of risk management and what role do they have on the decision making process?

Let us first address what risk management truly means. Simply put it is understanding the various factors (law, regulation, business) that contribute to risk and formulating strategies to mitigate such risk. Essentially there is Legal Risk (the risk of losing a lawsuit or of being sued); Regulatory Risk (the risks involved with regulatory compliance and mandates); and Business Risk (risks associated with business continuity – i.e. the going concern question).

Legal and Regulatory Risk
The first set of these risks is the Legal and Regulatory climate that many companies must contend with. All companies operate with risk constraints that fuel their business model. Publicly traded companies worldwide must contend with the various legally binding regulatory disclosures that come with trading in the market. Additionally, each industry will have specific laws and regulations that burden them, not only with reporting requirements, but operational requirements. The pharmaceuticals industry for instance has a number of regulations that place demands on them and which dictate the operations and design of their businesses model– in the US there is FDA, CPSC, OSHA, and even EPA oversight, in the EU you have REACH, and there are many more across the globe.

How does regulation, or the law, impact cloud computing? Some countries, especially EU member nations, require that client data meet some very strict privacy requirements. Some national mandates require that information about their citizens be kept within their geographical borders (i.e. it’s illegal to store such data in another country). Such laws stem from the days when paper was the primary media, but draconian as they are, such laws persist and apply to the digital realm. Another aspect to regulation is change management as it relates to data – i.e. audit trails. Who changed what, when, and how, is often a requirement of regulation, but such audit trails serve to fulfill a rapidly evolving section of law called electronic discovery (e-Discovery).

So, you might ask what does this all mean in the realm of the cloud? On its face managing such risks seems ominous or difficult. However, in practice, the impact is negligible when considering a couple of factors. First, most providers are well aware of the regulatory and legal climate in which their clients exist. Second, to the extent that SaaS providers will make a significant error when it comes to a regulatory issue - it is possible, but the probabilities are no greater than if your enterprise were to deal with compliance on its own.

As for legal risk, here’s where we find shades of gray. Primarily “who is ultimately responsible for securing data that meets the very broad and loosely interpreted requirements of e-Discovery?” Courts in the US have been reluctant to forgive companies for the misdeeds of solutions providers, and courts in Europe aren’t much different. In essence, the company is required to guarantee that they can provide all the documentation needed regardless of whether the application is hosted in house or by a SaaS provider.

Business Risk
Business risk, as discussed earlier, reflects the extent to which a given issue causes a loss of value to an enterprise (including terminating the business). Without getting into a discussion of best practices regarding risk management, it is easy to say that, based on experience; most companies do not have formal processes that score risk when making decisions at every level. When it comes to SaaS solutions business risks tend to appear in three major forms – operational risk; policy / administrative risk; and provider risk.

Let’s address the first – operational risk. In basic terms this risk is basically related to control. Who controls the data, access, and security? The more important the application is to the organization the greater these concerns are.

Secondly, there is policy or administrative risk – does the application support administration of, and adherence to, overall enterprise policies? Risk here is that enterprise policies will need to be drastically altered or that compliance with such policies cannot be met.

Finally, there is provider risk. By this I mean concerns regarding the provider itself, primarily the soundness of their enterprise and their ability to deliver services to an acceptable level or meet their SLA’s.

Addressing Risk Management
At this point the question begs “What can be done to address risk management as it relates to cloud computing?” First –gain an understanding of what risks are facing you (compliance, legal, and business). It isn’t sufficient make a decision based strictly on ROI or TCO.

Next, develop a risk management methodology that helps you assign risk in such a way that you can score, or weight, risk. Finally, make certain that your service provider has risk management strategies and have them explain what they are – in detail.

One final point is that these three items should be repeated frequently. In other words they aren’t once and done tasks and should be re-assessed periodically as part of your overall enterprise risk management program.

Also published on THE CTO FORUM