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.
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.
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://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
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
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.
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.
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…)
Bunch of my friendly architects chatting over a significant number of beers and spirits, telling rather silly jokes got into a heated discussion on SharePoint Content Deployment. Hrm… Sounds like a punchline building up here – Anyway, it all went a bit like the ‘I went fishing and caught one this big but it got away’ scenario; highly amusing. After recovering I though mmm… sounds like a blog this; so here’s my take…
Before a little chat about what Content Deployment is, lets look at the options available to you:
1: Content Deployment Method
Using the Central Admin, create content deployment jobs to schedule the content that you wish to copy into the production environment.
http://blogs.msdn.com/jackiebo/archive/2007/02/26/content-deployment-step-by-step-tutorial.aspx
2: Third Party.
There’s a mass of products for doing this for example Quest , Content Deployment Wizard on Codeplex – the content deployment wizard is good (and its free ):
3: Coding.
You could write a web service or delve into the land of SharePoint Object Model coding, that scans the content of your staging environment and maps it into production – this is a big deal and a lot of work. If you’re not a developer be prepared to learn about SPSite, SPList, SPFolder and much more. If this grabs your fancy, and pretty keen to going it alone, check out the below link:
Of course, you may have your own methods, but these ones work well for me!
The problem with Content Deployment – what do you deploy? Whats the scope? From where to where? Whats the reason for Content Deployment.
In any case, a lot of careful thought needs to go into the provision of Content Deployment and Best Practice would be to analyse the requirements with the client (even if the client happens to be another tech team), trial it in a test environment then apply it to your staging / production environment.
Some links?:
Video: http://www.youtube.com/watch?v=8_Vy6a1sI_Y
Technet: http://technet.microsoft.com/en-us/library/cc263428.aspx
A Best Practices Blog: http://blogs.technet.com/stefan_gossner/pages/content-deployment-best-practices.aspx
