IT Consulting Ethics – Part 3 – Benefit-Cost Analysis and Government Considerations

If the principal objective of a not-for-profit organization is to maximize some aspect of its non-pecuniary mission, the marginal comparison criteria applied in the for-profit sector to revenues and costs should be equally applicable in the not-for-profit sector to the quantifiable    characteristics of the mission being pursued. “Benefit-cost” analysis may provide decision criteria for the organization manager in the government and not-for-profit sectors. The sum of all benefits (non-pecuniary as well as revenue) resulting from mission pursuit constitutes the numerator, B, of the benefit-cost ratio. Its denominator, C, consists of the sum of all costs (non-pecuniary as well as pecuniary) incurred in pursuing the mission. If the value of the ratio is a number greater than unity (i.e., B/C > 1), then the activity under analysis is justifiable; any benefit-cost ratio less than unity (i.e., B/C < 1) suggests that the activity is unwarranted.

Simple benefit-cost analysis has been extended to the concept of marginal benefit-cost analysis. This version is applicable to situations where the question is whether to do more or less of the activity which is already in progress. The numerator of the marginal benefit-cost ratio includes only the additional benefits which are expected to flow from some increment of the activity; the denominator sums only the increased costs incurred by the activity increment. The same decision criterion holds for the marginal as for the simple benefit-cost ratio: a value greater than unity warrants the activity increment while a value less than unity indicates that the activity increment should not be undertaken. While marginal benefit-cost analysis has been used most often as a decision criterion in the not-for-profit sector, it is apparent that the for-profit criteria of marginal revenue and marginal costs are special cases of marginal benefits and costs where the benefits and costs are pecuniary values (or equivalents).

Both simple and marginal benefit-cost analyses are subject to bias and fraught with the potential for abuse. The bias follows from the requirement to include all benefits (psychic and other non-pecuniary benefits as well as any revenues resulting from the activity) and all relevant costs (non-pecuniary psychic and opportunity costs as well as explicit money costs). The problem is that a decision maker who is has a predisposition favoring a proposed activity tends to exhaustively identify all possible benefits and also tends to overestimate their money value equivalents. A decision maker with such a predisposition also tends to be more casual about identifying the relevant costs, and may also be inclined to underestimate their money value equivalents. By the same token, a decision maker with a predisposition against an activity tends to do the opposite, i.e., to casually overlook some benefits and underestimate the values of those identified, while exhaustively finding all relevant costs and carefully estimating their full money-value equivalents. Because of the subjectivity involved, it is entirely possible for two decision makers, confronted by precisely the same prospects and with the same information, to estimate widely divergent benefit-cost ratios and reach opposite decisions about whether to proceed with the activity.

Because capitalism (or market economy) is the form of economic organization to which the world seems to be drawn, I shall presume its general characteristics in subsequent discussion of the role of government. Given this presumption, there are six principal points of contact between firms and the government.

(1) Along with other entities in the economy, the government is a demander of goods and services from private-sector business firms; i.e., firms function as suppliers to the government. Since the government is likely to be the single largest economic entity in any economy, the prospect of supplying the government should provide market opportunities for a great many firms in the economy. However, firms seeking to function as suppliers to government should be aware of becoming too highly dependent upon government orders.

(2) Firms pay taxes to the government. The taxes may be related to the firms’ profits, their sales, their inventories or other assets, or the wages which they pay to their employees. Tax-related record keeping and reporting often become burdensome to business firms, and tax liabilities and rates are subject to change at the dictatorial or parliamentary whims of the state.

(3) Depending upon the government’s particular political, social, and military programs, various firms in the economy may become objects of support by the government. Such support may take the forms of subsidies, approval of licenses, preferential contracts, or other encouragements. The government may attempt to structure such activity as a coherent industrial policy for the promotion of international competitiveness of domestic companies.

