Inside the Mind of the Hot Group

A hot group…is not a name for another kind of organizational unit. A hot group is not to be confused with a team, task force, panel, board, or committee. It is a state of mind, shared by a group’s members. -- Lipman-Blumen and Leavitt, 1999

Such is one way Jean Lipman-Blumen and Harold J. Leavitt describe the phenomenon known as a hot group. Lipman-Blumen and Leavitt have written extensively on the all encompassing, productive, and unconventional execution that is the hot group in an attempt to explain the business benefits. Businesses, however, may ultimately find an explanation of hot group state of mind in the research conducted by the field of humanistic psychology.

Lipman-Blumen and Leavitt suggest the potential value hot groups bring to organizations in their 1995 Harvard Business Review article, “Hot Groups,” their 1999 CIO Magazine article, “Jammin’,” and in their 1999 book Hot Groups. Lipman-Blumen and Leavitt (1995) begin by providing a definition of hot groups, by stating,

A hot group is…a lively, high-achieving, dedicated group, usually small, whose members are turned onto an exciting task. Hot groups, while they last, completely captivate their members, occupying their hearts and minds to the exclusion of almost everything else. When the conditions are right, hot groups happen, inspired by the dedication of their members to solve an impossible problem or beat an unbeatable foe (p. 109).

Describing hot groups as such, Lipman-Blumen and Leavitt spend the majority of their writings unpacking this definition.

Based on their writings, it can be suggested that hot groups are an alternative to the traditional corporate team structure. Several characteristics of hot groups illustrate this. First, no one can form a hot group or will it into existence. Instead, hot groups form naturally and last only for relatively short periods of time (Lipman-Blumen & Leavitt, 1995). Second, Lipman-Blumen and Leavitt (1995) indicate that the bureaucracy of business distracts members in hot groups. Reports such as expense forms and status reports are deemed unnecessary (Lipman-Blumen & Leavitt, 1995). Members avoid symbols of authority amongst each other and instead focus on communicating freely and casually. They tend to set their own schedules, ignore company policy, and work secretly until it is time to unveil the results of their work (Lipman-Blumen & Leavitt, 1999). As a result many organizations view hot groups negatively, citing the group’s single-mindedness, self-centeredness, and seemingly uncooperative nature as counterproductive to business (Lipman-Blumen & Leavitt, 1995). Ultimately, however, these characteristics are outward expressions of what Lipman-Blumen and Leavitt (1995) feel is the single most defining feature of hot groups, total focus on the task at hand.

Members in a hot group all share this total focus because they feel that the group is doing a task full of meaning, one that is extremely significant to their organization (Lipman-Blumen & Leavitt, 1995). Every thought of every day during the group’s existence is ultimately focused on the task. In fact, the more challenging the task, the more dedicated and focused the members become (Lipman-Blumen & Leavitt, 1995). Lipman-Blumen and Leavitt (1995) state, “Participants in hot groups achieve this level of preoccupation because they always feel that their task is immensely significant both in terms of the challenges it represents and in terms of its intrinsic meaning” (p. 111). In fact, this intrinsic meaning causes members to volunteer for extra work, effectively creating more work for themselves (Lipman-Blumen & Leavitt, 1999).

In describing the internal dynamics of a hot group, Lipman-Blumen and Leavitt (1995) state that members of the group feel more “creative, capable, and productive” as part of the group than at any point of their lives (p. 110). Lipman-Blumen and Leavitt (1995) describe this as a “peak experience” for those members because they feel like they are stretching and surpassing their normal performance abilities (p. 110). It is here that the humanistic approach can shed additional light on the total focus exhibited in a hot group. Unfortunately, Lipman-Blumen and Leavitt provide only a brief mention of the humanistic approach’s influence on the understanding of the hot group. In fact, Lipman-Blumen and Leavitt seemingly minimize the humanistic contribution and place it solely in the context of needs-based fulfillment. While needs-based fulfillment is indeed a central tenet of the humanistic approach, it is not the whole of the humanistic contribution to the understanding of hot groups. In Hot Groups, Lipman-Blumen and Leavitt (1995) state,

Abraham Maslow offered his hierarchy of needs…More recently, Mihaly Csikszentmihalyi developed the concept of flow, the urge in individuals to move forward, to accomplish things worth accomplishing. “The best moments [in life] usually occur,” he writes, “when a person’s body or mind is stretched to its limits in a voluntary effort to accomplish something difficult and worthwhile.” Hot groups don’t help individuals satisfy all their needs, drives, and motives, but they can certainly give us chances to strive toward those “best moments” (p. 219-220).

Such is the extent of Lipman-Blumen and Leavitt’s reference to the humanistic contribution. By confining their research to needs-based fulfillment, they seemingly miss the fact that drives and motives are two integral parts of the hot group mentality. In fact, Lipman-Blumen and Leavitt (1995) define the members of a hot group as being “high-achieving and dedicated,” which are essential to succeeding and surpassing one’s normal abilities.

Surpassing one’s normal performance abilities is a phenomenon that has been studied by humanistic psychologists for several decades. During his career in the mid 1900’s, humanistic psychologist Abraham Maslow described the “peak experience” of psychologically healthy people (Burger, 2000, p. 325). In his explanation, psychologically healthy people are less restricted by the norms of culture, less inhibited, and more spontaneous than the average person (Burger, 2000). These are the people who have peak experiences, which Maslow described as “one in which time and place are transcended, in which people lose their anxieties and experience a unity of self with the universe and a momentary feeling of power and wonder” (Burger, 2000, p. 325). While Maslow’s definition of a peak experience is a bit mystical, it neatly parallels Lipman-Blumen and Leavitt’s assertion that members of hot groups surpass themselves and their abilities. In fact, Maslow’s definition of psychologically healthy people can be applied to the members who are part of a hot group, in that they are a bit unconventional in their ways.

In addition to Maslow’s work on peak experiences, the research of another humanist, Mihaly Csikszentmihalyi has produced some interesting parallels to the total focus described by Lipman-Blumen and Leavitt. In his research, Csikszentmihalyi described what he called “flow in the optimal experience” (Burger, 2000, p. 326). Csikszentmihalyi (1997) defines flow as occurring “when a person faces a clear set of goals that require appropriate responses” (para. 6). In his studies, participants were presented with challenges that demanded full concentration and afterward, they described the events of these challenges as flowing from one step to the next (Burger, 2000). When a goal was reached the participants stated that the process was more pleasurable than the mastery of the goal (Burger, 2000). In addition, participants described these events as being so involving that they became oblivious to everything else (Burger, 2000). This is essentially the same feeling experienced by the members of a hot group. The oblivious state experienced by the participants in Csikszentmihalyi’s studies parallel the total focus that the members of the hot group experience.

Csikszentmihalyi (1997) states that provided the right elements are present, almost any activity can produce flow. In fact, Csikszentmihalyi (1997) feels that these experiences are more likely to occur at work, where skills are required to attend to challenges presented. Indeed, Lipman-Blumen and Leavitt describe the hot group in the workplace environment. Much in the same way that the flow occurs when the right elements are in place, hot groups grow naturally when the corporate environment is ripe and does not inhibit them. It can be suggested that a hot group in Csikszentmihalyi’s terms is a team that experiences flow in the face of a challenge that requires total use of their skills.

It should be noted that the peak/optimal experience and flow do not necessarily correlate to the hot group experience. The total focus found in the hot group parallels the peak/optimal experience and flow, but total focus is not the sole distinguishing characteristic of the hot group. Other characteristics are present, such as the secrecy, unconventional workplace behavior and the like. Moreover, the research of Maslow and Csikszentmihalyi focused on the individual and not the group. The influence however is unmistakable. Even Lipman-Blumen and Leavitt state that the “psychology of the individual is relevant” (Lipman-Blumen & Leavitt, 1999, p. 219). After all, groups are constructed of individuals by definition.

The contributions of humanistic psychology constructs to the understanding of the hot group mentality cannot be underestimated. The parallels of peak experiences and flow to the hot group mentality abound. Just as hot groups are made up of diverse individuals, the psychology of those individuals makes up the unique and incredibly potent experience that defines that of the hot group. By looking to the understanding of individuals who have peak experiences, businesses can come to understand what makes up the hot group and why Lipman-Blumen and Leavitt believe in the value hot groups offer. Only when businesses understand the dynamics of “hot” individuals can the come to understand the dynamics of the hot groups.


References

Burger, J. (2000). Personality. Santa Clara: Wadsworth.

Csikszentmihalyi , M. (1997, July/August). Finding Flow. Psychology Today. Retrieved February 8, 2004, from http://www.psychologytoday.com/htdocs/prod/PTOArticle/PTO-19970701-000042.ASP


Lipman-Blumen, J. & Leavitt, H. J. (1999, November). Jammin’. CIO Magazine. Retrieved February 8, 2004, from http://www.cio.com/archive/110199/jammin.html


Lipman-Blumen, J. & Leavitt, H. J. (1995). Hot Groups. Harvard Business Review, 109-116.


Lipman-Blumen, J. & Leavitt, H. J. (1999). Hot Groups. New York: Oxford University
Press.

Read the complete text of this post

Bolstering Security by Combining Patch Management with Risk Management

With the recent barrage of attacks on computer software by viruses and worms, it has become increasingly evident that the software organizations employ is insecure. As organizations move almost every aspect of their business to computing environments, the need for reliable and secure software has become paramount. All too often, however, security is lackingin the software that vendors release and this lack of security is the source for most information security breaches. In light of this lack ofsecurity, this paper examines the causes of security flaws and attempts to combine two existing methodologies in order to bolster an organization's defenses against security breaches that result from these flaws.

