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.

~

Product backlog - key to agile success

  

The product backlog is an organized and structured list of work items that reflect your customer needs in relation to a particular product. The product backlog is used to categorize customer requests and ensure the development team is working on the most important features for your business.

 Getting started

Before work begins on a new software release, the product manager needs to organize and categorize the items in the product backlog. For new products this may involve spending time with business stakeholders and documenting their requirements into work items. In the case of an existing product this may involve reviewing the list of known customer requests, bugs (defects) and new features.

Adding features to the product backlog

The product backlog can be made of different types of work items. The following list shows the typical work item types in a product backlog:
- Bugs
- Outstanding technical work (technical debt)
- New features

Bugs are known defects that are found during the development, testing and production use of the system.

Technical debt relates to any technical work that needs to be carried out. It can be code refactoring, work to address performance and scalability issues,upgrading 3rd party components, etc... Technical debt is often not visible to the end user unless it impacts the daily system usage such as performance issues. Outstanding technical work needs to be prioritized and scheduled so there is visibility of it in the work plan and all stakeholders are aware of what the development team is working on.

It can be hard to prioritize purely technical work because, often, users don't see the value in spending time in these kind of tasks, however it is important to prioritize and address any technical debt before they become a real hindrance to the system and/or the development process.

New features are functional items that are not currently available or potential improvements to current functionality. Depending on the size and complexity of the system, I tend to separate new feature requests from improvement requests.

A good product backlog will contain a number of work items of various different types including bugs, new requests, improvement requests and technical debt.

Once you have your product log, the next step is to categorize and prioritize the each work item.



Organizing the product backlog in preparation for a new sprint

The next step is to classify and prioritize your product backlog. A backlog is useless if you cannot find the most important tasks or if you don't have the ability to group items together.

Start by classifying your list into themes that make sense to your project. Themes could be "search", "usability" or anything else that is useful to group work items together.

Classifying work items into these themes will help you to quickly identify all types of work items that relate to a certain function and you may decide to have sprints based on themes.

Once you classified your work items it is time to start prioritizing. I find it easier to set priorities once my backlog is organized into themes, however you may choose to prioritize first and then classify your work items, it is really up to you.

It is very important to involve business stakeholders in the process of setting priorities. At the very least,the product owner needs to be able to set high level priorities for your next set of work. This can be done at the theme level, say the next sprint will be about improving usability issues, or he may contribute by setting the relative priority of work items that will be include in the next release.

In my experience, if your product backlog is logically categorized product owners tend to set priorities at the category level (themes), not for each individual work item. It will be your job as the product manager to set the relative priority of the tasks and confirm the final list with the product owner or business stakeholder.

This may sound like a very segmented and inefficient process, however it is important to ensure that you involve the product owner at this stage of the work so that your priorities are aligned with business priorities and strategies.

Once your backlog is categorized and priorities are set it is time to organize your sprint.

Generating your sprint backlog

Once the team knows what features go into the sprint backlog, the development team decomposes the work items into tasks and get on with the work.

Project vs. Program vs. Portfolio Management

Many people get confused with project vs. program vs. portfolio management.
A project is a temporary undertaking to achieve a defined output. The output of a project may be a tangible product or other things such a the answer to a question. A project has defned start and end dates as well as well defined outputs. A project must not be confused with normal operational work which is defined by processes, procedures and job descriptions. A project is temporary as opposed to operational work which is ongoing.
A progam is a group of related projects managed together to achieve specific benefits and controls that would not be achievable if the projects were managed separately. While projects focus on achieving individuak objectives, programs are defined to achieve a strategic objective. The program manager is responsible for ensuring that the various projects are working together to achieve the defined strategic objectives.
A portfolio is all the programs and/or projects of an organisation managed together to achieve strategic goals. A portfolio may be all the programs for an entire organisation, a division or a business unit.

The image below depicts the difference between portfolio, program and project.

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. 


~