(4) In pursuit of its agenda, government’s interests in firms may extend beyond support to efforts to control the activities of firms. Objects of governmental controls may include directions of research and development efforts, determination of product mixes and item specifications, selection of capital investment alternatives, eligibilities for import or export licenses, and employment practices. These activities may become elements in a more comprehensive industrial policy.

(5) The private sector may become an object of regulation by the government in the interest of employees, consumers, or other interests in the economy. Such regulation almost always imposes additional costs upon business firms, and consequently squeezes profits or results in higher market prices.

(6) And finally, the private sector may become the object of efforts either to promote and encourage competition, or to stifle or prevent competition. In the former case, “antitrust” or “antimonopolies” laws may be enacted and enforced; in the latter case the government may become the prime mover in the effort to “rationalize” or cartellize industry (also a possible component of industrial policy).

In their extreme manifestations, points (1) and (4) above may devolve to the characteristics of fascism. I may also note that the government can effect a ready transformation to the characteristics of socialism simply by nationalizing private-sector firms so that they become government-owned and directed enterprises. Our purpose in making these observations and otherwise identifying the various points of contact between firms and the government is to note that the operation of government in a capitalistic economy may pose threats to private sector firms as well as provide opportunities which they may attempt to exploit.

The most fundamental role for government to play in the market economy is the maintenance of an environment which is hospitable to the functioning of market economy and the exercise of entrepreneurship. At very minimum this means establishing the rules for holding, transferring, and arbitrating disputes over the possession of private property, determining weights and measures, providing a stable money supply, insuring the sanctity of contracts, and otherwise maintaining law and order. John Stuart Mill during the nineteenth century referred to these minimal roles for government as the “night-watchman” functions.

Beyond the night-watchman functions are four other significant rationales for governmental involvement in the market economy: to maintain competition, to reallocate resources, to redistribute incomes, and to stabilize the economy. Each of these rationales is founded upon some fault, shortcoming, or failure in the functioning of the market.

From this perspective it may be noted that any problem in the functioning of a market may invite some response from government to address the perceived problem. And if market mechanisms exhibit traumatic failure or become fundamentally distrusted by the political leadership of the society, these constitute the rationales for shifting to fascism by conferring product-mix decision making upon a central authority, or to socialism by nationalizing privately-owned productive resources and imposing central planning and direction. By the same token, failure of authoritarian socialism constitutes the rationale for shifting from authoritarian control to some form of market economy. It appears that this latter phenomenon is being widely experienced in the Eastern Europe even as some economies of the West experiment with more statist orientations.

Viable competition among business firms in each market is the sine qua non of market capitalism. It is competition which ensures that firms efficiently produce only those goods and services demanded by the consumers of the society. But there is an inherent divergence of interest between the firms in an industry and their customers. Although customers surely benefit from adequate competition (lower prices, higher quality merchandise, greater product variety), firms might achieve greater profits in cooperation with each other or as sole monopolists of their respective markets.

Governments of democratic societies then find rationale to undertake the promotion and preservation of competitive conditions in their economies. This is usually done by enacting legislation which declares the existence of monopoly to be unlawful (in the U.S. this is accomplished by Section 1 of the Sherman Antitrust Act) and the perpetrator of monopoly to be guilty of an unlawful act (Sherman, Section 2), or which enumerates specific acts or activities which diminish competition and which are thus unlawful (the Clayton, Robinson-Patman, and Wheeler-Lea acts). But the enactment of legislation alone is not enough. The government must further establish an enforcement authority (in the U.S., the Federal Trade Commission and the Antitrust Division of the Department of Justice) and resolve to make effective the enforcement of the relevant legislation. This resolve may differ significantly according to the political party in office and the particular agenda which it is attempting to implement.

The managerial implications of the determined enforcement of laws which are intended to preserve and maintain competition are that managers of business firms must make themselves knowledgeable of the pertinent laws, and they must make calculated judgments as to whether to risk violating such laws in any of their sourcing, producing, or marketing activities. It may also be worthwhile to note that in a society governed by law (as is the U.S.), innocence is presumed until guilt has been established. The significance of this is that no act undertaken by the management of a business firm is necessarily in violation of the law until it has been tested in the courts.