In the past, most security breaches took place at the servers and firewalls facing the Internet (Nicastro, 2003). As a result, most security efforts focused primarily on hardware. Over time, however, the types of threats and the potential risks both increased and changed to such a degree that organizations can no longer assume that they are secure behind a firewall. Today, viruses and worms can be delivered by various means, suchas through emails and their attachments, effectively bypassing the
protection provided by firewalls (Nicastro, 2003). Additionally, these viruses and worms can search for exploitable flaws on a variety of systems and can be automatically executed (Nicastro, 2003).

To understand why software flaws have become so prolific, one only needs to look into the mindset of the developers of the flawed software. From there, one can see that the flaws are the result of business-driven pressures. Scott Berinato (2003) sheds some light on these pressures, indicating that the vendors view time-to-market as having a higher priority than security. As such, he feels that vendors will continue to ship flawed code as long as they can. Deadlines imposed by vendor schedules cause
developers to work fast while under the continual pressure to add more features (Berinato, 2003). Berinato (2003) relates an old adage among developers that states, "When it comes to software, you can pick only two of three: speed to market, number of features, or level of quality" (para. 13). As a result, the third option is rarely chosen "since, of course, software is so easily repaired later, by someone else" (Berinato, 2003, para. 13).

According to an SEI study, the vast majority of software vulnerabilities result from ten common flaws. These include parameters that were not validated, broken access control, broken session and account management, and cross-site scripting flaws. Others include command injection flaws, error-handling problems, insecure cryptography, remote administration flaws, and server misconfigurations. The most common flaw, however, is that of the buffer overflow (Berinato, 2003). In fact, a
prominent database vendor estimates that 80% of its flaws are the result of buffer overflows. If it were able to eliminate the cost of patching these flaws, the vendor estimates a savings of $12 million per month on average (Austin & Darby, 2003). Thompson and Chase (2003) agree, arguing that if the software running on systems were more secure, the need for patching could be reduced or perhaps even eliminated. Unfortunately, history indicates that as long as dealing with security in code threatens a deadline, the need for patching will remain.


Research Questions


The following questions were posed in an effort to guide the research.

What are the causes for software security deficiencies?

Are the current methods of patch management sufficient as a solution for
these software security deficiencies?

Are there strategies that organizations can adopt to mitigate the risks
associated with these software security deficiencies?


1 Hypothesis

As a result of the security flaws in software, organizations should take a proactive and calculated approach toward securing their systems, one that no longer relies solely on firewalls or the security provided by the software vendors. By adopting a combined strategy of rigorous patch management and risk management practices, organizations can minimize the risks posed by software deficiencies. One solution is not entirely effective.

2 Methodology

To gain an understanding about the mitigation of risks regarding software flaws, research was conducted and consisted of a literature search for several topics in the realm of security and patch management. The topics of software coding deficiencies, patch management, patch management deficiencies, and risk management as applied to information technology were researched.

Much of the current literature dealing with software and patching deficiencies can be found in trade publications, whereas both academic journals and trade publications have provided much of the treatment on risk management. Few publications, however, have looked solely at the role risk management plays regarding the patching of software flaws. Most literature treats risk management in a broader sense, applying it to the information technology field as a whole.

Research Results

2.1 Patch Management Deficiencies

Patching arose as a reactive measure to repair software flaws. It is the predominant way in which organizations combat the threat posed by exploitable software flaws. Historically, however, patching has not always been the panacea for these flaws. Research indicates that the patch management process is cumbersome and requires diligence on the part of those charged with the duties of patching. According to Robinson (2003),the inability to deal with the cumbersome nature of patching has resulted in the overwhelming majority of security breaches in today's computing
environment.

The problems associated with patching begin at the moment of a security vulnerability disclosure. When a vulnerability is disclosed over the Internet, a race begins between the hackers and those trying to patch their systems (Berinato, 2003). "Disclosure basically gives hackers an attack map," says Gary McGraw, CTO of Cigital (Berinato, 2003, para. 24). Nicastro (2003) concurs, stating that the publicity a flaw receives across the Internet increases the risk that hackers could attempt to use the knowledge from the disclosure to compromise vulnerable systems.

Making patches available for these vulnerable systems does not necessarily eliminate the risks of exploits. According to Robinson (2003), patches may not be identified and installed in time to prevent attacks. In addition, some systems may go unpatched during a large-scale patch deployment. Coupled with defective patches that either fail to close vulnerabilities or create new ones, organizations face serious consequences should an exploit occur. These range from cleanup costs to legal liabilities for loss or corruption of data. Organizations may also face a loss of revenue due to outages and possible a loss in consumer confidence (Robinson, 2003).

Violino and Berinato agree that the current state of patch management is untenable for those applying the patches. Violino (2003) points out that patches are generally issued "in a way that's convenient for the supplier but not necessarily for the user" (p. 80). He adds, "There isn't really an integrated, one-size-fits-all tool for patch management" (Violino, 2003, p. 81). Berinato (2003) expands on this notion by stating
that "there's nothing standard about the patch infrastructure or managing the onslaught of patches" (para. 41). He notes that patches lack a standard naming convention, a standard installation procedure, and that there is little record keeping regarding the patch process. Yet, even with all of its flaws, the only way to repair flawed software after it is released is through patches (Berinato, 2003).


3. Case Study: The Slammer Worm


According to Berinato (2003), "Slammer neatly demonstrates everything that is wrong with manufacturing software patches" (para. 23). Echoing McGraw and Nicastro on the notion of disclosure, Berinato (2003) states, "everything about the SQL Slammer was old. It was an old hack that exploited an old vulnerability on an old target, Microsoft software" (p. 60). He indicates that the patch existed six months before the exploits, but "it was so kludgy to install that the patch needed a patch" (Berinato,2003, p. 60).

The Slammer worm was small in terms of computer code size, but enormous in terms of the havoc it unleashed. The 376 bytes of code that made up Slammer fit inside a single data packet that was broadcast across the Internet in January 2003 (Berinato, 2003). It was designed to infect unpatched Microsoft SQL Servers and MSDE, a piece of client software embedded into approximately 130 third-party applications (Berinato, 2003). Once it infected a single server, it generated a random set of IP addresses
upon which it would try to infect. Once it infected another server, the process repeated itself, with each new infection generating new IP addresses to infect (Berinato, 2003). At the height of its efforts, Slammer was scanning approximately 55 million servers per second, reaching this point only three minutes after the initial infection. After ten minutes, it is estimated that Slammer had infected 90% of all possible vulnerable SQL Servers (Berinato, 2003). Some of the more high profile
results included the taking down of the Finnish telephone service and over 13,000 Bank of America ATMs (Austin & Darby, 2003). In the midst of such a large-scale failure of patch management, Berinato finds an element of good in the Slammer worm events by stating,

There won't be a formal announcement of the fact, and no one
really planned it this way, but Slammer has become something of a
turning point. The fury of its 10-minute conflagration and the
ensuing comedy of a gaggle of firefighters untangling their
hoses, rushing out to the scene and finding that the building
burnt down left enough of an impression to convince many that
patching, as currently practiced, really doesn't work (para.
46).

Indeed, Slammer appears to have become a turning point for the industry, causing industry analysts to consider the role of risk management as a potential force in the software security area.

4 Risk Management and Information Technology

To gain a perspective on why some analysts are turning to risk management, it helps to have an understanding of the fundamental concepts of risk management and how they apply to information technology. From there, one can see the how risk management concepts can guide those dealing with software flaws.

Risk is defined as the "net negative impact of the exercise of a vulnerability, considering both the probability and the impact of the occurrence" (Stoneburner et al., 2001, p. 1). Strauss and Stummer (2002) concur, declaring that the "two essential characteristics of risk are the probability of occurrence and the magnitude of the damage" (p. 252). Risk management, therefore, is the "process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level" (Stoneburner et al., 2001, p. 1).

Siegel et al. (2002) defines the risk management process as a "cycle of assessment, mitigation, insurance, detection, and remediation" (p. 34). Assessment involves the conducting of a comprehensive evaluation of security, which aids in determining the tools necessary for mitigation. Stoneburner (2001) adds that the risk assessment performed should enable an organization to determine the extent of the potential for threats and risks associated with an information technology system. The outputs of the process should enable management to identify the appropriate measures for the reduction or possible elimination of risk in the mitigation process.

One of the principle ways to measure risk during the assessment is to develop a risk scale and a risk-level matrix. Multiplying the ratings assigned for threat probability and the threat impact derives this matrix (Stoneburner, 2001).

Applying the risk scale and risk-level matrix allows an organization to easily determine which risks should be given priority and develop mitigation strategies to avoid such risks. It is the responsibility of the organization to determine the values it places in these tables regarding the threat likelihood.

During risk mitigation, Stoneburner (2001) holds that information technology managers are responsible for using the "least-cost approach" and should "implement the most appropriate controls to decrease mission risk to an acceptable level, with minimal adverse impact on the organization's resources and mission" (p. 27). Mitigation consists of the steps an organization takes to reduce risk, limit the possibility of incidents, and limit the impacts of breaches that do occur (Siegel et al., 2002). Shouldbreaches occur, insurance procured by an organization acts as a risk transfer mechanism, reducing any negative impact through finances and indemnifying if damage is detected. Such detection involves consistent and constant monitoring as a proactive means of discovering vulnerabilities and remediation is the response to any vulnerability that are discovered (Siegel et al., 2002).

According to Stoneburner (2001), the main goal of any risk management process for an organization is the protection of the organization and its ability to carry out its mission. Managers need to decide which risks are likely to materialize and which could cause the most harm, spending money where it will be most beneficial. In addition, technicians should not be making the decisions at this level. Instead, the general managers, who tend have more experience with risk management, should be the ones who "assess the business value of their information assets, determine the
likelihood they they'll be compromised, and then tailor a set of risk abatement processes to particular vulnerabilities" (Austin & Darby, 2003, p. 3).

