We've discussed the importance of proper planning, change management strategies and providing end user training in order to ensure a successful SharePoint implementation. While it is definitely good to have a plan or strategy in place for any software project, with the fast pace of change you shouldn't wait until you have the entire project complete before rolling out anything. If you wait too long to deliver something, users will get impatient and the project will lose momentum.
Here are some proven ways that you can get new functionality out to users quickly:
1. Pick Your Primary Area of Focus and Start There
A lot of companies choose to build out their Human Resources area first because that will affect the most users and get them to start using it immediately. Face it -- every user is interested in requesting time off. Something simple like a time off request form and approval workflow will get every user onto your site eventually (unless they never take vacation). Users will start to become familiar with the interface, then as you roll out additional functionality, it will seem commonplace to them.
I've also seen companies choose a couple teams or departments to pilot a SharePoint collaboration site for a few months before making them available to the rest of the company. These early adopters can also act as SharePoint subject matter experts when the rest of the company starts using it.
2. Concentrate on Quick Wins
You'll want to choose the small things that are very simple to implement, yet will also have a big impact. The vacation request form mentioned above would fit that bill.
At one company I worked for, we moved our old online classified ads solution that was built using ColdFusion and a SQL database into SharePoint. We used a basic SharePoint announcements list and a lookup list contained the different ad categories. While it wasn't necessarily a work-related solution, it was super quick to implement, and it was something that almost every employee glanced at daily, so it also got people into the SharePoint site.
3. Keep It Simple -- Don't Over Architect
While adding all the bells and whistles might make your SharePoint site the greatest thing since sliced bread, it likely won't provide enough business value to justify the extra time and expense to implement.
I see this a lot with workflows. Companies want to account for every possible scenario and create complex routing paths that are sure to get messy. Follow the 80/20 rule here. Build your workflows to handle 80 percent of the cases that you will see. If you must do a little bit of manual processing for the other 20 percent, that's fine. If that 20 percent then continues to grow and become a much larger chunk of your transactions, then modify the workflow at that time to accommodate.
The reason I say this is because for many companies it is already hard to extrapolate the requirements for their business processes. They usually don't know exactly what they want because the process has never been automated before. By starting out small they can get a feel for how the process works, then add functionality later to accommodate more needs once they know what those needs are.
4. Roll Out SharePoint Sites or Functionality in Small, Predictable, Iterative Chunks
You don't need to adhere to a strict agile approach, however you should create a plan where you will roll out new functionality on a monthly or quarterly basis, publish that plan and stick to it. You could create a rollout calendar in SharePoint so users can easily see what exciting new functionality awaits them and when they can expect to see it.
Again, if you wait until you get your entire Intranet built in SharePoint before rolling out anything, users will have nothing to work with for several months.
Once you've moved each bit of functionality into SharePoint, don’t forget to remove access or delete the old way of doing the same thing. If the only place a user can find their team's financial reports or the company's benefits documents is in SharePoint then they won't be tempted to continue doing it the old way, which in these cases might be to go to the shared drive.
The same is true for manual processes. If the old way to request time off was to email Suzy and she'd take care of it, then Suzy must be taught to be firm and redirect the users to the SharePoint form.