I need to see a demo of this thing, because MOSS for external facing sites has, in my experience, been a pretty ridiculous undertaking.

Microsoft has huge plans for SharePoint to break down the silos between the enterprise and the web (which includes the cloud). That’s right, even though their original intention for SharePoint was not for externally based websites, they have now embraced the Internet and are offering SharePoint 2010 as a single platform for your Intranet and Internet needs.

To help, they have added two new SKUs to SharePoint 2010:

* SharePoint for Internet Sites Standard: Rizzo told us that Microsoft was astounded by the adoption of SharePoint for Internet websites. They believed they had a great solution for high-end websites but at a price point that SMBs could take on. SharePoint for Internet Sites Standard is the standard on premise version.

* SharePoint Online for the Web: This is similar to SharePoint Online that exists today, but it’s for internet websites. It will have both dedicated and SaaS versions, with an emphasis on shared hosting to keep costs down for SMBs.

via SharePoint 2010 Breaks Down Silos Between Enterprise and the Web.

Meanwhile, MOSS was supposed to do that to begin with, no?

You’ll notice the lack of “Office” in the name of the product. That is not accidental or casual. I guess the Office Team at MS wasn’t that good at managing server software. Either that, or it’s just a paradigm shift for the Product Owners (how many must there be?).

SharePoint 2010 is supposed to be the real deal, as is Windows 7, but I have yet to be convinced or see enough to know if this is not just more of the same.

I am looking forward to my first SharePoint 2010 implementation. I really want to like that product but just cannot get behind MOSS and root for the likes of Alfresco. If all goes according to plan, I hope to be involved in implementing SharePoint 2010 in Q1 of 2010. Kinda early, but let’s see… I don’t know enough about it to assess that risk

Josh

I will write more about this later, but I am putting it up now as much (or more) as a reference for myself as a post that may help folks. MOSS 2007 is an improvement to SPS 2003 in regard to Compliance, and this is a very handy chart for those of you concerned with being compliant.

Support Open Source!  Or at least, please support Compliance…

Specifics on 508 Compliance can be found at the Section 508 Website

Specifics on W3C Compliance can be found at the W3C Website

It is interesting or at least noteworthy that the W3C standards and not the same as 508 Standards. The W3C standards are more rigorous, so the argument goes that if you follow their guidelines and CYA in regard to what they have put forth, you will be okay with 508. I will look into this further.

The following chart was lifted from: www.chandima.net with regrettable impunity:

Josh Milane

MIT Technical, Boston

This has been a challenge. I am involved with a 2 million dollar project that is under tremendous time constraints. The project itself is a MOSS (SharePoint 2007) project, and it is very stressful because of a variety of reasons. Let me enumerate some of them, if only to vent.

1. This is not really a SharePoint project. SharePoint vendors were solicited, came in, did a good job at convincing people, and maintained momentum. They did a great job. The company hiring them might not have done a great job.
2. The PMO in place at this organization was led by a person who did not know what a Use Case or Risk Assessment Document was. I did not know this when I came on as a consultant and was in fact told that there was a brand new methodology in place. I saw it, on paper. It looked like a cross between RUP and something custom (that I assumed was related to Health Care project milestones – since this is a Health Care company). I should have asked more questions, but the truth is, I like this organization and believe in what they do. Whatever the state of their PMO, I want to be involved.
3. A methodology on paper is very very VERY different from a methodology that has been accepted by the organization and is understood. We have this paper methodology, but there is very little understanding of the WHY.
4. This project involved building a system. A big System. The system should be capable of producing templatized “child” websites that share a common feature base but can have these features turned on/off and be able to receive totally custom modules when called for. It should also incorporate workflow management, document management, and CMS-related functionality. The team decided upon SharePoint 2007 before I came aboard. I did not know that
   • There was no official signoff on SharePoint
   • No Risk Assessment had been done
   • No Cost Analysis had been done
   • No forecasting had been done in terms of cost or staff or technology
   • Although meetings were taking place and money was being spent on this project, it has yet to be signed off on. There is no Project Charter. Not even a Statement of Work.
5. Development and Scoping of this system has been outsourced. The theory (the incorrect theory) was that it made sense to have MOSS specialists do the Requirements Documentation. The outsourced agency has spent 2 days on-site and come up with a “High-Level Requirements Document.” This document has cost the company $20k. It will reveal nothing we do not already know. The consulting company has ignored internal documentation regarding the “child sites” and has instead focused MOSS. Here is a typical conversation:

Us: “We want the breadcrumbs to reflect their MySite at the top level, and we want content to open within the body of the MySite page.”

Them: “Well, you can’t do it quite like that. Let me tell you how SharePoint does it, and why it’s really better this way…”

Us: “Okay, well… let’s run this past Design, Bill, Sarah, Ed, Development…”

So of course, this MOSS spec is being built by an outsourced agency while we run around internally and have meetings to see if we want them to do what they are already *doing*

There are several obvious problems here. Early on, I raised the issue of a Risk Assessment. I was told that we needed to wait until the system was scoped. I persisted, saying there were risks inherent in the technology and the engagement with the consultant as well as the definition of the project as a whole and the fact that there was no Project Charter, Communications Matrix, or even internal Project Code. T