4.2 Risk Management and Patch Management

Performing such risk analysis on software vulnerabilities is exactly what led Peter Tippett, Vice Chairman and CTO of Tru Secure, to declare, "With patching, we're picking the worst possible risk-reduction model there is" (Berinato, 2003, para. 56). Based on data he collected over twelve years, Tippett concludes that only 2% of vulnerabilities ever result in exploits. In fact, he claims, "more than half of Microsoft's 72 major vulnerabilities last year will never affect anyone ever" (Berinato, 2003, para. 56). As a result, Tippett suggests that organizations should improve their security policies, lock down unused ports on their firewalls, and pay
third party companies to "figure out which patches are necessary and which ones you can ignore" (Berinato, 2003, para. 56). In effect, he is making the case for a strong risk management process at the patching level.

Tippett is not alone in his opinion that patch management can be made more tenable through the application of risk management. In fact, Chad Robinson, in his CSO Analyst Report for the Robert Francis Group, states that information technology executives should evaluate services offered by providers that identify and deploy patches. He argues that the executives should evaluate these vendor solutions "to determine whether it would be possible to mitigate the cost associated with patching vulnerable systems without sacrificing response times to vendor alerts or thoroughness in identifying required patches" (Robinson, 2003, para. 4).

Robinson, however, does not off-load the entire risk management process to third parties. He leaves this to the information technology executives, much in the same way as Austin and Darby. These executives are charged with the responsibility to develop a matrix similar to that presented by Stoneburner. The matrix should be used to profile each software package employed by the organization and their sensitivity to vulnerabilities. The matrix should include the risk to the business should
a breach occur, the allowable periods of downtime for patching, and the risk vulnerability at each level (Robinson, 2003).

From this matrix, one can see the similarities to the matrix offered by Stoneburner. Although it is structurally different, it effectively adapts the notions of low, medium, and high and applies it to patch management accordingly. In addition, it provides timeframes during which the patching should take place.

Robinson (2003) provides an additional matrix that applies to patch management procedures. Such a matrix clearly identifies the procedures with the corresponding
owner of each. This matrix includes a notification column as well. Robinson feels that no one step should be considered complete without written notification. Such notification provides a means of identifying the events of the patching process and resolves the lack of documentation raised by Berinato.

The ultimate goal of applying risk management to the process of patch management is to define which servers are most important to the organization and to use the matrices to determine the schedule in which these servers are patched, while minimizing the cost and time to complete the process of patching (Robinson, 2003).

Discussion

With each new patch release, the notion that software is insecure becomes increasingly evident. Research indicates that poor coding practices are the main cause of software security deficiencies. To combat these deficiencies, the practice of patch management has been developed, but has seen mixed success. The research conducted on issues of patch management revealed that patch management, as currently implemented and practiced, is not sufficient as a solution for software deficiencies due to its cumbersome nature.

In an attempt to discover if standard risk management methodologies could bolster security defenses, it was hypothesized that risk management practices could allow an organization to minimize the risks posed by software security deficiencies when paired with patch management. The data gathered supports the hypothesis, in that, risk management practices can be combined with patch management policies to form a security strategy for organizations. Robinson's CSO Analyst Report effectively outlines such a strategy and, on these terms, the hypothesis can be accepted. In effect,introducing risk management to the patch management process makes good
business sense, effectively eliminating Berinato's "comedy of a gaggle of
firefighters" by providing structure. It does not protect an organization, however, as it merely serves to bring the process under control. Essentially, the introduction of a combined approach decreases or defers the patch management workload for those who must patch the systems.

Conducting further analysis, however, illustrates that the nature of software deficiencies makes any patch management process untenable on a practical level and reveals the limitations of such an approach. As an illustration of these limitations, consider the Slammer worm's affect on MSDE applications. Applying the risk management approach suggested by Robinson calls for the immediate patching of critical servers with high-risk levels, such as SQL Servers. This practice, however, would not have
prevented Slammer infections within an organization due to the vulnerabilities of the MSDE engine. As noted, this engine is embedded into desktop applications, and as such, would not have been immediately patched in accordance with Robinson's Sample Business Application Patching Matrix. As "Medium-Business Risk" systems, desktop products would have remained unpatched for several hours at best, providing a wealth of time for Slammer infections. Due to Slammer's self-replicating nature and its ability to generate network traffic, the organization would feel the effects of such
an infection almost immediately.

This presents an opportunity for further research regarding the creation of these software deficiencies. If the combination of patch management and risk management cannot resolve the issue of software deficiencies in a reactive fashion, then perhaps the responsibility to prevent such flaws should fall on the developers themselves. Research could be conducted to understand the pressures developers face and perhaps
develop ways to reduce the number of coding errors that result in software flaws.

The software that vendors ship is riddled with flaws that are the result of insecure code developed under intense pressure. In light of this, it was hypothesized that the combined approach of patch management and risk management could provide a means for an organization to protect itself. Ultimately, the hypothesis must be rejected on the basis of its inability to address the software deficiencies at a practical level. While the application of risk management to patch management does lend structure
to the process of patch management, it does not appropriate any additional security defenses by reducing risk for an organization.


References

Austin, R & Darby, C. (2003). The Myth of Secure Computing. Harvard Business Review, 1-7.

Berinato, S. (2003, May 15). The Bugs Stop Here. CIO, 60-68.

Berinato, S. (2003, August). Patch and Pray. CSO. Retrieved September 25, 2003, from
http://www.csoonline.com/opinion/links/1556.html.

Nicastro, F. (2003, November). Security Patch Management. Security Management
Practices, 5-18.

Robinson, C. (2003, October). Patch Deployment Best Practices in the Enterprise. CSO.


Retrieved October 25, 2003, from http://www.csoonline.com/analyst/report1837.html.


Siegel, C., Sagalow, T., & Serritella, P. (2002, September). Security Patch Management. Security Management Practices, 33-49.


Stoneburner, G., Goguen, A., & Feringa, A. (2001). Risk Management Guide
for Information


Technology Systems. Washington, DC. (NIST No. SP 800-30).


Strauss, C. & Stummer, C. (2002). Multiobjective Decision Support In IT-Risk Management.


International Journal of Information Technology and Decision Making. 1, 251-268.


Thompson, H., & Chase, S. (2003). Red-Team Application Security Testing. Dr. Dobb's
Journal, 28(11), 18-25.


Violino, B. (2003, August 1). Patching Things Up. CIO, 79-82.

Read the complete text of this post

Finding the Exit

The decision to discontinue a project is often difficult to make. It can be even more difficult to make when the entire project team believes in the viability of the project and its inevitable success. Management is often faced with the decision to funnel more money into an unsuccessful project or to cancel it outright. In such cases, one or more individuals are needed to conduct an objective analysis of the project to determine its viability. This role is often called the “exit champion” or “stopping-champion.” Based on a literature review, this paper examines the reasons why unsuccessful projects are pursued, highlights specific strategies for coping with these projects, and then analyzes the role of the exit champion.

Reasons for Supporting Unsuccessful Projects

Managing a project to its successful completion has proven to be a challenging prospect. Any number of problems can arise which can alter the course of the project. When such problems do arise, the project team must be able to objectively make decisions regarding the continuation of the project. More often than not, however, the project team either feels pressured into continuing a project or the team vehemently believes in the ultimate success of their project, making it difficult to consider termination. Barry M. Staw and Jerry Ross have conducted research on the forces that compel the continuation of unsuccessful projects. In addition, the work of Isabelle Royer has focused on the momentum that can build to continue an unsuccessful project, despite signs of failure. Together their research lends insight into why unsuccessful projects are supported.

Four Factors that Influence the Continuation of Unsuccessful Projects

To understand why project teams continue supporting projects that are unsuccessful, it is useful to look at the situations in which project team members find themselves. In their 1987 Harvard Business Review article, “Knowing When to Pull the Plug,” Barry M. Staw and Jerry Ross highlight four factors that drive project teams to continue pursuing an unsuccessful project.

The first factor that influences the project team is the project itself. Staw and Ross (1987) point out that minor setbacks and issues tend to encourage team members to continue pursuing the project. In fact, some team members may view these setbacks as the cost of conducting business. In addition, Staw and Ross (1987) indicate that the salvage value of a project may cause the team to continue its support. They state that if the project exit is too difficult and the expenditures are not recoverable, the team will continue its support. If the exit is easy and the team can recoup the expenditures, there will likely be less opposition to ending the project (Staw & Ross, 1987).

The second factor highlighted by Staw and Ross is the manager’s motivations. There is a tendency to celebrate the success of those who have persevered despite hardship. Knowing this, project teams may continue in the hope that the project will turn around (Staw & Ross, 1987). Managers may also be motivated to continue a project if they have a biased view of information. They may only see the positives and ignore the negatives (Staw & Ross, 1987). In addition, they may try to prove that the project will be a success by continuing the project, believing that, in time, the project will succeed. Staw and Ross (1987) call this self-justification.

Social pressure is the third factor influencing decisions to continue with unsuccessful projects. Staw and Ross (1987) state that no one wants to appear incompetent or admit mistakes to the organization. Coupled with the fact that persistence is viewed as strength and withdrawal is viewed as weakness, Staw and Ross (1987) believe that few would be motivated to withdraw.

The final factor is organizational pushes and pulls. This primarily consists of administrative inertia, which Staw and Ross (1987) define as “all the rules, procedures, and routines of an organization as well as the sheer trouble it takes for managers to give up day-to-day activities in favor of a serious operational disruption” (p. 4). Such inertia may include the wishes of governing bodies, budget committees, and political groups who are controlling the project’s backing (Staw & Ross, 1987).

