A: Should you expect the solution to be a pilot or something that goes into production and stays in production for a year or longer? This is a key question that should be asked.
Project scope is an early key indicator that predicts the success of your first project. Consider the risks of an overly narrow project scope. Even if you succeeded in hitting project milestones and blow end user expectations off the roof, what have you really accomplished? It may be an important political victory, but this book isn't about political victories. You could be setting a bad precedent for future projects by having set unrealistically high expectations. This has happened before when a project team configured a SharePoint document library with a few content types and list views. It met the needs of the target business user group brilliantly. However, the project team didn't gain any great new understanding about SharePoint. When they took on their next project that involved using event receivers to populate intelligent default values on a list and communicate to an external web service, which ironically was of less business value than the pilot, the project team struggled and made a wreck of the schedule timeline. It wasn't a fatal blow, but it did create a negative experience and understanding of SharePoint.
Of course, you must avoid the opposite too. Don't select a major project with far-reaching implications for the business. You may never succeed in the first place.
When you think about scope, you need to think in both business and technical terms.
To begin, business scope for a SharePoint project is no different from business scope for any other project. Ultimately business value must be in the solution. The same principles apply here as they do to any other business solution you would have your team implement. However, the business scope discussion is somewhat different with SharePoint and is more about strategy than putting a box around the solution. Your first SharePoint project's scope should follow these three principles:
- Target a small number of users for the initial project: This will tend to limit the technical implementation, which is your greatest source of risk in your first project. It also allows you to foster a great working relationship with the team, which leads to the next principle.
- Select flexible business units: The first project will be rocky. Your team may give mixed signals to the end users as they could be brimming with confidence (recall that SharePoint is "just a .NET application"). Beyond all of the usual miscommunications and not-quite-on-the-same-page moments any project suffers, you also need to deal with a new technology. If your end user business units aren't flexible, they may not prove to be supportive, as described in the next principle.
- Do everything you can to ensure that your end user business unit is a good champion on your behalf: So ideally this business unit should have a good working relationship with IT and yourself.
By defining an appropriately sized business scope, you've significantly reduced the risk you take on with your first SharePoint project. You can further reduce the risks by narrowing the technical scope.
The ideal technical scope is somewhere between too simple and too complex. That's easy to say, but how do you know in advance that you're going down the middle path? Let's consider the four most common types of SharePoint customizations that require programming:
- Event receivers: These programs run when end users upload new documents, change document metadata, or delete documents. They do the same for list items (for example, SharePoint calendar lists) except that they execute when the user creates, updates, or deletes a list item.
- Timer jobs: Similar to Unix cron jobs, Windows Services, and Windows scheduled tasks, a SharePoint timer job executes code on a periodic basis. The SharePoint platform installs dozens of timer jobs and you can create your own.
- Custom web parts: These are small programs that follow a handful of development rules. Web parts do not run on their own, but rather in the context of a SharePoint web page (in fact, web parts are a broader .NET artifact, but this discussion is confined to SharePoint for obvious reasons). As with timer jobs, SharePoint installs dozens of web parts. You can also create your own.
- Visual Studio workflow: SharePoint is based upon Microsoft .NET framework version 3.5, which includes a workflow engine, and you can leverage this engine in SharePoint.
Beyond coding, SharePoint offers several other customization options that lie somewhere in between coding and what your typical power user would do:
- Workflows using SharePoint Designer: Microsoft provides a friendly end user interface to .NET's workflow engine by way of a wizard-style GUI. "Friendly" is in the eye of the beholder and it's not unusual, especially in a SharePoint 2010 world, for developers to create workflow solutions using SharePoint Designer workflow capabilities.
- SharePoint Designer for customizing the UI.
- InfoPath for custom forms, often linked to workflow processes.
Tip
Lastly, companies take advantage of a very common use case, jQuery. jQuery is a JavaScript library that simplifies using JavaScript in a wide array of web development contexts, including SharePoint.
Bottom line: focus on one web part, one event receiver, or one event receiver and one timer job. Visual studio Workflow Foundation (WF) may not be a good first choice, especially a state machine WF (developers are always wanting to create state machine WFs).
As we wrap up this section, it's important to point out a peculiar problem that SharePoint may create. Similar to the Sirens whose songs lured Greek sailors to their deaths, SharePoint has its own peculiar song that seems to drive SharePoint developers, business analysts, and even ordinarily sober book authors to over-engineer solutions for their end users. Let's consider a real-world example.
A client described a set of requirements for a Legal and Medical Review (LMR) process. The SharePoint developer and his team worked with the end users using traditional requirements gathering techniques and then designed a solution to meet the requirements using SharePoint. The design was beautiful. It automated every action down to the last click of the mouse. It had branding, complex workflows, personalized e-mail notifications, and practically made coffee for you. It was a souped-up Cadillac with a gold plate and everything else you could think of. The effort it took to deliver the solution came to about 1,800 billable hours. The client balked at the hefty price tag and asked, "Why is this one business process going to cost me more to develop than it cost me to buy SharePoint in the first place?" It was a sobering moment and the team went back to the drawing board, producing an acceptable design that was 80 percent less effort to implement. This reduced effort design didn't meet 100 percent of the end users' requirements, but it met close to 90 percent of them and was far simpler than the original design. With the revised design, the tool could be built faster with less risk, be maintained easier and with less cost, and upgraded to the newest version of SharePoint with much less hassle than the original design. The moral of the story is that just because SharePoint can be extended in myriad ways using a host of technical means does not mean that it should be. This is true, of course, for any other kind of application in the world. However, SharePoint seems to suck architects and developers into an over-engineering mindset. Be aware of the pull and resist it.
There is often focus on end user training but technical training is also the key, particularly for .NET developers. For example, many experienced techies are shocked to learn that there is no use case for direct database reads, let alone updates, to the SharePoint SQL database backend; it is always brokered through the SharePoint API layer. Knowing this in advance will help you plan your first project carefully.