Appreciating Asymmetrical Advantage (Lean IT)

Competitive weapons

Napoleon said an army marches on its stomach. The ability to provide food, supplies, and shelter to his troops was his primary building block of success. He didn't attribute his victories to the obvious factors of battlefield tactics, great weapons, or excellent training. His focus on logistics was much more mundane, yet infinitely practical. He created a simple advantage that his enemies could not match easily. Can your IT organization identity something it does that no one else does nearly as effectively? Strategy is about advantage, so what makes you so special that it gives you an edge over your enemies?

Creating an effective IT strategy begins with developing an appreciation of your own IT organization’s asymmetrical advantages. What do you have that your competitors don't have? Such advantages can be measured by context, influence, and tolerance. By context, I mean how deep is your awareness of all the market forces affecting your competitive position. Influence means how much you can affect outcomes in your chosen market. Finally, tolerance is the degree to which you are willing accept the risks of competing.

Big vs. lean

Let’s look at the example of a large IT organization vs. a lean one. The lean IT organization typically has a much smaller staff and budget relative to comparison organizations in the same industry, and operates with a minimal margin for error. Leading a large IT organization makes strategy easy. You can afford to "let 1,000 flowers bloom" by experimenting, testing, and making mistakes. Your context is big, your influence is substantial, and your tolerance is high. But a lean IT organization does not have that luxury. These organizations need to leverage every opportunity available and maximize their return from every investment.

The simplest comparison between big and lean is their approach to an ERP system. A large organization can afford to buy, run, and customize their ERP system. They can fine-tune it to every nuance of their specialized processes. But a lean IT organization is forced to rent a standardized version where they accommodate their business processes to fit the system - customization is an unaffordable luxury.

Let’s assume you run a smaller lean IT group. How do you level the playing field? You can start by thinking differently about every aspect of your operations. No IT organization needs their own data centre if they are willing to take the necessary precautions and make the necessary sacrifices to move everything to the cloud. No IT organization needs to customize their applications suite if they are willing to modify their business processes. No IT organization needs to run its own enterprise systems like email, content management, and collaboration software if they are willing to use industry standard software services.

If you actively move in all of these directions, your lean IT organization pushes the implementation, management, and support of conventional and traditional systems out the door. Does that mean you should shut down your IT department? Hardly. What you do with what you have left is your asymmetrical advantage. The core IT staff members become your unique footprint in the industry. These are the folks that understand the business processes at the very core of your organization. These are the folks who will integrate and leverage the low cost tools you have pushed out the door.

The ability to integrate technology and to improve process becomes a strategic advantage of the lean IT organization. You have the remarkable opportunity to focus the intimate business knowledge of your subject matter experts on building unique projects, processes, and initiatives that the big organizations are ignoring because they are too busy running their overly complex in-house information systems.

Should, can, and control

So how do you get there? The lean IT organization uses the concepts of context, influence, and tolerance to whittle down its list of strategic initiatives into two piles. The stuff they can give to someone else is in the first pile. The second pile is the stuff they are uniquely positioned to implement better than anyone else in their industry.

Context dictates what technologies the IT department should operate. What market forces are buffeting your competitive position? If the industry is consolidating, where can you collaborate with other organizations to create shared services? Is this really an activity that gives your organization a competitive advantage? Is this IT function really part of the core business? Ask yourself these questions for all aspects of your information systems.

Influence determines what technologies the IT department can operate. Sometimes you simply may not have the right resources to operate the IT services you might like to keep within your organization. Sometimes geographic isolation or over-subscribed demand for specific technical skills forces you to consider alternative delivery mechanisms outside your IT organization. Often you simply don’t have enough budget money to do everything you would like to do. Don’t operate the functions you cannot properly influence.

Tolerance defines how much control the IT department needs to successfully operate these technologies. What is your risk profile? What is the probability of success? What is the degree of impact if you fail? If you can’t stand the heat then get out of the kitchen. Some IT initiatives are just too risky for the culture and risk tolerance profile of your organization. Stop doing them and give them to someone who is willing to take the risks or can mitigate the risk through systemic factors.

An example

These three factors act like a series of successive filters. For example, if you are considering moving a new data warehouse system to the cloud you need to first assess context. Do you really want to be in the business of managing the servers needed to support the new system? Unless you are a technology company it is unlikely that you would consider server management to be part of your core business, so your context would indicate support for the move.

Now consider your degree of influence: do you really have the database administration skills in your organization to manage the new technology efficiently? A lean IT organization may not be able to afford high-priced data base administrators or may want to focus their precious skills on other systems. Since you would struggle to support the technology internally, the externalization of the system makes sense from an influence perspective.

Finally, are you willing to tolerate the risk by placing this sensitive information in another organization's care? If can successfully write a contract that transfers the risks associated with housing mission-critical data to a third party, then the last filter also supports the move.

In this example all three gates have been opened and the move makes sense. Only when all three filters are aligned should you be willing to make the strategic change, because then you have a conclusive asymmetrical advantage.

Lean on your asymmetrical advantage

Becoming a lean organization is an asymmetrical advantage despite your size. When you are forced to scrutinize every IT investment for maximum leverage and return, you inevitably become more efficient than the big players. For each dollar invested in IT, you gain business improvements that outstrip your larger competitors. Ultimately, your relative size can change your behaviour and gives you a distinct lead over the bigger and slower competitors. You can float like a butterfly and sting like a bee even if you a mere David to your competitor's Goliath. 

As you become more effective, don't lose sight of your core competencies defined by context, influence, and tolerance. Remember, Napoleon conquered all of Europe with a lean military organization. But he was resolutely defeated when he lost sight of his core competencies and let his army starve in Russia.

~

The Process Design Blues

Everyone needs a hobby and mine is playing blues guitar. I may not be very good at it, but I'm not ready to sell my soul at the crossroads just yet. What I find fascinating about the blues is how such a simple musical structure becomes a portal into an infinite variety of musical improvisation and creativity. From a basic chord progression of 12 simple bars, the opportunity to innovate is literally limitless. Strangely enough, playing the blues is a great opportunity to think differently about business process.

Having designed many business processes, I have discovered great process design is lot like the blues musical structure: you need to leave lots of room for improvisation within a tightly structured and easy-to-understand framework. Good process design optimizes an algorithm for getting things done, but great process design builds in room to handle inevitable change. Great process design empowers process users to make independent decisions within the framework of the process. Great processes give users the room to deal with the variability of real life while simultaneously enforcing tight controls and high expectations around the key milestones in the process.