The Collective Belief

In her 2003 Harvard Business Review article, “Why Bad Projects are So Hard to Kill,” Isabelle Royer presents additional reasons why project teams continue to support unsuccessful projects. Rather than focus on a myriad of individual factors that may influence decisions, she theorizes that a single “fervent and widespread belief” exists among managers (p. 6). This “collective belief,” which is a belief in the inevitable success of their project, originates within one individual, usually the project champion (Royer, 2003, p.6). As it spreads throughout the organization, it has the potential to lead rational organizations to make irrational decisions and can blind the project team from seeing negatives and setbacks (Royer, 2003).

Royer (2003) states that the collective belief often starts out as the project champion’s hunch and is not usually based in fact or evidence. The belief then permeates through the organizations based on the champion’s credibility and the belief’s alignment with people’s desires. Once the belief begins to perpetuate itself, it gains the power to silence skeptics, resulting in failure warnings being ignored (Royer, 2003). Once ignored, the skeptics usually stop asking questions and this ultimately bolsters the false sense of security cultivated by the collective belief. Royer (2003) states that the greatest danger of the collective belief is that even if problems are acknowledged, they will not be seen as signs of failure or issues that must be resolved. Instead the momentum of the belief pushes the project forward.

Royer’s analysis is largely based on the findings of her research on two French organizations, Essilor and Lafarge. In both studies, a skeptical team member raises concerns about the viability of the project. These concerns are readily discounted due to a lack of experience or credibility and the momentum of the collective belief. Years pass and millions of Francs are spent with little success. Eventually, when company turnover causes some team members to be replaced, the projects are re-examined with fresh eyes and are cancelled (Royer, 2003). These examples neatly illustrate much of Royer’s theory and Staw and Ross’ ways to avoid supporting unsuccessful projects.

Avoiding Support for Unsuccessful Projects: Recognizing Over-commitment

Staw and Ross have developed suggestions for how to avoid the tendency to support unsuccessful projects. These suggestions consist of changing the company or organization by recognizing over-commitment on a project and taking action.

One step in changing the organization is attempting to improve the information system (Staw & Ross, 1987). This consists of encouraging candid reporting of the project’s progress and by improving the honesty of reporting throughout the organization (Staw & Ross, 1987). Another step organizations can take is to turn over the project team (Staw & Ross, 1987). Although this may be costly and disruptive, it can be quite effective, as was illustrated in both of Royer’s examples.

According to Staw and Ross (1987), recognizing over-commitment is difficult. Managers must be able to define project failure and must not let such failure radically change their opinion of themselves. In addition, managers must be able to hear the concerns of others, put the organization before the project, and realize that life continues even when a project ends.

Finally, Staw and Ross state that managers should step away from their projects for a brief time and return to look at the projects from a fresh perspective. Managers should ask themselves if they would support or terminate a project if they picked it up in its current state, thereby assuming the role of an exit champion (Staw & Ross, 1987).

Avoiding Collective Belief

Echoing Staw and Ross to some degree, Royer offers three suggestions on how to avoid the collective belief and its resulting blind faith in a failing project. These suggestions consist of avoiding self-selected teams, establishing early warning systems, and recognizing the role of the exit champion.

Royer (2003) feels that project teams are often self-selected and as a result, the missteps and misunderstandings that often prove fruitful when disparate team members come together never take place. In addition, she feels that skeptics should be included as part of the project team and over time, various members of the team should be rotated out in order to provide a fresh view of the project (Royer, 2003). Such was the case in her Essilor and Lafarge examples, albeit involuntarily.

Her second suggestion states that the organization needs to ensure that the proper controls and procedures need to be put in place in order to evaluate the project at every stage. These controls and procedures must be rigorous, clearly defined, and deployed (Royer, 2003). In the cases of Essilor and Lafarge, these controls were largely ignored.

Finally, she details the role of the exit champion, which Staw and Ross touched on in their suggestions. Royer (2003) believes that the exit champion should be a countervailing force on the project team. When concerns are raised, exit champions must seek objective evidence to substantiate their concerns (Royer, 2003). This allows them to then take action to either validate the concerns as reasons for discontinuing the project or to dismiss them and continue with the project. Royer (2003) feels that exit champions must be recognized as a defined role by the organization’s senior staff. They must also have the freedom to challenge the project at any stage without fear of repercussions (Royer, 2003).

In her 2001 report, “Stopping-champions of Failing Projects,” Royer provides a detailed comparison of the project champion (champion of innovation) and the exit champion (stopping-champion). She states in her report that “at a general level, champions of innovation and stopping-champions share the same characteristics, are needed for the same reasons, and rely on the same tactics to achieve their goals” (p. 18). In addition, she highlights three differences between the two types of champions. First, the champion of innovation can be ambiguous regarding the project’s viability, especially at the outset of a project. Stopping-champions must remove ambiguity (Royer, 2001). Second, champions of innovation face the threat of being wrong in the long-term outcome of the project. Stopping-champions face an immediate threat of being wrong when they cancel a project (Royer, 2001). Finally, champions of innovation do not need to possess the level of credibility when starting a project that stopping-champions must possess when canceling a project (Royer, 2001). Aside from these differences, champions of innovation and stopping-champions are largely similar.

The research of Allan Barnes largely supports Royer’s comparisons. He defines the exit champion as someone whose role is to “gather the hard facts that remove any ambiguity about the success or otherwise of the project” (Barnes, 2004, para. 32). In addition, he notes that exit champions are not hired by management to deliberately terminate a project. To the contrary, the exit champion’s role is to provide the necessary objective assessment for management to continue its support of the project (Barnes, 2004). To Barnes, the exit champion is the complement of the project champion.

Discussion

Making the decision to cancel a project can be difficult. For a variety of reasons, managers and project teams are reluctant to cancel projects. Sometimes personal motivations play a role. Other times, the momentum of the collective belief plays a role. Often, combinations of these elements can dissuade a team from canceling the project. Regardless of the reasons, the literature detailing the support for unsuccessful projects indicates that more often than not, the projects are not cancelled.

The results of Staw and Ross’ research and the results of Royer’s research are interesting. They conducted their research separately and by different means, yet they developed similar suggestions. One could suggest that the studies performed by Royer lend a degree of credibility to the suggestions of Staw and Ross regarding recognizing over-commitment. Indeed, Staw and Ross’ suggestions match the actual events that took place in the case studies of Essilor and Lafarge. In addition, it can be suggested from the similarities found in both bodies of research, that the need for exit champions is indeed valid. The results of the research of both Staw and Ross and that of Royer underscore the validity of this need.

The application of the exit champion, however, poses some problems. It is seemingly counter-productive to formally define this role in a project team, but that is what Royer seems to suggest. Further complicating the issue is Royer’s indication that the exit champion can “emerge” from the project team. This seemingly contradicts her statement that “senior executives need to recognize the exit champion as a defined role” (Royer, 2003, p. 12). Additional clarification is needed in this area. One could suggest that the ideal situation is, in fact, a combination of these two statements. The exit champion should emerge from within the project team at signs of trouble, and once this occurs, should be recognized as a specific role by senior management.

When signs of trouble appear, the decision to cancel a project can be difficult to make. A failing project can compel team members to continue supporting the project hoping to make it successful. A multitude of reasons exist that would compel a team to do so, but at some point, a decision must be made to continue or discontinue the project. The research of Staw and Ross and the research of Royer indicate that this decision should be objective and well researched. The magnitude of such a decision has prompted the researchers to define a new role for this decision making process. Despite the confusion in Royer’s definition regarding the time when an exit champion should materialize, the goal of the exit champion is clear. An objective analysis must be conducted to ensure the viability of the project. Although this role of “exit champion” may not be as prestigious or dynamic as that of the project champion, it is as every bit as crucial.


References

Barnes, A. (2004). True Believers and Their Sceptical Foes. Position Magazine. Retrieved May 1, 2004 from
http://www.positionmag.com.au/POS/content/2004/POS10/pos10_feature/pos10_feature_2.html.


Royer, I. (2001). Stopping-champions of Failing Projects. Academy of Management
Confernece. Washington, D.C.


Royer, I. (2003). Why Bad Projects Are So Hard to Kill. Harvard Business Review, 5-12.


Staw, B. M. & Ross, J. (1987). Knowing When to Pull the Plug. Harvard Business Review, 1-7.

Read the complete text of this post

Privacy Policies and eGovernment

Maintaining the trust of its customers is a major concern for any ecommerce site. Customers willing to conduct business and transfer sensitive data electronically have a reasonable expectancy that the site has taken the proper precautions to assure the safety of the data. Securing the data, however, is only half of the responsibility of the site. The other half, ensuring the customer’s privacy, is perhaps even more important. Customers expect that their shopping patterns, interests, and other profile-specific data be treated with the utmost respect and that this data remains private. In response to this expectancy, many sites have successfully implemented privacy policies. These policies have become a common practice and have been integral parts of ecommerce activities for some time.

As time has passed, governments have realized the promise of taking government services online. While relatively young compared to ecommerce, egovernment has the potential to transform government services much like the way ecommerce has transformed commerce. In fact, egovernment shares many similarities with ecommerce, including speed, convenience, and cost savings. Egovernment also shares the same security and privacy issues and the protection of this privacy seemingly takes on an even greater importance for egovernment due to the sensitive nature of the data. Unfortunately, egovernment has not always followed the example provided by ecommerce when it comes to privacy policies.

It is the issue of privacy that Ellen Perlman (2003) suggests can either make or break an egovernment initiative. In her article, “Trust Busters,” she raises the notion that state and local governments must make it a priority to protect and ensure citizens’ privacy while still allowing for the convenience and efficiency enabled by placing information online. While she stops short of offering her own specific suggestions, she does cite several approaches chosen by various states and their varying results.

