Psychographics - Interesting fact of the day

Psychographics is the science of measuring and categorizing consumer lifestyles.
One of the most popular classifications based on psychographic measurements is SRI
International’s Values and Lifestyles (VALS) framework. The VALS 2 system classifies
all U.S. adults into eight groups based on psychological attributes drawn from survey
responses to demographic, attitudinal, and behavioral questions, including questions
about Internet usage. The major tendencies of these groups are:

➤ Actualizers: Successful, sophisticated, active, “take-charge” people whose purchases
often reflect cultivated tastes for relatively upscale, niche-oriented products.

➤ Fulfilleds: Mature, satisfied, comfortable, and reflective people who favor durability,
functionality, and value in products.

➤ Achievers: Successful, career- and work-oriented consumers who favor established,
prestige products that demonstrate success.

➤ Experiencers: Young, vital, enthusiastic, impulsive, and rebellious people who spend
much of their income on clothing, fast food, music, movies, and video.

➤ Believers: Conservative, conventional, and traditional people who favor familiar
products and established brands.

➤ Strivers: Uncertain, insecure, approval-seeking, resource constrained consumers who
favor stylish products that emulate the purchases of wealthier people.

➤ Makers: Practical, self-sufficient, traditional, and family-oriented people who favor
products with a practical or functional purpose, such as tools and fishing
equipment.

➤ Strugglers: Elderly, resigned, passive, concerned, and resource-constrained
consumers who are cautious and loyal to favorite brands.

Which group would you fall into?

Src. Framework for Marketing Management by Philip Kotler

Chinese "Six Pocket Syndrome" - Interesting fact of the day

The explosive world population growth has major implications for business. A
growing population does not mean growing markets unless these markets have sufficient
purchasing power. Nonetheless, companies that carefully analyze their markets
can find major opportunities. For example, to curb its skyrocketing population, the
Chinese government has passed regulations limiting families to one child per family.
Toy marketers, in particular, are paying attention to one consequence of these regulations:
These children are spoiled and fussed over as never before. Known in China
as “little emperors,” Chinese children are being showered with everything from candy
to computers as a result of what’s known as the “six pocket syndrome.” As many as
six adults—parents, grandparents, great-grandparents, and aunts and uncles—may be
indulging the whims of each child. This trend has encouraged such companies as
Japan’s Bandai Company (famous for its Mighty Morphin’ Power Rangers), Denmark’s
Lego Group, and Mattel to enter the Chinese market.

Src: Framework for Marketing Management by Philip Kotler

Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapter 14 to 17 Reflection

Reflection on Chapters 14 to 17 of Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco

Link to sample Chapter 1 from Waltzing with Bears http://www.systemsguild.com/pdfs/bearsample.pdf

Link to Waltzing with Bears Textbook Download

Chapter 14, “A Defined process for Risk discovery”, states that along with core risks, there may be project-specific risks that impact a project. This chapter talks about identifying project-specific risks and the factors that hinder the risk discovery process. One such factor is the “can-do” attitude of the organization, wherein a project member who articulates a risk could be termed as a negative-thinker. In order to overcome this problem, it is important that the organization encourages “what-if” thinking. This is also the basis of the defined process for risk discovery described which begins with the outcomes of the risk, unfolding the scenarios that could lead to the risk and ultimately the causes of the scenarios.

The chapter also suggests some more techniques for risk discovery such as brainstorming, scenario-building and root cause analysis. My previous project employed the brainstorming and root-cause analysis techniques for identifying the causes of defects in the code, which were very effective in reducing majority of the defects caused due to oversight or not following coding standards. These techniques will help promote “what-if” thinking among project members to identify the risks. The author also recommends identifying and isolating the “win” conditions of each stakeholder in the project to make sure that they are not contradictory, as conflicts in “win” conditions is a definite risk to the project being accepted.

Chapter 15, “Risk Management Dynamics” emphasizes the importance of risk management as an ongoing activity as opposed to an activity done only at the beginning of the project. It includes the following tasks that need to be carried out throughout the life cycle of the project - risk monitoring, risk discovery, risk data collection and tracking closure metrics. The closure metrics that need to be tracked include “boundary elements closure” and “earned value running”. The boundary elements closure metric protects against the risk of specification breakdown by analyzing the net boundary flows so as to obtain a sign-off by all the stakeholders within the first 15% of project duration. The earned value running (EVR) metric is used to track project completion status from 0 to 100 percent and provide credible evidence of partial doneness while the project is in progress, as and when each module of the project completes (incremental delivery).

 Chapter 16, “Incrementalism for Risk Mitigation” further explains the concept of “incremental implementation” as explained by the earned value running metric collection in the previous chapter. Creating the work breakdown structure is one of the techniques for categorizing tasks and their dependencies, measuring the EVR and targeting incremental delivery. In my previous project, the visual basic screens for insurance member enrollment and billing were developed in increments and each week a “build” (incremental version) of all the screens combined would be sent to the client as a deliverable for review. This technique would help in increasing visibility and involvement of the stakeholders and gaining acceptance from them early on as the product is being developed as opposed to once the product is already built and thereby, reduces the risk of product not being accepted by the stakeholders. It also helps in targeting the uncertain requirements in earlier versions to reduce the risk. So, I agree with the author that incremental delivery is a good method for any project, especially when the risks are high.