In a legal environment of presumed innocence, even though a law may declare a certain act unlawful and other firms engaging in the act have been indicted and successfully prosecuted, the act may be repeated by yet another firm. In order for the firm to be penalized under the law, the act must be detected, indicted by an appropriate legal authority, and successfully prosecuted in court. Because failure may occur at any of these stages, the management of a firm may behave rationally to assess the probability of detection, the probability of indictment if detected, the probability of successful prosecution if indicted, and the magnitude of the penalty if found guilty under the law. Then if the “expected value” of the penalty (i.e., the conditional probabilities multiplied by the likely penalty) is judged small enough, the management may deliberately assume the risks of detection and prosecution by engaging in the act. Indeed, it is not uncommon for business firms to maintain legal staffs or contingency funds to cover legal fees and any penalties which are actually assessed.

Two cautionary notes are appropriate at this point. First, even though the behavior described in the paragraph above may be rational, the reader should not take this acknowledgement as an advocacy of the assumption of risk in knowingly breaking the law. And second, although the liability of corporate shareholders is limited to their investment in the firm, corporate managers should beware of the possibility of both criminal prosecution and civil liability suits when their firms have been found guilty of violation of the law.

Suffice it to say at this point that the rationale is based upon the conclusion that the particular allocation of resources resulting from the normal functioning of the market economy is not satisfactory and needs adjustment. This conclusion may emerge if there are so-called “public goods” desired by society but not producible in response to market incentives, or if there are positive or negative externalities (or “spillovers”) resulting from the market production of goods or services. The managerial implication of this rationale is that declining profits or losses will likely emerge in industries from which resources are diverted, but profitable opportunities should be found in industries toward which resources are reallocated.

The income redistribution rationale follows from a social and political judgment that incomes are being inequitably distributed across the population of the society by the normal functioning of the market economy. There is little doubt that any market economy distributes incomes unequally because of the fundamental reward mechanism of capitalism: to each according to his or her contribution to the process of production of demanded goods and services. Since members of any population possess differential abilities and experience varying intensities of drive and motivation, there will occur different contributions to the production process, and as a consequence an unequal distribution of income.

Social action becomes warranted only when it is judged that the inequality of distribution is also inequitable. The governmental vehicles for redistribution include progressivity of income and profits taxation, the taxation of capital appreciation, and any of a wide range of possible transfer payments. One managerial implication of governmental redistribution is that business net incomes, assets, and wages paid are likely to be objects of taxation to raise revenue for redistribution to lower-income members of society. Another is that businesses catering to transfer recipient clienteles may benefit from the redistributions. However, there may be little hope for managements of business firms to exert significant control or influence upon the political process which determines how incomes are to be redistributed.

The rationale for bringing the offices of government to bear upon the stability of the economy is based upon the view that market economies are naturally unstable, that the degree of instability is intolerable, and that some force must be applied to counteract the natural instability of the market economy. Of course, the only entity in the economy which can possibly bring enough force to bear upon the problem of instability is the government.


Are SharePoint Developers Better Architects than Architects?

I was at dinner last night with a SharePoint-y friend of mine and the dialogue arose about distinctions in what is coined as a SharePoint developer and as a SharePoint architect. In a majority of SharePoint projects these are advised as key, mutually exclusive roles that are obligatory for project success. And while I to some extent agree with this notion (such positions being requisite that is), if you look at a arbitrary, indiscriminate company on like or something that is spinning up a freshy practice, staffing a client project, or doing a clean IT slate at a corporation, you are going to most likely see these positions listed. As a result, I just consider it the industry, while it might be exactly my personal, standard.

Defining the difference between an architect and a developer is prickly, and to be honest I think such arguments revolving around position semantics are at best lackluster. However there are a few things I think that deserve noting before I get a wee bit rantish with the remainder of this post.

