1,695 articles and 12,705 comments as of Tuesday, September 14th, 2010

Tuesday, April 27, 2010

SharePoint Out-Of-The-Box: Is this Really a Debate?

Dessie Lunsford
Points-of-Sharing 

I subscribe to a number of blogs and tech sites for the sole purpose of finding out what’s new in the world, and what’s new in things that I have interest in.  For the most part, I simply scan through the new items I get in Outlook, read more on those that catch my eye, and occasionally comment on those that are of value to me.  Some, as in with the following, have stirred me to the point where I must express my opinion in the same manner in which each "OP" stated theirs – in an attempt to create some clarity in the confusion.

It starts with Bjørn Furuknap posting an article denouncing the use of OOTB ("Out of the box") features and functionality in a SharePoint deployment.  To "some" degree, I can agree with his reasoning, because for the most part, the default set of lists and libraries (the "Out of the box" set of pre-done components) are really more of a "sample" or "demo" to get you started and they really don’t always represent an answer to a client’s specific need…although, they may be close.  Generally, you’d run through the list of requirements and create a brand new list or library that has custom columns and workflows to do the job needed.  Additional customizations may be needed later to make things more complete solution-wise, but in a very basic sense, this is the normal starting point for anyone.

The issue I have however with what Bjørn professes is in his push to simply scrap everything from the start because it has no value and that everything "Out of the Box" is bad and "stupid".  As someone who uses the default out-of-the-box lists and libraries on a daily basis, and has used many of the "Fab 40" templates in their default out-of-the-box state – with all out-of-the-box lists and libraries intact, I think he may be pushing things a bit to the extreme in his thinking, and here’s why…

