Five suggestions for office building a SharePoint project

In the past few months, in fact, for several years, there has been a clear divergence of views among corporate organizations about SharePoint. Some companies think SharePoint is another product produced by Microsoft that they can buy and install in their current system, while others think SharePoint is a strategic platform that can be built and will gain commercial benefits from it.

Sharepoint-Products

In theory, SharePoint is a product. Developed by Microsoft and must be paid to buy. Yes, you can simply buy a serial number, insert a CD into the server, and then be amazed at the point where you can build a SharePoint server. He may even have a very good function, perhaps enough to meet your collaboration and even document (management) needs. In most enterprises that adopt such schemes, there are often two kinds of phenomena. First, there is no proper configuration sharepoint,sharepoint is just a glorified shared drive expansion; second, the enterprise simply does not see any benefits in the SharePoint system, and SharePoint is often not accepted. I'm not saying that all clients will be like this, but according to my experience, there are more clients than you can imagine.

Sharepoint-Platform

This is when you have a deep understanding of SharePoint (you will think) that even though SharePoint is sold like a product, it is actually a platform that requires some kind of love and care so that he will run as you wish. When the enterprise takes the time and effort to design, develop, and deploy the SharePoint system so that he has all the predefined content types and a good classification system, SharePoint is properly adopted and quickly becomes a key system for the enterprise. Now we know that SharePoint doesn't always work this way, but how do you make sure that SharePoint runs like this?

In this article, I do not intend to discuss this issue, because there have been many articles to discuss this issue. However, what I want to write is a few steps to be performed for an outstanding SharePoint project:

Get experts involved

Promote the platform within the company

Let Business participate

Set the desired effect

Test and test again

Get experts involved

This is when you call me and say, Liam, come and help me!! It's just a joke, but it may be expensive for some people to design, develop, and deploy SharePoint as a full-time job, but that will speed up your deployment from within. SharePoint experts have experience in this area, such as getting T-Shirt, etc. (got the T-Shirt etc, do not know whether to acquire the meaning of a certain identity), they often know relative to one method another method of potential pitfalls. My advice is to involve people who may be helpful in some areas, not to let them do all the work, just to let them help you expand your business to ensure that there is nothing wrong with the initial design phase.

Promote the platform in the company

When Microsoft developed a new product, it was part of its lifecycle, perhaps through a Technology Adoption Program (TAP), rapid deployment Plan (RDP), Events, Tech-ed Sessions, webcasts, and a large number of articles. Why do you think Microsoft is doing this?

This is simply to get feedback on new technologies and to get people excited about newly developed technologies. I think of vista,office and exchange events, and think about how excited Microsoft is going to launch his fashionable new product. This is what we should do when we deploy SharePoint systems within the enterprise. I don't mean to say that we should start doing what we described earlier, because these are a little too much, and they cost a bit of money. But to get your business to buy your account, you need to make your business feel excited about what you are doing. If SharePoint is built by the IT department and they choose to use SharePoint as a product, most users will not like it. This concept has to change, yes, SharePoint may be a choice made by the IT department, but it has to be convinced that the whole company is their choice because they can't have it (SharePoint system).

Let Business participate

With the promotion (System), let the enterprise participate in is the key to success. As a SharePoint consultant, the success of the project really is based on my ability to capture the needs of the business and then provide something that they want to use. If companies never get involved, then I'm almost guessing the needs of the business and tell them you need to do what I say! It sounds like a dictator. J

As part of my work, I was responsible for designing and conducting meetings when there were significant differences in the ratio of infrastructure work to enterprise analysis. In a common solution, architecture and infrastructure design can be quickly resolved, but obtaining business requirements for human resources is two times that long. The key here is to get them involved in the usability and categorization of the system (design) so that you will succeed. Think like an enterprise user.

Question: "In order to get content, I already have 10 systems that need to be accessed, why do I have to visit one more time?"

Answer: "Because this is the presentation layer for all systems, and it also provides complete lifecycle management for documents and content."

Set the desired effect

This is as important as acquiring demand. Setting the desired effect can result in a project or a project. A lot of times I watch the system build, the demo then received a comment like this, "on the system you will be able to get a read-only view of your SAP schedule", resulting in a project failure because the enterprise found that they did not have an enterprise license number (translator: This should refer to Moss's business license number, Because the BDC requires moss, it cannot be integrated with business data catalogs. I know it sounds ridiculous, but it's true.

Realistically, if you're going to provide a timesheet system that's built on SharePoint, the system can be automatically populated with payroll-Payroll servers and project servers, so do your best. If you want to achieve this, then in fact please do not make any promises or even mention it, lest business users will hear something and serve as truth. Set the desired effect by decomposing it into several steps, and then exposing it to the enterprise by all means to let them know. In a project I have worked on, this approach (to set the desired effect) is not only decomposed into multiple steps based on time, but also broken down into a paragraph by function in each step. This allows the project's management team or yourself to manage the deployment within a smaller access. This will make the deployment more successful, and the enterprise will have a clear roadmap for when and what functionality is to be released.

Test and test again

This step is one of the most important steps for me. You complete your system, everything is well spent, and ready to deploy to the enterprise in the morning of Monday. The Monday breakfast arrived as scheduled, and in the first few hours everything was fine, and suddenly there was an error in the event log, the user was denied access, or the system reacted slowly. So you think, if we've been tested in full scope, then I've found these problems and how to solve them now. In many projects, I have found that there are factors that are not considered in tests or stress tests anywhere. User Acceptance Testing (UT) always seems to be complete, but he is faced with a handful of selected users, not all of the users in the company. In order to ensure that your solution can be applied to a wide range and that your new system does not have a bottleneck, it needs to be tested correctly.

These steps are not precise science for building SharePoint; I simply write this to share what I've experienced and share what works well when you decide to build SharePoint for your business. If you have anything you want to add, or disagree with any of them, please let me know in the comments.