Chapter 17, “The Ultimate risk mitigation strategy” emphasizes with examples that for projects with critical deadlines, it is better to make an early start, which I think is a very practical option for reducing the risk of not meeting deadlines. It will also help in discovering issues early on. Since the amount of effort involved in a project is more or less constant, starting the project early will enable finishing it early or at least on time. 

Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 8 to 13 Reflection

Reflection on Chapters 8 to 13 of Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco

Link to sample Chapter 1 from Waltzing with Bears http://www.systemsguild.com/pdfs/bearsample.pdf 

Link to Waltzing with Bears Textbook Download

Chapter 8, “Quantifying uncertainty”, explains that one of the risks for any project is uncertainty in the schedule for completion of the project. It further illustrates how this uncertainty can be expressed in the form of a risk diagram, which helps to at least narrow down the window of uncertainty.

Chapter 9, “Mechanics of risk management”, talks about how risks can be identified. As the saying goes, “History repeats itself”. So the chapter states that one of the most useful methods of identifying risks is analyzing previously failed projects in the organization and listing the causes, which can serve as risks for the current project. However, I feel that this method will be highly effective only if the organization has been involved in similar projects in the past. For instance, if an organization has only been involved with maintenance projects previously, then the risks in a development project will be much higher. Nevertheless, the technique can be a valuable step in identifying risks initially. The chapter also states project estimation as an important task in risk management and emphasizes that both planned and un-planned tasks in the project must be estimated in order to avoid project delays.

Further, the chapter mentions four strategies of dealing with risks – avoidance, containment, mitigation and evasion. The author presents a very interesting point that out of the above four strategies, risk evasion does not cost anything. However, ideally it can not be considered as a risk management strategy because as per the “ethics of belief” philosophy, the risk evader is not proved right, he is just “not found out”. Another task that I thought could have been included in the above four is “risk prevention”. In my previous project, we were to design a database for storing procedure codes for claim adjudication. The current system had 5 character procedure codes, so a field size of 5 would be sufficient. However, to support future expansion of procedure codes, a field size of 10 was allocated. This would prevent the risk of the database not being able to accommodate larger procedure codes.

The chapter also explains the concept of showstoppers as risks and how their ownership can be transferred to higher authority so they are just assumptions for the project. To quote an example, in my previous project, the developers worked directly on the client’s mainframe. The mainframe had both scheduled and unscheduled downtime each day, which was essentially a showstopper for the project. So the project maintained a log of the mainframe downtime, which would help get an extension of the project deadline. Additionally, the chapter elucidates how risk impacts budget and schedule and how risk mitigation is in fact a good investment of time and cost.

Chapter 10, “Risk Management Prescription” presents a comprehensive list of the steps involved in risk management, namely risk discovery, risk estimation, calculating risk exposure, risk mitigation, and risk monitoring. It emphasizes the “Schedule > Goal > N” rule of N-based scheduling.

Chapter 11, “Back to Basics” discusses the use of risk diagrams as a tool for assessing the extent of risks and their characteristics and types, namely aggregate risks and causal risks. It also explains how a risk model can be used to transform causal risks into aggregate risks and help in estimating the schedule for the project. The examples provided in order to explain the concepts of the incremental and cumulative uncertainty diagrams were quite simple to understand.

Chapter 12, “Tools and Procedures” introduces the Riskology tool for risk assessment and explains its use and the underlying risk model. Although the use of the tool does not require an understanding of the risk model, the chapter presents an explanation of the model and the Monte Carlo sampler very aptly through a simple example (estimating time for jogging along a track) to give a background of the underlying framework. I found the tool quite intuitive in use and addressing the core risks that impact a project.

Chapter 13, “Core risks of software projects” lists five of the most common risks that impact any project such as schedule flaw due to overaggressiveness, undersizing or wishful thinking, requirements inflation due to change in domain, employee turnover, specification breakdown due to ambiguities in product specification or requirements being piled up by stakeholders and poor productivity. The chapter further quantifies the risks using industry patterns.

Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 5,6 and 7 Reflection

Reflection on Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 5,6 and 7
Link to sample Chapter 1 from Waltzing with Bears http://www.systemsguild.com/pdfs/bearsample.pdf

Link to Waltzing with Bears Textbook Download

Primarily, the book “Waltzing with Bears” offers valuable insights about risk management techniques and how they can be applied. However, chapters 5, 6, and 7 deviate from the theme a little to talk about scenarios where risk management techniques cannot be employed (For example: ‘can-do’ attitude of an organization).

Chapter 5 adopts a very pragmatic approach towards risk management and explains various such circumstances where risk management is avoided. For instance, stakeholder might not take up the project if he/she knew the risks involved. The author also talks about organizations that advocate the “manage for success” approach and that it is difficult for one person to swim against the tide and promote risk management in such an organization.