SharePoint architects commonly are not considered to have mastered development tools and frameworks; generally you find them working closer with the operations group for the inclusive IT environment. Inferring then, it can be assumed that responsibility lies more with the physical / application network, SharePoint servers, SQL storage, management / operations / governance, server and SharePoint security, and miscellaneous other systemic qualities of SharePoint. Conversely, this implies that the other portions of the team pick up weight understanding and implementing the functional aspects of the product, or in relation to what was stated before development tools and frameworks. It is tough to place a multifarious job description in a succinct, single sentence however that is the best I can do for the time being and serves this particular argument pretty well.

Leveraging this as a definition, we then raised the question of not the differences that exist between the two positions (although this conjecture is important in the following argument), but whether SharePoint developers are better SharePoint architects than those that solely define themselves as architects.
The questioning is simplistic; the reasoning is slightly more convoluted. Consider two candidates for a project, one of them a SharePoint architect and the other a SharePoint developer. Furthermore, in order to maintain a equitable baseline, let’s assume comparable (obviously can’t be identical) backgrounds, projects, experiences, etc. Would you insist that the SharePoint developer will be more successful if given a series of requirements and turned feral on a SharePoint project? While this isn’t the structure of a particular staffing strategy for a SharePoint project, it’s the most extreme argument.

For me, the answer is a resounding yes!

Below are three principal reasons why this is the case in my opinion, which is obviously very, very subjective so take it with a grain of salt.

Inherent API Use Leads To Innate Architectural Understanding

Developing against a commercial OOB product such as SharePoint necessitates a majority of the knowledge that architects generally tout as requisite because of object, method, etc. use. As such, the thread that weaves the overall linen is already known, and while IMMEDIATLY the strands being put together properly might not be holistically identified, the knowledge does exist so the barrier to entry is lessened to an immeasurable extent. So while this might not immediately translate to the breadth of architectural knowledge having immediate applicability, I consider this more to be a lack of situational experience (which is even more subjective) easily garnished during a project therefore making a developer a more appealing candidate in the long term.

While there are a lot of examples, I am going to assume a more common one that I see to support such a claim. Consider the use of a UserProfile object and its tricky permissions requirements that require setting in the SSP. I can’t count how many architects I have caught with this on an interview question, but I have never really caught a reasonable developer off with it since when enumerating UserProfile objects in a UserProfileManager that they always get the pesky System.UnAuthorizedException due to personalization services permissions being malformed. As a result, they are already privy to such knowledge.

Developers Are Unquestionably More Learned in Orthodox .NET Concepts

SharePoint is often misconstrued as a mythical unicorn type thing from a platform standpoint that is built on a hugely disparate stack then the rest of Microsoft platforms. And while there were a lot of awkward things in V2 that would imply it really was a one off (for this, I am thinking more a lot of the ISAPI request handoff’s etc.), in V3 it is really just a ASP.NET 2.0 application (outside of fickle things like virtual path providers and what not which are never going away anyways), using the same underlying technologies as thousands of separate web applications across the world. Applications that .NET developers have written, and most convert SharePoint developers already have a fairly thick background in orthodox .NET development.

While interviewing architects for companies, something that I see is that architects stop learning technology once it crosses a certain cusp, in the terms of this post essentially pigeon-holing themselves into the SharePoint slot. While this has both pros and cons, the lack of understanding makes it more difficult when problems arise in a SharePoint environment that can be traced back to a deeper part of the MSFT technology stack, things not well handled by native SharePoint mechanisms.
Again, lots of examples of it. Pragmatic example wise, I always see it with claims aware SharePoint environments. Since developers are more accustomed to different identity contexts, when building claims based environments they are much more effective at putting together how a federated identity processes should flow.

Tend To Have a More Refined Pattern for Business Problem to Technology Translation