The concept of using a loose/tight process design makes some folks uncomfortable. Traditional thinking dictates highly structured and specific steps with no room for independent thought. And that is exactly where traditional process thinking fails - not leaving any room for autonomous and liberated thought. If you want processes to be agile and adaptive to change you need to leave room for human intelligence and creativity to engage. But business processes are not like Grade 2 art class. You need to be very disciplined at the key milestones. Each key milestone in the process needs to be measurable and comparable. Exceptional rigour around defining these process checkpoints ensures the process is executed appropriately. Installing metrics for all milestones ensures managerial control during process execution.

These metrics also enable process improvements over time as the process is executed repeatedly. You need to experiment continually with improvements to the process and measure the results. Measuring the change helps you understand the effect of the change. By comparing multiple executions of the process over time you begin to identify new and better ways of running the process. If you can't measure it, you can't improve it.

As a manager you need to carefully weigh your own engagement in the process. In between these highly controlled and evaluated milestones, you need to empower your staff. Leave the decision-making between milestones up to the discretion of your staff. They should be given your absolute trust to make the right decisions between milestones. After all, you did hire good people didn't you? So give them the opportunity to shine. If you are not comfortable with the room to maneuver you have given them between milestones then you need to re-think the process design. Are there other milestones you need to build into your process? Remember not to overdo it, or the milestones become millstones and the whole process slows down and looses it flexibility and agility. Finally, remember not to abdicate your responsibility to monitor the process for performance variations. If the variations are too extreme, then you need to get engaged.

As an example of this process design philosophy, let's examine a key strategic process for any organization - the project management process. You must be absolutely tight around several key milestones. The first is the project charter. It has one simple objective: define, in certain and quantifiable terms, why you want to do the project. The act of requiring this document as a milestone demands extensive analysis, collaboration, and consensus building before the document is submitted for approval. As a process owner, you do not need to manage the analysis work, but you absolutely must assess the results of the analysis and use the project charter to make the crucial go or no-go decision.

The next milestone is the Project Plan. This document is the contract between the project team and the sponsor. As a contract, it articulates the specific scope, budget, timeline, resources, and risks of the project. Once again, the process owner does not need to engage in the detailed analysis and development work. The project staff members are more than capable of building the components such as a work breakdown structure. However, this contract document is of mission-critical importance to the project sponsors. As a project process owner your role is to ensure the results of the analysis stand-up to significant, extensive, and careful scrutiny. The Project Plan milestone sets the stage for the most expensive stage of the project, so you want to use the milestone to be absolutely positive the project is ready to move to the next stage.

Once you have an approved plan, the execution begins. A well-written project plan has specific execution milestones defined. These milestones report on completion of activities according to scope, budget, and timeline of the plan with a change control mechanism. Once again, the project sponsor and project owner need to be actively informed and engaged in reviewing these execution milestones. If milestones are meeting promises (or appropriate change requests are approved), then the project manager and her/his team are perfectly capable of implementing the work between milestones without interference. However, if the project misses milestones, then the process owner and sponsor must engage in the project's detail work.

Assuming everything goes well the final milestone is the Project Closure. At this milestone you decide if you did what you said you would do. Are all the expected project products and services completed to a satisfactory quality level? Will the organization reap the benefits promised in the project charter? The sponsor and process owner review the original project charter to determine if the project delivered on the promises made. This milestone is used to determine if the project is truly finished. These two leaders do not need to be involved in the final development work for the product or service, but they do need to ensure it is are completed properly, hence the existence of a milestone at this point in the process.

Throughout this project management process there are specific and explicit expectations in each of the milestones, and liberal room to empower project managers to use their judgment and make decisions throughout the process. The worst project management methodology I have ever seen consisted of 14 binders, each 2" thick. They were never opened and never used. Conversely, the best project management methodology I've ever seen was a single 1" binder that was well thumbed with lots of coffee stains. It was a process that left lots of room for individual creativity within a tight context of specific milestone-based deliverables.

I can always tell when I hear great blues. The old familiar structure is always there, yet the great artists make every blues song sound unique, inspiring, and wonderful. Just like great blues music, great processes can lead to business innovation and creativity. But don't let them run amuck or you will get 20-minute guitar solos that bore your audience to tears.

~

Fear and Loathing in IT Communications

When I was in my mid-twenties I took a visitor from the Ukraine to dinner. She was in town to attend a wedding and I wanted to shown her my city. She spoke several European languages, none of which was English. I spoke English and several other languages, but my list included Fortran, Pascal, COBOL, and C. In theory, we should have had a serious communications issue. But we didn't. I explained most of the menu by mimicking the sounds of the various farms animals on the menu (much to the amusement of everyone at the surrounding tables) and we both ended up enjoying the evening.

Partially based on this experience I have always been suspicious about communications issues. I never cease to be amazed at how often IT folks point the finger of blame at communications skills. Repeatedly I hear "everything just boils down to communications" or "if we could just communicate better everything would be okay" or "all our problems could be solved by better communications." I don't agree. I would go so far as to say that there is no such thing as a communications issue. Faulty communications are inevitably an indication of a deeper issue. Communications issues are only symptoms of real problems. If you solve the issue at the communications layer, you are not solving the real problem. You need to dig deeper if want to create a sustainable fix.

For example, I once replaced a CIO who failed with an ERP implementation. Folks claimed she failed because she did not communicate in an accurate fashion. She had oversold the benefits and undersold the costs, so her communication had twisted expectations beyond the realm of reality. This observation may have been true on the surface, but why did she feel the need to distort the messages? She clearly felt obliged to make exaggerated claims about how the system would improve the organization at bargain basement prices.

So why did she do it? She was right that the organization needed an ERP system and she was right that the benefits are hard to explain. Try telling a senior board member that an integrated database will improve the strategic mission of the enterprise. But instead of taking the time to educate folks on the issues, she tried to sway them with promises that could not be kept. In the short term she was able to sell them on the concept and got buy-in to the project. In the long-term she couldn't keep her promises and paid the price of not being realistic.