Now, $60k has been spent on a SharePoint 2007 document. Not a Requirements Document. They have produced a proposal, and we have paid for it – which is fine and dandy, but it is a proposal for a MOSS solution, not a technical solution. It is not a PORTABLE Requirements Document. It is a very high level SharePoint blueprint.

The platform and child sites must be up and running by February.

What I have forgotten (and this is a bad thing) is that everything the consulting company stipulates that is dependant upon a specific techology begs an Assumption that needs to be documented. It seems like an awful lot of work has been created by going down this path. Not only is our documentation biased, it is unsupported and requires more documentation. Lots more documentation. Makes you ask, “Why do we do all this documentation?”

At some point, it is a matter of CYA, yes.

But documentation is supposed to be USEFUL. It is supposed to have UTILITY. If people create documents and the documents are not scrutinized, used to make business decisions, used to shape solutions, or used in some way, the PM/BA is wasting their time. This consulting company is creating a lot of wasted time. Time would be better spent doing real discovery, real Requirements Definition for the “child” sites, real analysis upon common features, the deltas between them, and real cost/benefit analysis. Earned Value Analysis. Present Cost Analysis. Common Sense Analysis. This all should have been done a long time ago, and yes – so what, it isnt done… do it now. However, there isn’t enough time. There isn’t enough time to do this project correctly. A major deliverable – the completed platform and child sites – is Feb 1, 2008. That is 6 months away.

So this is about damage control as much as it is about being hyper-aware of this road we have chosen and the obstacles, costs, and other gremlins that lie in wait.

This post was a venting session and I don’t expect people to get much value from it.

As I said, I am being utilized as a technical consultant on this project. I am to ensure that the PM is covering herself in regard to the technology aspects of the project.

We will be okay. It will just take a lot of hard work, intense conversations, and long nights of me writing dot notated documents and forcing people to sign off on them before the consultants build *anything*.

Josh Milane

MIT Technical, Boston

I was pleased to read about AccRepair, a product by New Hampshire-based HiSoftware. SharePoint 2007 is a powerful tool, but I am forever interested in adhering to standards and in compliance issues, 508-related and other.

Because there is so much compiling and dynamic page generation happening from within MOSS, the code can be less than crisp. For most people, this will not be an issue. It will not affect performance and it may affect Search Engine System indexing, but the extent to which it would be affected is not clear. The issue resonates most strongly with those who are working on government contracts, grants, or creating sites that positively must be accessable by the impaired.

The tool itself has been designed to work with SharePoint Designer, and contains OOTB 508, W3C, and other compliance tests for your MOSS sites.

This is great news, because it allows developers to include compliance testing in their normal QA processes. I have not seen the tool in action yet, and I do not know if it contains any knowledge base in regard to fixing whatever issues it may uncover, but the fact that it even pinpoints issues is very promising to me. If you have the chance to use the software, I would welcome your feedback and review.

This is a step in the right direction, and I am happy to see someone fill the need for a MOSS-oriented compliance tool that can be integrated within the development environment.

Best,

Josh Milane

MIT Technical, Boston

Right now there are SharePoint consultants working on a project with me. They were brought on because they are one of the few groups that have worked on a MOSS implementation of this size that didn’t sound as though they were going to waste the client’s money. Of course, with niche expertise comes big money. They are being paid $185/hour for four weeks and, as the old adage holds, you can price something at whatever people will pay

So far they seem very good and it is nice to see the MSFT approach to Requirements Gathering and the Project Define Phase. They ask all the right questions and dont waste time with the unimportant ones. I look forward to working with them more, especially in the weeks ahead as documentation is created.

In building a Requirements Document, it is very tempting to me to keep the platform itself – MOSS – in mind. Seeing as the consultants cost so much money it makes sense on one hand to try to make the Requirements somehow specific to their tool set.

But I resist, and work from the truth, upwards. It is a custom implementation, so there will be custom work and things will be eliminated from the Scope. The platform will not define the scope. This project is too important to the organization to be straitjacketed by software.

And so we are painstakingly going through Requirements, starting from the kickoff meeting, and we are doing two sets of Requirements Documents. It is an experiment. I want to see where the deltas are and how it works out. I will let you know.

And that clock is ticking at more than $3 a minute.

It is interesting, and I will post whatever I think you might want to know about the unique factors in a MOSS implementation of the size I am working on. It will spawn 5 or 6 public-facing sites with a few thousand members each (and they will all have to be migrated to the new site). It will also attempt to organize document and workflow management at an organization without any.

If this winds up being anything like implementations I have participated in before, one of the really tough pieces (the toughest piece?) of this effort will be in getting people to use the new technology. Thankfully, it is a MSFT office so they will likely enjoy SharePoint and it’s Excel Services, document workflow, etc. It will, however take time. That is one thing that is not OOTB with SharePoint Server 2007: enthusiasm.

Almost a million dollars is being spent on this project, and I am trying to manage the technology end on my own. I am not really a SharePoint guy. Guess I will have to become one. Truthfully, I am impressed so far. It seems like a super-robust product. Of course, I am a bit concerned about SEO. MOSS builds pages in a way that might not be conducive to what I would consider proper SEO. I am reseaching this, and if you have any experience in that regard, shoot me a note!

Stay tuned.

Josh Milane

MIT Technical, Boston