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.
Excerp: “For those entrenched in trying to get information workers to buy into using SharePoint, SharePoint User Adoption seems to be a black art. In a way, it is because the kind of enticements and methods you use will be relative to the product that is being supplied. In reality, complexity of User Adoption is based on the breadth of the SharePoint solution being implemented.
This article shows the different types of people there are in terms of the User Adoption (which has a lifecycle), and attempts to identify the related high priority areas where you should focus your communication and training programmes. Note. The kind of users involved are ‘generic’; and therefore you should use this as a model for any SharePoint solution – irrespective of version. The key areas of SharePoint I will focus on relate to Information Architecture, Term Store, Search and User Profiles and in SharePoint 2013”.
The article I wrote for MSDN newsletter is located here:
Using SharePoint, organizations should be leveraging every asset which makes them more productive out of the platform, and as effectively as they can. This means investing time and resources to make sure users are fully utilizing the functions made available to them; especially the capabilities that can help them more productive and meets their objectives.
One of the most difficult migration paths for SharePoint is from version 2007 to 2010. Not so much due to the technical requirements concerning things like content database shift, Web Application shift, Site Collection review, Third Party review. But more on the actual sequence of events, which if not worked out completely could leave people attempting to go this in a pickle! To help, I’ve provided a map which I have used with several customers which allows me to produce key documentation and at the same time keep them involved in the process.
To assist the map, there are two project plans attached in 2007 / 2010 / 2013 formats, which allows you to set time-frames against each of the sections.
Note that these are generic. You must use your own judgement concerning things like Third party products (and what you wish to do with them), what must happen to content on the document lifecycle trail (i.e. old sites, archived content), and what must happen to any control processes surrounding things like security (who should have access to the new world).
This is particularly related to testing, and again, you should adopt a generic approach first then tailour it to your own requirements. Read through my Verification and Validation article to give you ideas of what should be in your testing plans (which will encompass technical and non-technical concerns).
Am working on my forthcoming book concerning the delivery of user adoption and platform governance, and thought that I would share a summarised section which concerns the creation of SharePoint support. a crucial area that relates to how SharePoint services will be managed.
Nb. Am also working on an article which goes into further detail looking at SharePoint support and what are the necessary items to put in place to guarantee success (rather like my Ten Steps for SharePoint implementation article :D). This will be available soon…
Please read on though – hope the summary is useful!
From a planning perspective, what are the very basic areas that one needs to think of when going down the route of creating a SharePoint solution, whether its a site, or farm, or even a workflow solution. I have attempted to answer this by building a presentation key covering planning, adoption, supporting, delivery from a high level.
There’s plenty of technical articles discussing what tool to use, what commands to use, what products to use and more in the face of migrating one or more SharePoint environments from 2007 to 2010. However, this article describes the process that a SharePoint Architect would need to define with the SharePoint Administrator to ensure there is a plan which covers:
Welcome to the third and final part of my Value Management article concerning how to define and apply a model for solution architecture in SharePoint.
(more…)
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.
People have been requesting me do a shortened article to cover SharePoint Implementation from a higher level; a kind of whats my the key steps required to deliver SharePoint to a client. Please note there’s a whole bunch of webcasts coming soon to go into some more detail on each of the steps, so watch this space. If you need further information go ahead and give me a shout! Happy Reading!
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.
SharePoint Implementation concerning the ten key steps required to successfully deliver SharePoint to an organisation, available as a map on this link: http://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.
When implementing SharePoint in an organization, its not just about dropping SharePoint on a server and saying to the client ‘There you go!’. This introduction to SharePoint Project Planning gives 10 useful steps to ensuring a successful SharePoint implementation.
As a SharePoint evangelist, working with users to identify their requirements can sometimes feel like an uphill struggle. We have all heard of the wishful thinkers, the my app does this so SharePoint had better too, the lets tweak this bit by bolting on that from ‘XYZ Consultants Are Us Inc’, and the list goes on.
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://sharepointgeoff.azurewebsites.net/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
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.
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
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
O365 Security and Compliance Information Security News |
 |
 |
 |
 |
 |
 |
 |
 |
 |