This approach reflects a lack of patience for explaining the real reasons to undertake a significant project. Take the time to understand the issues yourself. Think in terms of your stakeholders. Understand their needs, their fears, and their language. Instead of talking about "integrated databases", call it a "single source of the truth." Spend the time educating and informing before selling. You may be surprised by what you find. Maybe your organization doesn't really need the new system after all - or maybe it needs the system more than you realized. But this isn't about communications. This is about taking the time to understand the fundamental issues before moving forward. Look before you leap. Think before you communicate.

Whenever I hear IT staff complain about a communications failure I like to probe into the underlying motivation. Sometimes "communications failure" really means, "I don't want to communicate" because "I'm afraid to let them know what's really going on." If your staff are afraid to pass on an honest message, then it may be due to a lack of skills, inappropriate control processes, or a repressive departmental culture. And that's your fault, not theirs. Let's look at each of these three issues separately.

When I talk about lack of skills, I don't mean the basic ability to talk and write. Let's assume that you have hired folks who were sufficiently educated to earnestly function in your IT shop. But what they might not have are the skills to face a problem in a direct manner. You need to teach them how to frame a problem and give it context. IT staff need to avoid the "the sky is falling" approach. Chicken Little will only panic your customers. Your staff need to be coached on explaining the issue in plain language without emotion and with potential recommendations. Issues are lonely creatures - make sure they are always accompanied by a solution.

Once your staff have the skills to give the problem the appropriate context you need to implement non-bureaucratic control processes. Give them the opportunity to explain problems. For example, your projects will inevitably go through changes during their lifecycle. If modifications are inevitable, so is the need to explain why you need to make the change. Build mechanisms for escalating changes into your project management methodology. Ensure project steering committees are trained to expect these shifts in plans. Too often "poor communications" are blamed for what in reality are poor processes.

No matter how much context and process you provide, if your culture does not encourage open and honest discussion of issues, they will remain veiled behind the hazy cloud of "poor communications." Shooting the messenger doesn't change the truth; it only hides the truth. That's when communications skills get blamed. But even the best communications in the world are not going to change a repressive culture. You need to nurture the ability to say, "I made a mistake." Mistakes are tolerated and learning outcomes are encouraged.

These are just three examples of when communications takes the blame for more fundamental problems. Sometimes a communications breakdown is based on an emotional fear of change. Change is like a death. The old way has died, and the new way is an unknown and unfamiliar place. Fear of change is irrational, but real. But it is not a communications failure. If you simply address the communications issues you will never fix the real change management issues. Address the change head-on; don't wallow in the black hole of superficial communications-driven fear and loathing.

I have implemented major change initiatives where the communications are quite easy and natural if you have done all the other hard work. This hard work includes really understanding your stakeholders. Spend time getting to know what makes them tick. Engage them in a meaningful way in the decision-making process.  Create an education process for you and them. The more you both learn about each other at the beginning if an IT initiative, the easier it is to talk frankly and openly when issues arise. When someone blames a "communications failure" someone probably hasn't done the hard work.

There is an interesting follow-up to my dinner with the visitor from the Ukraine. I attended the wedding with my dinner companion the next day. At the reception a couple came up to us and revealed they were in the same restaurant as us the night before. We were a little embarrassed until they said they made their dinner choice based on our mimicking of animals from the menu. They chose the Chicken Kiev.

~

Are Students Customers or Products?

Are students customers or products in an higher education institution?

The answer to the question is forced upon higher education institutions by the very nature of the information systems they implement. There are two types of systems in a higher education environment. Some information systems treat students like products of the institution and other systems treat students like customers of the institution.

ERP systems like Banner, Kuali, and PeopleSoft are designed to maximize efficiency. By simple virtue of the need to process large volumes of students in registration or accounts payable, the student becomes a product. They enter into a system for processing like unfinished goods. The administration module begins processing the large volume of raw material (applicants). The registration system and associated systems like the degree audit system help track the work-in-process inventory (students). Eventually they become finished goods to be delivered by the convocation system (graduates).

Learning management systems such as Moodle and BlackBoard are designed to enhance learning outcomes and improve the educational experience. The LMS is designed to help students learn the course material. A well-designed LMS environment provides consistency throughout the student's lifecycle at the institution. They are designed to optimize the learning experience with little consideration given to maximizing efficiency. Similarly, campus services such as wireless are architected to improve the student experience through ubiquitous service and gobs of bandwidth. These types of systems are intended to treat students as customers receiving a service from the institution.

The student help desk is a transaction-processing environment. Clear response and escalation processes are defined to maximize the customer experience. Effectiveness of response, and customer satisfaction take priority over efficiency. High touch and human contact create a positive student experience that will improve student retention. Conversely, billing students for tuition is a production process. It is a process that demands financial rigour and productive use of system resources. The entire billing system is designed to be as efficient as possible.

To be a truly effective CIO in a world where students are sometimes customers and sometimes products is what makes the job interesting. The real opportunity for a CIO in the higher education world is to understand when to see students as products in certain circumstances, and when to focus on students as customers in other scenarios. This wonderful opportunity forces CIOs to deliver process efficiency and learning effectiveness concurrently to the same group of people. The best CIOs are good at both skills sets and know exactly when to apply the right approach.

One more wrinkle to make it more interesting. Are faculty and staff customers of the IT organization? I suggest that IT needs to treat faculty and staff in a more thoughtful manner than just customers. Like consulting firms, IT should consider faculty and staff to be clients. A client relationship suggests a more nurturing and enduring relationship based on more complex relationship than straightforward customer transactions. WalMart has customers. McKinsey has clients. Which way do you think your faculty and staff would like to be treated?

~

The View from IT Mountain

For the first time in my life, I went mountain biking. It was exhilarating, frightening, demanding, and fun. Most of all, it provided a unique view. After a long climb to the top of the mountain we came to the edge of the first trail. I also came to the edge of a clearing where I could see everything - the adjoining mountains, the community where I live, and the remarkable path to the top of a small mountain.


While I paused to catch my breath (which was a good long time), I had a chance to think about the unique view that IT has in any organization.  Much like being at the top of a mountain, IT gets to see everything in an organization: the hills, the valleys, and the paths connecting key centres. No other group in an organization has such breadth. Marketing, finance, manufacturing, and HR have incredibly deep understanding of their own valleys. They might also have a wonderful knowledge of how their department connects with some neighbouring organizations in the adjacent valleys. But they do not see the whole connected picture.

Can anyone connect all the dots?