Perlman begins by contrasting the past with the present. In the past, governments stored sensitive data in file cabinets, placed in locked rooms behind security guards equipped with logbooks. Today, governments are increasingly moving toward electronic storage (Perlman, 2003). She notes that few people were concerned about their privacy when the physical security and “rigidity of file cabinets, locked doors, and 9-to-5 office hours” (Perlman, 2003, p. 32) were in place. Even if the data was considered to be publicly accessible, it was often tedious and time-consuming to obtain such information. With online storage, this is no longer the case and she feels that the inherent security risks could “stymie egovernment and the efficiencies it offers” (Perlman, 2003, p. 32).

To better understand the value of egovernment efficiencies, it is helpful to understand the goals of egovernment. The Federal government provides some insight into the purpose of egovernment. Its purpose is to encourage “interagency IT initiatives that, while improving customer service, also consolidate redundant systems, decrease paperwork, increase productivity, and save money” (Datz, 2003, p. ). To achieve this goal, “more data is collected and shared among agencies” (Datz, 2003, p. ). Sharon Dawes (2003), the Director of the Center for Technology in Government at the State University of New York in Albany, feels that such sharing and transfer of data is what raises the concerns about privacy. Referring to the data, she states that citizens expect that the “government won’t share it, won’t put it on public websites, will keep it in secure systems and that people will be trained in how to handle information of a confidential nature responsibly” (Perlman, 2003, p. 32).

If the government fails to uphold these expectancies, serious privacy issues can result. Perlman (2003) raises the concern of the public’s use of the data once it is available, stating, “It is no longer much of an effort for, say, nosy neighbors – or people with malice in their motive – to use browsers to try to check out personal details” (p. 32). Such fears were aroused in Nassau County, New York, when state officials posted names, addresses and assessments online for property comparison purposes (Perlman, 2003). Eventually the names were removed when concerns mounted, but other states, such as Maryland, maintain citizens’ names and addresses online with its “Real Property Data Search.” This search allows anyone with an Internet connection and a street name to locate homeowners, property value, and deed reference numbers for that particular street. This data can be viewed as a service to the public, but in the hands of malevolent individuals, this data could be the basis for a number of attacks.

Bob Freeman (2003), the Executive Director of the Committee on Open Government in New York, provides some insight into these attacks. He states that “the real issue of privacy is not the names and addresses. The reality is that with a good search engine, you can take my name and address and combine it with other information about me and come up with a profile” (Perlman, 2003, p. 39).

Perlman (2003) cites several other cases in her article regarding what some states have done in their attempts to handle these privacy issues. These include Washington State’s Gary Locke, who issued an executive order prohibiting the use of personal information on state Web sites, and New York and Alabama’s placing of court documents online. In each of the cases, there is a recurring theme about how much data should be placed online and whether data should be posted just because governments are capable of doing so. It is here that perhaps governments could borrow from their ecommerce lineage. Ecommerce sites have had to deal with customer privacy for years and have developed privacy policies that, in most cases, clearly state how information will be collected, used, and transferred among other sites.

Perhaps one of the most detailed strategies comes out of Microsoft. In an interview with the Harvard Business Review, Microsoft’s Director of Corporate Privacy, Richard Purcell, provides a five-point plan that attempts to provide a solution. He feels that it is “critical to have a single place where knowledge resides about the way customers’ information is handled and where policies are set for collecting and using on-line and off-line data” (Fusaro, 2000, p. 1). In an effort to do so, Microsoft designed an “ethical framework” for customer data. This framework consists of the five elements of notice, choice, access, security, and enforcement. Essentially, this means that ample notice should be provided that data is being collected and that customers should have the choice to determine how data is used, the length of time it is kept, and the circumstances under which it may be transferred to other companies. Data should also be protected, but remain available to the customer to make changes as necessary. In addition, Microsoft feels that some form of enforcement should be in place to hold itself accountable to ensure that it is adhering to its policies (Fusaro, 2000).

Borrowing and adopting privacy policies from the world of ecommerce might provide some direction for egovernment and perhaps alleviate some of the inconsistencies that currently exist. Charles Bacaraisse (2003) notes that state and local governments are clearly looking for direction. He states that the problem egovernment faces is that “there is no state statute, no Supreme Court guidance” (Perlman, 2003, p. 36) regarding public access to data and the protection of privacy online. Compounding the issue is the fact that all citizens are currently subject to egovernment’s placing of their information online, whereas consumers voluntarily submit their information to ecommerce sites. In states such as New York and Maryland, citizens are not given the option to opt-out of having their tax assessment data placed online with their names and addresses.

Ecommerce sites and egovernment initiatives share many similarities. From convenience to cost savings, the technology behind both ecommerce and egovernment provides many features of which the public can take advantage. Unfortunately, some take advantage of egovernment information in ways that were not meant to be taken. Some of this behavior could be prevented if privacy policies are developed for the posting of citizens’ data online. Privacy policies are somewhat lacking, if not non-existent in egovernment. It is this difference that separates ecommerce for egovernment as it stands today. If egovernment is to see the acceptance that its older sibling ecommerce has seen, privacy must be given the proper attention it deserves.


References

Datz, Todd. (2003, May 1). A More Perfect Union. CIO Magazine. Retrieved September 30, 2003, from http://www.cio.com/archive/030103/union.html.

Fusaro, Roberta. (2000). Chief Privacy Officer. Harvard Business Review, 1-3.

Perlman, Ellen. (2003, September). Trust Busters. Governing, 16, 32-39.

Read the complete text of this post

An Alternative to Counting Lines of Code

Software has become integral to almost every facet of life. From computers to automobiles, software plays an important role. When such importance is placed on something such as a product, it is important to make the correct judgments when cost, schedule, and the deployment of resources are concerned. Such is the case with software development. In response to the constraints placed on software development by cost, schedule, and resources, system software metrics have been developed. Such techniques can be useful in the selection and rejection of projects by a business. Many techniques exist, two of which are counting lines of code and Function Point Analysis. Based on a literature review of the theory behind these two techniques, this paper presents an analysis of counting lines of code, its flaws, and why Function Point Analysis offers an alternative.

The Need For Accurate Estimates

To understand the need for accurate estimations, one can look to statistical data gathered on the success and failure rates of software development projects. In their 1999 PM article, “Curing the Software Requirements and cost Estimating Blues,” Major Mike Nelson, James Clark, and Martha Ann Spurlock indicate that a large number of software development projects were not accurately estimated. The results of the 1995 Standish Group survey of 8380 software applications indicate that only 16% of projects stayed on schedule without exceeding their budgets, while 31% were cancelled, and 52.7% were completed with schedule and budget overruns (Nelson et al., 1999). In addition, the average budget overrun was 189% and the average schedule overrun was 222% (Nelson et al., 1999). A survey of the completed projects showed that the developers had to reduce features and functionality to 61% of the original requirements just to meet their schedule (Nelson et al., 1999). From these statistics, it is clear that accurate cost and schedule estimates are needed to avoid these failures. While Nelson et al. does not indicate if the Standish Group recorded the estimation techniques used by those surveyed, or even if those in the survey practiced an estimation technique, the predominant technique employed at the time of the survey was counting lines of code (Ferens, 1998).

Counting Lines of Code

The technique of counting lines of code involves counting the number of compiled source code lines in a program to estimate the size, cost, and effort required (Nelson et al., 1999). According to Nelson et al. (1999), the flaws associated with this technique result in a dramatically high error rate, sometimes reaching 400% of the original estimates. Nelson et al. (1999) notes that the software development industry lacks a standard definition for the measurement of source lines of code. Ferens (1988) concurs and adds that there is a large discrepancy between organizations as to what types of code statements constitute source code. He notes that most estimations include executable lines of code, but some do not include statements such as comments, test data statements, and declarative statements (Ferens, 1988). Compounding this issue is the proliferation of programming languages, which can achieve the same execution with differing numbers of executable statements. Moreover, Sean Furey, in his 1997 IEEE Software article, “Why We Should Use Function Points,” states that object-oriented programming languages make estimation difficult because “applications or major pieces of applications can be created with virtually no countable lines of code” (p. 28). Finally, Nelson et al. (1999) notes that estimates are often produced prior to the determination of the programming language used on a project.

Function Point Analysis

The need to produce estimates prior to programming language selection is perhaps one of the reasons A.J. Albrecht developed the Function Point Analysis technique, which was released to the public in 1979 (Jones, 1999). Since then, several variations of Function Point Analysis have been developed. These include the Symons Mark II version and several revisions developed by the International Function Point Users Group (Furey, 1997).

Function Point Analysis “is a measure of software complexity derived from five attributes of a program” (Jones, 1999, p. 165). Function points are computed by calculating the number of inputs, outputs, inquiries, master files, and interfaces in a program. Under the Version 4.0 rules set by the International Function Point Users Group, the five attributes are assigned a numeric value, weighted according to their complexity, and then are summed. With the sum calculated, adjustments are then made to this value by comparing it to a set of pre-defined criteria. The end result enables managers, developers and even users to estimate the relative size of a program in terms of cost and effort, terms the business, not just developers, can understand (Jones, 1999).

Advantages of Function Point Analysis

Function Point Analysis allows program managers to accurately estimate software size in terms that the business can understand because function points are based on a logical understanding of the software rather than a physical, or line count, view. This enables managers to make informed choices about their software development more objectively (Furey, 1997).

