A: Fundamentally, SharePoint isn't really any different from any other projects. The factors you just read about apply equally well to your typical CRM, ERP, or other system rollout. But there are some important differences that you need to understand, if you don't want to end up in the dust bin of SharePoint history along with the many other unfortunate souls who jumped into this world without looking first.
One of the key pitfalls into which too many organizations fall can best be described with the old saying, "familiarity breeds contempt". SharePoint is after all just a .NET technology platform, based on C# and VB.NET, uses SQL Server as a backend, and Internet Information Services (IIS) for content delivery. It is an ASP.NET application at its core. This does not mean that you only need these hard technical skills for a successful SharePoint project. User training, project management, and managing expectations are still the key.
Many organizations jump into the SharePoint world knowing all these facts and with more than passing experience working with all of those components. As a result, you and your team may think: "This SharePoint thing is just another .NET app and as a result, I already know 99 percent of what I need to know to be successful. It's Microsoft after all, a technology vendor that we have been using for years."
Despite these familiar tools, it's vitally important to recognize that many of these routine processes to which you're accustomed, such as XCOPY deployments, client-server development, direct access to SQL via SQL statements and stored procedures, and even relying upon web.config edits for application configuration follow different patterns than the traditional ASP.NET development. This isn't to say that your team's ASP.NET knowledge has no value, but you need to take great care here. SharePoint does many things the same way but it does even more things differently, and the only way to really learn that is by getting your hands dirty, making some mistakes and growing your team's expertise step-by-step. Let's examine a real-world example that illustrates this point.
An insurance organization in the New York metro area contracted with a vendor to build a major new piece of business functionality on SharePoint that would enable their non-employee agents to do business via the Web. They selected a vendor with a proven track record of building similar .NET and ASP.NET-based applications. However, the vendor had not worked with SharePoint before. They ended up building a solution riddled with problems. To name three:
- They implemented a custom security interface that stood entirely "outside" of SharePoint. Instead of leveraging out of the box SharePoint security features, they developed a separate module that performed poorly and was bug-ridden and still is to this day.
- They blew up the project schedule with their branding tasks. They didn't understand how SharePoint branding worked. Branding was important in this extranet environment. Although their technical implementation was appropriate for a traditional ASP.NET application, it didn't take a number of core SharePoint facts into account. At the same time, they informed the marketing department that SharePoint could not support the business requirements for branding. They provided bad information and biased the marketing team against SharePoint entirely (not just for branding) for their entire engagement.
- They did not understand SharePoint's feature/solution architecture. They used old and familiar XCOPY techniques to deploy the solution from development to QA and finally to production; this is a manual and at times unpredictable process.
To this day, the failures have led to recurring problems that the company continues to manage. The site is unreliable and barely achieves 95 percent uptime. The techniques that the vendor company chose also prevented the site from being upgraded from SharePoint 2007 to SharePoint 2010. The downtime costs to the firm are almost USD $20,000 per hour and the site is unavailable during business hours, which is a major problem for the company.
None of this is to say that the vendor was incompetent. They made a number of architecture and technical decisions on the basis of their understanding of .NET technology. Viewed through that prism, their decisions were entirely logical and appropriate, albeit disastrously wrong. Therefore it is critical to understand the differences in SharePoint and not let your team fall into the same trap.
With SharePoint, you typically face a different problem with your end user community. You have probably seen your share of CRM and ERP rollouts over the years. So too has a slice of your end user community. They know what to expect with these and similar business systems. By now some of them have a good amount of hands-on experience with SharePoint, from previous organizations they have worked at. As a result, you have an end user population that may have certain "preconceived notions". Developers may think SharePoint is nothing particularly special and end users may have pigeon-holed the whole platform into a type of advanced network shared drive (the famous "s-drive"). Yet, much of what your team and your end users "know" is actually incomplete. For instance, SharePoint obviously offers far more capability than document management, but your end users may have put SharePoint into this pigeon hole. In some cases what your team "knows" is actually outright inaccurate.
Let's discuss an anti-pattern in some detail to illustrate all the previous discussions. An organization in the southern United States adopted SharePoint and rolled it out to their end user community. Like many organizations, the rollout was very shallow in nature and end users used SharePoint primarily for light document management. IT management, knowing that the platform was underutilized cast about for a business case to build a solution on SharePoint so that they could derive greater value from their SharePoint investment and ultimately settled upon a ticket management solution owned by the marketing and sales department. The goal was to automate how sales reps could order tickets on behalf of their customers and prospects from a pool of available tickets to local sports events (basketball, American football, and hockey).
They went through an appropriately rigorous requirements gathering and definition process for this surprisingly complex business process. IT's first mistake was to commit to delivering this solution on SharePoint with a deeply experienced .NET team who lacked experience with SharePoint (except as end users themselves). To top it off, they committed to an unrealistic delivery date. Of course, the delivery date didn't feel unrealistic at that time because the IT Team had delivered similar projects before just not in SharePoint.
To cut a long story short, the team did deliver a solution on SharePoint and in the promised timeline. However, they crafted a solution characterized by the following anti-patterns:
- They developed the entire user interface as standalone ASP.NET web parts that were integrated with SharePoint via Page Viewer web parts (which is shorthand for saying they were not really integrated with SharePoint at all).
- They leveraged SharePoint security for the mere purpose of identifying whether a user was part of a group (that is, a simple lookup). No other part of SharePoint security was used. They had to roll their own security model within this supposed SharePoint application.
- They did not follow the SharePoint solution framework and instead relied upon an XCOPY deployment strategy. They didn't realize this was an issue until they added a new web frontend to the farm and everything broke.
- They created a side database to store lookup tables and transactional information that could have been and probably should have been stored in SharePoint custom lists and document libraries.
- They created an elaborate set of
web.configmodifications that required production system downtime for even minor changes to the application.
In the end, they had created a "SharePoint" application that used a bare fraction of the SharePoint functionality. As if the list of issues they've had isn't enough, their upgrade to SharePoint 2010 was greatly complicated by these poor technical decisions. Luckily, they took the time to refactor the application to work in SharePoint 2010, and in the long run these problems were solved. As with the insurance company example discussed earlier, the decisions were reasonable and appropriate from a traditional .NET point of view. However, they were actually insufficient when it came to working with SharePoint specifically.