Stop gathering business requirements for SharePoint Intranet!

I see this happening over and over and can’t resist the urge to speak up again on the topic. I see many companies and even potential clients of mine developing 50-page business requirements documents for SharePoint, where they list every single wish list item, feature, and functionality they want to see in their new Intranet, from the number of sites to the number of document libraries, content types, metadata columns, views, and workflows. With this post, which should not take more than 5 minutes to read, I hope I can save organizations looking to document their business requirements months of lost time and productivity,  money, and disappointment down the road. Let me explain.

You don’t gather business requirements for other software

Do you gather requirements for other software, like DropBox, Word or Excel? Probably not. So why do you need to document requirements for SharePoint? Especially, considering the fact that you already own the software? It is like telling an airline that you would like to fly in their airplane in your own couch with a wine bar by your side. Sorry to break the news to you, honey, but you will be seating between a crying baby and a guy that smells, so suck up and enjoy your flight!

We have already created a business requirements document. What do we do with it now?

Congratulations on wasting company money! Follow these 5 easy steps to mitigate:

1. Print the document
2. Staple all the pages together
3. Go to your boss’s office
4. Wait until you have his or her attention
5. Throw the document into their trash bin (or shred), whatever method you prefer

Business Requirements document becomes obsolete the minute it is written

We live in a fast-paced world and SharePoint is no exception. SharePoint literally changes by the minute, and Microsoft releases new apps and collaboration tools with a lightning speed. That means that many of your assumptions might not be valid by the time you start implementation, and your business requirements document has a very limited shelf life. Case in point: You put all the energy into documenting custom layout and functionality of project team sites but maybe all you need is a Microsoft Team, Planner and an Office 365 Group.

Education first!

Too many times, I see these business requirements documents being created by users who have very little experience with SharePoint. In fact, they either used SharePoint at the previous job, like 10 years ago or worse, never used it at all. In order for users to come up with great ideas and requirements, they must be familiar with what SharePoint is, what it can do and what its major capabilities are. I have seen many instances where my clients would spend thousands of dollars (with the help of 3rd party consultants) to document the whole taxonomy, all the possible content types, and metadata, without realizing what all these things mean and what the end user experience will be like once implemented.

Phased approach

I blogged about this many times before, the only way to implement SharePoint Intranet successfully is by utilizing phased approach. That means, breaking the implementation into multiple phases and implementing 1 (one) phase at a time. This makes implementation happen faster, reduces time to Go-Live and increases the chances of successful user adoption. When I implement SharePoint for my clients, for example, I use a 7-phase approach to SharePoint implementation. You can read about it here.

Implement SharePoint using Agile, not Waterfall

Related to the above topic, Business Requirements document implies that you are using Waterfall approach to manage your implementation. This does not play well with SharePoint implementation. To assure employee engagement and participation, SharePoint shall be implemented using Agile principle. Introduce some basic functionality early on, let your users adjust and adopt and then gradually introduce more complicated features, functionality, workflows, etc. down the road.

Cost and duration

The size of the business requirements document is directly proportional to the cost and duration of your SharePoint implementation. The bigger the document, the more expensive and more time-consuming your implementation will be (think months, if not years). Just to give you a sense for comparison purposes, when I implement Intranet portal for my clients, duration of a project is usually 4-6 weeks max. How big is the business requirements document when I do this for my clients, you may ask? It does not exist.