This article, split into three blogs, goes into detail on describing Managing Value for SharePoint, and the basis of the two key tools to Managing Value. To help you understand the concepts, I will be drawing on real life projects and showing how using the techniques described was able to determine the best solution.
With every SharePoint solution being delivered, there is comes a change management effort that requires not only organizational, but also behavioural change on the part of the participants. You can set up the finest SharePoint solution on the planet, but if people do not take to the SharePoint solution, nothing will change and the effort will be lost.
“To get a horse to drink water, you make the horse thirsty”
Successful adoption of any SharePoint solution enables users with self determination. Irrespective of user task, or position, self determination needs three factors, which is competence, relatedness and autonomy. These combined produces motivation. And, when you have self determined people, support requirements are properly defined, people understand how the solution makes their tasks more productive, training strategies are easier to develop and sustain. A key person requirement, which is not technical, is the SharePoint Champion; whose objective is to foster self-determination amongs their peers; a person elected to help drive adoption of SharePoint solutions, elected by the business, and for the business.
I wrote a pretty detailed piece on the topic of SharePoint Champion being a vital role, because I think it is so important to provide successful service delivery of SharePoint solutions. To see this, check out on Microsoft TechNet Newsletters article posted here:
http://blogs.technet.com/b/uktechnet/archive/2013/07/29/sharepoint-champions-are-vital-roles.aspx
Hope you find the article useful!
I was asked to describe how a small team, who has never seen SharePoint or Project before, could take on a SharePoint look at Project Management tools focused Information Worker level. By doing this, a Project Management solution could be created whereby solving collaboration and information challenges. This article describes how that can be done to enhance project team efforts, enable project information can be centralised and managed using SharePoint 2013 using built in features only. This is in order to help solve Delivery Manager issues concerning planning progress, reporting progress and auditing progress.
Take control of user adoption and governance processes in your next SharePoint 2013 deployment—whether it’s a specific site or complete farm solution. In this book, you’ll learn proven techniques and methods that will help you better manage the entire project lifecycle concerning SharePoint implementation from a practical standpoint.
Discover how to:
Go here to get the book and find out more information.
As part of my book, SharePoint 2013 User Adoption Planning and Governance, below is a SharePoint Delivery Detail Plan. This plan encompasses the tasks required to deliver a SharePoint solution from Envision through to User Adoption.
I’m focused on SharePoint, having been involved since SharePoint 2003 hit the streets. All of my books are dedicated to SharePoint Implementation, Service, Support, Automation and SharePoint teaching. Click any of the links below to find out more about the books I have published:
Managing and Implementing SharePoint® 2010 Projects
MOS 2010 Study Guide for Microsoft® Office SharePoint®
MOS 2010 Study Guide for Microsoft® Word Expert, Excel® Expert, Access®, and SharePoint®
Microsoft® SharePoint® 2013: Planning for Adoption and Governance
Additionally, I was technical author for the following two books:
MOS 2013 Study Guide for Microsoft Office SharePoint
Creating and Implementing Microsoft SharePoint 2010 Real-World Projects
I am editor for the Software Best Practice Development Journal here.
Time for a service delivery article, looking at working with external SharePoint agencies in a SharePoint environment in BAU…
If you are operating and managing SharePoint environments for your clients, you may find that there is a business requirement for enhancements or modifications to something to take place which would alter your controlled SharePoint environment. This business requirement may be one where there is a call for the intended work to be carried out by utilising services from an external ‘SharePoint’ on a sub-contracted basis.
The ten key steps required to successfully deliver SharePoint to an organisation, is also available as a map on this link: https://www.geoffevelyn.com/mmap/spimpl/spimpl.html
SharePoint governance is not a hardware, software, or people resource solution. It is an organizational strategy and methodology for documenting and implementing business rules and controls related to your client’s data. It brings cross-functional teams together to identify data issues impacting the company or organization.
Hi there, time for another blog from the evangelical Geoff marching into the land of SharePoint Capacity Planning. Start with an example if I may. Met up with a client who needed a SharePoint environment, and needs someone to help with a specification. Following a number of briefs, seemingly the clients’ requirement is a requirement for a central place so that users could manage online content, using tools such as Visio, Word, Excel.
So, spent some evenings designing the user specification, then worked with the client to produce a design and technical specification. This is the fun part, having to move your mind-set from the production of a user specification (derived from analysis at business level) and converting that into a solution at a technical level through the production of a system specification.
Lets’ put that into perspective. If you was implementing SharePoint, which one would you be? More often than not you could find yourself in both camps. Sometimes though, that’s not the case. The evangelistic approach on a creative people centric level would be keen to do the user requirements, and then say ‘I am not a techie’ or ‘I am not interested in the nuts and bolts’ because that person would be only wanting to be focused on trying to improve productivity through the use of SharePoint. But, the person who is likely to be building the SharePoint environment would be much more interested in figures, statistics, content sizes, locations of data, features to be installed – not so much on the user requirement (lots of techies coming from a server admin environment would be in this area).
Both of these areas require some thinking of how SharePoint will provide proper levels of performance – the users need to be able to understand it, and the SharePoint admins need to be able to provide it in a method that’s easily understood. So, this means that the person who designs is not necessarily the one who builds – but at the end of the day, a SharePoint environment is based on its level of performance, and that comes from good capacity planning.
Now, it’s very common for an organization to manage SharePoint performance in a reactionary fashion, analysing and correcting performance problems as users report them. When problems occur, there is a perception that SharePoint administrators have tools necessary to quickly analyse and remedy the situation.
So, after I did the user requirements I went back to carry out some capacity planning. First, I categorised the work done by their current systems and quantified user expectations. Then I analysed the current capacity of their system to determine how it was meeting their needs. Finally, I asked what the future business activity trends would be since that would determine system requirements.
Ok, Geoff, so throw me a bone….
In a bit more detail. Please note that capacity planning is a massive topic and one where even I, a lowly SharePoint guy, is still learning to improve my methods – but these seem to work for me:
1 – Categorise the work done. Get an SLR (no I don’t mean a camera, SLR means Service Level Requirements). To categorise means to get an understanding of workload. Find out who is doing the work, what type of work is being done, and how it is being done. This happens to be a big part of user requirements gathering – the user requirements is not just about “what do you want then”. There needs to be an understanding of what is currently done to understand the workload, and this then gives you a priority on the levels of work and as such creates the ‘magical’ SLA.
2 – Analyse Current Capacity. Compare the measurements in the above with their objectives and match this against SharePoint. Check the current systems to identify the resources being utilised – this might sound ‘boring’ but its’ vital – get an idea of the current levels of CPU, memory and I/O on the servers (especially if you are migrating). This identifies highly used resources that may prove problematic now and in future. Analyse utilization for each workload, determine where each workload is spending its time. For example, examining the workload for Excel spread sheets in terms of Business Intelligence workloads may identify that the resources required are high – this will then affect the topology design you provide (for example, you may want to put Excel Services on its own server).
3: Plan for the future. Ask the client to help you forecast what the organization will require of SharePoint in the future – this will help you determine the optimal SharePoint topology and configuration for meeting service levels on into the future.
So, in summary to this blog, capacity planning is all about making sure the organization adopting SharePoint will be prepared for the future, ensuring that service level requirements will be met using an optimal configuration. I’ve found that following my steps above I’ve been able to get the information necessary to detail only what is needed, and avoiding over-provisioning.
For more information concerning Capacity Planning in SharePoint check out these links:
TechNet: http://technet.microsoft.com/en-us/library/cc262971.aspx
Joel Olson: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?List=0cd1a63d-183c-4fc2-8320-ba5369008acb&ID=332
If you are about to implement SharePoint and the client states a nebulous scope of a project on the level of “I’ll take all of it right now, please; as soon as you can” then that sounds like the client is ordering a meal at a fast-food restaurant. If that happens, take a deep breath, sit the client down and negotiate the scope. Ask questions that help you determine the client’s requirements and vision for SharePoint.
Ask questions concerning the budget the client has allocated, and not just to cover the cost of hiring project members. You should be sure that the budget covers the technical costs, such as the cost of servers, software, licenses, third-party products, and so forth. To determine the budget, you need to define the top-level scope and work out the basics of the SharePoint 2010 implementation.
Time framing the project is also vitally important. There is little point of doing the project if you have no idea when the client wants it completed. It is like being in a bar, ordering a drink, and saying to the bartender, “Just bring the drink when you are ready.” At that point, the bartender has no compulsion to bring you anything and your budget will linger for a long time without anything being delivered.
Make sure SharePoint fits the organizations client tools – are they using Microsoft Office or Open Office for example? I think it is probably one of the most important aspects of ensuring you have a proper scope and you don’t end up biting off more than you can chew.
Take this scenario, for example:
A client would like to implement SharePoint in an organization where there is a Linux-based environment. They are using Open Office and have been for the last 3 years. The client wants only the installation of SharePoint and training to use the product, and wants no productivity issues from the addition of the product. After some investigation, this requirement is deemed to more costly to the client. The investigation determined that extra servers would have to be purchased, additional software would have to be installed, training would take longer and become complex, support would be a challenge to implement, and so on. Before long, the client would be looking at a monster of a project, amounting to an organizational technology refresh.
I’m not saying that as soon as you hear “They use Linux!” that you should dash out of the door. What I am saying is that you have to clearly state in your Project Overview document what you intend to provide to the client. This means that if the client wants SharePoint 2010 implemented you need to list the parts of SharePoint 2010 you will implement, including any components that support its installation.
Check out more information concerning the production of SharePoint Quality and Project Plans in the book Managing and Implementing SharePoint 2010 Projects.
