SharePoint University

Hey all! New member here. I'm not a developer, but I've been an active user in the testing and evaluation of our MOSS 2007 environment. Trouble is, we're running it all on one box. We have an organization of about 300, and we'd like to architect the system to support extranet linking (probably via EPOK).

 I'm trying to generate a proposal to our leadership to commit to moving SP into production mode, but don't have any idea of what costs to expect in terms of initial set up, annual costs, hardware needs, etc.

 Is there anyone out here that can point me in the right direction, or if you have experience in this size org, can provide me with costs associated with getting this off the ground?

Thanks

Yes, sure, no problem, just tell me in advance what a vehicle costs.

Seriously, I've worked with larger organizations (15,000+ users) that got a usable SP installation off the ground in less than 100 hours and I've seen far smaller (50 users) spend 1,500 hours getting a bare minimum up. The funny thing is that, of these two, the latter, smaller and more expensive solution, made more money (including expenses saved) than the larger one, dollar for dollar.

In any case, you need a lot more parameters to find out your cost. OOTB you can simply multiply the number of SP boxes with the licence cost, add a SQL server with licence, guesstimate operations overhead and put in a few hours to install the damn thing. Or you can implement a cure for cancer at the touch of a button which will be infinately more expensive. Your cost will be somewhere in between.

How much functionality do you need? What kind of data do you want published? What collaboration features do you want to utilize and how? Do you need custom design? Do you want to implement business processes as workflows? Do you put forms online for employees or partners to use? How many subsites are custom made? How many editors and publishers do you have and how much training do they need? What is the cost of initial failure? And even these questions only answer a small amount of the development and architecture information you need. You still need to calculate operational costs, internal cost (time taken to implement and develop, training, employee motivation), etc.

Undertaking a simple project may seem, well, simple, but what do you loose when your users don't like or are able to use what you have made? If you need to remake something better to get your users' attention, how much more do you need to spend on employee motivation? How will a badly designed installation impact IT and how much internal grudge will you get from putting undue stress on them?

Don't go overboard but realize that any 'I think that X hours should be enough' answers will only trick you. Get an architect with proven track record to evaluate for you, in the long run you will save a ton of money or even better, make a ton of money if that is your goal.

.b

I guess I set myself up for that one...  I was hoping that someone in this forum would be willing to share their actual cost figures and input variables (size, # sites/subsites, custom workflows, etc) , from which I could 'parameterize' to give my leadership a +/- 50% estimate.

thanks anyways.

I'd like to ask the  opposite question: How much money do you have? Getting this answer may be easier than you think. If you let me explain a few options.

Very few SharePoint installations with much success are simple and straight forward. Microsoft should have marketed SharePoint more as a platform than as a product. In that respect, answering what a SharePoint installation costs is about as simple as answering what a .Net application costs. And while you may probably be able to deduct some kind of estimate based on several input parameters you are more likely to forget something or change the scope when you start working more on the specifications.

That being said, there are several things you can do in order to control costs, which might help you along the way. Agile based development methodologies works on the premise that everything is more or less changing. Short development cycles, called iterations, deliver production ready features for every iteration, with each iteration having a pre-determined cost. Thus you focus on the primary deal-breaker functionality first so you have something you can use, and then you add features as long as you want to spend money. While this is a greatly simplified explanation the point is that you control your costs by adding features with fixed costs and when you stop you have something that can be put into production right away. During the development lifetime you will likely focus on the features that gets you the highest return first. The idea of Pareto diagrams is greatly beneficial in this process.

Let me take an example, a business process that costs the company $20,000 a year. Workflow-wise, costs are again difficult to predict. Using an agile approach you may define sub-features of a business process. So you can start by defining what the basics are, perhaps costing $20,000. Then you find that it reduces your cost for that business process 70% but you need better exception handling (non-intuitive forms, too many people get involved if certain things happen, etc).

You improve the workflow for another $20,000 yielding a further 20% cost reduction. Having achived 90% of a 'perfect' you spend another $10,000 on improving performance, giving you another 2% of the way. Reducing the cost further may be too expensive compared to the cost. You end up at 92% of perfect and have controlled your costs all the way. Even with 'only' a ~92% reduction in cost, you still have a pretty good return on investment over five years, with your development costs at $50,000 and business process cost still at $8,000 (8% of $100,000), totaling $58,000 versus the 'unoptimized' cost of $100,000.

In conclusion, getting a reliable estimate before any thorough analysis is close to impossible. You will likely find that controlling cost may be a better option. Your first order of business thus should be to get a budget by estimating costs reduction or profit increase. Estimate how fast a return-on-investment you need and then start looking at how you can get your optimalization going and what features of that optimization gives the greates return.

Oh, and by the way, if you find the numbers too big or too small for your project, just remove or add a few zeroes at the end before presenting to your boss :-)

.b

Thanks for the follow-up. As far as budget goes, I'm not too worried. Our organization (gov't) is spending $7+ Million on a clunky, over the top CRM system. They've spent $2.5 Million on a pretty-looking, but very limited "collaboration portal" capability.  I've presented SharePoint as a possible solution to take on many of the collaborative/document management issues we face.

 I was hoping to get a feel for a few companies' actual figures, so I can at least present some rudimentary data to my leadership. I'm not asking how much our implementation is going to cost, but with someone else's experience, I can draw some conclusions based on complexity and our lessons learned with our demo implementation.

If I could get information like: We have a 5 server farm, supporting 3 site collections (averaging 50 sites and subsites), with a user base of 500, and it cost us $X to design the system, $Y for the first year's development, and we're spending $Z per year to enhance and support it... I would've been perfectly happy. Does anyone maintain that type of data for these implementations?

Thanks again,

 ~S

Sorry for sounding dogdy about this. If I had an answer I thought would benefit you, based on several years of doing this, I would gladly give it to you. The parameters you give are not enough for me to base an estimate on. As I said, 50 users for $300,000 or 15,000 users for $20,000. Or somewhere in between.

Now, if you like I could help you in estimating costs based on your needs, but you need far more parameters rather than (vehicle analogy coming up) the number of miles the vehicle will travel and how many days of the year it needs to run. Based on these facts along you can end up with both an Indycar or a supertanker, but likely not what you really need.

.b