Chapter 6 further elaborates on the “uncertainty” factor in certain corporate cultures that accept failures and delays but not uncertainties. Such an approach thwarts risk management efforts. The result is that such organizations concentrate on selective minor issues while large problems are blindly ignored and taken off the risk list, the consequences of which usually cataclysmic to the project. This can be avoided by tracking the risks that are crucial to the project from effect to cause, along with other minor issues.

Chapter 7 explains that when listing the risks, there are some risks that are dependent on sheer luck and which cannot be incorporated in the list of risks impacting a project. The example the author quotes is that of an “asteroid demolishing the company”. From personal experience, I can share one such instance. During the coding phase of my project in my previous organization, when the team size increased to 60, we were shifted to another building so that the entire team could be seated together. About 2 weeks after the shift, there was a downpour, which flooded the basement of the building and damaged the servers and generators in the building. As a result, the entire team was not able to do any work for 3 days till the servers and generators were restored. The project went off-schedule.

So basically, the absence of 1-2 people in the team can be handled using risk mitigation strategies like padding the schedule but the absence of an entire team of 60 for 3 days (more than 1000 hours of effort) is not foreseeable and hence cannot be planned for in advance when estimating the delivery dates for a project. But that does not imply taking chances with all the risks as the author concludes. Proper risk management strategy requires every risk to be evaluated before taking it off the list.

Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 1 to 4 Reflection

Reflection on Waltzing with Bears : Managing Risk on Software Projects by Tom Demarco Chapters 1 to 4
Link to sample Chapter 1 from Waltzing with Bears http://www.systemsguild.com/pdfs/bearsample.pdf

Link to Waltzing with Bears Textbook Download

Chapter 1, "Running toward risk" starts off with describing what should be your attitude towards risks. There is no project without risks. And the best way to deal with risks is to accept them instead of avoiding risks. Once you accept the risk, you can work on a risk management strategy.

Chapter 2, "Risk Management Is Project Management for Adults" presents examples of risk management and risk mitigation. We all do some sort of risk management or mitigation in our daily lives. Insurance, for instance, is a classic example of risk mitigation by transferring the risk of financial loss to the insurance company and obtaining coverage for a monthly premium in the event of an accident or a health problem. Tom Demarco discusses the phases of risk management which start with

1. "Risk Discovery" - identifying all possible risks through brainstorming
2. "Exposure Analysis" - quantification of each risk in terms of its probability of materializing
   and its potential impact
3. "Contingency Planning" - what you expect to do if and when the risk materializes
4. "Mitigation" - steps that must be taken before transition in order to make the planned
   contingency actions possible and effective when required
5. "Ongoing transition monitoring" - tracking of managed risks, looking for materialization

Chapter 3, "Denver International Airport Reconsidered" talks about the project to build a new Denver International airport to replace the existing one, Stapleton Airport. Stapleton was judged incapable of expansion, inadequate to serve the growing city, and guilty of contributing to ever-more-evident noise- and air-pollution problems. With the new airport, costs would be reduced, pollution and air-traffic delays would be eliminated, and growth would be assured. The new Denver International Airport (DIA) was scheduled to open on October 31, 1993 and everything for ready except for the software DIA Automated Baggage Handling System (ABHS) due to which the airport could not open.So much blame was laid on the software team that even today, the phrase "DIA Automated Baggage Handling System" is a recognized symbol of incompetent software projects. Later analysis found that there was little or no risk management at the DIA project. Had there been a risk management strategy adopted earlier on in the project, a delay in the software delivery would have been identified as a significant risk.



Chapter 4, "The Case for Risk Management" presents the importance of risk management for even the smallest projects. What the software industry can learn from the DIA example is the potential cost of not managing risk. Risk management is a way to break the grim cycle of failed projects by providing a set of meet-able goals and schedules and engendering successful projects that look and feel successful from beginning to end.

Similarities and Differences between Software and Systems Engineering

According to CMMI, Software engineering is defined as a discipline that covers the development of software systems. It focuses on applying systematic, disciplined and quantifiable approaches to the development, operation and maintenance of software. Systems engineering is defined as a discipline that covers the development of total systems, which may or may not include software. It focuses on transforming customer needs, expectations and constraints into product solutions and supporting those product solutions throughout the product life cycle. These definitions elicit the primary difference between systems and software engineering.

The differences between software and systems engineering can be further classified based on different parameters. For instance, in software engineering, the architecture can be dynamic and subject to change, based on emergent needs during the software development life cycle. Whereas in systems engineering, the architecture is established at the beginning of the systems development life cycle and usually remains stable. In order to develop high-quality software, software engineering lays emphasis on portability, adaptability, customizability and flexibility. Systems engineering, on the other hand, concentrates on the reliability, safety, availability and maintainability of the system.

Another distinction between software and systems engineering is that software engineering does not take into consideration physical wear and fatigue which are important criteria for consideration in building a system. Also, software engineering is not restricted by the laws of physics. Systems engineering needs to take into consideration the system environment, which greatly impacts the functionality of the system.

In software engineering, the interfaces between software components are typically conceptual such as protocols. Systems engineering interfaces, in contrast, are generally more tangible and well defined for the integration of components within the system. For example, the Security Alarm system consists of components such as sensor, telephone caller, actuator and interface. Systems engineering process frequently involves manufacturing and lead-time, whereas software engineering often involves rapid application development using prototyping.