Furey (1997) states that “Function points are technologically independent, consistent, repeatable, and help normalize data, enable comparisons, and set scope and client expectations” (p. 28). In fact, function points allow the focus to be placed on the required functionality of the users, and therefore, also measure the software requirements. As a result of having a basis grounded in functional requirements, function points have an advantage over counting lines of code, in that, function points can be counted earlier in the development process (Furey, 1997).

Perhaps the greatest advantage of Function Point Analysis is that this technique has been ratified as an international standard, embodied in the International Function Point Users Group (Furey, 1997). As such, Function Point Analysis has an established set of rules and is independent of any programming language or changes in languages (Nelson et al., 1999).

An Example of the Benefits of Function Point Analysis

Furey (1997) provides an example of how Function Point analysis can allow managers to make more accurate judgments. In his example, two teams each develop an application that contains the same level of functionality and features, with two different languages. The first team develops the application with COBOL, writes 4000 lines of code, and finishes after ten months of work. The second team develops their application in Smalltalk, writes 900 lines of code, and finishes in five months. Under the lines of code counting technique, the first team is considered to be more productive because they produced more lines of code. However, when Function Point Analysis is applied, the second team was more productive because they developed an application with equal functionality in only half the time (Furey, 1997).

Disadvantages of Function Point Analysis

Ironically, the greatest advantage of Function Point Analysis, can be, at times, its greatest disadvantage. Having an established set of rules is advantageous only when those rules are followed. Barbara Kitchenham (1997) elaborates on this in her 1997 IEEE Software article, “The Problem with Function Points.” She argues that there is a need to understand the limitations of Function Point Analysis. In her analysis, she limits her discussion to Albrecht’s rules and Symons Mark II, citing their respective popularity in the United States and the United Kingdom (Kitchenham, 1997).

Keeping in mind that she is only analyzing Albrecht’s and the Symons techniques, she states that problems can be encountered when using function point measurements as the basis for negotiations and contracts between organizations (Kitchenham, 1997). She cites Albrecht’s use of an ordinal scale of “simple, average, and complex,” rather than a numeric scale, noting that the ordinal scale is vague in its descriptions of systems (Kitchenham, 1997).

Regarding the Symons Mark II technique, she notes that individual function point counts are transformed into weighted counts. She feels that this introduces issues because it assumes that all counts are equivalent measures, when standard conversion factors for these counts do not exist. In addition, she feels that function point counting involves the judgment of the person performing the count, and subsequently introduces variances and discrepancies in counts conducted by different people (Kitchenham, 1997).
Discussion

Accurate software metrics are crucial to the goals of staying on budget and on schedule. Without accurate measurements, serious budget expenses can be incurred and product releases can be delayed. Such failures to deliver could have serious repercussions for those developing the software and those managing the projects.

The literature regarding software estimation reveals two prevalent issues. First, the software metric used by organizations must produce accurate measurements of size, cost, and schedule. The second issue involves industry-wide acceptance of a standard so that organizations can properly make comparisons using their estimations.

Measuring software by counting lines of code has been, and is some analysts’ estimation, will continue to be, the standard software metric. Unfortunately, there is little that can be considered standard about counting lines of code. In fact, the discrepancies are so great that there is little consensus on whether a comment is a line of code. Within an organization, these discrepancies may have little impact. Across the industry, however, the differences in estimation could have serious impacts on the development contracts between organizations.

In terms of estimation accuracy when compared to counting lines of code, it can be suggested from the literature that any Function Point Analysis technique has definite advantages, all of which provide the potential for more accurate estimations. Some empirical studies, such as those conducted by Kermerer, corroborate this suggestion (Kermerer, 1987). The advantages include technological and programming language independence, earlier estimation in the life cycle, and data normalization. In addition to these advantages, Function Point Analysis has the benefit of international standardization. This, however, only applies to the technique developed by the International Function Point Users Group. Albrecht’s original technique and the Symons Mark II technique are not internationally standardized and as such, places Function Point Analysis in a similar situation as the lines of code counting technique in terms of universal acceptance. The fact that Kitchenham neglects the International Function Point Users Group version of Function Point Analysis seemingly underscores this situation and points to the larger issue of a need for function point standardization.

Estimating software to determine cost, schedules, and effort is clearly an important activity for software developers and managers. Making the correct estimations can have serious impacts on a projects success or failure. The technique of counting lines of code does not appear to be providing organizations with the accurate estimates that they require, but by the same token, it would be unfair to characterize Function Point Analysis as the absolute solution to all problems. Even with its flaws, Function Point Analysis can, however, be a valuable alternative to the technique of counting lines of code.


References

Ferens, D. V. (1988). Software Size Estimation Techniques. Proceedings of the IEEE, 701-705.

Furey, S. (1997). Why We Should Use Function Points. IEEE Software, 28-30.

Jones, C. (1999). Software Sizing. IEE Review, 165-167.

Kermerer, C. (1987). An Empirical Validation of software Cost Estimation Models. Communications of the ACM, 416-429.

Kitchenham, B. (1997). The Problem With Function Points. IEEE Software, 29-31.

Nelson, M., Clark, J., & Spurlock, M. (1999). Curing the Software Requirements and Cost Estimation Blues. PM, 54-60.

Read the complete text of this post

The Demise of the Desktop?

Update: Since I originally wrote this paper in November 2006, Microsoft announced its "Surface," and Apple released the iPhone and announced "stacks" in the soon to be released Mac OS X Version 10.5 Leopard.

Metaphors in Computing

Recognizing, understanding, and remembering are essential parts of intelligence and metaphors may play a significant role is such tasks. In fact, Marx (1994) holds that metaphors have substantial explanatory power when it comes to learning and that “anything new must be learned by metaphorically extending existing knowledge” (p. 379). Leveraging the power of metaphors enables designers of interfaces to provide users with a “head start” as it pertains to learning a new interface (Marx, 1994, p. 379).

In general, two kinds of metaphors exist in user interfaces. These are individual metaphors and systemic/over-arching metaphors. Individual metaphors pertain to specific user interface controls, such as radio buttons. Systemic or over-arching metaphors allow for a thorough understanding of a system, such as that which is understood via the “desktop metaphor” for operating systems such as Windows and the Mac OS. (Marcus, 1998, p. 46).

The Desktop Metaphor

The desktop metaphor is the dominant metaphor used in today’s commercial operating systems. Popularized by Apple and then by Microsoft, it contains references to items in the modern office and building structures. These items and structures include the desktop, files, documents, folders, trash cans, and windows (Marcus, 1994, p. 13). According to Gozzi (2002), the desktop metaphor “asserts that the computer screen is like a real desktop” (p. 425).

It has been argued that the desktop metaphor has successfully allowed novice users to acquaint themselves with the computing environment. Its success can be attributed to the highly familiar concepts of the office and the similarity between the metaphor and the real world. In general, documents look and act like real documents (Madsen, 2000). Johnson et al. (1985) states that the desktop metaphor approach is “intended to facilitate one’s use of the system by making the manipulation of information in the system analogous to the manipulation of physical objects on a desktop” (p. 548). Ravasio et al. would concur. In fact, Ravasio et al. (2004) suggests that with the release of the Xerox Star in 1981, computers were finally understandable to non-expert users.

With its twenty-plus years of existence and its current status, once might argue that the desktop metaphor is the standard for a reason. In general, the desktop metaphor holds up well against Marcus’ criteria for successful metaphors in user interfaces. Marcus (1998) states that a metaphor should use concepts familiar to the user, prepare the user to transfer the content domain model into the user’s mental model, and increase the ease of learning, memorization, and use. Proponents of the desktop metaphor would argue that it does these reasonable well. Even critics of the desktop metaphor, such as Gentner and Nielson, seem to agree.

Shortcomings of the Desktop Metaphor

In The Anti-Mac Interface, Gentner and Nielson (1996) concede that they do not think the Macintosh interface, and to a greater extent, the desktop metaphor, are bad by any means. They do, however, offer many criticisms about the desktop metaphor. As will be seen, they are not alone in their assertions.

Hudson (2000) notes that the desktop metaphor is most often cited as the primary failure of metaphorical design. In Hudson’s opinion, one of its greatest features is also one of its most negative aspects. It is often found to be too restrictive and helpful only to new users (Hudson, 2000). Additionally, he describes some of the more confounding features by stating,
"I think the desktop metaphor on our computer screens has drifted too far from the original office domain. Microsoft Windows, for example, hides the in-tray and out-tray in an e-mail application, variously called Mail, Inbox, Outlook, or Outlook Express depending on the age and configuration of the system. The desktop is confusingly covered by wallpaper, and printing documents by dragging them to a printer does not work reliably. The Macintosh does not fare much better: it has the odd feature of allowing users to drag the floppy disk to the wastebasket (“Trash”) to eject the floppy. From the office domain it’s obvious that the effect of that action (if any) should be the same as discarding a document or folder" (p. 13).

Indeed, he raises some interesting points. Such examples, while seemingly trivial, might confuse the very users for which the system is intended to serve.

Gentner and Nielson (1996) take a much broader stance, claiming that the interface is stuck in a “WIMP (windows, icons, menus, pointer)” model (p. 70), offering little innovation. Madsen (2000) refers to the desktop metaphor as a “straitjacket” (p. 167), echoing Gentner and Nielson’s (1996) statement that the desktop metaphor only serves to cripple the interface “with irrelevant functions” (p. 72). Furthermore, Gentner and Nielson (1996) state that the desktop metaphor limits the designer’s ability to develop more powerful interfaces.

Gentner and Nielson (1996) acknowledge that the desktop metaphor’s intention is to save time by leveraging a user’s knowledge of the traditional office, much like the assertions of Hudson. They, however, feel that the desktop metaphor may hinder the productivity of the next generation of users who will grow up using computers and may have little knowledge of the office domain (1996). Gentner and Nielson (1996) recommend that new paradigms be developed “based on the structure of computer systems and the tasks users really have to perform” (p. 74).

