There are probably hundreds of books, thousands of internet discussions, endless forums on social media that talk about Waterfall vs. Agile Methodologies and pros and cons of each project management methodology. In the context of SharePoint Implementation, given my vast experience in the fields of SharePoint and Project Management (I am PMP certified), I can provide the following advice:
Do not implement SharePoint using Waterfall methodology. If you do, you will fail.
The whole idea around Waterfall approach is that it is a pretty rigid process, with sequential phases, phase gates and tight management controls from start to finish. Changes (a.k.a. change requests) are heavily “penalized” with consequences to cost, scope or schedule. This methodology worked “well” in the 70’s, 80’s and 90’s because things were run mostly by large, bureaucratic corporations.
With the arrival of internet, small and innovative start-ups, things started to change. Time to market, quality, and cost became key factors that determined the success of a company. That’s when Agile methodology was embraced and became quite popular as of late. It is efficient, transparent and “easy to maneuver”. It also prevents “shadow” project management. In addition, Agile appeals a lot to the current culture we live in: we want everything NOW! We are hungry for information, progress and something new.
If you think about this, Agile Methodology also goes hand in hand with the whole concept of SharePoint Online / Office 365. With SharePoint Online as a tool, there is no “big upgrade” day or anything like that. Changes are transparent to the users and happen all the time in the “cloud”. You can literally wake up one day and find a completely new feature, functionality or setting working differently in SharePoint.
Coming back to the blog post headline, in my opinion, Waterfall approach must never be used when implementing SharePoint in the organization. Below is a diagram that depicts simple, yet very powerful methodology I have been using to roll out SharePoint (SharePoint sites) to my clients.
The core idea is that there is little distinction between the different phases of the project. Immediately after I get initial requirements/wish list from users, I go in and create the actual sites, document libraries, metadata and views, right in live (production) environment. Users get to access the sites and test them out soon after providing initial requirements to me. So they have a chance to “play” with sites, upload documents, test out metadata and search capabilities. Here is another image that depicts the process.
The above process and methodology ensures quickest “time to market”, happy user base and refined/polished SharePoint sites which are built with “users in mind”.