In spite of the evident dissimilarities described previously, there are some noticeable commonalities between software and systems engineering. Both are complex processes involving people, facilities, processes, hardware, and policies. Both are undertaken for the purpose of meeting stakeholder requirements and accomplishing the defined performance. Both involve the generic practices of establishing requirements, involving relevant stakeholders, managing configurations, reviewing status with high-level management, rigorous testing procedures, defect analysis, defect prevention and correction, adhering to quality objectives, ensuring continuous performance in a changing environment and training people.

Software engineering is increasingly becoming a part of systems engineering. But it is sometimes seen as a problem, as it has caused delays in many large system development projects, an example being the Denver Airport Baggage Handling System. In conclusion, systems engineering can be considered as an interdisciplinary field of engineering, which could be a superset of software engineering and which considers both the technical needs and business needs of the customer, with the objective of delivering a quality product.

Mr. Thompkin's Journal from Death March by Tom Demarco

Mr. Tompkins, a manager downsized from a giant telecommunications company, divides the huge staff of developers at his disposal into eighteen teams--three for each of the software products. The teams are different sizes and use different methods, and they compete against each other and against an impossible deadline. With these teams--and with the help of numerous "fictionalized" consultants who come to his aid--Tompkins tests the project management principles he has gathered over a lifetime. Each chapter in the book Death March by Tom Demarco closes with journal entries that form the core of the eye-opening approaches to management illustrated in this entertaining novel. This is my reflection on the journal entries of Mr. Tompkins from Death March.

Mr. Tompkin's Journal packages a concise collection of insightful project management principles, approaches, skills and best practices and summary points for review. Each journal entry presents a series of conclusions for new scenarios discussed in the chapter. It covers a broad array of technical subjects like risk management, project estimating, metrics, improving productivity, overstaffing effect, dealing with ambiguous specifications, modeling for simulation, process improvement as well as soft skills such as leadership, interviewing and hiring project staff, motivating performance, improving communication, team politics, team dynamics, anger management, conflict resolution and negotiation.

Most project management books and guides focus on the technical aspects of project management processes. However, the journal entries emphasize that it is the people along with the processes that are the indispensable foundation of any successful project. An interesting point that the journal mentions which I had not come across in any other project management book is in the “Playing Defense” entry: “Keep good teams together to help your successors avoid problems of slow-jelling or non-jelling teams. Think of a jelled team as one of the project deliverables”. In my previous organization, it was a policy to disperse the project team to different projects or even different department domains (from insurance to banking) once the project is complete. Sometimes, the resources would even be shuffled between projects while the project is still going on, which would put additional strain on the project team to get the new resource on-level. I believe that when resources are transferred between domains, the existing domain knowledge of the resource is wasted.  So, I completely agree that a jelled team is the most important resource and should be considered as one of the deliverables. This is especially true in bigger projects that last for more than a year, unless you are dealing with a geographically dispersed team (GDT), because of the time invested in promoting trust and making certain that everyone knows their contribution.

Another journal entry that I had not come across before in any other book was about “Negative Reinforcements”: “Threats are an imperfect way to motivate performance

No matter how serious the threat, the work still won’t get done on time if the time originally allocated for it was not sufficient”. This reminded me of one of my earlier projects which had stringent deadlines and the scope of the project increased because of requirements not being properly documented. The upper management made it clear that unless the team put in more hours during weekdays we will have to work on weekends. Not only, did the entire team have to put in more hours during weekdays, but we spent three consecutive weekends trying to meet the deadline, which ultimately had to be extended, which I think goes to prove another journal entry that “The real reason for use of pressure and overtime may be to make everyone look better when the project fails”.

The best part about the journal was that, apart from the realm of software and projects, it also offers some practical, positive, and philosophical advice such as “You can’t get people to do anything different without caring for them and about them. To get them to change you have to understand and appreciate where they’re coming from and why”. This is applicable not only to the project scenario, but also to life in general. The one I liked the most is “There are infinitely many ways to lose a day, but not even one way to get one back.” because sometimes people have a tendency to procrastinate and finish work at the last minute.

Thus, I think Mr. Tompkin’s journal helped me in comprehending a lot of important project and process concepts and made me think how I would react to certain situations and also to obtain a perspective about interacting with people while working in a team.

Six Sigma Methodology Critique

Six Sigma is basically a methodology, originally developed by Motorola, to improve
the quality of processes by removing and preventing defects. A defect can be any
feature or functionality of a product or a process that does not meet its specification.
Six Sigma can be defined as a metric to measure the performance of a process. Its
goal is to improve the performance and increase profitability by targeting a defect
rate of less than 3.4 DPMO (defects per million opportunities).

The key processes involved in applying Six Sigma are DMAIC (Define, Measure,
Analyze, Improve, Control). The Define stage identifies the process to be improved.
The Measure stage collects the data for the process for comparison. The Analyze
stage identifies any discrepancies between the current performance and optimal
performance of the process. The Improve stage fixes the inconsistencies in the
target process. The Control stage targets at ensuring the non-occurrence of the
discrepancies and continued optimal performance of the process.

