“If at first you don’t succeed, then skydiving is not for you.” (and so is MOSS)
 

The above quote is true for skydiving and some other extreme sports as is valid for enterprise SharePoint projects.  I have been involved in a lot of serious enterprise-level MOSS-based transformation projects from a small internetsite POC to a HUMONGOUS project which had intranet, applications, integration and BI facets. Offcourse I have seen a number of talented teams struggling with MOSS projects. More often than not that is the reason we (or other consultants like us) get invited to help, ya?

It does hurt me when I hear from CIOs and IT managers about how much time and money they spent “trying” to do something with MOSS.

One of my customers spent one and half years and nearly 250k in trying to create a small extranet portal on MOSS. They hired a developer who was not skilled in MOSS but knew .NET and allowed him to learn on the job. Voila, they ended up with a system which could not be deployed and which did not meet the requirements 100%.

One of our other customers tried “in-house” approach with inhouse skills for more than a year with a large MOSS farm and ended up with an unstable platform after all this time. Money spent was eaily around 500k when taken into all hardware, software, people salaries etc.

Some other customers, burnt by hardships, have lowered their bar and are just content with the scrappy out-of-the-box intranet.

It does hurt, doesnt it, to see and hear about these self-inflicted wounds by these companies. Yes, they do fall prey to some sales pitch that MOSS is so easy that even a monkey can do it. And what happens when they try it. They wish they did not have to hand a hammer to a monkey.

Would the same companies deal with  a SAP project the same way? Would they deal with a Tibco B2B project the same way? I bet not. Then why with MOSS, they make these decisions and get hurt?

I really think that IT and business decision-makers should start taking MOSS projects seriously and stop the “trial and error” approach. MOSS just like any other middleware is as complex and requires a skilled hand. Why waste the time and money in trying to do “something” with MOSS? Why “somehow” implement an OOTB MOSS feature set and not achieve an optimum ROI? and then complain about MOSS?

When properly architected and designed, MOSS can help you achieve optimum ROI from your investments. We are helping our customers with their first entry in SOA enabled enterprise clouds by using MOSS. We are using MOSS for rapid application development for their business apps. We are creating an integrated platform on MOSS which delivers consistent and controlled content to their internet,intranet and extranet properties. We are creating business LOB systems on MOSS. Thus we are helping our customers reap optimum ROI from their investments.

So I say, when in doubt, seek wisdom. Dont waste time and money with experimentation on MOSS. It is not worth it. More often than not, the next guy ends up cleaning up mess created by the first guy. Thus wasting more time and money for you. That is what I am currently doing at my current project.

MOSS just like SAP or Sieble, requires specialised skillset and you should seek it if you dont have it available inhouse. It requires same SDLC considerations, architecture thought and planning game.

So do yourself a favour and seek help when  you need.