I don’t wish to come across like some old “back in my day” type of person reminiscing about the good old days for several reasons. First when I was starting out the powers that be, thought it would be a good idea to buddy me up with a lot of the senior technical staff and fellows within the company. This had a profound effect on how I think today. Second my employers engaged me in active participation brainstorming solving a wide range of big corporate problems rather than having me as a go-fer. The lessons I would later learn from these experiences helped shape who I am today and are still with me even today, though I’m on the other side of the fence now mentoring others starting out or growing their careers at Satory Global.

First lesson: That old guy you think is slow, may be thinking a lot deeper about the problem than you are. It may be he/she has recognized a pattern from the past; Experience is being able to recognize when you’re about to make the same mistake again. Or maybe see a learning experience that can be passed along to you.

Second Lesson: My mentors never gave me the answers, they asked me questions that provoked me to think deeper about the problem. At Toyota these people are call Ninja Mentors. I was fortunate to have many in my career at multiple companies.

This was a rather exhilarating experience as later, as my father’s generation was retiring, I was asked to work on capturing some small percentage of knowledge from these grand old wizards. Today I still see people trying to recreate the same knowledge that was hard learned but captured in another technology and is not recognized as the same problem. This may have occurred as the corporate knowledge retired with that person. Sad but True.

Yesterday I posted about technology adoption Vs. information management. We could go into a long discussion as to whether the cloud is nothing more than timeshare rebranded, but it’s a waste of time. The technology trend is here, the important factor is whether its managed to improve business productivity or just following the latest fad. In that line of though here is a reposting, slightly updated of an article I did in 1998. I am actively working on updating the last methodology with the intent of sharing it at one of the SharePoint Saturday events.

Technology Management and Investment

Why “technology management?” While it has not been a cause for business failure, or at least not identified as such, the inability to manage technology is becoming a significant factor in a company’s success. This in turn has made developing technology management one of a company’s core competencies. It is a critical skill that technical professionals must develop.

To understand why technology management is so critical, all one has to do is scan the newspapers and trade journals for examples of how it has failed. These examples include catastrophic results from failure to manage the technology, the current wave of forecasted unforeseen effects of technological decisions, and Herculean efforts to mitigate those impending effects on the corporation.

The year-2000 problem is just the most recent incident in a still immature industry and discipline. However, such technologies as the internal-combustion engine, the telephone, pesticides, and fertilizers have effects and consequences beyond the scope and duration that inventors and exploiters of the technology had considered.

By now some of you may be starting to question whether this is an article about the subject of technology management, an attempted political rationale for world planning, or another anti-technological manifesto. Let me assure you that it is neither of the latter two. My home is filled with the latest electronic entertainment gadgets and wizardry. My family owns several automobiles, and with the exception of a rather large library and paper document file system, most of my written composition and information processing is done on one of several computers on our home network. What else would you expect from someone that works at Microsoft?

What should you expect from an article purportedly about technology management? In short, more questions than answers. I could spend literally hours discussing the finer points of some esoteric theory of management or give mounds of statistical data to show why one forecasting technique is better than another one. However, I don’t see that it would hold much interest or relevance, except to a few specialized domain experts. It is not my objective to make you an expert in the field or to present the latest fad technique. Rather, I seek to present to you a broad overview of technology management and its potential benefits and possible pitfalls and to raise some points when considering technology management.

Technology Management Techniques

• Architecture
• Systems Engineering
• Microsoft Solutions Framework 2.0
• Investment Strategies for Information Systems (ISIS)
• Information Economics
• Total Cost of Ownership (TCO)
• Portfolio Mgt. (Investment Model)
• Rapid Economic Justification (REJ)

What is Technology Management?

Technology Management, in the opinion of this author, are the processes to plan the selection, usage, and demise of technologies. This sounds like a very broad statement, where almost any activity of a technical nature could apply, and it is. Most technical and business professionals are engaged in technology management through the selection and design of technologies used to design a product or products. We are thus engaged in this process consciously, unconsciously or by abdication to circumstances. This observation is not an absolute. There are various processes I would suggest which have as objectives managing technology. However, I would also suggest that many of us are engaged in using these processes semiconscious about their effects. I refer to the architectural process, systems engineering, and several design processes such as QFD, VA/VE, and the like. While these have a primary goal of designing a product, various aspects of these techniques ask the practitioner to select properties and attributes to determine qualities the final product should possess. In most of these techniques it is assumed that the practitioner has an understanding and perspective of the qualities the final product should have in a larger context.

Who cares and why?

So does anyone care? The first and most obvious answer has already been hinted at earlier. With the advent of the “Global Economy,” corporations have geared up to this new challenge through improved management of all resources. The effective management of technology and intellectual property has been seen as a competitive advantage. Technology management has thus become a critical competency requirement in most organizations. There are two important points that need to be made with regard to the technologies one needs to manage: the technology a corporation develops and delivers as part of a product to a customer, and the technologies which are developed to develop the product.