An interesting point to note in the application of Six Sigma methodology is that
it is applicable to almost any process. This is evident from the example of the
“Tiffin carriers” in Mumbai (India), who deliver thousands of tiffins to their correct
destinations each day with remarkable precision and Six Sigma efficiency of 99.99%.
The technique employed is straightforward - uniquely identifying each tiffin by the
use of different colors, symbols, letters and numbers indicating each tiffin’s origin
and destination, leaving no margin for error or misinterpretation, even when there
is no documentation. Thus, Six Sigma focuses on process optimization by identifying
and eliminating all the defects in the course of a process and delivering almost
defect-free products.

Quality, defect-free and on-time delivery are vital to the software industry.
These can be achieved by training all the members of the project to meticulously
streamline processes by applying the Six Sigma methodology. It establishes a
culture of excellence and encourages all the members to not only accomplish
the objectives, but also to provide quality solutions at each stage of the software
development life cycle.

A notable shortcoming of the Six Sigma methodology is the lack of a standard
certification/accreditation institution which is acknowledged globally. Each
organization has its own method of judging the competency of its employees. Since
the Six Sigma level is declared by the company itself, it holds less credibility as a
quality directive. Also, Six Sigma training represents a significant cost investment,
and it does not promise zero-defect deliverables. Moreover, it is important to
consider the buy-in of the employees to implement Six Sigma.

In spite of these limitations, Six Sigma methodology promises a good return on
investment in the software industry since high-quality deliverables are part of the
business goals. The organization is able to understand customer needs much better
and take better decisions. This assists in decreasing the defects, thereby significantly
reducing the costs and consistently generating superior quality deliverables, which
ultimately lead to customer satisfaction, gaining customer’s confidence and even
continued business.

Harvard Business Review: Case Analysis - ERP Implementation at CISCO (699022-PDF-ENG) from Strategic Role of IT perspective

Presenting an analysis of the HBR case ERP Implementation at CISCO (699022-PDF-ENG) from Strategic Role of IT perspective. Link to the case http://hbr.org/product/cisco-systems-inc-implementing-erp/an/699022-PDF-ENG

Case Background: Reviews Cisco System's approach to implementing Oracle's Enterprise Resource Planning (ERP) software product. This case chronologically reviews the diverse, critical success factors and obstacles facing Cisco during its implementation. Cisco faced the need for information systems replacement based on its significant growth potential and its reliance on failing legacy systems. The discussion focuses on where management was particularly savvy in contrast to where it was the beneficiary of good fortune.

Introduction. 3

I.       Overview of the Business. 3

A.      Company Background. 3

B.      Market segment, Products & Channels. 3

C.      Business strategy. 4

D.      Financial Position. 4

II.      Porter’s Model of Five Competitive Forces: 5

III.         Role of IT and Strategic Grid. 6

IV.         Description and Brief Discussion of the Issue. 7

V.     ERP Implementation at Cisco. 8

A.      Strong impetus for change. 8

B.      Strong sponsorship & business involvement. 9

C.      ERP vendor selection. 9

D.      Lack of data encryption during transmission. 9

E.      Violation of PCI standards. 9

F.      Lack of regular audits. 10

G.     Lack of processing logs. 10

VI.         MOT Triangle. 10

VII.        Recommendations

Introduction

Cisco Systems Inc. is the world’s largest maker of computer networking gear. Cisco provides a broad line of products for transporting data, voice and video around the world, which transforms how people connect, communicate and collaborate. Since the networking industry is rapidly evolving, Cisco is focusing on delivering intelligent networks and technology and business architectures built on integrated products, services, and software platforms to its customers. This case analyzes the ERP rollout that took place on the brink of legacy system failures in Cisco in the years 1994-1995; the process and impact, and strategic recommendations.

       I.            Overview of the Business

A.     Company Background

CISCO was founded by two Stanford computer scientists in California in 1984 to capitalize on the expanding “internetworking” market and brought public in 1990. In 1997, Cisco featured in the list of Fortune 500 companies and ranked in the top five companies in Return on Revenues and Return on Assets[1]. In 1998, Cisco’s market capitalization passed the significant $100 billion mark. In 1999, Cisco had more than 75% internet traffic share.

B.     Market segment, Products & Channels

Cisco operates in the communications and information technology (IT) segment. At the time of the case, Routers were Cisco’s main product. Digitization had enabled the convergence of three independent proprietary networks – phone networks for voice, the local-area and wide-area networks for data, and the broadcast networks for video, in the form of the Internet. Following this trend, Cisco was accelerating to grow in the new IP-based networks market segment that did not exist earlier. Presently, Cisco designs, manufactures and sells Internet Protocol (“IP”) based networking and other products related to the communications and IT industry and provide services associated with these products and their use[2]. Cisco’s product portfolio is categorized into following categories – Switching, Routing, Service Provider Video (set-top boxes & cable modems), Collaboration (IP phones, call center & messaging products, WebEx), Security, Wireless, Data Center, Other Products (mainly Linksys home networking products) & Services (Technical Support).

C.      Business strategy