A truly successful IT organization can see the whole picture. Its job is to work with all facets of the organization to build integrated information flows. The role of IT puts the department in a unique position. A successful IT service transcends organizational boundaries. IT delivers service horizontally across the entire organization enabling it to see all the valleys, all the connections, all barriers, and all the opportunities.

How can organizations leverage the broad IT perspective?

To start with,  IT departments need to view themselves as holistic and systemic process improvement groups. They are not just technologists, but broad integrators who bring together people, process, projects, and technology from across many disparate units to deliver unified systemic change. If an IT organization builds trusted relationships with all its partners, it can leverage  its unique perspective through these relations into a powerful wellspring of change for everyone in the organization.

Does IT need help walking to the top of the mountain?

To succeed, organizations cannot bury the IT department at a low level in the organization. Reporting needs to be at the most senior levels in the organization. High level reporting responsibility enables IT to move customer initiatives from a technology focus to a business focus. IT applies the force of broad horizontal connectivity to topple the vertical silos of political dysfunction.

Is simply changing structure enough?

Structure does not change organizations, people do. But people cannot do it without process. IT needs models for benchmarking processes, re-engineering techniques, and process design. Typically IT departments live with these tools on a day-to-day basis and have more experience with them than any other group. The trick is for IT to leverage these tools into integrated agents of progressive change - a series of progressive changes that improves life for customers, staff, shareholders, and the community. The changes succeed when IT's partners adopt and implement processes, such as a common project management discipline, to deliver projects. The spirit of mutuality of interest leads to real success in the implementation of enterprise IT.

IT is horizontal, everyone else is vertical. 

If you keep this horizontal/vertical perspective in mind, you will realize the unique value of IT: a way of integrating enterprise-wide processes into unified and holistic processes. These processes become sustainable competitive advantages for the entire organization. 


Climbing to the top of the mountain is a lot of work. But the view is spectacular. 


~

The Perfect IT Department

We spend a lot of time developing IT strategies. A typical strategy starts with a mission, vision, and purpose. I've read several IT strategic plans recently and I have come to the conclusion that organizations have become pretty good at developing these documents. Execution of the plan is tricky, but successful implementation is also becoming a more commonplace skill.

What seems to be missing from these plans is the opportunity to dream. We have become quite good at mechanically developing goals and objectives, then putting in place the processes to get them done. Results are delivered on time, on budget, and in scope. What falls through the cracks is creativity. Creativity is the spark that ignites innovation.

Sometimes we need to dream.

I recently read the actual text of one of my favourite speeches of all time. It was an eye-opener because the passion of the speaker seemed to overwhelm the actual written word. But the text is just as powerful as the delivery. A key line of the speech:

"I have a dream that one day every valley shall be exalted, and every hill and mountain shall be made low, the rough places will be made plain, and the crooked places will be made straight;"

I don't have Martin Luther King's eloquence, but his idea is powerful. Let us dream first. The reality and implementation follow the dream. If we were to dream about the perfect IT department, what would it look like? Imagine an IT strategy where contributors were asked to close their eyes and dream of the perfect IT department. What if we could simply imagine what we want to be when we grow up?

Here's my dream IT department ...

Under ideal circumstances, the information technology department is seamlessly integrated into all processes at the organization. The department provides secure and reliable access anywhere, anytime to dependable high performance information technology services. The people who provide the service are trusted and inspire confidence in the technologies they deliver. The department generates innovative ideas supporting the purpose and mission of the organization. Similarly, continuous process improvement ideas are sourced from the information technology department in a collaborative manner.  New projects are delivered within promised timeframes and budgets. Ongoing services meet or exceed customer expectations. People in the information technology department enjoy their work and their customers enjoy working with them. The culture of the department embraces an outstanding client-centric service ethic. Clients of the department embrace technology and enthusiastically work with the department to build a better future for customers and the organization.

Would not the dream create a better mission, vision, and purpose? Once you have the dream, you have the fuel to inspire an exciting strategy. A strategy where IT really can change your world. A strategy where you can make the rough technology plain and the crooked systems straight.

~

Who Should IT Report To?

One of the perennial debates in IT is the question: whom should the IT department report to? The CEO? The finance department? The social media team? The head of research and development? The question is like asking how many angels can dance on a micron of silicon. At the risk of appearing to dodge the question, I suggest IT reports to everyone.

Tradition says IT should report into Finance. Historically IT departments evolved out of a corporate need to automate billing, payroll, and other fundamental and crucial financial transactions. Naturally it made sense for IT to report into the finance department. But times change. IT is an integral part of everything everyone does in an organization. IT is an essential part of the value proposition of any product or service. From pizza stores providing real-time delivery tracking to universities providing online degrees, the IT function affects every aspect of the business relationship.

I saw the issue first hand when I was the financial controller for a large IT department. I reported into a CIO whom I greatly admired and respected. One piece of career advice he gave regularly was "never let IT report to Finance." At the time I had a hard time understanding his reasons. Our CFO was a great guy and I worked closely with him because of my particular role in IT. The way our company was organized, both the CIO and CFO reported to the president and everything worked extraordinarily well.

Then the company was sold.

As the new buyer dissected our organization they made an interesting discovery. The single most expensive physical asset in the organization was the IT infrastructure. But instead of leveraging IT as an integrated value generation mechanism, the buyer viewed it a financial asset to divvy up among disparate interests in the new organization. Like a pirate looting plunder, the new owners did not recognize the real value of the treasures they had captured. The assets were squandered because they were only seen from a financial perspective and not a business perspective.

The acquiring company's IT group reported into the CFO and the results of the merger seemed to confirm my boss's advice about the IT reporting relationship with Finance. But in hindsight, that was not the real problem. They were an old style organization where the IT department had a weak voice. IT did not see itself as part of the business. They saw themselves as technology order-takers, not as leaders of the information systems strategy and execution.

As a CIO I've reported into the Finance side of organization and quite enjoyed the relationship. However, the organizational reporting relationship never biased the organizational decision-making process. IT decisions are investments with long term implications for organization success, but financial systems should never receive preferential or biased prioritization simply because of organization hierarchy. Strategic engagement of IT requires broad organization involvement that transcends arbitrary organization structures. A self-aware IT organization perceives itself as reporting to the entire organization, not just the sole linear strand of the hierarchical organization chart.

So how can IT report to everyone? It starts with an attitude - a collective state of mind defined by the IT departmental culture. It requires an open approach to all relationships across the organization and is manifested in a desire to collaborate and integrate and deliver. This open IT culture is rooted in a mutuality of respect among all departments. Whether it is finance, human resources, or manufacturing, the IT folks need to earn their respect by delivering on promises and meeting expectations.

