SharePoint User Requirements Analysis is vital; the corner stone in developing, deploying and providing a properly managed SharePoint environment.
As the use of content management systems evolve with users adding more, ahem, “content”, the organizations accountable for those content systems will need to ensure that they build in people resources who can manage that content, and particularly people who can find insights in that content for the benefit of the organization.
Business intelligence requirements and implementations are growing faster than ever before, particularly due to the rise of cloud computing and more cloud services. There is now much more pressure on ensuring that customer interactions are tracked as a key aspect of business intelligence data gathering. This is one of the most critically important ways of working out the value that cloud services provide.
The blog article has been written for TechNet and is available on this link.
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.
This is the second part of the article concerning the delivery of SharePoint solutions. I will start by recapping on why I have produced these set of free articles, which will combine into an e-Book soon, check out this article. In essence, a successful solution delivery process encapsulates a design, creation, provision and support framework – that’s what makes up a SharePoint solution.
As stated in the first article, I am not designing a new process, rather, giving ideas surrounding theory, and actions for the reader to use.
The first article in the series, first looked into the understanding of creating a Usable SharePoint solution. A usable SharePoint solution takes into consideration the service standards applicable like design, development, commonality, consistency, tools and cross platform standards that can be applied when working with SharePoint. In learning the standards relating to usability, repeatability, supportability and extensibility you will be able to continually provision solutions easily, slicker and also help the client learn how to manage the solution once handed over.
A danger in writing these kind of articles is that the reader may be fooled into assuming that this is a business article, and somehow, not related to anything technical in SharePoint. In fact, service delivery is combination of the two – known as Systems Analysis which has been around as long as software has!
This is the second article in the series, concentrating on the key aspect of providing a sustainable solution – repeatability. In essence, this is the use of common processes, components, and products to build SharePoint solutions; continually – meaning using a repeatable method. Before thinking ‘this isn’t for me’ – wrong. As a SharePoint worker, you will be using a ‘repeatable’ process when even the simplest of SharePoint site solutions. For example, a document template re-use is defined as using a repeatable process. A web service that provides solutions such as say copying files from one place to another can be set to carry out the same process on another source and destination with minor customisation. Even a SharePoint site carrying a common structure can be easily created using a template, such as a Team Site Template. Apps are ‘repeatable’. Other examples could include workflows which are re-purposed, like Approval workflows.
The challenge is that most people, faced with constructing a SharePoint solution using components do not understand the principle of re-use which is a key aspect of a repeatable SharePoint solution delivery process. They may understand that something such as a template can be used again and again of course; however, they do not understand why a process ensuring why and when that a re-use management process can be applied; from the lowest component, to sites, site collections, web applications or farms. Even the provision of an Office365 tenant to a client is defined as a repeatable process. If there is no understanding, even a laissez faire approach, no standard or structure applied. And, as time marches on, as components morph, change and multiply, the potential for chaos ensues, where people simply have no idea what component should be used for what solution – instead, a patchwork of ‘guessing’ takes place!
Time I think to put a spin on helping you understand the principles of a ‘repeatable’ SharePoint solution. Again, this is a really challenging article to write, but an enjoyable one as well (like all my articles!).
First, time to get back to basics. Am going to start this section with a strange analogy – IKEA tables.
I went to IKEA Edinburgh last week looking for tables. My partner wanted some new tables to brighten up the conservatory, the kitchen and the cinema room. Now, browsing around IKEA for tables (well in fact anything in IKEA as I am not a great shopper) can be a bit of an experience, and sometimes, an annoyance. Trying the find the right colour, size took a huge wedge of the day to find what would look right.
So, in the end after hunting for tables in IKEA, we decided on three tables, put them into the horsebox and drove back home with them. Once home, I spent the following day putting the tables together. The first attempt at building a table was a nightmare. Yes, the instructions are easy to follow, but unfortunately I am not that great in following IKEA instructions; I dove in blindly with the screwdriver – then once I started getting things wrong, I went to the manual. It took me over 3 hours to build the table. Finally, I managed to put the first table together. Then, onto the second table. This was easier to put together, simply because I remembered all the wrong things I did about the first, and because I followed the manual :). The third was such a blur of activity – I simply didn’t need the manual, and I placed all the components in the order of building – the time taken to build was a fraction of the time to build the first.
Of course, stating that building tables is not a great and wonderful idea of delivering SharePoint solutions using repeatable exercises. But it is a great analogy because of two key reasons:
- All components fit together because the form an object
- A manual is there to guide you through the process
That means this two simple reasons can easily be applied to SharePoint to ensure a repeatable process. Surely it is easier to put a SharePoint site solution together if there are common components that can be reused at will? Surely, if there is a documented process that aids the creation of the SharePoint solution which utilises those common components, then that defines a repeatable method of creating those solutions. However, the concepts I have mentioned are unfortunately not carried out, or is a challenge to understand how to put them in place – and this is because the capabilities that describe how a SharePoint solution can be made ‘efficient’, through its delivery process is not at hand. I am going to attempt to address that, by describing the key capabilities that make the SharePoint solution efficient in terms of its development, deployment and maintenance.
The capabilities that you should consider, which in my view help you create a SharePoint solution (requiring the roles of Systems Analysis, Development, Architecture and Administration) and by definition can help build a ‘repeatable’ framework are:
- Create Service Blocks. Service blocks are a common set of high level components that can be reused. Examples of these are pre-configured Apps (site, repository, third party products and integrated services, workflow templates) which can be combined build SharePoint solutions. A great example of this are workflow templates that can be constructed by the fabric ‘or snippets’ from other workflow templates (Nintex provides a great way of doing this).
- Set a Common Schema. Creating a common format that can be applied to multiple solutions. Examples include branded custom pages, format of the quick launch bar, top line bar, enterprise taxonomy, navigation, etc. House the combined solution designs in a central location armed with keywords and categories to identify them.
- Discover and build the skills necessary. Creating a common set of training and guidance material for the solution that allows the user-base to learn the product, explore and use the relevant possibilities that are available.
- Ensure products can be Self-Provisioned. Users are empowered if the solutions they have constructed can be re-used to solve likewise problems for themselves and others. This aids the productivity of the individual, their peers and enhances the ability of support.
- Build Enterprise Policies. The creation, re-use and management of policies which will aid in the adoption, design, structure, implementation and deployment of the solution.
- Factor in Deployment Management. Drives the configuration management process whereby a SharePoint solution can get from idea to Test to UAT (User Acceptance Test) to Production. Aids the version control management of the solution in terms of how the solution can be updated and upgraded. Aids the document and data control process so that the solution can be adequately documented.
Service delivery of the relevant solution needs to be efficient. This means being understood and managed by the stakeholders, since they are responsible for managing / devolving the management of the solution going forward.
For Service Delivery to be efficient, the solution delivery mechanism needs to be carried out in a sequenced and logical approach that the customer will understand and be part of. For example, if SharePoint is going to be employed in an organisation, the client needs to understand the part that SharePoint is going to play. This means understanding the information framework, and applying that, including controls for managing and locating that information. The fact that SharePoint is going to be used is irrelevant at that stage, since through the evaluation of the information flow in the organisation, the tools being used, the culture of the organization, amongst other key issues like control, security will influence the platform being employed.
So, a service delivery mechanism which encapsulates vision, decision, design, build, support, sustain, control needs to be defined first. A key outcome of creating a service delivery mechanism provides the stakeholder with the knowledge and comfort that an understood process (which they will manage) is clear and can be adhered to.
This means providing a number of service blocks that can be provided whenever releasing a SharePoint service. Examples of this are:
- Maintaining and managing a list of owners that also concerns who the owners are, the key stakeholders and users.
- Maintaining and managing a list of the key resources used both SharePoint oriented and people who will be using the solution
Efficient Service Deployment
There is confusion on the terminology surrounding the term ‘Service Deployment’. It seems that it is a technological term, and therefore, something related to getting some software from somewhere and installing it. I have witnessed situations where someone says ‘We are going to deploy the software service by following the installation process given in the manual’. In other words, download the product from somewhere and follow the automated installation process by clicking ‘Setup.exe’….
Service Deployment is the process under which the SharePoint solution is deployed from a full implementation perspective and involves all resources necessary for that to take place. That means including people. That is the first simple rule. Keep the users involved.
Example. An app has been sanctioned to be deployed to a SharePoint online team site. The procedure that was followed to get the product sanctioned is a tried and tested method of user requirements, testing, user acceptance.
Efficient Service Deployment is part of a Software Delivery Process. A process by which the deployment of the solution is simply part of its lifecycle. That lifecycle includes the design, build, maintenance, support and any other aspect that defines the solution.
Henceforth, knowing what makes up the SharePoint solution is vital since that naturally produces the information required to ensure that the solution can be deployed. There are a number of documents which should be created:
- Hardware Components
- Installation Guide
- Related Productions
- UAT Provisioning
- Release Notes
Because the people must be capable in using the delivered SharePoint solution. Therefore, the solution must be capable in enabling and enhancing business productivity, knowledge, and solving information and management collaboration challenges.
So, in order to repeat the process of creating successful SharePoint solutions, the capability (structure, roles) of the support service team responsible for designing, crafting and, deploying and most likely supporting the solution must be repeatable from solution to solution.
This means that:
- SharePoint support services must be capable of supporting the delivered solution in line with customer expectations
- SharePoint delivery teams must be capable on delivering on the promises that were made about time and quality
- Any relevant SharePoint support services must be capable of standing over any key performance indicators or service level agreements.
Scenario: You are going to deliver a SharePoint platform to a client. You gather their information requirements and process. You provision a ‘Proof of Concept’ SharePoint platform open to key stakeholders to showcase, demo, and gather further requirements. The client wants SharePoint. From there, you provision a UAT (User Acceptance Test) environment which maps to their requirements in terms of infrastructure, availability, scalability, extensibility, support. You then open that up to key stakeholders. Workshops ensue. The client still wants SharePoint, the UAT environment provided appears to meet functional and system requirements. You then provision a Production environment which matches the infrastructure provided at UAT level, and then deploy SharePoint services to the client as prescribed in UAT.
The above is a simplistic approach concerning the delivery of SharePoint to a client, following a design, build, deploy process. A repeatable SharePoint Service Delivery mechanism focusing on implementation.
However, the point being made about the scenario given about is a word which encompasses the delivery – future-proofing. ‘Future-proofing’, means that the solution being provided will not only meet the client requirements at the point of inception, but can also in the future because it can be scaled, and therefore will continue to meet changing requirements.
Scaling a SharePoint platform and any relevant solutions is not a single event exercise. Any alteration, addition or deletion to the solutions provided within the SharePoint platform requires a review to determine the impact on the scalability of SharePoint. For example, take the addition of a third party app to SharePoint, which becomes important, an app which the users cannot do without. The impact to the scalability of SharePoint comes into question if, for example, that app cannot itself scale to the next ‘hotfix’ of SharePoint, let alone the next version of SharePoint!
A lifecycle of delivering SharePoint solution needs to be based on being repeatable. Reasons for doing this have been stressed in this section, but to summarise:
- Stakeholder map per solution. Carrying analysis on the gathered maps will show connections between the common components being used across multiple solutions and also the key individuals helping to create a focal / champion group.
- Efficient Service Deployment. Due to re-use, there will be reduced requirements to bring in key resources build likewise solutions and components leading to reduced cost and management issues.
- Efficient Maintenance. Updates to repeated solutions can be applied generically, change management is easier to define, business policies and rules related to the solutions are easier to enforce and get buy-in.
- Capability. Users and Support gain knowledge and maintain that knowledge more readily than disparate solutions non repeated solutions.
- Scalability. Easier to plan, coordinate and carry out configuration management processes on repeated solutions.
In the Scalability section above, I gave a simple scenario based on deployment of SharePoint and boiled this into a repeatable solution exercise. That’s not the only scenario that uses Repeatable as a method to service deliver SharePoint solutions. SharePoint provides virtually all the components and tools that allows components to be configured, connected and scaled. SharePoint provides the ability for modules of functionality, developed internally or externally to the organization and contained in Apps. Apps that can be re-deployed, and further enhanced based on changing needs of the client, and can be deployed centrally from a bank of other Apps. For example, a simple document library App may alter need the ability to be connected to a third party tool, or may require further enhancement concerning views and sort, or may be required to lookup information from another repository. When completed, the entire configuration of the document library can be transformed into an ‘App’ which can then be redeployed elsewhere without having to re-develop from scratch. Other Apps include Site Apps, and Third Party Apps.
Third Party Apps throw a different kind of repeatable solution scenario because of the added dimension in providing automation, which then leads to the ‘Supportable’ element of the SharePoint Service Framework. This is simply due to the fact that Third Party Apps cannot be successful unless there is a support group. The sheer number of Apps available from the Office Store for SharePoint compounds scenarios concerning re-use, consumption, implementation and administration.
As per all things when implementing a solution in SharePoint, the answer to solving business and information challenges requires you to continually and critically review the requirements to find nuggets of functionality that has already been created. Analyse thoroughly the various elements of the SharePoint solution, so you can identify common areas that can be defined generically and as repeatable components. Harvest them into deliverable chunks and rework to see if they can be repeated. Remember the DEV to UAT to Production model – this applies to any kind of solution (design, develop, test, make it live).
If this sounds a little convoluted, remember the client perspective. Generally, they will not care what the resolution is made up from, is as long as it works – however, they will care, if the solution is usable, whether the solution once implementation can be repeated to meet a likewise requirement elsewhere without having to pay extra, whether the solution can be supported and whether the solution can be extended as the SharePoint platform scales.
Before going onto the relevant actions concerning what you need to implement, how the customers can consume, and how you can administer a SharePoint solution that can be repeated, check out these articles which all have a bearing on this section.
- Road Map Perspectives for SharePoint Service Delivery
- SharePoint Communication Message Framework
- What is SharePoint Service Delivery
- Some Thoughts on the Process of Building SharePoint Solutions
In conclusion to this article, which I will continually come back to update, you should also consider the three actions that you should consider in building a ‘repeatable’ SharePoint solution framework – Implementation, Consumption and Administration.
- List the common attributes of ALL solutions and group them into the four key aspects of SharePoint service provisioning – Support, Automation, Management, Reporting
- When designing solutions, record aspects of those solutions (if not in their entirety) that could be included in other solutions into a knowledge base.
- Record the aspects that allow third party products to export configurations that could be re-used. For example, you could develop a simple SharePoint site that houses developed and them exported Nintex workflow templates, thus making them accessible for re-use to others. In other cases, you could even export workflow templates and have them available for download in other sites.
- Build a process whereby users can provision solutions which are available in a library.
- Communicate available solutions and review all solutions in that library so that you can be sure they are being used effectively
- Record usage of the solutions in terms of where, how and popularity of the solution
- Create enterprise policies that ensure users follow rules in terms of re-using ready-made solutions and link them to support
- In relationship to consumption, associate business rules and policies concerning the solutions that are in your library of solution
This article is part of Delivering SharePoint Solutions – Areas of Importance.
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!
Welcome to an article which goes into the land of SharePoint Training. This attempts to examine various levels of training and how they can and are being mapped to SharePoint information workers, irrespective of whether they are SharePoint on-premise, or SharePoint through Office365. Please note, that whilst I go into some detail on training delivery that I am not a SharePoint Trainer; however, I think I’ve got enough experience through the implementation of SharePoint Training strategies for many organizations, so I suppose I’ve got some points that may be useful either to you as a trainer, or SharePoint user, or even a programme manager seeking to identify the key areas of SharePoint training delivery.
Let us begin with a typical picture facing a SharePoint support perspective, featuring the SharePoint Administrator on-premise…. Put yourself in the shoes of such SharePoint Administrator, monitoring a SharePoint environment, and through the wonderful event viewer on SharePoint servers see a whole bunch of reds (Errors) in an Application Event log. After trawling through the sea of ULS logs, Web.Configs and IIS logs on the screen for several hours, trying this and that, crashing out on numerous occasions; you’ve may have just about had enough. Your pride may already hurting from the fact that the SharePoint reference manuals are piled high all over the desk, and still the flashes of understanding and inspiration simply won’t come…
And if you are thinking “Hey that’s easier in SharePoint Online, there’s no event logs to worry about” – think again. Here is an example. User calls in stating that they have problems viewing their site on their phone. So you need to find out the kind of phone they are using, what the mobile settings are, whether the site settings for mobility have been applied and to ensure that all the services they use whilst in the SharePoint site are also accessible. The issue about the SharePoint Administrator simply looking at ‘SharePoint’ is gone. Therefore, looking for the inspirational flashes would become more difficult.
Another example, starring the SharePoint Information Worker:
You have joined an organization who has adopted SharePoint. You have been told to use a SharePoint site so you can store your work content in. After accessing your site for the first time you are daunted by the options there. Site Actions? What’s that? What’s the Breadcrumb Trail? Someone said to get to the ‘Projects Document Library’ by looking in the Quick Launch Bar – What’s that and where is that? In fact, what’s a Document Library? Faced with these bewildering features and options, and faced with having to just read a book to try to understand what they all mean, you decide to use e-mail.
One more example, this time to the ‘experienced’ SharePoint Worker – typically called a Poweruser:
Yes, you may be one of them. You are a person who is comfortable with SharePoint, because SharePoint does what you want it to. You are aware of the relevant functions in SharePoint that makes you productive, but want to learn more.
So where do you go to get the answers you need?
We are already in the world where we have our ‘intelligent agents’ (known to previous tech generations as a genie or guardian angel) can be summoned using good ole’ Google, to hunt down that famous and grail-like Blog, TechNet article, Google Answers, Yahoo Answers – ad-infinitum’. However, as we all know life as a SharePoint Admin, Developer or Architect doesn’t necessarily mean you find the information you want first time! Sometime, hunting down the right answer is like looking for a needle in a stack of needles! For example, in the above example concerning Office365 and setting a mobile to view a site eventually took me to this article:
In truth, there is not yet that silver bullet in training where, at a click of a button, or using some kind of ‘Star Trek like’ speaking into your computer response to answer your SharePoint queries. The ‘Hey; computer – tell me how to setup Kerberos on SharePoint’, or ‘show me what the version history is on my documents” is just not there – yet…
So, perhaps some good old fashioned training is better than nothing. To a lot of people, especially developers in SharePoint I’ve seen, training is ‘the T word’, and almost an admission of defeat.
However, as I’ll describe in this article, there are many ways SharePoint training can be delivered – through the written and spoken word, on the desktop as well as the classroom. Most which are inexpensive and above all, interesting and fun.
Also, lots of SharePoint tools are available that go some way towards realising the equivalent of the genie in the bottle 🙂
1 A potted theory of learning 2
2 Self Paced Training 3
3 Computer Based Training 4
4 Support Resources 5
5 Learning Centres 6
6 The Human Touch 6
7 A Model Student 7
A potted theory of learning
Just in case you’ve never considered how or why you’ve ever learned anything – from being able to read this article to driving a car, let’s go back to basics.
The Competency Ladder.
If you view learning primarily as a ‘damage limitation’ process whilst trying to acquire competency in SharePoint, the following series of stages can be applied to most situations:
Stage 1: Unconscious incompetence – Making large amounts of mistakes.
Stage 2: Conscious incompetence – I see and admit to myself and others I’m making mistakes.
Stage 3: Conscious competence – I am learning new concepts and skills, my error rate is decreasing (normally in a non-linear fashion :)).
Stage 4: Unconscious competence – or ‘what was all the fuss about?’
Now, this four stage cycle is sometimes referred to as the Competency Model for (hopefully) obvious reasons. Where do you think you are on this model? If you are implementing SharePoint, where do you think those about to use SharePoint would be?
Additionally, the competency model really does come into its own when considering your role in SharePoint. Let’s take the SharePoint Administrator situation again. If the SharePoint Administrator is at Stage 1, then making ‘mission critical’ mistakes could result in damage to the relevant SharePoint environment. For SharePoint Information workers, making many mistakes could result in a loss of productivity and confidence in using SharePoint. Both of course could also result in the company loosing money.
In order to move up the competency ladder, we tend to accept that Stages 1 and 2 shouldn’t last for too long at all, and that Stage 3 is worth investing time and money in training. However, learning is never a Stage 1 to 4 kind of deal. It’s a loop as we consider new areas of SharePoint to learn; and; we ensure there are tools available to mitigate Stage 1 and 2 (for example, getting a SharePoint test site to play in).
Training = competency = Training.
So, it is very important to consider that training surrounds the level of competency one has relevant to the tasks they have to perform. Consider the common activity of learning to drive a car. Think of all the would-be Michael Schumachers in cars displaying ‘L’ plates, their terrified parents, and the huge number of driving schools that make a multi-billion pound business from the accepted norm of the need for formal training.
The other accepted of ‘mission critical’ competency is that we need to prove Stage 4 has been reached (hence the driving test) and achieve recognition and certification (the driving license). This certification then allows us to perform various other job roles and for some people it acts as a pre-requisite qualification to apply for a further specialist training, such as the Heavy Goods Vehicle (HGV) License.
The final point to note is the model of cyclical, that is, the tendency is for skills needing to be renewed or modified over time. This is not just because ‘familiarity breeds contempt’, but for the environment in which the original skill set was valid has probably changed. Consider the continued debates about including motorway driving as part of the standard test?
The amount of training you think you need is based on the amount of knowledge to cover your ‘mission critical’ needs. What I mean by ‘mission critical’ needs are the basic skills needed to ensure that what you do is carried out to the satisfaction of ‘your peers, makes you productive and meets / enhances the profile of yourself and the organisation you work for.
So, do you identify your ‘mission critical’ training needs? If you don’t, consider that if crashing your car is obviously a bad thing, then as a SharePoint Administrator isn’t regularly crashing your SharePoint environment equally unacceptable?
If the answer is ‘yes’ then doesn’t that mean from the outset, without admitting defeat, that some investment in training is justified?
Even if you answer ‘no’, implying your using SharePoint as a hobby, not as a means to make a living, would not investing in training help you achieve more satisfaction and avoid some sleepless nights in the process?
Specialist Learning and Exams.
There are some specialist areas of SharePoint where training is very important. SharePoint web development, administration or architecture involves diverse skill sets and key underpinning knowledge of SharePoint. To ensure competency for those roles can be measured there are recognised Microsoft Certification sets (for example; MCTS for 2007, MCITP for 2010, MCSA for Office365, and MCSE for SharePoint 2013). These cover the technical side of SharePoint, namely in application development and configuration in SharePoint.
This is seen as effectively a version of the driving test for those engaged in the technical side of SharePoint.
However, SharePoint is not simply seen as a technical toy! The SharePoint Information Worker is definitely included in terms of competency measurement. When Office 2010 was released, SharePoint became more tightly integrated with Office, and that provided MOS for SharePoint. MOS stands for MOS (Microsoft Office Specialist). The reach of this certification is even greater since it extends to the user of Office of which SharePoint is a partner. Microsoft certification exams are now also aimed at those using SharePoint from an end-users perspective.
People take it as faith that when somebody goes for SharePoint training, they will return wiser and better for the experience. In most cases, they may see a gain in productivity, but whether they failed to learn to their full potential because the course was too easy or too advanced is normally impossible to judge unless some kind of pre-requisite test is available.
Self Paced Training
Given the intangible nature of traditional training benefits, there is a natural appeal to invest in tangible training products, as well as the additional benefits that self-paced training brings – savings in travel and accommodation costs, consistency of delivery, reusability and so on.
Generally, self-paced training always begins with the humble book, yes, in the beginning was the word. The book is the original self-paced training package, and still provides the low-cost learning option, and may be sufficient if your learning requirements are modest or you have no time pressures.
Dividing this into three camps, end user, administration and development, development is more a practical skill. In this respect, books that include the opportunity for hands-on are a more useful choice. In the early days, this included the good ole ‘CDrom’ at the back of the book (and in some amazing examples, USB sticks!), and snippets of information that could be entered. Whilst this also occurs for SharePoint Administrators, the format is different.
For instance, programming related books would contain many worked through examples of code ready used. Administrator books would include scripts and maybe code blocks to apply to SharePoint site collections and servers. End user books would include practice files to apply as you followed guides in the book.
Nowadays though, virtually all SharePoint books now come as e-Books making that kind of information easier to get to. So has the eBook fully replaced the book? An interesting argument. In chatting to a SharePoint Architect the other day, they indicated that having an e-book cluttered the desktop, as opposed to having the book opened so they could work through a problem and fully understand how to do something without having to swop between screens. In other cases, people have found the eBook easier because of its portability, and additionally because it’s easier to copy a script from an eBook than having to rekey all of it or having to access a CDrom, or USB Stick, or Network Share, or OneDrive to get to the information.
The key here though is to understand that self-paced training is based on the resources that you use. E-Books and Books are not the only resources available. There are online resources as well from sites providing blocks of information related to a particular aspect of SharePoint, to those other which cover entire courses and include ‘check’ exams at the end.
Computer Based Training
CBT (Computer Based Training) is one of those touchstones (like AI) that promises much but often disappoints – corporates in millions invest in CBT projects – unfortunately, this often results in delivering too little, too late.
Part of the problem was the need for high cost specialist software and/or lack of mainstream, high level authoring tools and the special skills required to create the relevant packages.
Another problem is the amount of overhead administration given that the CBT would most likely record results of the ‘student’ and these would need to be audited and managed to gauge user productivity and usability of the product.
That said, there is a mass of computer based training for SharePoint; the only thing that needs to be done is to define the scope of training that needs to be provided at either end user, developer, administrator and then to provide that. To do that takes time simply because of the need to factor SharePoint training with desktop software training e.g. Microsoft Office Suite.
For example, there is VLE (Virtual Learning Environment) type training available or even build you own like the SharePoint Learning Kit (this was firstly provided in SharePoint 2007, then arrived on Codeplex for SharePoint 2010 and has been released for SharePoint 2013). There’s Open Learning courses on all things SharePoint at the Microsoft Learning Centre. There’s video clips relevant to carrying out popular tasks and also explaining SharePoint concepts on Youtube, You can also get FAQ and Question and Answer support at Technet (SharePoint Forums).
Additionally, you can also use SharePoint itself to host your very own training centre, because SharePoint has the ability to store and playback images, Flash Hypermedia, so hours of audio-visual tuition could be created by you (a simple web cam and some video editing software will do). This has been done to great effect by SharePoint uber admins out there, some making these learning centres called ‘How Do I(‘ as part of a home for SharePoint in their organisation (like a One Stop Shop ).
However, the sign of a good quality CBT is the inclusion of challenge testing so that students can quickly ‘opt out’ of a section of check understanding plus animated expert solutions and demonstrations to help in those difficult moments. If the product behaves like a linear book with nothing more than electronic page turning, what value does it add over a paper based book?
CBT has come a long way from the earlier days of SharePoint.
For SharePoint 2007, there is a Learning package available for SharePoint which will enable users to actively learn how to use SharePoint and their learning is tracked; it’s on this link:
For SharePoint 2010, the Productivity Hub is targeted at those who need to quickly setup a central location for a knowledge base on SharePoint, Word, Lync and more.
It’s a downloadable product that can be further customised. Additional modules can be added that meet business requirements.
For SharePoint 2013, there is a SharePoint Learning Kit available download in Codeplex. This is a e-learning delivery and tracking application, built as a SharePoint solution, and amongst other things allows assignment, tracking and grading of e-learning and non-e-learning content.
There are also other CBT’s; that could be provided, but you need to pay for them – again, you need to carry out appraisals to identify which best fits the requirement. An example is OnTidWit (which provides a learning platform of collected resources which can be selected) – see http://sharepointgeoff.ontidwit.com for an example.
Strictly speaking, Support Resources are not training tools, but are part of the renewal process once Stage 4 (unconscious competence) has been reached, providing ‘on the job’ information at your fingertips. The most basic form is the electronic manual with a search and retrieval engine, with linked hypertext, a memory of topics visited, suggested related topics and the ability to copy and paste code and scripts for SharePoint.
Microsoft Press now has a good collection of SharePoint books located on this link:
There is the Support Office site which in particular provides information about SharePoint Online – in particular describing the major feature areas:
The Office365 Learning Centre for Business and Education is also an extremely useful resource. This resource helps when providing a SharePoint service – the Discover SharePoint section advises users how to start using a team site, controlling access, customising navigation and many more topics. Additionally, there links to training resources. Check this one out for example, the ‘Organize files in your SharePoint libraries‘ training course.
Additionally, there are a vast list of online resources, like Technet, WSSDemo, EndSharePoint and many others. Again, with all of this information available the issue is the same as having someone ask for a SharePoint site but doesn’t know what to put in it – meaning, what do I need, where do I need it, how will I record it, how will I retrieve it.
Increasingly, there are a number of online providers now pushing Knowledge Bases on SharePoint. Slowly, these are becoming more structured and standardised into their own lands of expertise.
This I think is a good thing. Someone once said to me ‘I’m going to provide a central blog on the Internet that will provide information on everything to do with SharePoint’. I said ‘Wow… That’s going to either take a long time or you will need a hell of a lot of help’ (thinking of it at the time I was being diplomatic – its impossible to provide let along support that resource unless you know everything there is to know about SharePoint and have a huge amount of time to gathering and maintaining that resource).
Note that whilst I call these ‘support resources’ they are definitely not designed to simply be a replacement for your SharePoint company support resource. Information provides on these resources should be tested in your own test environments and validated before putting them into your production environment.
In SharePoint land, in fact, probably with any kind of development, workers find that the normal workplace is not suitable for self-paced learning. They are subject to many interruptions and cannot dedicate the time needed to learn or develop.
Self-Paced products can form the core of a facilitated ‘Learning Centre’. That Learning Centre concept uses training technology to help people learn and become more effective. It does this by recording their activities; how long they are working through a topic and pointers as to where they may get further information concerning an aspect of SharePoint.
Microsoft provides a Learning Centre which displays end user courses, and provides material that should be used when the user wishes to engage in Microsoft Certifications. For SharePoint and Office365, there are specific areas of interest covering End Users, IT Pros and Developers. SharePoint has its own learning segment which includes over 10 separated courses which have been rated.
Microsoft also provides a Certification Roadmap which shows the popular Skills and Certification Roadmap to reflect the latest skills development and certification information, including the new Devices MCSE, Azure exams and exam electives. For a one-stop source for certification pathways, download the roadmap. When looking at the Roadmap, it is interesting to see how SharePoint certification has changed over the ages. The clearer distinction in the fact of simply taking a non-compulsory training course grants an MTA (Microsoft Technology Associate). Also the MCSA Office365 and MCSE SharePoint 2013 are closer together.
What resources are there to help people with taking technical exams?
MeasureUp provides material in the form of test questions to allow individuals to prepare for product certification.
Certiport provides end user certification and provides the MOS (Microsoft Office Specialist) certification tracks for Microsoft Office which includes SharePoint.
These are just the ones I am aware of but there will undoubtedly be others. How valid they are depends on the strategy you adopt for yourself and others, especially if you are setting out a strategy for SharePoint training in the organisation.
The Human Touch
Whilst self-paced courses can provide the majority of training needed, do not forget the value human experience can bring. A hybrid approach is to attend scheduled events where an experienced trainer is available to provide assistance and advice as the student progresses through a self-paced programme. The student also gains from meeting other SharePoint developers, administrators, architects, program managers, exchanging ideas and attending optional break-out sessions on additional topics given by the class leader.
Certain technologies may be best covered by traditional means involving lectures and presentations. Some of these may include:
Microsoft Seminars and Conferences. These are very useful since they bring additional training sessions and normally rolled into the cost. Additionally good to meet with other SharePoint peeps, learn best practices and find out how others are using SharePoint. These are regional and there are many of these. A search on google gave this:
SharePoint User Groups.
There are so many benefits to belonging to a SharePoint user group. You can learn about SharePoint related events applicable to your user group when they become available. You can find out how your peers are solving problems and even sharpen your leadership and managerial skills by serving as a user group manager. The reason why user groups appear as a human touch is because social events usually evolve around them. User groups, whilst revolving around a bulletin board or forum, are regional / local so getting to see faces is definitely an option. This is very useful since it increases your social network and allows you to focus your training resources. Don’t get me wrong, forums are great – SharePoint Technet forum is really good, but to expand your social network there’s nothing like a user group where you can put blogs and articles to faces.
Externally Provided Training
Going back to competency, if you want human touch training you had better make sure that you choose a relevant arena – in SharePoint, there are a number of these – I’ve listed the key ones and in no particular order:
- Content Management
- Social Computing
- Business Productivity
- Look and Feel
- Business Solutions
Within these sections you will find training companies providing resources and instructors in one or more of those arenas. In my experience, make sure you define a strategy for training that connects SharePoint to the business in terms of what other tools SharePoint integrates with. Get a trainer who can instruct and provide resources on those additional levels. There are a number of success stories which details how organisations seeking a training model have managed to provide training to their staff, not only on the different aspects of the technology, but also in combining the best of differing provisions I have covered in this article (CBT, On-Line, Classroom, etc.) – crucially from one training provider. Check out the following case study for more information on how they succeeded.
Finding a good training company can be daunting, like looking for a needle in a stack of needles. Make sure you choose wisely, read-up on their credentials, customer reviews and associated case studies. A good source to get started on choosing a SharePoint training company is here:
Are you a ‘Model Student’?
In the land of SharePoint everyday I learn something new about the product. Whether it is a technical bit of knowledge or even business, governance, implementation – everyday is a voyage of discovery. I am I think, a student but far from being a model student. I reckon a model student is that who has all the resources at hand for the topic area they wish to cover.
So after reading this article, ask yourself these questions.
- What kind of training suits you the most? Book? e-Book? Online Training? CBT? A combination?
- Where do you stand on the competency ladder?
- Do you have access to the resources you need? How do you collate them? Can you quickly find the answers in the resources you have?
- What area do you excel in? Do you have a blog and is this communicated to others?
- How did you learn SharePoint? Reading? Diving into the Platform? Certification? A combination?
- Whatever happens, when tackling SharePoint Training, try to get a vision of where would want to get to, whether you need training to prove to others you are competent, whether you want to solve a problem, or even whether you are attempting to build a strategy for others. Doing this will help you identify the planning that needs to be done, how long it will take and what is needed to succeed.
When delivering an Office 365 service, you will need to ensure that the customer has access to resources to help them understand and get up to speed. As seen with SharePoint ‘getting the users on-board’, there is always a danger of ‘recreating’ adoption content, simply because information is non-centralised – that also means having to spend time gathering and crafting that content so that it is visually appealing (for example)..
This article takes a service delivery examination concerning workflow provisions around SharePoint, Office365, Windows Azure to help you understand the implications there are for organisations needing to improve business process automation, collaboration and productivity through workflow adoption.
Support service development for SharePoint is crucial to ensure sustained SharePoint Governance and User Adoption. I had the situation where in building a SharePoint support service that a customer needed the provision of support to be handled differently for a newly delivered SharePoint solution, and also needed that to be documented and agreed by the SharePoint sponsor. The reason for this is that they needed the support service to be measured against the supply of support to that solution, which was critical to the department and the organization.
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:
- The level of support provided is inadequate to the solution can be scaled
- The deployment process has not been followed, for example, in an ‘on-premise land’, ‘let’s build the lot on production…’
- It’s easier to start building the solution virtually identical to one already in use, than working from the design of another likewise solution, because it is not possible to locate the design for the existing solution.
- Solution ABC is nothing like another solution whose focus is virtually identical and has been built from scratch
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:
- Get a third party organisation to put the solution in for us because we do not have the time to follow any delivery process – but we want to control everything and be able to support it ourselves
- Build a delivery process, show that there is such a process in place, but don’t actually follow the process
- Let’s simply get on with it, build the lot in a ‘fly by night’ fashion, we will deal with all the issues as they arise
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:
- Service Testing
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:
- Be Usable
- Be Repeatable
- Be Supportable
- Be Extensible
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:
- Implementation – what actions needs to be done to ensure that the relevant framework section is in place.
- Consumption – what resources will benefit from the relevant section and what resources should be used to help place the framework section.
- Administration – How you will ensure that the service delivery model relevant to the section includes an element of management. This will ensure the sustainability of the relevant section.
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:
- Get help. Seek a SharePoint solutions architect to help you meld the service framework to match your organisation resources.
- Ensure that to back up the SharePoint framework that you have / using a methodology that allows the framework to connect to, that also allows a logical and structured approach.
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):
- What makes a ‘Usable’ SharePoint Solution
- What makes a ‘Repeatable’ SharePoint Solution Delivery Process
- Defining a ‘Supportable’ SharePoint Solution (TBA)
- What makes an ‘Extensible’ SharePoint Solution (TBA)
Lets take a look at developing Road Maps for SharePoint. Now, before you start yawning and thinking ‘Like I need to know about Road Maps?’ – Well, let me tell you that whenever you deliver solutions in SharePoint you should at the very least be thinking of how not only what the capabilities required to build those solutions, but also consider support, user consumption, and administration of SharePoint solutions in an ever changing organization technology landscape (whew). That means building Road Maps.
If you design SharePoint solutions, you will at least be thinking, ‘I want the solution provided to my SharePoint users to last as long as SharePoint does’. If that’s not your thinking on delivering SharePoint solutions, one might say ‘Why are you delivering solutions for into SharePoint in the first place’?
The challenge is what process do you adopt to even start thinking of Road Maps for SharePoint? When talking about this to other SharePoint solution architects they generally have their own ideas, but it is a massive topic to consider. This short article therefore is to look at what layers need aid Road Map development in SharePoint. There will be following further articles looking at each of those layers, describing detail behind each, along with key actions that are required.
A SharePoint roadmap takes the relevant customer goals, prioritises them into short, mid and long terms and defines a plan that provisions those services. You do this to ensure that the solutions being provisioned within SharePoint, whether they be default, third party, internally developed, integrated meet the customer needs and at the same time helps planning future SharePoint developments. This is not to be confused with simple SharePoint implementation; developing a road map for SharePoint requires a thought process which encapsulates the fundamental goals of the customer in utilising the relevant technologies in order to fulfil the key SharePoint premise: “To create and manage content in a website”.
Through engagements and interactions with customers over the last couple of years, I have recognized a need to document the capabilities required to aid the development of a Road map for SharePoint. For example, one client had a hard time appreciating the need for site design and user experience. They were quite content using automated tools to drive site development without challenging those requirements or even managing the process. Through explaining the importance of delivering solutions through a modular approach it has helped the customer not only understand but engage with the development of processes manage site design and user experience in SharePoint for their user-base.
My challenge though has always been mapping SharePoint requirements to not simply refer to a technology release, but into a Road Map which ensures the future-proofing of that SharePoint solution. So, that means not simply looking at SharePoint in a gold fish bowl. It is taking into consideration all other services and processes that the client has through their use of the technology available to them, and making sure that whatever solution is provided follows a defined method of delivery.
I found that it is important to recognize that not all capabilities of the solution being delivered are driven by the actual service owner, or the provider of the components being provided in the solution. For example, if an app that allows automation of a process is deployed in a SharePoint site, which does not necessarily mean that the exact same app can be used in another site meeting all the requirements of that new site. No two sites are identical – the reasons for their existence are never identical, even the support matrix for each site is never identical.
What Capabilities are needed
So, let’s firstly take a look at the three perspectives that aids the development of a Road Map for SharePoint.
- Implementation. This relates to the development and the deployment of the SharePoint solution and from only the providers perspective. This area is the one virtually all organizations appreciate by default and requires the least of clarification. For example, when procuring a third party application which provides SharePoint capabilities, there is an assumption that the implementation process is documented, and can be adhered to (assuming that the SharePoint organization does its home work and identifies these things up front beforehand!). Likewise, developing a solution in-house that relies on several SharePoint components, third party apps and data-sources internal to the organization needs to follow an implementation process that can be repeated. Again, this is something that the customer assumes will take place, and it is highly unlikely that the provider would not define a method of implementation.
- Consumption. This relates to the consumers of the services provided by the SharePoint solution, thus making the solution easier to implement and successfully adopted. Of the three capabilities, this is the area that I have found is somewhat neglected by customers. In other words, customers are simply not leveraging the services provisioned through the SharePoint solution, or, there has not been enough work to identify the value that the service will provide to the customer. Check out the Value Management in SharePoint article for further information.
- Administration. Any solution in SharePoint needs to follow an operational management procedure to ensure stability, and adheres to several governance rules that are both organizational and platform related. This will include proactive monitoring, support, automation rules, reports of usage, etc. The fact that user analytics is seen as an important measure and driver to adoption, and the fact that SharePoint provides usage information (and a number of third party products also provide this and more), means that this perspective is now recognized and appreciated. That said, more needs to be understood about its value and impact.
These capabilities are needed within all SharePoint solutions. It is important to realize that an organization can choose to focus on one or two of the capabilities listed above, but the overall maturity of the SharePoint solution, and hence, the overall value of the SharePoint services, depend on all three. Neglecting any of the three will have consequences – some more readily apparent than others.
To put this into context, appreciate that all services that are in the Road Map need to be extensible, supportable, repeatable and usable. Administration, Support and Implementation are all factors to consider for each service as stated. As an explanation:
- Extensible means that the SharePoint solution is capable of aggregating services and extending its use beyond its own borders. From a simply perspective, take a basic SharePoint site. Then, by adding components to meet the user requirement the SharePoint site grows. However, extensibility is not just growing a site. It’s managing the growth in such a way that the service grows using mostly enterprise technology.
- Supportable means that the SharePoint solution can effectively be managed even when services are increased against relevant SLAs.
- Repeatable means that SharePoint solutions can be implemented by reusing standard and defined processes. It also means that those solutions can consume and reuse relevant services efficiently and consistently. Examples of this includes using third party apps to deliver SharePoint productivity and ensuring they are set in such a way to provide the likewise functionality in other SharePoint solutions.
- Usable means that SharePoint solutions can if necessary use standard mechanisms to connect to enterprise technology. This is very important in order to keep pace with changes in SharePoint and connected technologies.
The four topics above, Extensive, Supportable, Repeatable and Usable are vital aspects in SharePoint service delivery. I use them as a mantra when designing, developing, and implementing SharePoint solutions. They will each have an article devoted to them where I hope to go into more detail on what each means and how you can apply them to your SharePoint solution delivery processes.
As pointed out in the start of this article, the topics discussed in this article will be expanded in future articles (particularly Extensible, Supportable, Repeatable and Usable). The capabilities whose thinking needs to be planted into your SharePoint Road Map are:
- Implementation. Ensuring that the design and development of all SharePoint solutions is optimised.
- Consumption. Ensuring that the services can be used by others which includes all aspects of continual service provision, like support, adoption, training, roll-outs of enhancement services, etc.
- Administration. Ensuring that the SharePoint services being provided are stable and governed. That means proactive monitoring, ownership, configuration management.
This (short) article has been an attempt at describing the key facets that help build a SharePoint Road Map. While it is important to know where you are (hence the reason for starting to build a Road Map in the first place), getting an exact bearing is less important than identifying the capabilities needed to address, so you can continue the advancing the value of SharePoint in your organization. As long as you are willing to ask yourself some hard questions in an objective manner across all the relevant SharePoint services, including third party, integrated and internally developed, you should be able to get a good understanding for your current challenges. If you apply the strategy and objectives of SharePoint, you will be able to identify which capabilities you will need to address in the short, mid and long term.
Time for another support article, and I’ll concentrate in this area for the next month or so since it is a key aspect of SharePoint Service Delivery, and crucial to sustaining SharePoint User Adoption. I put an article to the wonderful MS TechNet guys, and am so pleased they published it! The article is a ‘thought’ piece based on the importance of identifying exactly what in a SharePoint environment should be supported, and suggestions of some methods used to set those expectations back to those using the solutions provided (and therefore supported) in that SharePoint environment. To describe this, I’ve used a scenario common to many organisations using SharePoint. Anyway, best you read the article located here, and hope you find it useful!
With every SharePoint solution being delivered, there is comes a change management effort that requires not only organizational, but also behavioural change on the part of the participants. You can set up the finest SharePoint solution on the planet, but if people do not take to the SharePoint solution, nothing will change and the effort will be lost.
“To get a horse to drink water, you make the horse thirsty”
Successful adoption of any SharePoint solution enables users with self determination. Irrespective of user task, or position, self determination needs three factors, which is competence, relatedness and autonomy. These combined produces motivation. And, when you have self determined people, support requirements are properly defined, people understand how the solution makes their tasks more productive, training strategies are easier to develop and sustain. A key person requirement, which is not technical, is the SharePoint Champion; whose objective is to foster self-determination amongs their peers; a person elected to help drive adoption of SharePoint solutions, elected by the business, and for the business.
I wrote a pretty detailed piece on the topic of SharePoint Champion being a vital role, because I think it is so important to provide successful service delivery of SharePoint solutions. To see this, check out on Microsoft TechNet Newsletters article posted here:
Hope you find the article useful!
The SharePoint 2010 Productivity Hub and the User Adoption Kits for SharePoint 2010 and SharePoint 2013 are great tools of centralizing knowledge in the organization, providing materials to enable the communication of SharePoint to information workers and helping organizations address User Adoption principles. (more…)
Tracking site usage is a very important method of identifying and helping sustain user adoption of a SharePoint 2013 site. Using site usage statistics can help prove the take up of a new SharePoint site, identify shortfalls in the design, and indicates how searches are being used and whether they are effective and optimised. There is a usage report available in SharePoint 2013, which shows historical usage information about the site, such as the number of views and unique users.
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:
- Align organizational goals and requirements
- Define the full scope of the project
- Set up a team to deliver a SharePoint solution
- Effectively communicate with and include your stakeholders
- Prepare for user feedback and adoption
- Establish and maintain governance through the entire project
- Use web analytics to provide substance to governance
- Confirm readiness for delivery to the organization
Go here to get the book and find out more information.
SharePoint Service Delivery concerns itself with capability, and the methods used to ensure that the clients SharePoint vision and goals align with the users, and includes focusing how those responsible for managing the platform (the technical teams) fit and provide that service through guiding principles. These, if followed will ensure that your SharePoint environment can be managed in a structured and measured way.
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.