Cisco operates in both the Business-to-Business (B2B) and Business-to-Consumer (B2C) markets in the computer networking segment. In the B2C market, Cisco focuses on the “low cost” strategy selling products such as wireless routers, switches and surveillance cameras. Market, Cisco focuses on the “differentiation” strategy with innovative products and business solutions for collaboration such as Webex, Telepresence and SocialMiner. In terms of Porter’s potential business strategy types for achieving competitive advantage, Cisco lies between differentiation and low cost leadership quadrants at the bottom since it operates in a niche segment of networking. This business strategy heavily depends on research and development to ensure product's uniqueness, reliability, quality and customer satisfaction.

D.     Financial Position

Reviewing the financial statements of Cisco for the year ending January 1995, Cisco had a strong financial position with net sales of $1.9 billion and net income of $421 million[3]. Cisco was the leader in its market and had acquired four companies namely LightStream(R) Corporation, Combinet Inc., Internet Junction, Inc. and Grand Junction Networks, Inc. and further expanded its portfolio of products and services. Cisco’s net sales grew 59.2% from $1,243.0 million in 1994 to $1,978.9 million in 1995.

    II.            Porter’s Model of Five Competitive Forces:

1.      Existing Competitors

As the case mentioned, the internet and its open standards were creating a new competitive battleground for the entrenched telecommunications players such as AT&T, Verizon, British Telecom and Deutsche Telecom. Lucent Technologies was also another competitor that was transitioning towards digitization. Juniper Networks also competed with Cisco directly by providing next-generation Internet backbone routers specifically designed for service providers. There was a high rivalry among existing firms to obtain market share for different products such as routers, switches as well as network services, but neither had all the products they needed to ensure a big win. Cisco was also facing competition from over 5000 Internet Service Providers (ISPs) including UUNet, PSINet and GTE/BBN to provide fax, messaging and EDI capability at a much lesser price compared to CISCO.

2.      Threat of Substitute Products

Cisco has a brand value and it’s known for its reliable and high-quality products. Cisco’s investment in R&D provides it a competitive edge over its competitors with innovative products. Also Cisco offers a suite of networking products and services combined together that is not offered by any other single company. Customers would have to go to multiple vendors for different products, so there is a low threat of substitute products.

3.      Bargaining Power of Buyers

Since Cisco has a diverse set of products and services, large customer base and is not dependent on a single bulk buyer for its business, the bargaining power of buyers is low. As mentioned in the case, Cisco has more than 600,000 registered customers.

4.      Bargaining Power of Suppliers

Cisco does not rely on a single source of suppliers, but sources its products various contract manufacturers and only performs design, final assembly and test. Hence the bargaining power of suppliers is low.

5.      Threat of new entrants

The high growth rate of the three independent proprietary networks: phone networks for voice, local-area and wide-area networks for data and broadcast networks for video may seem to attract new entrants, however in order to successfully operate in the network industry, a company requires a huge capital investment for research and development and expert domain knowledge to design innovative networking products, or a company would need to acquire another company that is developing innovative networking products. The new entrant company would need to differentiate itself and provide complete business solutions. All these requirements serve as significant barriers to entry for new entrants. However, for big telecom companies such as AT&T and Verizon that have an established brand can easily diversify their product base through acquisitions and enter into the networking market. Hence there is a moderate threat of new entrants.  

 III.            Role of IT and Strategic Grid

IT plays an important role as an enabler of business through e-commerce, supply chain management, customer relationship management and employee self-service applications  in Cisco’s business strategy of providing innovative business solutions, achieving operational effectiveness, maintaining low cost and staying competitive. IT systems and networks enable rapid transmission of data between contract manufacturers, customers, employees, and business partners such as acquired companies. The legacy IT systems at Cisco would fall in the “Factory” quadrant of the strategic grid as it included applications that are critical to sustaining existing business for daily operations. When the legacy applications failed, Cisco was virtually shut down for two days.

Cisco’s ERP application was implemented as a turn-around system that would bring about major process and service transformations. The ERP solution would replace the legacy system with a “big-bang” instead of a phased implementation approach. At $15 million, the ERP project constituted the single largest capital project ever approved by Cisco. After the ERP implementation, Cisco was able to reorganize R&D and marketing from multiple business units to three lines of business in fewer than 60 days for a cost less than $1 million. ERP application provided significant cost reductions, flexibility and scalability through standardization. ERP project laid the foundation for incorporating the internet applications such as E-commerce, employee self-service, executive information systems and decision support systems which closed a significant cost, service and process performance gap with competitors. Since the ERP system did not have a high impact on the core operations, but had a high impact on Cisco’s core strategy, IT would be in the “Turn-around” quadrant on the Strategic Grid[4].

  IV.            Description and Brief Discussion of the Issue