Once the culture is established, relationships are continuously nurtured. You can't do that if you think you have one boss. Much like a consulting company has many customers, an IT organization has a multitude of clients. Specialized treatment of one client because of an organizational reporting relationship comes at the expense of servicing others. A nurturing and open IT culture flourishes in an environment where all clients become the centre of their universe.

Of course the official reporting relationship needs to be comfortable and supportive of the open IT culture. When IT reports to the CEO, this balanced perspective is assumed. In other reporting relationships, the need to be open may be less obvious. The CIO's role is to help everyone understand the need for an IT that meets the needs of the many, not the few.

As to the career advice from my old boss about never letting IT report to the CFO? I disagree. Sometimes IT should report to the CFO. But sometimes it shouldn't. It depends on the particular business model and the technical acumen of the leadership. What matters is that IT has a strong and respected voice throughout the organization. That can only be achieved by a open, service-oriented IT organization. One that identifies with the business and sees itself as part of the organization's bloodstream. One that sees itself as reporting to everyone.

~

Your IT Department Only Needs 6 People

I have a confession to make. I am home repair challenged. I can't fix anything around the house that requires tools more complex than screwdrivers and hammers and paint. But I do know exactly what I want done, how I want it done, and what it is worth to me. So I hire experts. When I needed to build a shed I hired folks who spend their lives specializing in home construction and repair and they did a better job than I ever could have done. While they built my shed, I spent my time working on things that I'm good at. We were both productive.

Similar logic applies to IT departments. There can be an almost infinite amount of IT work in any organization. From upgrading the ERP to enabling BYOD (bring your own device), the choice of opportunities is vast. The challenge is not what to do, but what to ask someone else to do. Where does IT draw the line between internal vs. external work?

IT needs to maximize the value of existing resources on the most important activities and deliver other services through new channels and creative partnerships. They cannot do everything internally. To understand what can be divested, organizations must assess IT’s core competencies. Core competencies in an IT organization are functions that are central to supporting the mission of the organization.

The three criteria for assessing whether any particular IT function is a core competency are:

• External service providers cannot perform the function more efficiently for lower cost, 
• Performing the function internally maintains appropriate control of the function in the organization, and 
• The knowledge needed to perform the function is central to the long-term success of the organization. 

Focusing the organization on core competencies requires reviewing the major activities performed by IT and deciding what to keep and what might be delivered in a new manner. Non-core competencies are often well served by partnering with a service provider whose sole specialization is the best possible delivery of that service. This approach is similar to hiring contractors to build my shed. Home construction is not my core competency, so I found someone who specializes in that line of work. Alternatively, why build a shed in the first place if my neighbour has extra space in his shed available for a cheap price?

If you were obliged to take this approach to the logical extreme, the process of assessing core competencies could lead to externalizing almost all the IT work. If an organization were to go to this extreme, what should be left? What are the ultimate core competencies of any IT department? I would suggest the minimal IT organization would consist of only six roles:

1. Chief Information Officer 
2. Enterprise Architect 
3. Project Office Director 
4. Business Administrator 
5. Security Manager 
6. Operations Director 

In this new IT world, there is still a need for a Chief Information Officer (CIO). This individual is responsible for making sure all the organization's IT needs are met. But the CIO's organization becomes a lean team of five staff. Let me describe each of the roles in the next few paragraphs.

The CIO drives IT through visionary leadership that inspires all staff and earns the confidence of clients. The CIO leads the organization's IT with strategic thinking and operational decisiveness, and is capable of bringing the entire organization through sustained periods of significant IT change. The CIO is a leader whose advice and guidance is respected for all information technology issues. These issues may not necessarily be part of the IT function, but the leader needs to be sufficiently well respected across the organization to be sought out for advice and guidance on any IT matter. The CIO ensures appropriate stewardship processes are in place and establishes information systems ethics.

If the bulk of the IT work is no longer a core competency, then the new challenge becomes how to link all the external service providers (contractors, hosted services, outsourcers, etc.) together. The Enterprise Architect (EA) owns this responsibility. The EA's first job is to understand and articulate how technologies, applications, and data interrelate. The second part of the job is to build a roadmap of where each of these functions will evolve. Defining context, setting direction, and linking external sources into a seamless information technology service is the role of the EA in this optimized organization.

With multiple service delivery providers come multiple projects. The organization needs to set non-negotiable project management processes and checkpoints to control vendor projects. Consistency of project delivery is essential to the management of expectations by IT's clients. The Project Office Director is accountable for all projects, irrespective of whether the staff are internal or external. Integrated and seamless delivery of project results are demanded and this director is responsible for ensuring everyone works together as single project team.

Since external suppliers will do most of the IT work, contract management and business relationships are essential to the success of the new IT organization. The Business Administrator manages the RFP writing, plans the operational and capital budgets, and handles the business affairs of the IT. The Business Administrator works closely with suppliers to negotiate IT services and projects required by the overall organization. The negotiations are done within the context of the enterprise architecture and the Project Office Director sets the project service delivery expectations.

The importance of IT security, data privacy, and compliance requires the presence of a full time Security Manager. The ideal IT environment would have unassailable policies, practices, and standards that are proactive, not reactive. Strong policy and enforcement is essential if external service providers are to be trusted with an organization's IT assets. The Security Manager is responsible for creating the policies and ensuring the appropriate practices are in place to enforce them as part of all contract negotiations.

The Operations Director is accountable for all production services. These operations must deliver according to service level agreements with external providers. This Director creates meaningful performance and capacity metrics. These are measures that the IT organization's clients understand. The Operations Director works closely with vendors to provide them with growth patterns for usage. Expected demand forecasts become part of the contract negotiation process and the Operations Director is responsible for meeting these needs by working with vendors.

Arguably, an IT organization could easily be larger than six people. But if you had to boil the organization down to its absolute minimum, these are the six roles you do not want to externalize. They are your fundamental core IT competencies.

~

IT Governance is Dead. Long live IT Stewardship.

There was a windstorm on Vancouver Island last night - one that blows off the Pacific and seems to make the whole island shudder. There was a weird noise that seemed to be coming from inside the house. As I lay in bed, the last thing I wanted to do was wander around the house looking for the problem. So I kept telling myself it was just my imagination and everything was ok. Then BLAM! Something fell inside the house. There was no making excuse anymore. I had to leap out of bed and deal with it.

