SharePoint Requirements Analysis Guide
SharePoint User Requirements Analysis is vital; the corner stone in developing, deploying and providing a properly managed SharePoint environment.
(more…)SharePoint User Requirements Analysis is vital; the corner stone in developing, deploying and providing a properly managed SharePoint environment.
(more…)A major challenge in businesses is a misconception, that data is 100% secure concerning any part of its data processing within that business. This data processing concerns the content management lifecycle; from creation, to storage, to distribution, to workflow and eventually archive of that data. The misconception? “Security Breach? Its not going to happen to us” mentality. It is vital that there is an understanding of Information security and Information Assurance in content management security. As an information security professional (or Architect covering security), you should be prepared for any aspect of secure breach can happen that can affect the confidentiality, availability, and integrity of the data. Any service delivery disruption caused by a security breach is harmful to the profitability, and has far reach consequences which could include liability, status and much more.
Platform Governance is there to help bridge the communications gap between the business and technological groups; ensure ROI, mitigate risks associated with IT Projects impacting SharePoint, and provide a key cog for SharePoint Service Delivery, capability of service.
When a SharePoint solution is delivered, you need to ensure the continued availability of that service to related customers. You will need to protect the integrity of that SharePoint solution. You will need to prove that the SharePoint solution is capable (that is, that things like Change, Risk and Issues concerning the SharePoint solution are managed and communicated and documented).
Take this scenario:
Fabrikam is a manufacturing organization and has a project management office. Their IT team gets SharePoint and installs a site for the project management office. The company culture isn’t strict in terms of website control, and the IT team do not create documentation concerning the design or installation. The small site expands as more projects are added, and more features are added. Again, no documentation concerning changes was made. Six months into the project management office site, and there is a request to add more functionality which will change the way in which the project management office runs. However, in order to do that information is needed about the features applied and the reasons behind why they have been applied. Chaos ensues as no-one has any idea on how the sites evolved; the IT team is squarely blamed for not having adequate documentation about the sites history
This section comes from my book, Implementing and Managing SharePoint 2010 Projects, which is a great read covering lots of service delivery topics to aid SharePoint programme delivery.
Clearly, not a scenario that you would ever like to find yourself in! Therefore, you should use Configuration Management techniques to control specifications, drawings, software assets and related documentation which define the functional and physical characteristics of a SharePoint solution, down to the lowest level required to assure standardization. Control of those elements also means you control the SharePoint solutions and its Platform, under a Change Control regime and to control release of SharePoint solutions into your SharePoint platform. This enforcement of change control is linked to Platform Governance. The Configuration Management (CM) process also provides a documented, traceable history of the development lifecycle of SharePoint in an organisation, including any modification, upgrades or variants, and should be used to hook into your Change Management processes with SharePoint.
SharePoint when implemented is defined by identifying configurable items based on its technical, administrative and maintainability criticality. The selection process is one of separating the elements of SharePoint on a hierarchical basis for the purpose of managing their baseline characteristics.
Any item associated with the SharePoint solution, including deployment and any associated asset is subject to Configuration Management.
The diagram below illustrates the degrees of control applied to a configurable item during its implementation lifecycle.
Initially an item is uncontrolled whilst under development by the author. It becomes controlled once a unique identified has been allocated and the item is subject to review. Once the development of an identified configurable item is sufficiently stable to declare a baseline standard, it will be subject to configuration control processes. On small projects, configuration management techniques may be applied by the project staff using a simple SharePoint list to control baselines and record the version / issue status of the identified configurable items.
On larger projects, particularly where a large number of hardware drawings or modules of SharePoint features have been produced, Configuration Management may be delegated to specialist staff. The advantage of a central site CM facility, with its own specialized staff and archive, is the long term maintenance of project configuration records. However, the production of SharePoint add on features (e.g. Web Parts, Automation, Branding, Site Definitions etc.) is particularly well suited to the use of configuration management and tools, remaining under project control.
This section comes from my book, Implementing and Managing SharePoint 2010 Projects, which is a great read covering lots of service delivery topics to aid SharePoint programme delivery.
How to apply Configuration Management in SharePoint
To apply Configuration Management in SharePoint you will need to state a policy for its use and its procedure. You will need to ensure that any deviation from this policy, together with designated configuration management authorities for the SharePoint delivery program is documented. Other configuration management details may be contained in a separate configuration management plan, depending on any contractual arrangements or the size and complexity of SharePoint being implemented.
As the SharePoint Delivery Planning initiates, so should Configuration Management. You must choose a set of methods, procedures and tools to satisfy the requirements below. If the client organization does not have any Configuration Management processes in place you will need to create those processes. A method of recording these is via a central SharePoint site for the purpose of storing CM documentation and history of changes to the solution. If you intend on doing this, and if the client does have a full configuration management process running, investigate and find out if either (a) there is connectivity between that and the SharePoint site and/or (b) that the configuration management process in place includes the requirements below:
To satisfy these fundamental requirements, the configuration management system should provide the following:
Configuration Management Applies to SharePoint
Configuration Management is mandatory for all SharePoint Delivery programs. You cannot have a controlled SharePoint environment without records concerning is makeup and traceability concerning changes made. Even from the perspective of a handover of a SharePoint solution, as a Delivery Management you cannot simply handover a SharePoint solution by stating “I’ve finished implementing SharePoint for you, off you go”. CM provides a structured system handover meaning everything that the delivery program can be audited on, everything that the delivery program has an asset of (and that includes all documentation, technical specifications, software assets etc.)
Configuration Management is needed for any deliverable of hardware or software or where there is a change to either of those in a production arena. Configuration Management applies to configured items that are used in the development of a SharePoint product but are not a deliverable in their own right. Typical configuration items include:
The Delivery Manager Specifies the Configuration Management Policy
The Delivery Manager is responsible for creating a configuration policy and the techniques to be applied. If this policy deviates from that stated in the Configuration Management procedures, those deviations must be defined in the SharePoint 2010 Quality Plan.
Additional issues that also need to be recorded are:
Configuration Management Glossary of Terms
Configuration Item | An item selected for configuration management. Configuration Items are established on a hierarchical basis with one item comprising the complete product (hardware / software). This is then broken down into its lower level constituent items or parts, each with its own reference number |
Configuration Baseline | A specification or product that has been reviewed and agreed on that therefore services as a basis for further development. A baseline can be modified only through formal change control processes. |
Controlled Item | An items that is not identified as a Configured Item but still requires controlling in a formal manner |
Configuration Control | The systematic evaluation, co-ordination, approval and dissemination of proposed changes and implementation of all approved changes in a Configured Item |
Master Record Index | The index(es) to the master set of drawings, specifications which define the configuration item. This term is used generally to refer to a set of indexes that provides a record of the Configuration Items. |
Bring the SharePoint Item under Control as it Develops
The following diagram illustrates when a SharePoint item should be brought under change control (note – whilst it refers to SharePoint 2010, the process is agnostic of SharePoint version):
This section comes from my book, Implementing and Managing SharePoint 2010 Projects, which is a great read covering lots of service delivery topics to aid SharePoint programme delivery.
The diagram above shows the passage of a configurable item from its generation to the point where it comes under customer control through change control. Each of the vertical lines represents a formal stage in the development of the item. Once the internal review cycle is complete the item will be raised to version 1, or, if being updated, to the next appropriate version number and issued for external use. From that point on its status shall be recorded in the Configuration Baseline Index and any changes to the item must be introduced via formal configuration control procedures (see the below section Changes to Configured Item Must be Controlled). When the client takes delivery / control of the product, there will be a need for a formal Master Record Index to be generated for each Configuration Item.
Control the Item Prior to Configuration Management
Whilst a configuration item is being developed during the pre-configuration stage, the author is free to make whatever changes that may be necessary on a day to day basis. Understanding the development of the item is still important and significant changes should be recorded as part of the configuration item.
Historical information needs to be maintained for Configuration Management auditing purposes. In SharePoint, you could, as shown in the above diagram, construct a list with Version Control switched on utilizing Minor and Major Versions. Those allow you to enter comments as the item moves from draft to draft version until it becomes a configured item.
Bring the Configured Item under Configuration Management at the Right Time
As the development of the item stabilizes, the baseline standard can be declared and the item brought under configuration control. Each configuration item must be given a unique reference number. All configurable items must be regularly reviewed. The review record may initiate further changes to the item, causing the draft number to be raised. Maintaining all the comment copies of a technical document is not necessary, provided the record and / or minutes are maintained to provide the traceability of the review process
Establish a Configuration Baseline for Each Item
A configuration baseline index shall be formally maintained as a status and history record of the project’s configuration items. The index must include the hierarchy and inter relationships of the items.
At appropriate points in the project development and certainly when the product is ready for delivery, it is necessary to product an index of all the configuration Items. This index is often called the Master Record Index (MRI). For software products, a Build Definition which defines the software and computing content of the release must be prepared.
A Configuration Status Account Provides History
Configuration status accounting is a mechanism for providing records of the current status of all the projects configuration items. The configuration status records provide complete traceability of what has happened to the configuration to date. These records can be centralized into a SharePoint CM site. For example, you could have an item subject to version control and carrying metadata – a multi-choice column called Configuration Status, for example. This configuration status column could have values defining the configuration level of the item. This means that not only do you have traceable history but you can also identify when and who made alterations to the configuration status and if there were any comments made at the time they would also be available.
Changes to Configured Items must be Controlled
Once an item comes under configuration control, changes can only be introduced by means of a formal change control process. All items in a SharePoint production and SharePoint User Acceptance come under configuration management. The following example of a processing chain concerning SharePoint Delivery through Change Control is shown in the below diagram:
This section comes from my book, Implementing and Managing SharePoint 2010 Projects, which is a great read covering lots of service delivery topics to aid SharePoint programme delivery.
Every item concerning SharePoint running in a production environment is subject to configuration management; whose rules are bound by Platform Governance. You may wish to argue that Configuration Management is overkill; that there is far too much ‘process’ and it would hamper SharePoint delivery. My response is the following question:
How do you know who created what?
If you cannot answer what constitute SharePoint operations under change control you do not have an environment under control. You do not have an environment duly documented to show the purpose, premise and operation of your SharePoint environment.
Configuration Management manages and records and brings a logical change control process, so that anything that takes place to deliver a product has a history from the point it was designed to the point it was implemented. SharePoint configuration management defines processes that describe the following:
Cyber security is about data loss prevention, detection and response. Service delivery includes ensuring the protection and managing the integrity of content through its lifecycle. This is cross platform, and cross industry, so in relation to whether you are using SharePoint on / off premise, or SharePoint is at the centre of an estate of multiple technologies, cyber security concerns all of these. These requirements directly relate to a technology current and future state – according to Gartner (and covered in my last keynote):
With the match of evolving technologies related to the above points, such as Internet of Things (IOT), Content Analytics, Hybrid Cloud Computing, Big Data, In Memory Database Management and more about to become widespread; how to provide integrity, protection, and governance to data becomes more important. We all work with data, utilising physical and digital technology in our daily lives. We use countless methods to create and use data, and assume that the accessed data has security maintained. In providing measures, providers of secure access to data provide measures to ensure legitimate access. Consequences resulting from unauthorised access to data could include:
From a global perspective there are security challenges in the ‘digital developed’ versus ‘digital developing’ world. For the developed world, users’ access information through a digital framework; internet services provisioned over high level Wi-Fi and 3G/4G networks. But, in the developing world, there some 950 million people still without the means to connect to these networks. Security provision is not a one-fits-all. Additional global challenges are ‘Freedom of Speech’, ‘Country A Trust Country B Trusts Country C’ and the ‘Political Will’.
From a company perspective, the primary objective is to ensure the management of security; enforcing breach policies and governance is vitally important to ensure their data integrity. The challenge is that the company workplace is changing, and so is the physical infrastructure. Whilst physical and digital technology has become increasingly sophisticated, like dongles, passwords, data encryption, the task is convincing staff – from senior manages to entry level employees that they need to become more security accountable, becomes harder due to their emotions about security and privacy.
From a personal perspective, security intertwines with privacy. Advances in technology threatens privacy, reducing the amount of control over data. Privacy affects technology use. The challenge is the space in which this takes place in the digital world, which is completely online through the use of the internet, which never corrects and never forgets.
In summary, humans adopt any cyber security imperative. Technology is neutral. This means work must be done in the governance, training, and management of data to protect integrity and at the same time provide detection and contingency against loss. Opportunities include:
A key aspect of implementing SharePoint in an organisation is relevant to security of content. The success of SharePoint in an organisation is due not only to how comfortable users are with using their current technology with SharePoint, it is also down to ensuring that the users are comfortable knowing the data they manage on their SharePoint sites are secure…
Look through the job advertisements for any online job site or computer journal for an indicator of what most organizations seems to regard as a key attribute of SharePoint support staff. The need, desire, and hunt for technical knowledge seems to jump out at you from the pages. I have seen advertisements for SharePoint members that reads like a list of SharePoint third party products and affiliated integrated Microsoft products. The closest match of the candidate to that list is the first step towards being interviewed.
Indeed, even Microsoft seems to lay great store by this. Microsoft provides a range of qualifications which can be pursued. These qualifications become a marketable commodity; a SharePoint support person whose technical competence is measured by a Microsoft endorsed certificate commands a higher salary and is in greater demand than one whose ability is not so endorsed. In fact, an entire market is already in operational to provide Microsoft recognised training courses, with a range of quality, pace and price to suit most pockets.
This makes me suspicious about the training courses just mentioned. Of course, they create some kind of measure of a support person’s technical knowledge, and that is a useful aid for an organisation seeking to employ a proven SharePoint support individual. However, a Microsoft certificate is rarely a true indicator of real knowledge. It is an indicator of the individual to get through the relevant training programme. Additionally, the knowledge learnt is transient. In six months, Microsoft will probably have another version of the relevant product. In two years, the product may well look and operate very differently to when the original course was taken. Nevertheless, the certificate will still be valid even if what it is being measured against is no longer valid.
With certification programmes, SharePoint software producing companies have nothing to lose, and so very much to gain. They can sell training courses, appoint recognised trainers. They can ride on the back of the hype the qualification brings in its wake. They can reduce their support burden by encouraging customers to pay to be able to do their own support.
Even so, organizations generally face issues in finding the right level of technical support for their products. SharePoint could be considered to be different in the mix of Microsoft products because SharePoint is a platform. That means more interaction from support level to the business, not just solving technical issues. The support the business is after from a SharePoint perspective goes beyond into the land of solving business challenges. Questions like the following are normal directed to SharePoint support:
But what exactly makes up a great SharePoint support person. Is it simply technical? Definitely not. This article attempts to answer the fundamental questions concerning how to determine what constitutes a ‘super-duper’ SharePoint support person. To do that, I am going to break the article into seven points. Each point relates to an attribute that a SharePoint support member should have. I have also tried to keep this article version agnostic. I will not be going into any particular version of SharePoint, or product.
So, let’s kick off with a basic statement. SharePoint Service Delivery is about capability. The solution being provided to users must be capable of fulfilling their requirements. At the same time, the relevant solution needs to be supported by individuals who will be able to provide help and aid to those using the relevant solution. Therefore, it goes without saying that the skills of those who need to support users’ needs to go beyond just technical aspects of the solution being provided.
A 2013 Gartner report called “ITs Aspirations Require Addressing Current Realities” described a disturbing trend:
“CIOs have consistently reported a lack of skills as the single biggest factor limiting IT’s successes”.
The report goes on to say:
“One in four CIOs believe that the IT labor market is ‘working’.”
That can mean at least two things. First, that those being recruited to provide support are not skilled enough. Secondly, that the recruitment process in identifying the right person to provide support is not working. And, the key to organisations having the right people is based on their capability to provide support services.
In addition, the constantly changing face of technology as it expands and morphs will lead people to become continuously productive as explained in this article:
http://www.businessinsider.com/next-generation-of-tools-make-us-constantly-productive-2013-9
This will therefore impact on how support is provided, particularly for those products which are in the centre of collaborative tools. In order for SharePoint to be capable of providing a support service to the user base, the user base needs to be adequately supported. The environment in which SharePoint can be employed, for example, on-premise in an organization, off-premise through Office 365, and on any mobile device, being smartphone, tablet, etc. means that the environments in which SharePoint support could be employed is also varied:
Irrespective of the environment (which may in fact be a combination of the above), SharePoint support persons require particular attributes to ensure that a SharePoint service can be effectively provided.
As a member of SharePoint Support, part of the job is to support end users and troubleshoot various types of tasks. However, their tasks involve much more than simply resolving a problem. They must be able to listen to a user, gather information from that user, diagnose and resolve the problem (or escalate the problem to a senior technician or system administrator), and properly document the resolution of the problem in the manner dictated by company policy.
A SharePoint Support team member is expected to fulfil a number of roles in the support environment. A good SharePoint Support team member must possess both technical skills and non-technical skills, such as interpersonal skills that are necessary for building rapport with the user to better troubleshoot and resolve the user issues. Some of the primary roles of the SharePoint Support team member include:
As stated in the section “1: Carry multiple roles”, a SharePoint support persons job is to provide end user support in a At a high level, the SharePoint support person should be prepared to perform the following tasks:
Note that whilst the above appear to be technical, the key is to support the customer. The mission statement simply means ‘Quickly Resolve the Problem’:
Within IT Support, there would generally be a support model. This covers, problem, service management and IT helpdesk support. Without going into any detail concerning how the IT Support model operates, the key is to understand that it is the duty of any member of SharePoint support is to provide a service understood by their customer. Therefore, for every issue to be resolved SharePoint support persons must get back to basics with every customer (and non-customer).
Here is a scenario:
Fabrikam is a coffee research company with offices in London and New York. They have a SharePoint installation which is supported by a SharePoint dedicated team. Fabrikam, at the start of setting up the SharePoint support model was aware of the time difference, and elected to have SharePoint support provisions in both time zones, but managed by IT Support. All calls would be logged centrally so that all IT Support teams and SharePoint support teams could see the work being carried out in New York and London.
The above scenario is a simple reminder that in order to have adequate support you need to understand the working time zones of the users. There is little point of proving that all your users are supported if your SharePoint support team is asleep when customers using your SharePoint provision need support on the other side of the planet. However, the above example is general. Let’s take the example back to specifically why it is important that each member of your SharePoint support team takes things back to basics. I have a large lawn to mow at my house. I use a lawnmower provided by a company in my nearest town. That lawnmower always breaks down, and generally, it’s my fault. Either I hit a stone, try to cut grass that’s far too long that plugs up the grass scoop, and more besides. I am getting better at working with that lawnmower, and that’s because the guys who supplied the lawnmower, who seem to fix things faster than you can say ‘Jack Robertson’, will always pass on a good bit of information when it is fixed, will always ask ‘what was you doing before the problem started’, and will always give demonstrations of using parts of the lawnmower which I didn’t think existed.
So, why is that important? Well, imagine that you are new to SharePoint. You need to upload a document, but cannot remember how to do that. You call your SharePoint support member. The SharePoint support member responds with something like this:
‘You dolt. It is easy to upload that file. Just click the New Document link. Why bother me with that’ – mutter… mutter…
In terms of even a relationship with SharePoint support that response guarantees service delivery ‘epic fail’.
Good SharePoint support persons get back to basics. They ask what the user was trying to do. They give step by step information on how to upload documents. They inform the user that there are places where the user can go to get more information. They state alternatives to using the New Document link in a document library. They empathise with the user (more on that later).
This does not mean that when the user calls SharePoint support that they have to wait while SharePoint support scrolls through a list of possible solutions or navigates around a decision tree, especially if the payoff does not appear to come quickly.
The reason why it is so important to go back to basics, is simply not because you want to teach SharePoint 101 basic stuff to SharePoint people. It is because the comfort factor of those calling SharePoint support increases. If that increases, they become more confident. If they become more confident, they learn, and want to learn. If this is not done, you will start seeing users ‘switch off’ from using SharePoint support. Or even worse, they will inform other users not to contact SharePoint support and will use other methods of finding out how to do things. Or even worse than that, they will stop using SharePoint all together!
Imagine you set up a SharePoint support service. You may find that many customer simply will not call that support service. Some will not call because they do not know about SharePoint support. Some may even complain about SharePoint when it does not do what they expect it to do, but they will not call because of their experiences with any other customer service, whether it is a airline, telephone company, car park fining, cinema ticket purchasing, etc.
A successful SharePoint support service has enthusiastic customers. There are so many ways in which SharePoint support team members can make customers enthusiastic customers. First, let me describe what it is that defines an enthusiastic customer.
Humans are forever needing to find easier ways to get things done. They love shortcuts. This is because at work humans are doing multiple things and making multiple decisions. And because they are doing multiple things, when they are shown how to increase the speed (and productivity) of certain things in their daily tasks, they will become more enthusiastic. This goes with any software application, or any business process they work in. The key however, is to not get technical, don’t use jargon. Speak in their language. Here is a scenario.
Scenario: Telling something to a customer that helps them associated to the problem at hand. User tries Search for the first time in SharePoint and whilst they understand how to use the interface, you ask how they carry out searches without using SharePoint. Customer states that they have used the Explorer to search for files using Windows 7. You state that by using the search option “Search in Windows Explorer” in Enterprise Search that the user is able to ‘connect’ Windows Explorer Search to SharePoint search.
The result is a customer who has learned something new, and passes this onto other customers.
Scenario: Customer calls into SharePoint support stating that they were working on a document which they had ‘checked-out’ from SharePoint, then something happened on their computer forcing the application to crash, and now they could not re-open the document because it was already checked out. The customer tried various ways of attempting to open the document, but had given up and called SharePoint support. By the time they did, they were angry, frustrated, and even more frustrated when they found that they had to wait for over an hour before anyone called back.
The point here is that first SharePoint support takes the blame. Irrespective of the problem, whether the user is at fault, whether SharePoint is at fault, the key is not to identify who or what is at fault in the first instance. The key is to get the customer to calm down, and to understand that you are the face of SharePoint and that you will resolve the issue one way or another.
To relate to this, another scenario is where a customer, in a restaurant, states that the service provided has not been to their approval. The restaurant manager, instead of apologising and stating they will seek to address the issue, says the customer is wrong to state the service is at fault, and instead states that the customer should not have come to their restaurant in the first place. Clearly this is the wrong move, because the customer can then easily state to others that the service was bad and no one took any attention to sort out the problem.
When someone complains, its easy to get caught up emotionally in the situation. This is particularly when the very thing you are supporting is the thing that the customer is complaining about.
Scenario. A customer calls stating that their document library displays an error every time they attempt to upload a document. The customer is quite frustrated and says that SharePoint is “rubbish”.
As a SharePoint support individual does not immediately become furious and state ‘How dare you say that?! I have never had a complaint from anyone else!’. Instead, they say ‘That’s terrible, please tell me what happened so I can make sure it never happens again’.
SharePoint support individuals will require technical abilities; however, that does not mean they come from a technical background. Organisations choosing SharePoint support individuals would be looking for the appropriate personal skills to deal with the users. That is because the users come first.
Training is another area to consider. Check out this article here: https://sharepointgeoff.azurewebsites.net/articles-2/training/
There is something that I think all SharePoint support persons should be aware of. And it is a certification called MCDST. MCDST stands for Microsoft Certified Desktop Support Technician. I did this when I was running a IT Support department, and needed to ensure that all my technicians did that course and the exam. I also did the same course and exam.
For more information on MCDST, check out this link:
http://www.microsoft.com/es-es/learning/certification/mcdst.aspx#tab3
The reason why I did the course was twofold. Firstly, to understand the issues concerned with providing support for the current operating system. Secondly, to understand the implications of providing a service to end-users. And do not be deterred by the fact that the course covers operating systems. A key element of the course is understanding customer service and what it means to be in support.
SharePoint support people understand their user expectation. This ‘expectation’ is rational, reviewable and realistic. Rational because support can understand how the user uses SharePoint, and therefore, is able to estimate the needs of their users with a degree of accuracy. For example, if the usage patterns of SharePoint appear to be heavy on a Thursday, but Friday is quiet – but Monday is difficult because that’s is when all the queries come in regarding any issues on Thursday, then SharePoint support can glean that carrying out maintenance on a Thursday, and testing on a Friday is best.
Relentless pursuit of technical acclaim distracts so much from the attributes we really want in our SharePoint support staff. If SharePoint support individuals only ever dealt with SharePoint technical issues and the servers SharePoint runs on, then technical ability is all we could ever reasonably ask of them. But they do not – they deal with people. This is particularly in the wake of support being provided through Office 365, where there is far less emphasis on technical ability on working with the SharePoint server side, but an increased awareness required on integrated products like Office, Exchange, Lync. Irrespective of the knowledge required to provide support, SharePoint support must be dedicated to maintaining continued, hour by hour productivity through user support. Therefore, what is needed is people and methods that increase or maintain user productivity. User productivity is not just an “I’ve got a bug in this SharePoint site” issue. It is a “Help me to know how I go about producing the output I need using SharePoint” issue. The first query requires technical ability. The second query requires technical knowledge coupled with an ability to convey that knowledge in terms the user can understand and believe in.
Therefore, to back up the 7 ways of identifying a super-duper SharePoint support person, there are the 7 attributes as follows:
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.
Hi there folks!
Sometime ago I created a quick ten step guide and had it published on TechNet – amazed to find so much interest, and great comments! ShareGate contacted me and asked if they could turn it into an info-graphic (which looks great); now available on their site and is displayed below – enjoy!
Getting hands on deployment information concerning SharePoint 2013 can be a challenge. Managed to locate this guide which is created by Microsoft detailing the process! This is available from the Knowledge Base so check that out for more guides as they come in. Also, check out the Ten Steps paper on the planning and implementation to get a complete picture..
A challenge that SharePoint organisations have who are actively involved in the creation, then management, of SharePoint solutions, is then applying a process of delivering those solutions, and then using the same defined process. And note, we are not talking complex or simple SharePoint solutions, these solutions could be as simple as configuring a SharePoint site with repositories to provide a records management experience, or to provide a method of filling in on-line forms, or a business automation solution utilising workflow templates, or even taking on a third party app in a SharePoint 2013 online site, etc.
More often than not, those who do not apply any process involving any kind of systems analysis and design, then through to administration of SharePoint solutions usually end in disaster because:
Some customers when quizzed speak of their alternatives to delivering a solution, and some are nothing short of astonishing – here are some examples – prepare to laugh:
Ok, laugh over… Let us quickly see why alternatives have been addressed which simply do not work. The main reason appears to be that organisations find it difficult to build let alone understand a delivery framework surrounding SharePoint solutions. This may be due to having one person to provide the entire solution start to finish with no proper support, or a lack of skills concerning how to provision a solution (because their background is programming), or even that the current process does not map to SharePoint.
If you happen to work in an organisation where there has been SharePoint solution success; for example, you have been on or lead a team responsible for delivering a SharePoint comprising of a number of tools and services, you will be in no doubt that the following areas would have been addressed:
Conversely, you may have been in a situation where there was deployed a SharePoint solution which had failed because it had not addressed the above.
Am going to try to help out then. I am going to describe four areas which relate to the practical work required around delivering SharePoint solutions – every SharePoint solution being conceived must:
If any one of the above areas is not fulfilled then the adoption of that solution will fail.
For each of the four areas I will describe some actions that you should consider. The topics will be written in a way that is SharePoint version agnostic and generic and can be applied to your organization.
At the end of each section will be a Deliver Actions section which will show three areas of concern related to the topic:
Please note though, describing these areas is not easy. I have even have difficulty amongst other solution architects in explaining the concepts, because of statements of SharePoint service delivery which is all over this article, and the fact that the areas covered in this article may touch all parts in an organization, which therefore increases complexity. So, to those new to SharePoint Service Delivery, as well as reading the guides, I suggest that you:
The areas being described are separate articles as follows – please read them (when they are available) and they will be listed and categorised on the site (when they are available):
No, security is not all about a Dalek yelling ‘Exterminate’ if you don’t follow rules concerning access to information 🙂 Access to information can be controlled at many different levels within Sharepoint. The question of where best to implement control of user access is answered only with an understanding of available options and requirements. As part of training those who need to manage security on the sites, even if they themselves do not set the security permissions, it is a very important that you communicate a policy concerning when and where to apply site security.
One of the most difficult areas of delivering a SharePoint solution is identifying not just who should be targetted for User Adoption, but, going forward, how to sustain that User Adoption through communication. Reasons include rapid changes in the business culture, direction, and changes in technology concerning the methods used to communicate (e.g. business process changes from manual to email notification to automation, etc.). Moreover, if you have developed a customer list for Service Delivery purposes (e.g. support, user adoption, training, governance, etc.) then you will need to keep tabs on customer culture, communication technology and apply communication tactics and strategies.
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:
Check out this review on the book:
http://www.bcs.org/content/conWebDoc/51817
Go here to get the book and find out more information.
In Chapter 4 of my forthcoming book SharePoint 2013 User Adoption Planning and Governance, there is a section titled ‘Collaborative Ownership’; it is my take on the creation of simple rules to manage a SharePoint solution (note – an implementation of a SharePoint environment could be defined as a solution)…
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.
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!
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.
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.