Cisco’s legacy IT department was too traditional and internally oriented and being viewed as a cost center. The potential contribution of IT to business was also much smaller than it could be. The legacy systems were traditional financial, manufacturing and order-entry systems, which could not scale to support Cisco’s growth, nor were they flexible or robust enough to meet management requirements. Years of customization to the legacy system had resulted in a complex platform, that was familiar and comfortable for its users, but was out of date and in danger of imminent failure.[5] In January 2004, Cisco’s legacy environment failed. An unauthorized method for accessing core application database was used as a workaround, which malfunctioned and corrupted Cisco’s central database. As a result, the company was virtually shut down for two days. Cisco was the biggest customer of their legacy software vendor and the vendor was being bought by another company. It was unclear who was going to support the legacy systems. This created a sense of urgency to replace the legacy system. If each department at Cisco such as manufacturing, marketing and finance implemented its own software it would take longer time to do the separate projects. Hence, implementing a single integrated replacement of the legacy system such as an ERP application was crucial and time-sensitive.

     V.            ERP Implementation at Cisco

Cisco successfully implemented Oracle’s ERP application on time. The key steps in the ERP implementation process and benefits are highlighted below:

A.     Strong impetus for change

With the serious failures and limitations of the legacy system, there was a strong impetus for replacing the legacy system with the ERP product. Even though the ERP implementation would have a high cost to the company, management was able to see value in implementing the ERP product and was not looking at cost avoidance.

When I was working at Chemistdirect.co.uk the management wanted to implement an ERP package, however the high costs of the off-the-shelf ERP packages such as SAP and Oracle proved to be a major deterrent and the company decided to develop an in-house ERP package with a team of 6 .Net developers. The scope of the project grew too large and with the budget limitations, the project had to be abandoned after 6 months. It is important for the business to see strategic value in the ERP implementation and not just view it as a good-to-have feature of IT.

B.     Strong sponsorship & business involvement

As the case suggests, the ERP project had strong sponsors in Peter Solvik, CIO and Carl Redfield, SVP of manufacturing who wanted to make the ERP implementation a priority for a company instead of a second-tier effort. The sponsor’s level of commitment and support can have the greatest impact on the delivery of an ERP system[6]. Cisco’s management team also realized that the ERP implementation could not be an IT-only initiative and would require heavy involvement from the business community, and assigned critically important people from business to the ERP implementation project. CEO Morgridge made the ERP project a priority for the business and one of the company’s top seven goals for the year.

C.      ERP vendor selection

Cisco leveraged KPMG’s experience in conducting a detailed vendor package evaluation and proof of concept, and identifying the best ERP software packages to meet Cisco’s business needs. With thorough evaluation criteria defined up front, the project team was able to objectively evaluate and score five vendors of relevant application packages[7]. The choices were narrowed down to two vendors, and Oracle was selected after a three-day software demonstration. Having Oracle as the ERP vendor was a good strategic decision by Cisco as it gave Cisco a strong partner in the ERP project, since Oracle was equally motivated to make the project a success as it would be the first major implementation for the new release of the Oracle ERP product.

D.     ERP project management

Cisco’s IT team did due diligence in proposing the cost and timeline for the ERP project and took a pragmatic approach to estimating project requirements. ERP projects can quickly scale up to become overdue and over-budget if the project scope is not correctly outlined and if the requirements are not accurately defined. The decision to completely replace the legacy system instead of a phased implementation was also a good decision as it would create less confusion for the IT team for having to support the legacy system and they could focus on the ERP implementation. The fact that the ERP project was completed on time and within budget suggests that the project team did a good job of preparing initial estimates and project management was able to avoid scope creeps and keep the project on track.

E.      Internet applications and benefits

The success of the ERP implementation provided the groundwork for the next phase of Cisco IT architecture – web-enablement and incorporating internet and intranet applications. Cisco developed several intranet and internet applications such as Employee self-service, supply chain management, customer self-service, e-commerce, communication and distance learning, EIS and DSS. Through its internal applications for employees, people deployed around the world were able to interact and address business issues and customer needs. Customers were able to place orders globally through the first-of-its-kind e-commerce application which formed 92% of Cisco’s revenue base by 2001. Cisco realized productivity gains of 60% through e-commerce. Customer’s were also able to obtain online technical support through the self-service application which improved customer satisfaction. From my experience working in the e-commerce industry, being responsive to customers greatly improves customer satisfaction. It is not so much a problem with the orders or late delivery, but a lack of response that affects a returning customer.

Cisco was also able to maintain an efficient supply chain between itself and its suppliers by creating a “single enterprise” of networked applications to integrate suppliers into its production systems. Cisco automated and standardized the product test routines and deployed these at the suppliers, allowing quality issues to be detected at source. Cisco also implemented “direct fulfillment” where suppliers were directly able to ship orders to the customers, instead of shipping it to Cisco. I think it was good move by Cisco to automate and outsource the testing, however it will need to be careful that the suppliers are not able to reverse engineer the autotest routines, otherwise Cisco can face the risk of its outsourced manufacturers becoming independent retailers and competitors for Cisco.

The web-based EIS and DSS systems provided a convenient access for sales managers and executives worldwide. While working with Philips marketing team, I was part of the IT team that created a dashboard for the Philips global marketing executives, that enabled them to view the sales for any Philips product or category in any region in the world for any time period, which would help them in creating targeted marketing campaigns. In such applications, it is important to restrict access based on authority. Cisco will also need to take measures to secure the web pages and restrict access to eligible employees.