Johnson et al. (1985) feels that the desktop metaphor “fails to recognize that user dexterity in manipulating simulated objects on a computer screen is not as high as it is in the physical world” (p. 548). In addition, he feels that users are handcuffed by trying to accomplish digital goals using the metaphor of the physical world (Johnson et al., 1985, p. 548). In other words, he feels that the computer’s functionality may be limited by attempting to perform the actions of the physical world due to the imposition of the desktop metaphor (Johnson et al., 1985).

Attempts at Enhancing the Desktop Metaphor

In “Not a Desktop, Not a Metaphor,” Gozzi (2002) suggests that the desktop metaphor is not a metaphor for our desks at all. In addition to pointing out that real desks “lack window close boxes,” he says that his “real desk is much messier” than what can be found on his computer desktop and that “the computer screen has nothing like ‘an intuitive pile of stuff’ on it” (Gozzi, 2002, p. 426). While such a literal comparison may be true today, attempts are being made to enhance the typical desktop metaphor with features such as “piles” and task-based functionality.

Ravasio et al. (2004) points out that researchers such as Malone have been studying the electronic office for many years. Research from the early 1980s suggests that there are two fundamentally different styles of filing. The two styles are that of neatly organized file folders and piles (Ravasio et al., 2004). Mander and Rose included piles in their systems designs in 1993, focusing on the idea of casual desktop organization (Ravasio et al. 2004). Mander et al. discovered that people preferred piles because piles did not require “detailed categorization” and information “could be more easily reordered” than it could be with a “folder and file system” (Mander, 1992, p. 628). In addition, “seemingly disordered piles were often sensible to the person who created them” (Mander, 1992, p. 628).

Agarawala and Balakrishnan (2006) are exploring adding physics simulation to virtual desktops in combination with “piling instead of filing as the fundamental organizational structure” (p. 1283). The goal is to mimic the information, feel, and visual clues provided by the spatial information on a real desktop (i.e. proximity indicates urgency). Their BumpTop prototype “presents users with a 2 _D view onto a planar desktop surface tilted 25 degrees” (Agarawala & Balakrishnan, 2006, p. 1285). Users can pile documents and other items on this surface. While their research is ongoing, it has been discovered that piles do not scale well once they become large (Agarawala & Balakrishnan, 2006).

Other research efforts have focused on task-based enhancements to the desktop metaphor. The “activity theory” has “resulted in task-centered approaches” (Ravasio, 2004. p. 161). The impetus for this approach stems from the assertion that “the desktop metaphor has inadequate support for task switching” (Robertson et al., 2000, p. 495). According to Bomsdorf and Szwillus (1998), “knowing the user’s tasks enables the designer to construct user interfaces reflecting the tasks’ properties” (p. 201). In their “Task Gallery,” Robertson et al. have designed a “window manager that uses interactive 3D graphics to provide direct support for task management and document comparison” (p. 494). In this enhancement to the desktop metaphor, users’ tasks are hung on walls much like an art gallery. Tasks are defined as a “collection of documents and applications organized around a particular user activity” and task management takes into account “creating, locating, and bringing tasks into focus” (p. 494). Their design attempts to use human spatial memory capabilities by relying on the location of tasks on the gallery walls (Robertson et al., 2000).

Gentner and Nielson (1996), however, have a distinctly pointed view about these new attempts at revitalizing the desktop metaphor. They feel that interfaces that try to emulate virtual reality in a 2D space introduce “clunky interactions” (p. 72). In addition, they find these interfaces to be “navigationally cumbersome” and “interactionally cumbersome” (p. 72). They suggest developing “new interface paradigms based on the structure of computer systems and the tasks users really have to perform” (p. 74). According to Marcus (2002), analysts such as David Gelerntner, Don Norman, and George Robertson “are calling for the end of the desktop metaphor” (p. 8). In Gozzi’s (2002) words, “the desktop metaphor is apparently on its way out” (p. 427).

Tangible Interfaces

If the desktop metaphor is on its way out, it must be replaced by something else. Marcus (1994) states that future interface designs need to strike a balance between mental models, presentation, interactions, metaphors, and navigation. With Gentner and Nielson recommending new paradigms and computer systems based on tasks and with the observations about spatiality and piles, it seems that tangible user interfaces may be the solution.

Fitzmaurice et al. are credited with distinguishing tangible user interfaces from all others when they coined the term “graspable user interfaces” (Sharlin et al., 2004, p. 338). Ishii and Ullmer are credited with coining the term “tangible user interfaces” and define them as “devices that give physical form to digital information, employing physical artifacts as representations and controls of the computational data” (Sharlin et al., 2004, p. 338). Although in their infancy, these interfaces may be the answer to providing highly functional, intuitive computing environments (Svanaes and Verplank, 2000).

Svanaes and Verplank (2000) feel that it is now time to “go beyond the GUI interface” (p. 121). They define tangible user interfaces as “systems that allow for the user to interact with the computer through physical objects (other than mouse and keyboard)” (p. 121). They provide Durrell Bishop’s Marble Answering Machine as an example, where the manipulation of marbles manipulates phone messages (p. 122).

Ishii and Ullmer’s (1997) research is attempting to make digital information tangible as well. Their designs include interactive surfaces (walls, desktops, ceilings, windows, and doors), coupled bits and atoms, and ambient media. Their goal is to turn “everyday architectural spaces into ‘interfaces’ between people and information” (p. 235). The design calls for “allowing users to ‘grasp and manipulate’ foreground bits by coupling bits with physical objects, and enabling users to be aware of background bits at the periphery using ambient media in an augmented space” (p. 235). As an example, they provide the “Clearboard,” which integrates the ability to draw on a wall with distributed computing. This “active surface” allows a person across distances to interact with another person. Other examples that use this technology include the metaDESK, transBOARD, and ambientROOM, all which seem to have enormous potential.

In “A Taxonomy for and Analysis of Tangible Interfaces,” Fishkin (2004) discusses the role metaphor can play in tangible user interfaces. He states, "We believe that metaphor is particularly appropriate for TUIs, as opposed to other interfaces, due precisely to their physical tangibility. Once parts of an interface are made physically tangible, a whole realm of physically afforded metaphors becomes available. A designer can use the shape, the size, the color, the weight, the smell, and the texture of the object to invoke any number of metaphorical links. Mithen [40] argues that ‘‘the most powerful [metaphors] are those which cross domain boundaries, such as by associating a living entity with something that is inert or an idea with something that is tangible.’’ Tangible interfaces, which can have exactly these properties, therefore, have this potential" (p. 349).

Indeed, it is conceivable that the power of metaphor can extend beyond the desktop interface into the realm of tangible interfaces and affect them in much the same way.

Discussion

One concept seems to permeate the whole of the research is the physical desktop’s influence on our designs. At first, this notion may seem to be a given; an obvious statement. The fact is, however, that our computing designs have largely been influenced by the way we worked prior to the advent of computers. It seems natural to transfer the sum of our experiences in the analog environment to the digital environment via the desktop metaphor. Granted, the desktop metaphor as implemented today may be flawed. Perhaps a little fine-tuning or enhancement is in order. While the actual implementation may change, the idea of the desktop seems to remain an integral part of way we use computers. The research has shown that humans naturally think metaphorically, and we have defined our work structure in such a way.

Perhaps those conducting the research are correct. Perhaps it is time to eschew the desktop metaphor. Perhaps it is time for the augmented desktop. At first glance, it seems that a desktop augmented with digital capabilities and computational power would be of great benefit to humanity. Indeed, it has much potential. Research into the desktop metaphor seems to be converging in this direction. Alignment of human skills and computing power appears to be the goal. Tangible interfaces seem to hold the key.

In a tangible computing world, Johnson would have users manipulating data with great dexterity, Gozzi’s physical desktop would actually be a messy computer screen, and piles of digital documents would serve as the normal filing strategy. Perhaps in the future, we’ll look back at the history of the desktop metaphor and reminisce about the progression from physical desks, to computer desktop interfaces, to digital desks. Does the physical desktop hold this much influence over our designs? Perhaps it does.

It seems that after twenty years, the desktop metaphor has aged well. While it may not be perfect for everyone, it has certainly been a functional tool that has served the majority of personal computer users well. Whatever its fate, the desktop metaphor has played an integral role in the advancement, development, and shaping of personal computers and computer users alike. Its influence will continue to pervade our understanding of computers for years to come.

References

Agarawala, Anand & Balakrishnan, Ravin. (2006). Keepin’ It Real: Pushing the Desktop
Metaphor with Physics, Piles and the Pen. Proceedings of the SIGCHI conference on
Human Factors in computing systems CHI '06, 1283-1292.

Bomsdorf, Birgit & Szwillus, Gerd. (1998). From Task to Dialogue: Task-Based User Interface
Design. Conference on Human Factors in Computing Systems, 201.

Fishkin, Kenneth P. (2004). A Taxonomy for and Analysis of Tangible Interfaces. Personal
and Ubiquitous Computing, 8, 5, 347-358.

Gentner, Don & Nielson, Jakob. (1996). The Anti-Mac Interface. Communications of the ACM,
39, 8, 70-82.

Gozzi, Raymond, Jr. (2002). Not a Desktop, Not a Metaphor. ETC: A Review of General
Semantics, 59,4, 425-428.

Hudson, William. (2000). Metaphor: A Double-Edged Sword. Interactions, 7, 3, 11-15.

