Differentiating Between the Cost and Value of SharePoint

In class today, we had a heated debate regarding trustworthy, commercial collaborative software. Not surprisingly, I took the side of SharePoint so joined the group preparing the argument for the Microsoft stack (it was small group session breakout). Interestingly, the argument ended in a stalemate after both presented cases, both sides agreeing that each has their inherent benefits (its god damn hard to come up with an ample argument against Open Source benefits), and innate faults. However, from that preliminary argument, a new dialogue was produced. Regardless of the stack choice that either group was defending, it is typical that management level sponsorship for collaborative environment efforts often has difficulty pegging down the value of standing up a collaborative software instance.

The celebrated dramatist Oscar Wilde once said:

A cynic is a man who knows the price of everything but the value of nothing.

This quote to me means numerous things (since it is so open to elucidation), however none more exceptional than the simplest interpretation. A person at times can repeatedly put an empirical cost on an arbitrary object since this is, well, pragmatic. However, to get something that is not as tangible such as Realized Business Value (RBV) or Return On Investment (ROI) for a collaborative effort is remarkably curious. Although the cost is certainly going to play a parameter when generating your Realized Business Value Docket (RPVD), it certainly is only that, a piece of input while in the presence of other inputs that hold more weight (this is one of the strengths of RBV since it provides some basic levels of cost abstraction, and those living in the small-to-medium size vertical the purchase of SharePoint can be quite expensive).

I want to stress that in my opinion, measuring things like monetized ROI on collaborative software efforts leveraging legacy business value approaches is a façade, a mirage, an illusion (this might not apply to some of its subsets). Just don’t even try it, it’s self-defeating and will only suffice in providing a depressing, dismal night where you are fudging numbers more than harvesting from the actual project.

This isn’t to say that you can’t acquire value with output metrics with collaborative software efforts, but it is problematic to present your findings to management since they can prove to be abstract and often times contain a buttload of inference. Commonly, at a most basic level, a manager is going to expect that he can gain an object for a cost from someone and somewhere, and from these parameters as well as insight into the owning organization, an ROI can be determined and implemented. In the end, we can say that managers tend to be good at looking at a particular project with a pair of monetization spectacles, compensating for human factors like apathy to technology. Taking this monetizing approach when attempting to appreciate the value of SharePoint, as well as all collaborative software, is not practical however.

Why? The outputs are different. Plain and simple. Whereas with traditional software development efforts we can do the type of surveying of project results as described previously, this is unquestionably not the case with SharePoint. Collaborative software has outputs such as:

Augmented Information Worker Knowledge
Improved Employee Productivity
Enhanced Customer Service

And while I can name these out just fine, and in some fashion there may be some methods to garnish metrics from them (notably the Enhanced Customer Service entry), how does one place a value on something like enhanced information worker knowledge. While we can certainly see whether there are variations between productivity, this reporting is in essence very circumstantial because we are pretty much preparing a collection of facts rather than a conclusive series. There could be too many factors involved that could cause discrepancies for any of these during that process, as well as for the aggregate output.

So, stuff like this is somewhat conjectural at the moment. I think that the best way to measure something like this would be with revolving, time adjusted surveillance of collaborative software utilization growth and taking into account parallel visualization of the stored and delivered data. However, I don’t think that is enough, because that is only a very small part of the measurement. Rather, it would have to be inclusive to include the more human factors, such as how often a person is involved in face-to-face interactions, movement patterns that occur in the workspace, etc. This type of research would be even further constrained as it would have to compensate for dependencies on legacy collaborative tools, such as email. I am not going to go into the approach I would use with this, I will save that for another post.

I guess what to take away from this, particularly if you are a manager, is this is a new concept and a new type of recognition. And while the benefits might not be immediately available to conventional brick-and-mortar industries, they are there. There just haven’t been any mature, intelligent tools built that inclusively deliver those types of reports.

Yet…… (and the gears start turning). Stay tuned!


Is SharePoint Going To Die?

I get asked this question a lot, I generally suspect it is because at first glance with SharePoint it takes a fair amount of resources to run a well-architected, organized, and maintained portal for an arbitrary organization, which I think is partially accurate. However, I don’t consider that is a fault of SharePoint as a product, rather I just believe that it is collaborative software as a whole breed being introduced to virgin organizations. As the breed continues to grow and evolve, becoming more of an arm of the enterprise body, I think that is bound to become even more complex and involved, demanding more resources form the organization. Quite honestly, I would not be surprised if larger companies started to dedicate more committed personnel into their communication and collaboration initiatives by the creation of entirely new positions that are responsible for those types of tasks.

Anyways, back to the question. To be honest, it usually just isn’t that one, it is usually a twofold one.

The first question is:

1) If and when do you think SharePoint is going to die?

Shortly followed by the second:

2) What are we going to do if SharePoint dies?

My first answer is I don’t think SharePoint is going anywhere for quite some time. The reasons for this are kind of disjointed, long, and numerous, so I will keep it to what I consider being one of an important three.

I think at the current moment a lot of people are buying into SharePoint as a secondary piece of software; however it is slowly engraining itself into corporations as becoming more of an operating system or some other type of central nexus for Office clients. So whereas you say Some Portal Thing, some might say the Beginning The Web Enablement of Office. You say it’s just a floating piece of software, I say it is a platform bringing important business concepts, and important business initiatives, (i.e. we can just say simply collaboration as an example of this), to a company. I don’t consider it to simply by a tool, I believe it brings more to the table then that. It breeds ideas and concepts, it doesn’t just simply provide some piece of functionality.

Familiarity I also think is a big portion. I think that following its proper deployment, it sort of builds dependencies from users, once people really start to become intertwined in it, taking that functionality away would be nothing but detrimental to a company. While I think this is mainly because of the familiarity talked about in the above, I believe that in a lot of the ways SharePoint tends to force business process creation within a company where they might not have existed previously. Familiarity too also spawns from the administration standpoint. I mean, you get WSS with Server 2003, and you already know Server 2003, so why not expand that knowledge to engrained products?

While these are kind of an abstract reasons, we can also look at it empirically as simply a sunk investment in Office, organizations already have a high familiarity and usage rate of Office versus other client office suites, and therefore it only make sense to harness that experience against more radical technologies that improve the overall information worker experience. I mean, nuff said right?

Lastly, I think that it is becoming much easier to develop (arg) in comparisons to past versions (2003 was torrential even though that was partly the fault of Visual Studio at the time). While the portability of WebParts against the new framework is consistent so movement between CMS framework assuming it is .NET would be minimal, I think that SharePoint handling a lot of the things I normally hate as a developer such as site design, etc. is kind of nice (even though I don’t think this makes up for the lack of a visual design surface in some type of IDE). Because there is some cost associated with developing against SharePoint (since you might be using SPList’s for data storage etc.) and familiarity has been grown while the application is housed in the company portal, this also makes SharePoint a rather permanent addition to a companies IT organization.

There are a bunch of other reasons, I am sure; however these were the big three that I could think of off the top of my head. I think the big thing to consider is either software dies, or it improves. The best mentality to take away from this is a platform, not typically secondary application software, tends to have a high chance of survival, meaning it tends to continue to innovate. We have seen this leaps and bounds between the versions of SharePoint.

As a side note, in my opinion it often makes sense for a lot of organizations to buy into the stack of a company as well, sometimes it is just easier and makes better business sense from an upgrade, maintenance, and support standpoint (I am not saying it is for all organizations since some seem to do fine with a combination of OpenOffice and LifeRay or JBoss Portal).

Anyways, I might expand on this post later, I am tired of writing this now though.