The IP based architecture also enabled Cisco to quickly and effectively integrate the acquired company through a documented and repeatable process for integration. Cisco was able to eliminate the non-standard technology within the acquired company and fully integrate it into Cisco’s infrastructure and core applications within 60 to 100 days.

  VI.            MOT Triangle

Cisco’s business strategy (mission) is to be a global, off-price value company by building their businesses gradually and providing a secure foundation and strong infrastructure[8]. In terms of information strategy, TJX had the necessary IT systems in place to enable the business through networks that enable vendor relationship management and CRM systems that helped target profitable customers. TJX also effectively implemented barcode scanners and kiosks to speed up business operations. However, its organizational strategy is not in-line with its business strategy of providing a secure foundation. There is a clear lack of ownership and authority in terms of IT network and systems security. There are no business processes defined for monitoring and regular internal audits. There are no incentives or rewards for identifying or reporting security issues internally. The company’s culture is working towards growing their business through focus on low-cost but not necessarily a secure infrastructure. Hence, the MOT triangle depicted below is uneven.

VII.            Recommendations

To align the organizational strategy with the business strategy and information strategy, the management at TJX will need to seriously focus on establishing an IT governance, risk mitigation and management strategy. The action plan for the immediate future must be to contain the security breach and implement steps to fix the vulnerabilities. First and foremost, TJX must upgrade its network security protocol to WPA at all of its store locations. TJX must also secure its physical assets to ensure that they cannot be tampered. They must be located near security cameras or store registers to ensure constant vigilance. TJX should implement firewalls to control access of kiosks to the system. TJX should look at implementing a three-tier architecture where the database layer is completely separated from the application layer to which the kiosks have access. TJX should also use a strong encryption algorithm such as MD5 (Message Digest 5) or AES (Advanced Encryption Standard) to store and transmit any information. It should also not store any customer data that is not required or against PCI standards. TJX must ensure that process and access logs are maintained at each and every system.

At an organizational level, TJX should create formal procedures for risk management and use a RACI (Responsible, Accountable, Consulted and Informed) matrix to assign key responsibilities such as network security scans and upgrades, internal PCI audits, firewall scans and ensure that these activities are carried out as planned. TJX should also look at having independent IT security audits on a quarterly basis. An effective risk management process will provide reduced cost of operations, predictability, transparency and confidence, avoidance of security breaches, and enhanced capabilities[9]. There should be training conducted throughout the organization to increase awareness about the importance of basic IT security measures such as not sharing passwords or leaving computer systems unlocked, to prevent internal security breaches. Management should promote employee rewards for exposing IT systems or network vulnerabilities. At Accenture where I worked, each project team has a “security monitor” who is in charge of reporting non-compliance to policies such as internal password exchanges or leaving work computers or laptops unlocked. TJX management must drive the organizational strategy for a secured IT framework to meet its strategic goals.

---

[1] Nolan, R. L., Porter, K., & Akers, C. (2001, March 24). Cisco Systems Architecture: ERP and Web-enabled IT. HBS Premier Case Collection, (301099), 1. Retrieved from http://hbr.org/product/cisco-systems-architecture-erp-and-web-enabled-it/an/301099-PDF-ENG

[2] Cisco Systems Inc. (2012, July 28). Cisco Systems, Inc 2012 Annual Report. Cisco Systems, Inc Annual Reports. Retrieved March 11, 2013, from http://www.cisco.com/assets/cdc_content_elements/docs/annualreports/ar2012.pdf

[3] Cisco Systems (1995, October 26). Cisco Systems - Annual Report 1995. Retrieved from http://investor.cisco.com/secfiling.cfm?filingID=950149-95-673

[4] Browne, J. (2009, January 25). Planning the Plan: McFarlan Matrix in action. Retrieved from http://www.julianbrowne.com/article/viewer/planning-the-plan

[5] Cisco IT (n.d.). Business Applications Case Study: How Cisco IT Migrated to an ERP Technical Support Module - Cisco on Cisco - Cisco Systems. Retrieved from http://www.cisco.com/web/about/ciscoitatwork/business_of_it/ERP_technical_support_web.html

[6] Guest Contributor (2006, September 19). 10 things you should know about implementing an ERP system | TechRepublic. Retrieved from http://www.techrepublic.com/article/10-things-you-should-know-about-implementing-an-erp-system/6117288

[7] Cisco IT (n.d.). Business Applications Case Study: How Cisco IT Migrated to an ERP Technical Support Module - Cisco on Cisco - Cisco Systems. Retrieved from http://www.cisco.com/web/about/ciscoitatwork/business_of_it/ERP_technical_support_web.html

[8] Our Businesses. (n.d.). Welcome to The TJX Companies, Inc. Retrieved February 2, 2013, from http://www.tjx.com/businesses.asp

[9] Building confidence in IT Programs. (2011, September). Ernst & Young - Global. Retrieved February 4, 2013, from http://www.ey.com/Publication/vwLUAssets/Building_confidence_in_IT_programmes_through_programme_risk_management/$FILE/Insights_IT_Building_confidence_in_IT_programs.pdf