Simply, return on investment is why corporations care. Today every resource at the command of a company is examined for how well it contributes to the bottom line. Capital, equipment, people, and technology, all are now being viewed through the same financial lens. Likewise the philosophy that all resources should be managed has also changed the corporate psyche.

In the past, corporations have swung like a pendulum between two extremes; full lifecycle planning and organic growth in their management technologies. The fact of the matter is there is no perfect technology management methodology.

Technology Management Techniques

During my early career at Rockwell one of the first Technology Management techniques I used was “architecture” as opposed to design.

A design is a specification for the creation of a product, while architecture is the rules for selection and usage of elements which constrain the process of design. Architecture constrains the design activity such that it only produces designs of similar characteristics and qualities such as a family.

What is useful about this methodology is its ability to focus simultaneously on both the whole and its constituents. Unlike many other techniques architecture seeks to strike a balance between these two perspectives (analysis and synthesis). Too often laypersons speak of architecture when they mean the design of a product. While architectural principles enable one to address this issue, using the metaphor to the extreme, in this context, puts him or her in jeopardy of creating a monument. It looks nice, but doesn’t have relevance or function for the present conditions.

Systems engineering, a close cousin to architecture, seeks to decompose a product into a collection of subsystems or components which when assembled meet the overall product requirement. The basis of this technique is the decomposition and allocation of requirements to the various elements that compose the final product. These elements are traditionally organized in a hierarchy that is related to a similar decomposition and allocation hierarchy of requirements.

Individual techniques within this methodology assist the designer in analysis and decision-making from a predictable and repeatable set of rules. Another important concept within systems engineering is the focus upon the management of interfaces. The rationale behind this is that properly constructed interfaces bind the implementation of the component from the rest of the system, therefore components can be replaced with other components as long as they have the same interface and characteristics. This concept makes modularization and delegation possible, since the interface is the only place where the system as a whole is affected by its pieces.

Other models of managing technology have derivations from the investment and financial community. The four most popular techniques are:

• Portfolio Management
• Investment Strategy for Information Systems (ISIS)
• Information Economics
• Rapid Economic Justification (REJ)

These methods are concerned less with technical issues than value and prioritization clarification. These techniques address establishment of benefit or value, assessment of risk and uncertainty, prioritization, and decision-making.

Portfolio management: Technologies are clustered into groups based upon similar attributes, and decisions as to managing these technologies based upon these groupings are used. The most famous of these techniques has been the Boston Consulting Group’s matrix that classifies members into groups: Dog, Cash Cow, Rising Star, etc.

Investment Strategy for Information Systems: This is an asset allocation and justification methodology developed by IBM in the 1980s to assist MIS directors. The benefits here are the ability to focus upon making decisions based upon relative values of the various members. The disadvantage is the oversimplification of issues to a single value decision that may not address other factors that have significant effects.

Information Economics: A technique developed by Parker and Benson of IBM. It provides the practitioner a means to quantify various factors which affect decisions and establish a relative weighting of importance to them. Though not a pure objective approach, these methods provide the decision maker visibility in the logic behind the decision made. Like the portfolio management, these techniques group technologies into a system based upon the attributes and relative weights of each attribute. The result of using these methodologies, specifically in a group, is more than just a ranking of alternatives. It forces one to examine the values that are placed upon decision criteria and apply them equally across all options.

This is where the Microsoft Solutions Framework (MSF 2.0) comes in. It is not a methodology in the strictest sense; it provides a map of techniques applicable to the various phases of the Software Development Life Cycle (SDLC). Many of the elements of the Framework can be employed or not. These techniques address various phases of software technology management such as planning, selection, and coordinating design and construction activities. In addition there are elements (templates) which guide and assist professionals in activities such as installation. These templates reduce project plans to a parametric exercise, thus enabling a manager to focus upon non-repetitive activities instead of the simple day-to-day mechanics.

What MSF does is allow a CIO, for instance, to manage the technology within an infrastructure of an organization. It’s important to note, what MSF doesn’t do is force you to choose a specific technique, therefore enabling you to choose the most appropriate techniques for your organization.

Rapid Economic Justification: A technique developed in conjunction with Microsoft corporation during the late 90s sought to create a fast, logical and mathematically correct model of evaluating benefits and costs of IT projects. The key factor was establishing a baseline of benefits in metrics that could be traced back to logical assumptions that were believable by CFOs. I am still working on a derivate of the methodology (BEIS) that adds portfolio management, options theory and a more robust means of measuring value.

Originally Published in START Magazine March/April, 1998, Minor Revision 2011 to add REJ