IT governance has become one of those issues. For the past ten years the holy grail of IT has been governance. But the wind has been shaking the house of governance for sometime now. Over the years I have seen a number of organizations create governance structures and governance models and governance committees. Typically these models are well planned and follow all the appropriate literature. Some processes achieve moderate success while others continue to struggle.

Typically the CIO creates the governance model, chairs the meetings, sets the agenda, and drives the action. They are attempting to govern IT in the enterprise. But they are attempting to govern someone else’s assets. What gets forgotten in these models is the reason for creating IT departments in the first place. IT departments exist to support the strategic and operational goals of the business. IT was created to realize the dreams and aspirations of their stakeholders. The assets are not theirs to govern. The mistaken notion that IT can govern someone else's property is the root of the problem.

I suggest we shift our thinking from governance to stewardship. Stewardship is the responsibility to take care of something belonging to someone else. By moving from a model where IT attempts to govern someone else’s assets to a model where IT recognizes the true ownership of the assets changes everything.

In a stewardship model, the needs and concerns of IT clients actively influence the decision-making process of the IT department. The decision-making process becomes transparent to stakeholders. The clarity creates trust among the IT department’s clients.

The intention of a stewardship process is to engage clients in enterprise IT decision-making. The organization uses an open and transparent process where clients actively and regularly participate in guiding the future of technology at the organization. The role of the IT department is to facilitate the process of decision-making, not to govern the decision-making.

The purpose of a vibrant stewardship model is to engage IT stakeholders in the prioritization of work and the selection of the criteria that determines those priorities. Successful stewardship allows customers to influence and guide IT planning, policy, and priorities for the entire organization. All appropriate stakeholders discuss information systems investments in a collaborative fashion.

Stewardship is the open, honest, and responsible management of something entrusted to your care. Governance is about making decisions that set expectations, grant power, or measure performance. These are two different worlds representing significantly different mindsets. Governance can lead to IT forgetting its role in the organization and attempting to assume more responsibility than is appropriate. Stewardship is about helping the organization realize its information technology dreams and aspirations.

In case you were worried about my house, everything was okay. The wind blew open a poorly fastened door and a painting that was loaned to us by my mother-in-law was blown to the floor. I fixed the door so it will never shake loose again. Hopefully I have improved my stewardship of my mother-in-law’s painting.

~

"Of Revenge"

The most unproductive urge in management is revenge. It is an irrational emotion created by a perceived injustice and it produces irrational behaviour with wasted energy. Over many years of mentoring and coaching I've seen hundreds of managers squander their leadership currency by dwelling on a grudge. 


There is no room for revenge in business. Revenge is like quicksand: the angrier you get, the faster you sink. I've always told folks that history is over, so get over it. Move on: build, create, and forgive. Of course that advice is easier said than done. So over the years I've looked for published material to help prevent folks from sinking in the revenge quicksand. 


There is a lot of well-written business material to provide guidance, but I have never found anything with much lasting impact until a few weeks ago. I was helping my son with an essay on Hamlet, a play centred around a character tortured by the need to seek revenge. In the process of researching the paper my son came across a wonderful quote from a Francis Bacon essay titled "Of Revenge": 

"Certainly, in taking revenge, a man is but even with his enemy; but in passing it over, he is superior; for it is a prince’s part to pardon."

The essay containing this quote was written over 400 years ago, yet it has enduring truth for current managers. We all feel wronged at times during the course of leading in an organization. Whether we get passed over for a promotion, cheated out of a bonus, or caught in a downsizing.  Dwelling on the event is fruitless. Focusing on the negative simply throws you into the infinite vortex of despair. 


Focus on what you are going to do next. The past may be prologue. But it has passed. The future will only start when you rise above the irrelevant self-imposed prison created by wanting revenge. The future belongs to the optimist.


~

Part 16 - When going out into the Universe, remember: "Boldly go where no man has gone before!"