A basic "Team Site" in its default state, has all the basic tools necessary to start someone on the path of learning to use SharePoint and collaborating with team members, and "can" exist for a long time as a sound foundation on which to build on (see, I can use the "house" building metaphor as well…although I tend to agree more with Bill Simser’s opinion on its over-usage.  Does this mean that the site should remain as is without any modifications or customizations forever?  Possibly, but normally no because there will be custom lists created that stray from what you get as default, but what’s really in question here is what "Out of the Box" really means.

In SharePoint terms, "Out of the box" refers to the functionality of what the platform can give you using all of its Built-in tools (note the term "Built-in").  This includes all of the default pre-created lists and libraries you get when you create a team site, as well as the ability to create a custom list or library using your own columns.  I would also venture to say that creating your own custom site columns and content types are also "Out of the Box" because it is native functionality built into the system that does not require any 3rd-party installation of custom features – all of this you get by default when you install SharePoint, so by definition, it is "Out of the Box".

When you’re creating a site for a new user, regardless of whether you start from a "Blank" site and create all lists and libraries needed, or if you start with a "Team site" and either build on the pre-created lists and libraries – or scrap them and create new ones, it’s all the same "Out of the Box" functionality – this is where I believe Bjørn is incorrect in his terminology.  Until you start adding in 3rd-party features (whether they be advanced CodePlex features and solutions, or simply adding in a small JavaScript into a CEWP [this includes JQuery]), you’re still in the "Out of the Box" feature set within SharePoint.  Deleting the default "Shared Documents" library simply because you don’t want the special characters in the URL and creating a new one with no space in the name is not straying from "Out of the Box", this is simply cleaning things up a bit.  Saying something like "You can take the out-of-the-box contact list and remove all the columns you don’t need, but then you’re not longer using out-of-the-box functionality", is absurd – a more correct statement would be that "You may want to consider creating a new list to more closely match your environment needs, and some of the default lists and libraries can be a good starting point".  Do I agree that removing unused columns rather than just starting from scratch on a new list vs. a default lists is better…maybe, it all depends, but I’d never ever use a blanket statement that "…modifying an out-of-the-box list is a stupid idea" – that’s just irresponsible and (to borrow from the quote itself) stupid.

When you create a new site in SharePoint, you start with an "Out of the Box" environment.  Using the built-in functionality that SharePoint gives you (again, all "Out of the Box" in terms of what functionality is available without installing anything 3rd-party), you then build upon what is default in order to achieve a better solution for what is needed (Marc Anderson posted a response article to Bjørn that covers this pretty well).  You create new lists and libraries, add in custom columns with advanced formulas (my favorite obviously, for those that know me), build workflows through SharePoint Designer (also "Out of the Box" – although some would most likely disagree with that), and eventually add in something 3rd-party (straying from what is "Out of the Box") in order to get to where the site becomes more of a complete solution.  Does a "Complete" solution require anything beyond what is available "Out of the Box"?…most definitely not.  As someone who has been working with SharePoint for quite some time now, I can attest to many scenarios in which a default team site has met the needs of my customers completely.  Obviously not every site is this way (the old adage of "One size fits all" does not apply, and I’d never ever say that it did), but many are.

Similar to what Bil Simser states in his rebuttal to both Bjørn and Marc, I believe there are really two different levels of functionality within SharePoint that details what is "Out of the Box" and what is not (or three, if you take it as far as Bil by separating customization to the front-end side [SPD], and development to the back-end [VS] – which I do agree with for the most part, but I lump them together in order to separate what is "Out of the Box" and what is not).

OOTB:

Working in a site that has nothing extra added to it – no JQuery, custom created Webparts and features, visual studio workflows or solutions – this is "Out of the Box".

Using the built-in default created lists and libraries; this is "Out of the Box"

Creating a custom list that perform a lookup or calculates winning lottery numbers, this is "Out of the Box" (and needed – someone please create this and share). 

Taking the default "Contacts" list and removing the "Company" column because it wasn’t needed, sorry Bjørn but this is still "Out of the Box".

Creating a few new content types in order to be able to have lists where you can create contacts that are either personal or professional and the need to have different columns of data based on which of the two you are creating – I’d argue that this is still "Out of the Box" functionality for the sole reason that the ability to do this exists within SharePoint already (nothing extra or 3rd-party is required).

Not OOTB:

Adding in a script to a CEWP to print out a calendar page without the header or Quicklaunch – not "Out of the Box" because the functionality the custom script provides does not exist within the system already. 

Anything with JQuery – not "Out of the box" (same as above).

Deploying custom features and solutions (ala CodePlex) – not "Out of the Box".

ANYTHING using Visual Studio – not "Out of the Box".

In my organization, I tend to wear multiple hats when it comes to SharePoint simply because we don’t have the ability to bring in extra people to separate out the roles (State-ran organization that has a very stringent budget).  I’m a developer by trade, but I’m also a designer, a trainer, a server admin, a media expert, and a user.  I’m responsible for everything SharePoint related, and am the first point of contact for new users as well as the Farm admin responsible for all deployments, their configuration, upkeep and health.  When someone has interest in SharePoint as a possible solution for a given need, I work with them from start to finish to not only make sure that SharePoint can be the solution, but how it can, and how to make it so.  More often than not, an "Out of the Box" scenario is more than enough to meets their needs.  Many times we eventually move towards extra functionality not included in the system to assist in their needs not identified at the time of site creation, but as all three authors (Bjørn, Marc, and Bil) can attest to, SharePoint is an evolution – which means that it is never complete, never finished.  As you get more familiar with it, you’ll see that it can always do more, and I’d venture to say that every customer would also agree.  "Out of the Box" or not, SharePoint in all its built-in functionality and ability to expand can be a great foundation on which to build on – where you go is up to you, the customer, and their needs – we only need to be able to envision the most appropriate path to get them where they want go, whatever that path may be.

Thanks for taking the time to read through this – I meant no ill-will towards any of the others I’ve mentioned here, and offer a sincerest apology if any offense was taken.  My only goal was to add to the discussion and offer in an opinion from someone who has to look at many different approaches to solving problems for my customers, and to point out the fact that each of us has to make sure that we don’t "lock" ourselves into one mode of thinking.

- Dessie

Dessie Lunsford
Points-of-Sharing 

View all entries in this series: SharePoint Out of the Box»
Entries in this series:
  1. "Why Out-of-the-Box Makes No Sense in SharePoint" – A Rebuttal
  2. What is SharePoint Out of the Box?
  3. SharePoint Out-Of-The-Box: Is this Really a Debate?
 

Please Join the Discussion

22 Responses to “SharePoint Out-Of-The-Box: Is this Really a Debate?”
  1. Dessie:

    Good to hear your thoughts on this. No offense taken at all! (Even if you disagreed with me, your opinion would have to have some validity.)

    In the old days, we used to think about “programming” and “application programming” differently, and we often had this same sort of debate. A good development platform blurs these lines, thus the confusion or debate which ensues. What’s totally clear is that SharePoint is not a “greenfield” environment: you start with a lot of good stuff and you can adapt it as needed, whether it be by writing managed code, tweaking thorugh the UI, or working in my favorite place, the Middle Tier. (I haven’t given up on the middle Tier moniker because no one has given me a better idea.)

    We all come at these things based on our prior experience. I fully admit to being (and wanting to be) more of an “application programmer”. I also try to do my damnedest to look at things from the business need in rather than the technology out. (This isn’t always easy because I’m also a techie at heart.)

    I respect everyone’s opinion in this “debate”. We can all be right on some level, even if we disagree. Hopefully having us chat about this in a public forum like EndUserSharePoint.com is useful to the readers and gives each of them some new thoughts to use in their work with SharePoint.

    M.

    • Matt B. says:

      How about calling it “Plug-In” instead of “Middle Tier”? That’s what they call it for every other piece of software I’ve came in contact with… I think that would stop the feeling i get when I see one of these posts: “Ugh, not another one of those posts” At the end of the day, does this really even matter?

  2. Paul Akerlind says:

    Dessie,

    Great article. One thing that you mentioned in your post was the fact that where most of us need to where “multiple hats”. If we aren’t performing Administration we are training are users etc. In this economy companies are doing more with less. This brings me to the point that are users run the risk of waiting for a custom solution to be developed when we can get close to there requirements with OOTB functionality. As a promising BA/developer hybrid I always try to strive to listen to the needs and attempt to model a solution that will get users up and running quickly and efficently. Naturally if customization is required than we will do the needful as long as the customer is aware of the risks(time, testing, controlled deployment etc) It also is wise to let the customer have a hand at building a site prototype with you. This gets them familar with how easy it is to do things with SharePoint.

  3. Bjørn says:

    Dessie,

    As Billy did, you try to redefine out-of-the-box to mean something else. You may be right, both of you, but it doesn’t really matter whether you include a richer out-of-the-box definition than I did.

    The way you’re using SharePoint is still to show how nice SharePoint is. Businesses don’t give a rats behind about how nice a piece of software is, they want to solve problems specific to their needs.

    Businesses do not have to get used to what SharePoint offers out-of-the-box or what you can configure, regardless of whether you want to include configuring and web creation of lists, content types, columns, or whatever.

    Let me use another analogy. SharePoint out-of-the-box is Lego. My out-of-the-box definition means you get a nice Lego toy, premade. Your definition means you can take a ton of Lego pieces and build something completely different. You may be able to create wonderful new toys, but it’s still just Lego pieces.

    What I’m saying is that the true power of SharePoint is not in Lego, but in the fact that the platform used to create those Lego pieces is plastic. Businesses don’t have to be limited to Lego square blocks of plastic when what they need to solve their problems are round, fluid, and purpose built plastic widgets. How would you build a laptop casing using Lego? Well, you could, but it would look funny and not be very durable. With plastic, however, you could create just what you need.

    That’s what SharePoint should be for businesses, something that adapts to their needs, rather than something that instructs them about what their needs should be. Yeah, in some cases, Lego is just what you need, but if it’s not, it makes little sense to try to force a solution to be whatever you can build with Lego.

    An no, analogies should still not be taken literally.

    .b

  4. Bjørn,
    Thanks for the comment – I think this discussion is a good one (regardless of the differences in opinion).

    I’ve never mentioned anything about forcing a customer to “get used” to SharePoint, or telling them that the system itself will dictate how to solve their problems…rather, the system (SharePoint) is a platform on which to build a solution using a variety of means. Customization?…Yes. Visual Studio for advanced solutions that make up the greater solution?…Of course (when “needed” only). Use of some of the “default” things you get when the site is first created?…damn right (it would be irresponsible of me not to).

    Again, the main issue I have in what you original posted (and even in your comment here), is in the narrow scope in which you refer to what is “Out of the Box”…and to be honest, your definition is what differs from the rest of us because in yours, OOTB is the state of a site at the time it is created and nothing more, which is not very realistic (so please stop saying that we’re trying to redefine what OOTB is…you’re the one doing that). I might agree with you some if you’d change it to be “Default”, or “Pre-created”, but I’m sorry…OOTB has to include inherent functionality, which for some reason you seem to skip over in lieu of creating your own.

    “Businesses do not have to get used to what SharePoint offers out-of-the-box or what you can configure, regardless of whether you want to include configuring and web creation of lists, content types, columns, or whatever.”

    So, in your mind, the only solution is to crack open Visual Studio and start programming? Doesn’t really sound like you have the customers best interest in mind by automatically going straight for the most expensive (not just money, but “time” itself) option. As a programmer myself, I understand all too well the mentality of developers and how we tend to gravitate more toward a custom built solution…hell, there’s not much that can’t be done through code – I get that, really. But to make that that the “go-to” move just because you can?…ok, maybe if you have the lock on the business (think Sony and the “BetaMax”), or if the list of requirements strays so far from what SharePoint can do in its native form, then yes, looking at something outside the system for an answer then attempting to integrate it in “might” be a better option. But if that’s the only move you even consider…ever…then you’re doing a disservice to your customers.

    And yes, we each have our own opinions on the matter, and we can go back and forth on this over and over till “the cows come home”, but what it comes down to is this…a customer should be treated with the utmost care and respect, after all they are the ones paying us. If we approach the task of assisting them with a problem with a preconceived notion of what we “think” is best without ever even considering all available options, then we do them a disservice. If we’re unable, or “un-willing” to take advantage of the tools we have available simply because we “think” it won’t do the job, then our days are limited. Obviously, part of the process involves sitting down with the customer and discussing what is needed and how to best get to a solution to meet that need…and yes, many times the best approach may be completely custom, but that cannot be the only path each and every time…if it is, then why are you even using SharePoint in the first place? Wouldn’t you be better off going out and developing your own ECM system that you can provide to the masses? Sorry, but just because you can build a screwdriver doesn’t mean that you can’t also use the one you got from Sears…just doesn’t make sense.

    - Dessie

    • Bjørn says:

      Dessie,

      I think I’ll actually write a separate blog post as a follow-up, but if you’re assuming that whipping out Visual Studio and developing a solution is the most expensive option, you must have very bad or inexperienced developers. Yeah, I claim everyone else sucks, but frankly, I spend far less time creating a maintainable, reproducible, testable, upgradable, and versionable solution than I would trying to shoe-horn something out-of-the-box, regardless of how far you want to drag the out-of-the-box definition.

      You’re making the point yourself, in fact: it’s still out-of-the-box. That’s the problem – out-of-the-box is too limiting and better a showing how great SharePoint is than to solve specific client needs. Feel free to include fiddling with SPD, hacking away with jQuery, or screw your head up with XSL in the out-of-the-box definition.

      .b

      • Bjørn, I have to smile at this discussion, especially after seeing you hold up judges scorecards of “9.5″ multiple times for the no assembly solutions Laura and I provided at SPTechCon. You actually said that you had never seen some of the things we were working on and that it could be helpful in the future. What’s up with that? — Mark

  5. Bjørn,
    And again, I think you’re still missing the point of what I’m trying to say. Saying that going straight to a VS solution is the best and only way to best serve a customer is just plain wrong. Not being even willing to use the tools available is also wrong.

    You seem to be stuck on the notion that using anything OOTB (your definition or mine, doesn’t matter) is a waste of time and does nothing more than provide a fashion show for SharePoint…and again, this is in error. SharePoint has many tools in its default state that are more than adequate to deal with some needs of a customer…can it server them all?…no, of course not (and I never said that it could), but to discount them all just because you dont think they have any value at all…then I have to question your knowledge of the system…sorry to blatently put it that way, but there it is.

    And, since you seem to be digging for things…as I stated in my article, I dont consider jQuery to be OOTB. Not sure why you felt the need to mention that in the last paragraph of your comment, but attempting to skew some of what I’ve been saying in your favor isn’t going to work.

    - Dessie

  6. Bjørn says:

    Mark,

    I started writing on a response, but again find myself writing far more than I should, so I’ll include a response to your questions in a blog post.

    .b

  7. Xene says:

    I think that we forget the information worker, althoug my title now includes the words ‘Sharepoint’ because I happen to grasp what this thing is supposed to do – there are lot of slightly savvy users out there like me who create really incredible things – meet workers needs, change the fundamental way people work, increase efficiency and accuracy – EVERDAY – because of OOTB Sharepoint web parts. This platform is for everyone, it isn’t just for the high end application designers, but for the pee-on workers like I once was, this product makes a difference. To make a sweeping statement of any sort that claims OOTB has little to no value, I stand up and shout, “Oh yes it does!” it surely does for those of us who use it to meet our “lowly” needs. The Sharepoint customer is so diverse that to make a comment like OOTB makes no sense is too closed minded and I think you have an unrealistic view of who the audience really is out here using Sharepoint and changing thier worlds one OOTB web part at a time.

  8. Marleen says:

    I agree with Dessie and Xene, but I’d like to know what viewpoint Björn is talking fromin this.
    Is he talking from a developer perspective where he’s working on a project that has already accumulated “critical business mass” (there’s budget to hire a valuable developer resource)? Or is he on the business end like Xene?

    I totally agree with Xene that OotB Sharepoint functionality (as described by Dessie) is wat makes Information Worker life better. You can’t deny SP is a definite upgrade from Excel and Access?

    From a developer point-of-view I can relate to what Björn is saying but am also wondering how much of it has to do with his fluency with VS as opposed to his fluency with configuring Sharepoint. I know a lot of developers who transform XML in C# code just because they don’t (want to?)understand XSLT.
    I doubt you can out-code Xene in a configurable scenario show-down… :-)

    • Marleen,

      I work primarily as an architect and developer, to answer that question first.

      I don’t know where you, or anyone else for that matter, gets the idea that hiring a developer is more expensive. Comparisons, however, would quickly turn into a pissing contest (I can work faster than you, I can do more in an hour than you, and so on) and serves no purpose. I would claim, however, that I haven’t yet met an out-of-the-box proponent able to do something like this in less than 5 minutes:

      http://www.codefornuts.com/2010/04/building-wcf-rest-jquery-webpart-based.html

      What matters, though, is what the end solution looks like today, in six months, and in three years. Developers are trained to think about that and take care to ensure that a solution is maintainable, upgradable, flexible, and, perhaps most importantly, serves exactly the need that a business problem requires.

      There are far more situations and business problems that a developer will know how to handle and support than those you can imagine if all you’ve done is out-of-the-box configurations. Remember that the tools you use shapes your mind; if all you know how to use is a hammer, you tend to view every problem as a nail.

      Despite what seems to be the general conception, however, I’m not talking out-of-the-box components down. In fact, here’s a direct quote from the blog article that caused all this, the context being that clients often instruct me (and others) to use out-of-the-box as much as possible:
      “If using out-of-the-box functionality is a good idea, then it is far more likely that I’ll tell you why it is a good idea” [rather than the client telling me why it is a good idea]

      .b

    • Xene says:

      I like the vote of confidence, but let’s not get carried away! My expertise lies in how to creatively use this hammer as a jig for anything that comes my way. My environment is so conservative that they won’t let anyone outside of IT into the server domain, so despite begging, pleading, and fits, I still can’t get into Designer – but I’ve come to realize that I have a tremendous amount of power without it, and I can create solutions that any information worker can support long after I’m gone. Cheaper and quicker than a developer? Yeah, I think so. I work here, I know the process like the back of my hand, so I can crank out a few lists that talk to each other, send OOTB workflow to some people and get some things done. Is is perfect? Perhaps not, but considering the state of what the process was before, even without perfection I’ve blown their doors with the added efficiency. It would take an outside developer at least a few hours to understand the needs.

      Would I do the same for a public high profile site, NO WAY! Yes, in that scenario I think Bjorn’s got the leg up, OOTB probably does make sense for high profile situations, but for the information worker, OOTB is pretty impressive – especially since Admins aren’t ready to hand out thousands for me to improve my process, that is completely up to me!

  9. pat clark says:

    I was browsing for info on what exactly sharepoint “is”, and found your article and these comments. I have to agree with Bjorn in the following sense. What I’ve learned about Sharepoint seems to include a desire to claim that it solves a lot of END USER’s problems out of the box. This is done a lot during sales pitches and advertising. For example, many government agencies have bought sharepoint, equating “out of the box” with turnkey, or “that’s all I need to fix my problems”. It is misleading at best to claim that, from what I’ve read. Dessie, it seems like what you’re saying is Sharepoint provides a lot of OOTB capabilities for people configuring Sharepoint to tailor it for END USERS. This is WAY not the same IMHO as OOTB to end users. From a business perspective, there is a huge increase in cost to the business if he has to spend six months and dedicate a team of 10 folks and a subcontractor to “tailoring” the OOTB capabilities. So my “coming in cold” opinion to this discussion is that you are both right in a sense, that Sharepoint is NOT OOTB for a lot of end user apps, but it is very OOTB for a group needing to develop those apps without necessarily going to Visual Studio. From the number of customers I’ve seen/heard of that bought a lot of Sharepoint and then had it sit around doing nothing because they didn’t realize what they would have to shell out after they bought OOTB software, it appears to me that redefining OOTB for these two different meanings may lead to a sales boom for Microsoft, but it doesn’t give the buyers what they thought they were getting when they heard the term OOTB.

  10. Xene says:

    I wasn’t going to comment again on this topic, but I can’t help myself. Sharepoint definitions are tough to pin down. How can you definately define the end-user? An end-user in my mind is the person at the end of this ‘point of sharing’, the person using Sharepoint (and in most cases has never heard the word “Sharepoint”), but just knows where to get the information they need to get their job done. Recently I read a statistic published from IBM in the Gobal CIO study that stated as much as 30% of the information worker’s time is spent searching for information. Another study by Google states that number is 25%. So across my division if I save each of those 100+ workers 10% of that search time by providing them the resources they need to do their jobs efficiently with a click of a button, that is a tremendous measureable improvement. I do that OOTB, and any information worker with a little tenacity, ingenuity, and organization can do it too – how do you define that? Success!

    How do you define Sharepoint? your role with Sharepoint? What it can do for you? Educate some of your employees on how to use it and that definition will start to come into focus. Share your knowledge, and watch what grows from it. If you are only using Sharepoint to grow top level solutions with specialized apps, paying high $$ developers to build you your solutions, you are missing out on a huge portion of what Sharepoint is meant to do. It is a terrible waste to allow Sharepoint to sit idle, to not tap your area experts to record their knowledge to pass on to others. If you start it, even if the rest of them don’t catch on right away, they will. Efficiency is hard to hide for long. Flat out – Sharepoint = success. Success to end-workers in time savings, success to Admins who recognize it’s potential, and huge success to anyone embracing the technology and running with it!

    • pat clark says:

      Xene,
      I apologize in advance if you weren’t asking your questions of me, or if they were rhetorical questions. I agree with you that there are a lot of great capabilities that you can take and customize. My objection is that I have seen Sharepoint sold to decision makers as a product that is ready to go as-is, without any customization by developers OR “information workers”. This is a commonly used definition of “out of the box” for software. When the purchased Sharepoint software arrives, invoices are paid, and it’s installed, then it becomes apparent that only a significant “configuration project” (possibly preceded by a significant KA and requirements definition phase) is required before this is something that will help the enterprise. Redefining OOTB to mean a configurable toolkit/API for information workers instead of for what I term end users (line managers, financial people, proposal people, HR people, etc) seems to be confusing decision makers about what they need when they say they want Sharepoint.. I’m pretty sure when most companies buy Sharepoint, they don’t see information workers as the end users. Many of them ARE trying “to grow top level solutions with specialized apps”.

      • Xene says:

        My questions were mostly rheotorical, because I think, the definitions change for each organization. So then we get back to the heart of your original search, “What IS Sharepoint?” According to everyone’s favorite source of ‘authenticated’ information, Wikipedia states ” SharePoint is a collection of products and software elements that includes, among a growing selection of components, web browser-based collaboration functions, process management modules, search modules, and a document-management platform”

        You want to do all that with ‘plug it in and go?’ Yeah, you have to configure it, it’s not software, it’s a platform. Can any end-user participate in the process? Yes, they can. Does it add measureable value? Yes it does. Do you have to learn it in order to use it? Yes you do. Do you have help? You’re HERE!

      • pat clark says:

        “You want to do all that with ‘plug it in and go?’ ”

        I agree that’s unrealistic and from what little I know, will rarely happen. But when decision makers are told their organization will get the capabilities they want OOTB, this is what most of them THINK is going to happen. They DON’T think they are going to have to spend millions (or tens of millions!) more configuring it. OOTB seems to be redefined in some cases in the marketing of Sharepoint to give them the wrong impression (either accidentally or on purpose). Maybe I’m dealing with a different market, but there are a lot of large customers out there that are sitting on MANY sharepoint licenses they’ve bought, doing nothing with them except installing them. I think a primary reason for that is decision makers not understanding enough about what they’re buying. It doesn’t help if a term like OOTB that they think means, “I buy it and it works like Word” is overloaded to mean something different than they’re used to.

  11. Xene says:

    An unused Sharepoint license? What a sorry state. It’s hard to understand Sharepoint without actually using it. While you do have excellent capabilities OOTB, you must learn what they do to get the most out of them. Learning Word is no different. You’d be hard pressed to find someone opening Word, and being able to instantly use all the functionality on the first encounter.

    In our environment we have one architect/developer who builds our solutions. Millions to tens of millions to build solutions? Phew! I guess I should show him a little more appreciation!

  12. Sunjay says:

    i have a philosphy for SP development. C cubed. Configuration, Customisation and Coded. Configuration is using the existing tools available in SharePoint framework (OOTB includes the worklows ). Customisation is via SPD (dataview, data connections etc) XSLT Jquery also includes CEWP as Dessie mentioned. Coded. We follow the rule of 50:30:20. 80% of the work can be achieved without opening VS. BTW i also consider InfoPath as part of the 80% process.
    So when i present to client i explain, sure SP can do everthing but does that mean you want to do everything with it. NOT.


Notify me of comments to this article:


Speak and you will be heard.

We check comments hourly.
If you want a pic to show with your comment, go get a gravatar!