Ten Steps Implementation Guide
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
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.
SharePoint Implementation – A Plan is Needed!
Had a chat with a friend in the pub talking technical over a whiskey and rum, and got into a reminiscent of the good ole days of writing databases in DOS (Nantucket Clipper and dBase – remember that?! Wow). I was asked about SharePoint and the coding for that and then someone piped up saying it was an application, and that started a whole new discussion. How do you take SharePoint as an application? Is it one? How does it ‘develop’? Hrm… Time to get theoretical and a blog is brewing…
SharePoint in an organisation is not data independent like an application may be. It is a centralised platform and therefore defined as a core system in an organisational information processing environment. A software application is designed to perform singular or multiple specific tasks to solve problems, like accounting software, office suites, graphics software, media players. Is SharePoint any of those? Nope, it’s a platform that allows users to create manage their own online content which could include output from any of those applications I’ve just mentioned.
Now, SharePoint of course can be made to produce transactions based on sharing and can even be defined to produce workflow like responses and outputs, such as sales, shipment of goods etc.). And because this is ‘created’ from organisational requirements as a part of the way they collaborate and share data, that transactional work in producing documents and records for sales is simply one aspect of the platform. And it is this platform that provides all of this data reporting, statistics and analysis for management and aids the decision making process.
SharePoint grows in an organisation as do all the entities with in (e.g. sites, repositories, workflows, connected databases, forms etc.). Even though these applications are interrelated, not all are developed at the same time. Priorities are set.
As a person embarking on implementing SharePoint there’s no point in saying “YAAAY, install it straight away and deal with the integrations later”. You can guess that is not going to solve any information or management challenges the client has (as I’ve described in my book a great deal J )
So, when you develop your SharePoint project plan, make sure that you follow a Design, Plan, Build and Operate format. Whilst you build on that plan you will be amazed to see how deep your SharePoint implementation has to be. Not only does the implementation need to capture the essence of collaboration in the organisation. The implementation must also serve as an evolutionary step to ensuring SharePoint grows with the organisation and stays integrated with the clients’ vision and applications.
I’ve provided a Project Planning Template designed in Microsoft Project format so you can download that and modify. It is located here:
https://serviceautomation.online/project-plan/
This has been made generic so that you can modify and detail the relevant tasks associated with your implementation of SharePoint, and bears no direct relationship to any implementations I have managed, neither do the resources assigned directly match and I would strongly suggest that you review the plan with the client to ensure their requirements are encapsulated.
Of course, this template works in close conjunction with my book (Managing and Implementing Microsoft SharePoint 2010 Projects) so make sure you get a copy from here:
http://www.microsoft-press.co.uk/scripts/product.asp?ref=189322
SharePoint Implementation Project Plan Available
Been asked a lot for a Project Planning Template in Microsoft Project format (versions below) showing the flow of a SharePoint 2010 / 2013 / 2016 implementation, so I’ve crafted a format you can use. I’ve purposely made it generic, so you can modify and detail the relevant tasks associated with your implementation of SharePoint and its version.
Implementation Steps to Success Presentation
I use this presentation for stakeholders in communicating to them the key reasons for Sharepoint implementation and the stages of implementation following project methodologies. Whilst it focuses on Document Management in SharePoint it is purposefully made generic to cover the general process of SharePoint adoption – I put 8 steps at the end of the presentation to re-inforce it.
The original was done back in the heady days of SharePoint 2003, so its been brought back out of the cupboard, updated just for you!
This presentation includes: Indentification of Current usage, Projected Key Benefits, Approach to implementation, Timeframe and Stages, and Key Strategies
The swopping of SharePoint Heads – Capacity Planning
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
SharePoint – The Spend, the Schedule, the Scope
A SharePoint Implementation combining a detailed Project Plan and Quality Plan allows you to capture key pieces of information; namely, the commitment to spend (i.e. what the budget is); the schedule (when it is needed by) and the scope (what is SharePoint going to solve).
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.
Build Template
This is a SharePoint Build Template. It is designed so that you can record the content of the SharePoint installation in terms of its software, and refer to the documents that will guide the installation of SharePoint.
The Software Build Template is referred from my book, Managing and Implementing SharePoint 2010 Projects.
Content Control
This article is concerned with how the management of documents and data in a site related to the delivery of a SharePoint solution, thus allowing the control, storage and management of information related to a SharePoint delivery program. (more…)