(This is part 16 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

Every episode of the original Star Trek began with the proclamation to "Boldly go where no man has gone before!" For folks working with technology, this statement is a natural assumption. But there are two caveats.

First, I’m a big believer in early to beta, late to production. What I mean is that it is good to experiment with new technologies in beta test mode. But we have an obligation to our organizations to treat production as sacred. Experiment to learn but be cautious about what you give to your clients who trust you for reliable production-ready solutions. No matter how much we like cool new toys; we must ensure they will work reliably in production.

For example, I worked at a Canadian organization where one of our peers moved some services to a foreign cloud computing service. At the time there were huge potential privacy and legislative compliance concerns about moving personal data out of the country. Although we wanted to do something similar, the legal and technical analysis was expensive and time consuming.

Pioneers have arrows in their backs, so we let them go first. They figured out the privacy issues, they sorted out legislation concerns, and they pioneered the first contract of its type in Canada. Once the first-mover problems were sorted out, the way was paved for cheaper, quicker, and less painful implementation at other similar organizations.

That was caveat #1. The second caveat is related to the time and period when the original Star Trek was aired. It was a product of the mid 1960's when political correctness was only beginning. You should boldly go where no person has gone before!

~

Part 15 - Even in our own world, sometimes we are aliens.

(This is part 15 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

In any IT environment you always face a vast array of varying technologies. With many different technologies you will be faced with many different subject matter experts. For example, almost all IT shops have a mixture of Windows and Linux servers. If you are an expert in one area you will inevitably be an “alien” in terms of technical expertise in another area. As a manager, you can’t know everything about every technology. So invest your own intellectual capital wisely. Become an expert in the high priority stuff and let someone else learn the rest.

The hardest part of moving into a leadership role in IT is to let go of technical skills, but the temptation to help out is always there. One evening I was working late and one of our programmers was trying to solve a nasty mainframe data conversion issue (we were running a project to shutdown the mainframe). Since I used to have some mainframe skills I offered to take a look at the problem. Together we solved the problem, which was good. Unfortunately, he told everyone else, and that was bad. The last thing I wanted was other folks asking me for help with their mainframe problems. So sometimes it is good to be the alien!

But when dealing with your clients, you don’t want to be an alien. You want them to feel like you’re one of them. You want them to feel like you’re on their side. I strongly recommend looking for ways to lose the alien “IT guy” tag. Build partnerships and positive relationships anywhere and everywhere you can.

As an example, we had initiated a statistical analysis reporting project. We worked closely with the business unit to build a development environment and reporting system. Their folks and our folks worked as a single team to deliver systems such as an interactive reporting cube that was ecstatically well received by our clients. We were a success because we were a team and not aliens. From a client point of view you couldn't tell the difference between the business unit and IT staff. First prize.

Another example was a desktop standardization project. Information Systems, Accounting, Purchasing, and Advancement all worked together to set standards for an organization-wide computer purchasing process. We developed a process that we all had a stake in. There were computing standards that fit our IT architecture. The ongoing acquisition model streamlined the purchasing process. The transaction processing model met the accounting group’s needs and the strategic alliance with the vendor met Advancement’s needs. We merged four very different “alien” cultures into a single team to develop a model that benefited the entire organization.

For those times when you are working closely with your customers, you must overcome that “alien” label. When you need to distance yourself from the day-to-day technical details, it can be useful to be an alien. As a manager, the trick is to know when to be an alien and when not to be.

~

Part 14 - If it can't be fixed, just ask Scotty.

(This is part 14 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

The Starship Enterprise, Scotty the engineer was the technology "goto" guy. If anything broke, everyone relied on Scotty to fix it. He could fix a warp engine with duct tape while the universe seemingly imploded around him. Every IT department also typically has a technology "goto" person. Some places call her or him the "architect." Other places may simply say the "guru." At previous organization I worked at, he was called Ron, not Scotty.

It's good to have someone like that as long as Scotty isn’t a one-person show. The real concern here is with single expert syndrome. Scotty needs backup. But Scotty is a rare breed, hard to find, and you can’t always afford two in a cost-conscious IT environment. So there are a couple of solutions. First, create resource pools to enhance knowledge sharing. Second, recognize that heroes are bad.

Let me explain the hero problem first. We all love Scotty from Star Trek because he solves seemingly impossible situations with innovative solutions. But these are exceptional circumstances. Situations that have never been experienced before and cannot be predicted nor planned for.

The problem in an IT shop is that we are not travelling through strange new worlds. In our world, a hero is an indicator of a bad thing. It reflects a lack of process. We are all familiar with the classes of problems that occur in IT and there should be a process in place to handle these problems. If you need a hero, it means you don’t have a good process. Ron was a superstar because be puts process in place to deal with major systems outages, or as he liked to call them “technology appreciation events.”

Another example is the project management process we implemented. There were no project managers who were heroes. We had project managers who were superstars because they excelled at executing our project management processes.

The resource pool idea solves a key staffing issue. Depending on the size of your organization, you may not have the kind of funding that is available in large banks or insurance companies to hire in depth to create redundancy of key positions. You need to do the next best thing and create resource pools. Software development groups and other project-driven organizations can benefit from such a structure.

In a resource pool, each key functional area is assigned a notional allocation of developer person-days. No names are specifically allocated. Bob isn’t permanently assigned to Finance and Betty isn’t permanently assigned to Student. They belong to a shared pool supporting all administrative systems. That way you have the option to move people around at your discretion.

This approach increases staff personal development opportunities because they learn more systems and technologies allowing you to grow the intellectual capital of your organization and give you greater depth. It also keeps your staff happy and growing so they’re more interested in their jobs. From a management perspective it gives you greater depth to cover multiple systems with a limited staff size. It also gives you the ability to adapt to changing demands across multiple client groups. Finally, it prevents your clients from developing the mistaken idea that they control specific resources (such as Bob always works for Finance, so Finance begins to think they own him).

In conclusion, it is okay to have a Scotty, but be wary when someone says Scotty is a hero! He needs to be part of team with folks who can fill his shoes when the need arises.

~

Part 13 - Insufficient data does not compute.

(This is part 13 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

Although insufficient data does not compute, a key management lesson from Star Trek is that often you must make decisions with insufficient data. You can’t move forward if you don’t make decisions. You will never have all the information, so you need to make decisions with enough information. Insufficient data may not compute, but as a leader, usually that is all you have to work with and you need to make the best of it.

The trick is to understand what is “enough”. As IT folks we are rational and logical so it is hard to make major decisions without all the data. For example, at my university we completed a brand new state-of-the-art data centre. Development of the business case was a challenge because it was a multi-million dollar decision. The existing data centre was out of space, power, and air conditioning because of explosive growth in research computing. Yet we wanted to develop a computing facility to attract new researchers to meet the university’s mission.

Before we could proceed, the board had two questions. First, why did we need a new data centre? Second, how big should it be? “Why” was easy. We had all the facts about why our existing data centre was too small. We drove the point home by giving the board a tour of the old data centre before we asked for any money. After the tour the board chair, who was non-technical, came out and was quite surprised. She said to me “I thought I just turned on my computer in the morning and it all just worked. I didn’t realize we needed all this. And by the way, it looks like you guys haven’t got anymore room!” That tour made the basic business case an easier sell.

“How big” was much tougher to answer because it was based on future predictions. Forecasting in a university environment has many problems. Research grants vary dramatically from year-to-year, so demand is unpredictable. Over long periods of time fundamental hardware technology requirements change such as mainframes to standalone servers to rack-based blades. Trends such as virtualization and cloud computing may dramatically alter what currently looks like a continuous growth curve.

With all that variability, our best guess said we needed about 5,000 sq. ft. over 5 years based on trends. After that, all bets were off. There is no way we had enough information to draw any conclusions past that time frame. But we didn’t want to build another data centre 5 years from now. So we did not have an air tight forecast. We decided to build a 10,000 sq. ft. building with one-half built as a data centre. The second half was setup as warehouse space that could be converted as needed to a data centre.

The result: in 9 months we filled 35% of the data centre. At that rate the built-out half of the data centre will be completely filled in 3 years, not 5 years! Because we included the additional warehouse space we have a contingency built in to handle what will likely be an overflow sooner rather than later.

We did not have all the information, it was a multi-million dollar decision, and we moved forward without being paralyzed by indecision. Based on the current utilization rate, we are glad we did. If we had not made a decision we would have lost significant amounts of research funding.

Insufficient data may not compute, but that does not mean you cannot make a good decision.

~

Part 12 - When your logic fails, trust a hunch.

(This is part 12 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

By observing Star Trek's Captain Kirk we inevitably learn that when your logic fails, trust a hunch. This is great advice for IT leaders when fixing stubborn problems. But you need to take it to the next level. You should always make decisions in three places: your head, your heart, and your stomach. The head is logic. The heart is emotion. The stomach is intuition (“gut” feeling). All three must be aligned and in agreement.

Now here’s the part that bugs IT folks: logic is not enough. Getting comfortable tapping into all three of these decision-making inputs is tough for IT folks who are typically completely reliant on logic, day-in and day-out, to solve computer problems. But leadership is very different. You never have all the information at your fingertips. You usually have shades of grey. That is where emotion and intuition come into play.

I had an interesting decision to make several years ago. I worked in a university where the learning management system (LMS) strategy was inadvertently “one of each.” We had major implementations of six different products across campus. It seemed like every department had it own favourite and we had one of every possible learning management systems available. Needless to say, it was a very expensive situation and no one appeared willing to compromise.

However, I noticed we had some pockets of strong support for a particular open source product. I also had someone on my team who was excited about championing that product. We did our homework and our best guess was that this product looked like a winner. It seemed to be getting more popular throughout the industry and the product looked like it was pulling away from the pack, but only a little bit at the time. There were concerns. It was open source software and there were a number of risks and unknowns associated with that type of product at the time. I was also nervous because we didn’t have a lot of experience in this area. On the other hand, the vendor support for from our largest proprietary LMS vendor was disastrous and we needed another solution.

In summary, my head said: “we are seeing a trend, but nothing definitive.” My heart said: “there are a lot of people I trust who are advocates.” My gut said: “we need to do something now.” Putting it all together, my hunch was: let’s invest in the open source system. So we bought a server, gave my product zealot a full time job, and launched a pilot with 15 courses. Within 2 years we had 400 courses on the new system – more than any other LMS on campus! Plus, the total number of LMS supported courses grew by 50%. This meant faculty were not only adapting quickly to the new system, but more faculty were generally willing to use an IT tool to enhance teaching of their courses. By the end of 3 years we had nearly 1,000 courses on the new system. The total number of LMS enhanced courses grew dramatically and many LMS users voted with their feet by moving to the new system.

This original “hunch” led the university to recognize the need to move from the old “one of each” strategy. By the fourth year, the user community chose to make the new system the standard learning management system on campus. We had moved from "one of each" to one.

In any decision, you need to make sure your head, your heart, and your stomach are all telling you the same story. Then trust your hunch, invest in it, and support it!

Part 11 - Don't put all your ranking officers in one shuttlecraft.

(This is part 11 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

According to Star Trek you should never put all your ranking officers in one shuttlecraft. If we were to apply this rule to management, I would suggest this rule is about diversifying your risk while at the same time learning from the diversification.

We don’t normally use shuttlecraft at work, but I like to think this rule is about making sure your leadership team isn’t all thinking the same way. In other words, diversify your risk by diversifying your team. Look for ways to avoid groupthink. Look for ways to prevent your whole team from having a similar mindset and doing everything the same way. Create a leadership team of differing personalities. You want a leadership team with broad perspectives and unique problem solving techniques.

For you as their leader it makes your job harder in the short term because you need to blend a very diverse set of skills. But it is easier in the long term because you get more bandwidth and capacity to handle a broader range of complex issues. Varying perspectives may require more effort to coordinate, but they keep you out of trouble and help prevent bad, narrow-minded decisions.

I worked for a manager early on in my career who insisted that everyone on his software development team have a computer science degree from the same university. With that sort of similar background we were able to gain consensus very easily and quickly. But we had a very narrow view of the world. That tendency prevented us from trying different approaches and solutions.

As a team, we came up with technologically innovative algorithms and elegant back-end systems. But none of us had any user interface design experience or training. Our brilliant solutions were nearly impossible to use by normal human beings. Diverse skills and attitudes would have prevented this problem from happening.

So don’t use one shuttle craft, use many. Spread out your risk and learn from a multitude of different voices. Voices whose hearts and souls come from very different places to sing together in one choir. As a manager, your role is the conductor, the teacher, and the mentor who builds the choir.

~

Part 10 - Enemies are often invisible – like Romulans, they can be cloaked.

(This is part 10 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

In Star Trek there was a defensive technology called a “Romulan Cloaking Device” that made their ships invisible to their enemies, much like Harry Potter’s invisibility cloak. From an IT perspective, you need to be aware that your enemies are often invisible. Like Romulans, they can be cloaked.

Viruses, spam, and malware are similar to Romulans. They can be cloaked, yet they can be defeated. But you can’t defeat them with just technology. Admittedly, you need great technology, but you also need to fight the battle on multiple fronts. The interesting lesson from Star Trek is that it is not just a technology game. There are three non-technical soft tools that can dramatically enhance your defensive posture: policy, communications, and coordination.

Let me explain what I mean by policy. You need an organization-wide level security policy giving you the right to enforce IT security (I’ve talked a little about this in Part 3 - Keep your phaser set on stun). To get the mandate to do something like this can be tough. My experience is to ask for an external security audit. You might think that is a bad idea because we all know how potentially vulnerable any infrastructure can be to determined security threats. Such a study might be embarrassing. But my advice is let the auditors be as negative as possible because it gives you, the IT leader, the ammunition necessary to request greater security authority through policy measures.

The second soft skill is communication. For example, prevent phishing attacks through education about never giving out passwords. I tell folks not to tell anybody their password. IT already knows your password, so why would we ask for it? You can’t over communicate this point. Phishing attacks are daily and they are increasingly sophisticated and focused. Spammers are taking the time to learn more about your environment and make the phishing messages more realistic all the time – including using your own logos and timing the attack to coincide with planned system outages. So I advocate communicating relentlessly about security issues.

The third soft skill is coordination. Integrate closely with your non-central IT folks to work together to fight campus threats. At my organization we had a team of folks from central IT and otherwise that worked together as an extended security team coordinated by our central IT security manager.

Most importantly, in many of my favourite Star Trek episodes, Captain Kirk didn’t win battles with superior technology. Quite often he ran into aliens with far superior technology. But he won his battles by outwitting them.

As a matter of fact, Star Trek isn’t an enduring TV show and movie franchise because it is cool science fiction. It is a success because it focused on our humanity and not on technology. The technology was often a gimmick to facilitate the human story. For example, the transporter beam was invented by the writers to conveniently switch scenes as part of a story telling technique. So keep your wits about you and do not let a cloaking device or any other advanced technology fool you.

~