I think this one is going to be the toughest point to sell, however I really do believe because developers understand a much deeper portion of the how the overall platform functions (since they are accustomed to extending it) they can provide a more seamless transition of taking requirements and providing the end result. What I see more on projects, way more when I am doing architectural / planning reviews than anything is the use of technology by architects for the simple reason of using it because it was described on a MSFT product page as being a possible solution, so it MUST be the BEST solution. There is awfully little thought given to inclusive environment impacts, and most importantly demonstrated the solution flow so a customer is aware of the steps that are involved in application function.

The BDC is a terrific example of this. When doing please-unfuck-our-SharePoint-environment projects I see architects all the time spouting all these terrific things about the BDC. When implemented not ONLY will you be able to display disparate data, but everyone in the organization will lose thirty pounds, get their hair back, and their significant others will gain an untamable sexual appetite. But 9/10, the BDC is an awful, unmaintainable solution (Obvious FYI: I don’t like the BDC very much in its current form. If I can do it in 10 lines of managed code as opposed to 40,000 lines of XML, I’ll take the managed code option), and the persons ultimately responsible don’t even understand how the XML translation provides DAC, further abstracting the customer from the actual solution. While the BDC is touted as a non-code solution, I can at least walk through my managed code and DEMONSTRATE how the data, in real time, is called, massaged, and presented.

Boy, I could go on with this for a while, but I’m gonna call it quits here :)


Problems with SharePoint Governance

Now hang on, this post shouldn’t be misconstrued as attacking the concept of governance as a whole, it is more rantish. I am not going to portray that “Buenz Thinks Governance is Bad”, I do violently believe that cultivating long-term value from an arbitrary SharePoint deployment requires a specified level of governance. I spoke on the exact subject at the last SPC conference, I eat the Wheaties. I just think there are a lot of tribulations with conceptualization, use, and implementation which leads to the prostitution of the notion which is maddening.

And I am of the firm belief that I can’t be the only one.

SharePoint can curiously be subject to colossal content sprawl which fundamentally equates to a failed implementation, and governance is generally put into place to curve that, otherwise, there are business-class nightmares. This is due to the fact that SharePoint can be considered as naturally organic and amorphous, empowering users which in turn can lead to content chaos. This can be multiplied by the fact that current business process problems can be replicated in SharePoint, and because of its reach, be even more of a problem than before. This is 100% the space that a governance strategy seeks to fill, and can productively accomplish when acknowledged as a series of piece-meal cogs that construct a complete machine. Loosely defined, let’s just consider SharePoint governance as a strategy to ensure quality of information architecture and associated content taxonomy while keeping in mind defined business objectives, ensuring procedures are defined for support of the aforementioned. Ahhh, nice and ambiguous.

I see more and more people doing three things in regards to SharePoint governance:

1) Downloading random governance templates / processes. Implementing them without taking into account the organization, then when failure occurs putting said policies in the same place as the old company BetaMax.

2) Thinking that a series of policies is actually going to be effective for an enterprise SharePoint governance strategy automagically. Governance tooling is required, and third party components will never provide a holistic closed-loop governance solution.

3) Using the word governance to characterize 50,000 things. Then using it incongruously because it sounds super nifty and is so ambiguous that hey, it should apply. Right? Yeah let’s do that, buzzwords are fun.

I Found This On A Blog. Let’s Do This. Like Nowish and Be Done With it.

Firstly, let’s start off with the misconception that SharePoint governance is solely policy definition and implementation. A lot of current organizations are downloading, briefly examining, and implementing governance policy definitions with little or no foresight into the auditing and enforcement of said governance policies. They just sit there; though can without difficulty be referenced in order to defend the deprecated state of a SharePoint implementation when such information is solicited. But lest us forget that standard, bare-bones policy management by definition is composed of three things:




Most people I see starting and stopping with the first one, which brings up the question, how the hell do you actually measure the effectiveness of the governance strategy when you have no means to gather indicator data? Sure, you can build some basic indicators through the internal use of SharePoint auditing and associated concepts; however that is woefully lacking in what is required for an inclusive governance strategy. Closed-loop SharePoint governance software is required in order to actually mine and massage required data (which I will get to in the next segment, small deviation), meaning that all three concepts lie in the same domain, and relationships between the three are inherently procured as part of the system. I mean, part of the standard definition of governance is verifying performance! While documents can provide benchmarks in order to empirically study some segments, translation of the information cannot be inherently provided with ease.

Furthermore, when defining the governance policies it is necessary to contextualize them, and this requires actually reading through the policies you are considering and tailoring them to an organization. If you don’t its literally like talking to a go to a car dealership and saying Hey you, slimy sales dude. You can have this blank check. I signed it. I just want something that gives the impression of having a four wheels and movement. A cardboard picture of an engine being under the hood as opposed to the real engine sounds pretty awesome. Lightweight! I’ll do that.

In the same respect as this post where best practices were discussed, governance requires taking into account all sides of the industry shape, not just piece-meal portions that seem attractively easily to put into place. This is something referred to as a Fragmented Governance Implementation, since you really have only hit aspects that seem on the surface as imperative without bearing in mind the relational nature of governance concepts.

I am NOT alluding to that broad governance concepts have no applicability; they can actually be useful and educational when leveraged in the right way. But they can also have severe implications, and be very, very dangerous when used in an erroneous way. You don’t run around blindly signing contracts, and implementing a governance policy is the *exact same thing* as a contractual obligation. It is effectively a SLA between an IT entity and itself in order to maintain platform sanity and ensure information architecture maintenance.

Governance Requires Tooling. Custom Tooling At That.

And if you think it can be solved with a one-size-fits-all third party component for everything (traditional architecture governance, data cleansing governance, etc.) since it looks like a low hanging fruit solution, you will speedily find yourself in a pigeon hole. A really small one that is uncomfortable and has glass shards glued all over it. Do you really think that there can exist a SharePoint governance application that allows IT organizations to create or adopt IT governance frameworks and structure, manage, and maintain the processes and activities required for meeting ANY governance objective? Puu-leaaaze.

Proper governance requires vertical sensitive tooling in the same way that applications are developed with industry understanding in mind. Assuming that the same series of governance steps will provide the same governance results is 100% false, analogous to someone claiming that a Task Management System software package can be used OOB in every sector with no friction. I can’t even count how many Task Management Systems I have written for SharePoint, and there were all severely dissimilar. And while they share broad concepts, the guts of the software was very different and would not translate well in-between each project. This is something that should be ported to the concept of governance, and why there can never be universally applied policies or a shipped software package that provides closed loop governance, deployments are unique and individual to organization. Like I said, I am not alluding to that broad governance concepts have no applicability, nor are there no available inbuilt mechanisms within the shipped SharePoint software that procure some tooling. However it woefully lacks the granular components required for a holistic closed loop governance solution and is effectively ignorant to organizational particulars.

For all intents and purposes, organizations that are serious about governance need to inspect their current business state and develop the governance strategy around it. This will lead to tooling that can use the overall governance concepts as a base to inherit more defined governance procedures around that are sensitive to the company. I have always purported that it is the poorest decision an architect can make to try to tailor an entity to a product; governance is no exception and should be treated accordingly.

Governance Means Everything!
This is seriously how I feel about this:

[kml_flashembed movie=”” width=”400″ height=”320″ /]”

but replace every time Bob Dole is saying Bob Dole with the word governance. People just like this drive me up the frickin wall because every 20 minutes it’s SOMETHING about governance. Governance this, governance that. Governance, governance, governance.

I don’t really want to argue semantics which I am sure I am going to hear about anyways, but I know I am not the only one in this camp that grows weary of the repetition and assumption of immediate applicability of word governance. Overuse of the word has actually made me do the RCA dog look to people in meetings that actually bring it up now. It’s becoming difficult to take seriously.

This blog post is too long so I am going to cut it off. I might continue it later but my fingers are going to need Band-Aids soon from all the typing.