Ishii, Hiroshi & Ullmer Brygg. (1997). Tangible Bits: Towards Seamless Interfaces Between
People, Bits, and Atoms. Conference on Human Factors in Computing Systems, 234-241.
Johnson, Jeff A., Smith, David C., Ludolph, Frank E., Irby, Charles H. (1985). The Desktop
Metaphor as an Approach to User Interface Design. Proceedings of the 1985 ACM
Annual Conference on The Range of Computing, 548-549.

Madsen, Kim H. (2000). Magic By Metaphors. Designing Augmented Reality Environments,
167-169.

Mander, Richard, Salomon, Gitta, Wong, Yin Yin. (1992). A ‘Pile’ Metaphor for Supporting
Casual Organization of Information. Conference on Human Factors in Computing Systems, 627-634.

Marcus, Aaron. (1994). Managing Metaphors for Advanced User Interfaces. Proceedings of the
Workshop on Advanced Visual Interfaces, 12-18.

Marcus, Aaron. (2002). Metaphors and User Interfaces in the 21st Century. Interactions, 9, 2, 7-
10.

Marcus, Aaron. (1998). Metaphor Design in User Interfaces. Journal of Computer
Documentation, 22, 2, 43-57.

Marx, Adam N. (1994). Using Metaphor Effectively in User Design. Conference on Human
Factors in Computing Systems, 379-380.

Ravasio, Pamela, Schar, Sissel Guttormsen, Krueger, Helmut. (2004). In Pursuit of Desktop
Evolution: User Problems and Practices with Modern Desktop Systems. ACM Transactions on Computer-Human Interaction, 11, 2, 156-180.

Robertson, George, van Dantzich, Maarten, Robbins, Daniel, Czerwinski, Mary, Hinckley, Ken,
Risden, Kirsten, et al. (2000). The Task Gallery: A 3D Window Manager. Conference on Human Factors in Computing Systems, 494- 501.

Sharlin, Ehud, Watson, Benjamin, Kitamura, Yoshifumi, Kishino, Fumio, Itoh, Yuichi. (2004).
On Tangible User Interfaces, Humans, and Spatiality. Personal and Ubiquitous Computing, 8, 5, 338 – 346.

Svanaes, Dag & Verplank, William. (2000). In Search of Metaphors for Tangible User
Interfaces. Designing Augmented Reality Environments, 121-129.

Read the complete text of this post

Precluding the Centralization Versus Decentralization Argument

In an industry where productivity is often measured by cpu cycles, a different sort of cycle has emerged, one which is defined by the vacillation between centralization and decentralization. This vacillation, or cycling, back and forth has caused some industry analysts to propose a middle ground, one that seeks to provide a balance of the best of both centralization and decentralization. While achieving such a balance is seemingly possible, it requires strong leadership at the top of the organization and ultimately requires the ability to align business goals with the information technology function.

In his 1990 article, “The ‘Centrally Decentralized’ IS Organization,” Ernest M. von Simpson makes the case for a hybrid model that incorporates the best of both the centralized model and the decentralized model. Speaking largely from the perspective of a period of decentralization, von Simpson (1990) states that decentralization successfully “minimized turf battles over budget allocations and ensured closer connections to users – but too often with the results of creating a rudderless IS staff” (p. 3). In an effort to provide the staff with some direction, he argues that an organization should centralize its information technology functions, while still allowing business units to maintain their flexibility provided by the decentralized model (von Simpson, 1990). Centralizing the information technology functions would enable an organization to take advantage of lower licensing fees, volume discounts, and increased support options while providing structure to companywide efforts such as managing the network infrastructure, staff training and recruitment, and standard establishment (von Simpson, 1990). To achieve this sort of structure, von Simpson (1990) argues that an organization must operate in a bidirectional fashion regarding the interaction between the corporate community and the information technology community.

This sort of bidirectional interaction appears thirteen years later, when Barbara T. Bauer essentially argues the same points as von Simpson in her article “Is a Centralized or Decentralized IT Organization Better?” She describes a movement toward centralization, which was brought on by the need for Year 2000 conversions and the emergence of “new network and database technologies” that required “centralized IT organizations for development and operation” (Bauer, 2003). Acknowledging that these arguments have been made in the past, Bauer indicates that the same issues von Simpson highlighted still remain and are now accompanied by the addition of business’ almost total reliance on information technology (2003). In addition, the effective use of information technology has become a “life or death matter” in her opinion (Bauer, 2003).

Bauer highlights the major advantages and disadvantages of each model before proposing her hybrid/federated model. Specifically, she states that the benefits of centralization are in software and hardware procurement, redundancy elimination, and resource integration (Bauer, 2003). The disadvantages are the inability to be responsive to users and the perception of information technology as a huge cost center to the business (Bauer, 2003). Regarding decentralization, she states that ease of integrating various systems using the client/server model and the ability to respond rapidly to change are advantages. The disadvantages are higher operating cost due to redundancy, a lack of unified presence, and the lack of a single point of accountability (Bauer, 2003).

In her hybrid model, “functions that require consistency across the entire company are centralized” (Bauer, 2003). These functions include procurement, operations, architecture, standards and processes, and ERP application development. Unique applications, however, are left to each business unit, as well as unit specific service level agreements, resources, and strategies (Bauer, 2003). In essence, business units maintain “budget control over the decentralized functions” (Bauer, 2003) and technical resources remain the responsibility of the centralized organization.

Bauer’s arguments for the hybrid/federated model are very similar to those of von Simpson, perhaps speaking ironically to the cyclical nature of the centralization versus decentralization argument itself. Notable, however, is the way Bauer branches off her argument into a discussion of alignment by stating, "The corresponding challenge, and possible disadvantage to a federated model, is that it requires strong, collaborative leadership in both headquarters and individual business units. The CIO, in particular, must be an executive who can lead a complex technical organization as well as understand the business needs and strategy of each business unit. It also requires effective strategy, planning and resource allocation processes in the company so that centralized resources continue to meet the needs of specific business activities" (2003).

Indeed, this task is quite daunting, but it is exactly one of the skills that define successful leadership by the CIO and other executive level leaders. As Ben Worthen (2003) notes, tradition places information technology and business units on different pages. It therefore becomes necessary for the CIO to practice alignment, which is the art of anticipating business needs and translating them into successful information technology systems (Worthen, 2003). While numerous alignment techniques exist, the importance of the goal remains the same. The coordination between the information technology staff and the business units is paramount, and is perhaps the most important function of executive leadership.

Worthen (2003) states that the seemingly difficult task of executive leadership can be accomplished and illustrates it with two examples. The first example details the business “playbook” developed by Christine Modie, CIO of the Massachusetts Mutual Fund Financial Group. She developed this playbook by interviewing users, assessing their business needs, and prioritizing them as a series of goals for the year. Implementing the initiatives of the playbook saved the company 12.6 million in one year alone and her information technology group became more aware of the business as a result (Worthen, 2003). In addition, by saving money, the idea of information technology as a cost center was reduced and the credibility of her group increased in the eyes of the business (Worthen, 2003).

Worthen’s second example details Sheleen Quish’s “rankings game,” which she developed for U.S. Can. The goal of the rankings games was to “mesh the corporate goals with divisional goals” (Worthen, 2003). Using a series of rankings, corporate goals and divisional goals are mapped out and prioritized. Once the priorities are established, each goal is labeled as a “must-do, should-do, or a nice-to-do” (Worthen, 2003). In the end, the goal is to ensure that the information technology staff and the company’s business units see “eye-to-eye” (Worthen, 2003). Seeing eye-to-eye is exactly Bauer’s point regarding the hybrid/federated model’s capability to allow centralized resources to meet business needs in a decentralized environment. From Worthen’s examples, one can see that the CIO must play an integral role in bringing together both the information technology staff and the business units, whether thorough interviewing techniques, prioritization activities, or other alignment procedures.

Such examples illustrate that alignment procedures are not limited to the hybrid/federated model. While Bauer places this extra responsibility on the CIO only in the hybrid/federated model, one could argue the conceivability of these techniques in any organizational structure. Alignment, then, becomes the issue, and the centralization versus decentralization argument is seemingly precluded. In fact, applying the alignment techniques could aid in overcoming the disadvantages of the other models. Worthen’s examples illustrate these applications. For example, responsiveness and cost were labeled as disadvantages of the centralized model. If a CIO in a centralized environment were to incorporate the techniques Modie developed, these issues could be alleviated to some degree, due to the heightened awareness that results from interaction with the users.

Alignment techniques have implications for the decentralized model as well. For example, redundancy, accountability, and a lack of a unified presence were labeled as disadvantages. Quish successfully addressed these issues in her rankings analysis by requiring that every submitted project include an ROI figure, and a statement of how the project increases revenue, reduces cost, improves customer service, or stabilizes the work environment. In order for the project to proceed, it must have buy-in from everyone. In fact, her largest goal was to eliminate the “everyone-for-himself affair” (Worthen, 2003) that largely characterized the yearly allocation of information technology projects.

While the debate about centralized and decentralized models may continue to cycle for years to come, these examples indicate that alignment strategies can mitigate their respective disadvantages and bring them closer to the balance sought by the hybrid/federated model. Perhaps it is the nature of the information technology industry and the ever-changing technologies involved are the cause for such cycling between models. In any event, The importance of the executive leadership’s ability to align resources with business goals will remain the key to successfully implementing information technology in an effort to advance the company’s future.


References

Bauer, Barbara T. (2003, October). Is a Centralized or Decentralized IT Organization Better? Darwin. Retrieved October 28, 2003, from http://www.darwinmag.com/read/100103/question54.html

von Simpson, Ernest M. (1990). The ‘Centrally Decentralized’ IS Organization. Harvard Business Review, 1-6.

Worthen, Ben. (2003, April). Line Up the Team. Retrieved October 29, 2003, from
http://www.cio.com/archive/040103/hs_team.html

Read the complete text of this post