So the word CHANGE is a word that translates straight to LOST REVENUE in the mindset of executives. I have to say, yep in most cases this can be a painful part of your governance. I do have to say though this can also be a point where you can start saving money, actually streamlining process, and in the end make money…yes I said make money.
Now if you are asking me to go down the process of preaching one change method versus another, no way. I don’t want to make my Change Management guys and gals I work with agree by putting one of them above the other.
Let’s take this post helping you define and explain guidelines for getting your change process started.
Change for SharePoint
The purpose of change management is to ensure that SharePoint changes are appropriately assessed for both business and technical risks, and to maintain the stability and reliability of SharePoint by reviewing, tracking, and communicating the proposed changes.
Now this is not the vehicle through which Strategic Decisions are made, that is up to the SharePoint Strategy Team (who we talked about in the Roles and Responsibilities), is should be the method used to minimize risk of service outages during implementation, as assist the Strategy Team implement the grand decisions they have made.
Types of Change for SharePoint
So first I like to define what CHANGE means. for a lot of folks this can actually be a point of resistance. Get use to the word RESISTANCE, you will experience it a lot in change management around SharePoint. Now there is different types of change, so I like to define at least two, there can be more, but two a good start.
What Is Change: ‘Change’ is defined as an action that results in altering the SharePoint features or services.
What is Emergency Change: ‘Change’ that is required to restore an application or return a piece of infrastructure to production due to (….act of god, failure, disaster, PEBKAC….) I do like to list out a few, but you will need to go to your DR documentation for this.
No DR to reference for what an Emergency is, sorry we are not talking about that hear. Maybe later.
Criteria for Change
So you have helped your fellow man understand what Change means…great. Now we have to define when that can come ask for change. Not all changes to SharePoint must follow the change management process. For example: ‘changes to the layout of individual sites within a collaboration portal do not require a request for change (RFC)’
RFC is Request For Change, a formal request process using a form, workflows, approvals, and signoffs. I am a fan of InfoPath, and doing this within SharePoint…Let SharePoint govern SharePoint.
I like to break this into two tiers: Small Change, and Med-Large Change. Both of these will follow the RFC process.
Modify or create new SharePoint templates and master pages Modify the SharePoint look and feel (branding) Develop new web parts Develop custom solutions on the SharePoint platform Deploy third-party solutions on the SharePoint platform
Impacted Users are enterprise wide Number of Users exceeds 500 External Users are directly (visibly) impacted Critical Business Applications or Interfaces are impacted Significant Financial Impact is possible
So I did not cover addressing Resisters in the Change Process, I will try and tackle that in the next post. Say 10 points to tackle.
So the Change Management process should be a extension of your best practice change management process already. The big thing to keep in mind is all the moving parts in SharePoint. Now this will be a series of posts in the next few days, just to cover change…it is a bugger and can cause a lot of folks to stumble. SharePoint is a diverse system with a significant amount of challenges. So change needs to address this. From Publishing process, Internets, Farms, Custom Code, Configuration, DR, Backups, Security, and future Customizations. Get ready for a ride, this should be fun, just remember that a governance is a living document/process and thus will likely also change your IT process.