SharePoint 2016: Application of Systems Engineering Methods to a Deployed SharePoint System

Article
1/17/2024

Status: Final

Abstract

This posting presents a proposal for the application of systems engineering to an already deployed SharePoint system as a means of resolving challenges frequently associated with deployed SharePoint systems. This posting first briefly reviews general challenges associated with SharePoint systems and how the post-deployment application of systems engineering can resolve these challenges. It then reviews the standard systems engineering process followed by a more detailed review of the modified, post-deployment systems engineering process. This posting then concludes by discussing the benefits of performing post-deployment systems engineering.

Introduction

Microsoft SharePoint is a highly scalable information management system widely used in government and commercial organizations to: centrally manage content, provide the tools necessary to engage in online collaboration, automate business processes and develop web portals. It employs a complex distributed, system of systems architecture composed of multiple application, database and web servers hosted on one or more Windows Servers and all communicating asynchronously.

Microsoft SharePoint systems are frequently initiated as point solutions that are then developed organically into enterprise platforms in response to changing business needs and objectives, without scoping exercises or business planning, on the basis of “let’s see what it can do” (AIIM, 2015).

Figure 1: SharePoint adoption ladder.

SharePoint consultants have reported that their clients who are seeking to implement SharePoint “…cannot clearly articulate why they want to implement it” (All, 2010). One survey found that more than half of respondents reported deploying SharePoint in an unplanned manner (AIIM, 2010), a finding that persisted four years later (McNeice, 2014). Industry surveys have found that less than 50% of organizations that had deployed SharePoint systems engaged in formal business case development prior to deployment (Efta, 2010), (McNeice, 2014), and, of these, less than half required financial justification (Efta, 2010). One independent consult reports the primary cause of SharePoint project failure to be a lack of vision and clear planning (Neal, 2014). Another consult stresses the importance of identifying requirements, stakeholders, scope, risks and dependencies in order to successfully accomplish SharePoint projects (Bailey, 2013). Many consultants stress the importance of planning (Williams, 2011), (Neal, 2014) (Byrne, 2009) (Bailey, 2013). Over 62% of organizations have been found to use SharePoint as their primary, secondary or legacy ECM system, with over 40% indicating that SharePoint is their primary ECM system; these organizations also report poor content management, limited adoption, limited implementation of SharePoint capabilities, poor change management and ineffective governance (AIIM, 2016). These challenges can be remedied through the application of post-deployment systems engineering.

Post-deployment systems engineering applies the methods of standard systems engineering to a system that has already been deployed so as to develop the critical system artifacts needed to effectively integrate the SharePoint system into organizational business processes. The advantage of using systems engineering methods is the structured and systematic approach that it brings to the development of these artifacts and the minimization of stovepipe methods.

For example, the owner of a SharePoint system may cause a baseline to be completed in preparation for:

Meeting the requirements of Federal Information Security Management Act (Public Law 107–347, 2002) in preparing the Authorization To Operate (ATO) for the system;
Developing a change management system in conformance with : IT Infrastructure Library (ITIL) standards;
Planning SharePoint system disaster recovery as part of business continuity planning; or in preparation of
Technical and end user training documentation.

Or consider a senior management directive to draft SharePoint system use cases needed for:

Implementation of standards for organizational business processes, some of which involve the organization’s SharePoint system
Guiding the effective development of end user training curriculum needed to facilitate user adoption of a SharePoint system
The more effective elicitation of requirements needed for wider, enterprise deployment of a departmental SharePoint system

These tasks may be initiated individually, as separate tasks, leading to potential redundancy or loss of data and inefficient application of human resources. Whereas, if conducted within post-deployment systems engineering, they are engaged in an integrated manner providing greater opportunity for more efficient resource allocation and knowledge transfer and re-use across all tasks.

Standard Systems Engineering Process

Standard systems engineering involves an organized and systematic approach to the development of complex systems. Its focus is on the design, development, integration and testing of a system of interrelated components working together to meet a problem. This approach tends to be a technical one, organized in such a fashion that focuses first on defining the problem in terms of the needs, requirements and operational concepts as presented by the future users of the solutions and products, before engaging in designing and developing the system to meet the problem. It also engages external factors affecting the development of the system, such as the intended operational environment of the system, its logistical support and the capabilities of the users of the system. It is iterative in nature, as the lessons-learned and emergent discoveries of various tasks in the systems engineering approach are applied to previous tasks and those previous tasks re-engaged so as to improve their output and contribution to the development of the system. This process is engaged with the intent of designing a better product than might otherwise be accomplished.

There are a variety of approaches that may be used for performing systems engineering. The approach that will be engaged here in this effort is best represented using the systems engineering “V” diagram (Kossiakoff, Sweet, Seymour, & Biemer, 2011). In this approach, the common project tasks of requirements analysis, design, development, testing and deployment are presented in an orderly fashion that intuitively depicts their sequence and interrelationships.

Figure 2: Standard Systems Engineering "V" Diagram. Source: (FHWA, 2007)

In standard systems engineering, the systems engineering process begins with examination of the regional architecture and how that architecture is related to the proposed system; and it involves discovering and collating all artifacts relevant to the project. This effort serves to initially define the system boundary. The feasibility and concept exploration phase examines whether it will be realistically possible to develop a solution to the problem or need, what potential solutions there might be and what might be the best possible solution. The concept of operations phase presents the understanding of the problem and the proposed solution to that problem in the context of the problem environment. This effort serves to initially define how the system will interact with its environment. During the system requirements phase, the boundaries of the proposed solution with its environment are materialized. In high-level design, also referred to as preliminary design or conceptual design (NASA, 2009), effort focuses on developing the overall system architecture in a way that correctly implements system requirements. During the detailed design phase, the system requirements are translated into the specific physical requirements for how the proposed system is to be built.

Actual development of the system proceeds during the Software/Hardware Development and Field Installation phase. Once the system is developed, it undergoes progressively higher level testing, from unit to system testing. This first phase of testing serves to verify that the system was built according to its specifications (i.e., “the systems was built right”). The second phase of testing serves to validate that the system meets the intended design needs identified in the concept of operations (i.e., “the right system was built”). On successful completion of verification and validation testing, the system enters into its operational and maintenance phase, where it remains until retirement or replacement. This approach to systems engineering activities is diagrammed on the systems engineering “V” diagram, as presented in Figure 2. This approach to systems engineering is the context in which this proposal for the Application of Systems Engineering Methods to a Deployed SharePoint System is engaged and understood. In this approach, and, indeed for any systems engineering project, the systems engineering solution development process proceeds from an initial undefined state and advances towards a desired, proposed state, referred to as the “to-be” solution. Each advance in this process incrementally resolves the proposed solution against the continuum of possible solutions, increasingly narrowing the scope of possible solutions until only a few or just one remains as the best possible solution to the original problem. The only change introduced to this process by post-deployment systems engineering is that, in both forms, the solution process proceeds from an undefined state; however, in post deployment systems engineering, the solution process does not so much advance to a theoretical solution that is increasingly resolved against a continuum, but to an actual “as-built” solution that is known but not yet defined.

Change in Solution Definition

Performing post-deployment systems engineering differs from standard systems engineering in two fundamental ways. These include: 1) the definition of the solution that systems engineering is working towards; and 2) the metrics that are used to measure solution development, completeness and effectiveness.

In standard systems engineering, system development proceeds from a large and mostly undefined system solution space to a specific, well-defined “to-be” system solution. This solution is generally not the only possible solution, but is usually the optimal one of a set of possible solutions meeting system requirements. A notional sense of this development is provided in Figure 3, below.

Figure 3: Standard Systems Engineering Process Timeline.

In post-deployment systems engineering, the systems engineering process generally follows the same series of steps executed in standard systems engineering. However, in post-deployment systems engineering, the systems engineering process no longer works towards the “to-be” solution but to the “as-built” solution. Additionally, the post- deployment systems engineering process may elucidate other possible solutions to requirements, but these other solutions are not possible solutions in the standard systems engineering sense but are solutions in the sense of post-deployment change management. A notional sense of this development is provided in Figure 4, below.

Figure 4: Post-Deployment Systems Engineering Timeline.

This fundamental change in the solution definition introduces various modifications to the standard systems engineering processes. Some tasks that would normally be performed in standard systems engineering are found to not return significant value in post-deployment systems engineering and do not need to be performed. Some other tasks with a typical systems engineering phase become optional, introducing useful but not necessary value to the process. The core tasks among the various phases remain useful and productively contribute to the systems engineering process as they do for traditional systems engineering.

Modified Process

Overview

Post-deployment systems engineering process follows the standard “V-process” with some modifications. Some phases of the standard systems engineering process can be skipped, and other phases can be attenuated. Determining the applicability and usefulness of a standard systems engineering phase to post-deployment engineering is analyzed here on an individual basis.

Regional Architecture

In this initial systems engineering phase, the modified post-deployment focus is on discovering and gathering relevant artifacts associated with the as-built system and its environment, including:

Gathering artifacts relevant to the system’s network environment
Reviewing existing documentation and determining what is available, what is missing from a systems engineering perspective, what can be modified and what must be created new
Discussing and negotiating with system owner the general scope of the post-deployment systems engineering project, identifying milestones and deliverables and presenting a general plan for the performance of post-deployment systems engineering on the owner’s system
Initial efforts in identifying, prioritizing and mitigating system risks

The general systems engineering plan developed during this phase will not be static but will continually be updated as facts emerge and efforts evolve. Data collection methods involved with performing this phase in post-deployment systems engineering, include:

Reviews of existing environment and system documentation (if any);
Interviews with system owner, engineers, administrators, key stakeholders;
Reviews of applicable Microsoft TechNet SharePoint library documentation; and
Examination of the system itself and its environment

Feasibility Study and Concept Exploration

The feasibility study and concept exploration tasks performed in standard systems engineering are generally of little value in post-deployment systems engineering:

The deployed system is already known to be feasible, since it has been operational for some time,
There is no uncertainty as to which conceptual approach to implement, since the deployed system effectively represents the particular concept that was chosen.

On the other hand, while a concept trade study would not yield value from a technical perspective, it might still return substantive value from a management perspective:

Obtain a better understanding of how the deployed SharePoint system compares against other systems having similar capabilities
Be able to engage policy and budget matters with senior management from a more informed perspective

Data collection methods involved with performing this phase in post-deployment systems engineering, include:

Internet searches and
Interviews with system owner and stakeholders, system users.

Concept of Operations

The concept of operations is the first significant deliverable that the post-deployment systems engineer will deliver to the system owner / customer. The CONOPS represents a tangible product providing a clear understanding of the system within the organization from the perspective of the system’s users. From a post-deployment systems engineering perspective, the CONOPS provides a useful milestone and metric to management in demonstrating that the post-deployment systems engineering task is proceeding productively. It effectively provides management with a key milestone, a Go/No Go decision point.

One key CONOPS task, development of the system validation plan, may not yield immediate value since the already deployed system has effectively already been validated. On the other hand, it can still be useful to engage in post-deployment system validation, as the results of performing system validation can be used to:

Corroborate the completeness and accuracy of the CONOPS and to
Identify new capabilities and services for the system to deliver to its users

Data collection methods involved with performing this phase in post-deployment systems engineering, include:

Interviews with system owner and stakeholders, system engineers and administrators, network administrators,
Reviews of existing system and environment documentation,
Examination of the system itself and its environment and
Reviews of SharePoint technical documentation

System Requirements

The system requirements document (SRD) and the system performance specification will be the two major deliverables resulting from performing the post-deployment systems requirements phase. Specific attention must be given to the clear separation of requirements that apply to the current as-built state of the system from its desired, “to-be,” state. Capturing both types of requirements adds significant value to the deployed system. Capturing as-built requirements enables the organization to more effectively:

Measure system performance and thus the system’s ROI
Integrate the system into existing business processes
Identify stakeholders and draft service level agreements and
Conduct more effective and accurate change management

Capturing prospective, “to-be”, system requirements adds value to the post-deployment systems engineering requirements development process as they capture capability gaps that can be addressed through change management. Once the set of system requirements are captured, collated and defined in the SRD, the second phase of this task involves translating these user requirements into technical requirements so as to define the functional baseline of the system. Data collection methods involved with performing this phase in post-deployment systems engineering, include:

Interviews with system owner and stakeholders
Reviews of Microsoft TechNet SharePoint library documentation
Reviews of existing system and environment documentation and
Examination of the system itself and its environment

System Design

This is the third most significant phase in post-deployment systems engineering of a deployed SharePoint system. It is the phase during which the system is thoroughly documented or baselined. It is also a useful milestone and metric in the post-deployment engineering process, this time from the technical perspective, in that it provides technical staff with a Go/No Go decision point. There are two distinct activities and deliverables accomplished during this phase:

High-level design, Conceptual Design Report
Detailed design, System Specification

A conceptual design report that has been approved by IT staff is an important confidence building measure in the post- deployment systems engineering process. A system specification of the deployed SharePoint system effectively defines the baseline of the system. A baseline is the core of every best practice or standardized change management system. Both of these deliverables represent knowledge transfer and capture from IT staff and SharePoint administrators to system documentation. The data collection methods engaged during this phase include:

Reviews of existing system and environment documentation
Examination of the system itself and its environment

Software/Hardware Development and Field Installation

The development stage in the standard systems engineering approach is of little value in post-deployment systems engineering since the system is already developed and deployed. Thus, this stage can generally be skipped in post- deployment systems engineering without adverse impact to the systems engineering process for already deployed systems. On the other hand, some of the secondary products of this stage, such as training materials, user manuals, installation and other documents may be of value if they have not yet been created.

For example, an administrator’s manual capturing the corporate knowledge of the SharePoint administrator team would be invaluable for helping ensure business continuity of the SharePoint system and engaging in facilitating consistency in routine, repetitive administrative tasks. An installation manual would be highly useful for standardizing SharePoint system deployment within the organization, such as for: 1) deploying staging and development systems, 2) interim staging systems needed for migration purposes, and 3) temporary development environments for individual software developers and administrators. Additionally, if service demands increase on the deployed production SharePoint system, there may be a need to deploy regional systems or systems dedicated to specific SharePoint services, such as Search and Managed Metadata. The installation manual developed at this stage is unique to the organization’s environment and thus identifies and defines the best SharePoint system deployment path for the organization.

Reviews of existing system and environment documentation
Examination of the system itself and its environment
Interviews with environment and system engineers and administrators
Interviews with developers

Unit Testing

In standard systems engineering, the unit/device testing stage involves software and hardware testing so as to find and identify as many defects as possible. In post-deployment systems engineering, the system has already been developed and deployed, its defects have already been identified and resolved, and the system is operational and performing. Therefore, there is no immediate value returned in performing the primary activity of this stage, finding defects. However, some substantive value can still be obtained in performing supporting activities of this stage, such as drafting test cases and drafting a unit verification plan. Test cases and a unit verification plan can be used in developing a regression testing procedure for the SharePoint system that can be performed after:

Installing patches
Installing upgrades
Deploying custom sandbox and farm solutions
Modifying user interfaces
Changing farm configuration

The data collection methods engaged during this phase include:

Interviews with system owners, stakeholders and users
Reviews of system documentation
Reviews of Microsoft TechNet SharePoint library documentation

Subsystem Verification

In standard systems engineering, the subsystem verification stage involves integrating the various developed components and verifying that these components accomplish their intended design objectives and requirements. In post-deployment systems engineering, the system has already been integrated from its components and is deployed & operational. Thus, the components are presumed to have met their design objectives and requirements, and standard subsystem verification against system requirements is not immediately unnecessary. In other words, the subsystems are presumed to have been “built right”. Thus, the focus of this phase is less on subsystems meeting requirements and now more on whether the requirement accurately reflect these subsystems.

Note that a SharePoint system is actually a system of systems, since it is composed of such components as Windows Server, SQL Server, IIS Server, etc, that provide services not dependent on SharePoint Server but can functioning independently of SharePoint Server Thus, subsystem verification includes verification of SharePoint system’s component systems, as well as the associated subsystems of these systems. Component systems include: Windows Server, SQL Server, SharePoint Server, etc…

On the other hand, the subsystem verification process in post-deployment systems engineering can be used to refine the previously developed “as-built” and “to-be” requirements against subsystems as they have actually been deployed. These deltas will involve refinements and optimizations to subsystem components and can be engaged through standard change management.

For example, the primary components of a SharePoint system, such as Windows Server, SQL Server, SharePoint Server, AppFabric Server and so on can be analyzed for the effectiveness of their deployment. The same approach would be applied to the effective deployment of role servers, such as Web Front End servers, Batch and Application servers, Office Web App Servers, AppFabric servers (when hosted separately) or App servers (as defined in the Microsoft App model).

Any deltas against “as-built” requirements would be considered as optimizations for attention through change management. Similarly, SharePoint system components can be analyzed against “to-be” system requirements. Any deltas against “to-be” requirements would be considered as potential enhancements for attention through change management.

Data collection methods engaged during this phase would include:

Interviews with system administrators
Reviews of Microsoft TechNet SharePoint library documentation
Reviews of existing system documentation and system requirements

System Verification and Deployment

In standard systems engineering, the system verification stage follows the subsystem verification stage and involves looking for defects in the fully integrated system and verifying that the fully integrated system meets system requirements. In post-deployment systems engineering, the system is already deployed and operational. Thus the system is presumed to have met its operational requirements, and standard system verification is not immediately necessary. In other words, the system is presumed to have been “built right.”

On the other hand, the system verification process in post-deployment systems engineering can be used to refine the previously developed as-built and “to-be” requirements against the integrated system as it was actually deployed. Deltas identified from the as-built can be used to optimize the requirements developed in an earlier stage. Deltas identified from the “to-be” will involve enhancements to the integrated system that can be engaged through standard change management.

For example, integrated systems, such as Windows Server or SQL Server, or integrated subsystems, such as Search and Office Web Apps, can be analyzed against as-built requirements for potential optimizations. Similarly, these can be analyzed against “to-be” requirements to identify potential enhancements. Both optimizations and enhancements would be engaged via standard change management.

The deployment phase is not immediately necessary in post-deployment systems engineering since the system is already deployed. On the other hand, this phase can be used to review and improve existing deployment documentation.

Data collection methods engaged during these phases include:

Reviews of system requirements, conceptual design, Microsoft TechNet SharePoint library documentation and existing system documentation
Reviews of notes captured from past interviews with system owner, stakeholders and users

System Validation

In standard systems engineering, system validation occurs after the system has been fully deployed and involves testing performed by the customer that validates the customer’s original needs and objectives that where presented in the CONOPS. Previously, in the subsystem and system verification phases, testing was performed to ensure that the system was built right. The system validation phase engages in testing that ensures the right system was built.

In post-deployment systems engineering, the system has effectively already been validated, since it is fully deployed and operational. The already deployed system is thus deemed to be fully validated and is therefore the right system. Were it otherwise, the post-deployment engineering process would effectively be engaging in standard systems engineering and working towards a complete solution. Thus, the system validation phase does not yield immediately necessary results. On the other hand, this phase can be used to:

Corroborate the completeness and accuracy of the CONOPS developed previously
Identify new capabilities and services for the system to deliver to its users

This is why the development of a system validation plan, as discussed previously, may still be worth the effort in validating that the system was documented right.

Data collection methods engaged during this phase include:

Reviews of the CONOPS, System requirements and System validation report

Operations and Maintenance

In standard systems engineering, the Operations and Maintenance phase involves the system being accepted by the customer and entering its period of steady-state operation where it is being used to meet its objectives. In post-deployment systems engineering, the system is already accepted, deployed and deemed to be meeting its objectives. Thus, the Operations and Maintenance phase of post-deployment systems engineering marks the completion of the post-deployment systems engineering process and there is little more to be done.

On the other hand, this phase can be usefully employed in reviewing and optimizing existing performance monitoring and maintenance processes and procedures if they exist or creating new ones if they don’t. Optimization of these is facilitated through the application of the rigorously defined and now verified requirements – requirements that may not have existed, or at least been documented, previously. If performance metrics were not previously developed, these can now be created against these requirements.

Similarly, maintenance processes and procedures can also be improved. As a result of having a fully defined system, these maintenance processes and procedures can be better aligned with the system, and technical staff can better support and justify their maintenance processes and procedures to other IT staff and to management.

Completion of the Operations and Maintenance phase marks the end of post-deployment systems engineering. On completion of this phase of systems engineering, the post-deployment systems engineering process has accurately and completely characterized the already-deployment SharePoint system, which is now not only known but also well-defined.

Data collection methods engaged during this phase include:

Reviews of system requirements, performance monitoring and maintenance plans and procedures
Interviews of technical staff

Metrics

The value added to the organization’s investment in a SharePoint system by the post-deployment application of systems engineering will initially be more qualitative than quantitative, but then becomes more measurable as the products of systems engineering return substantive value to organizational business processes. Initial qualitative metrics can measure such things as:

Completion of a standard systems engineering product
Completion of the product advancing the ability of the organization to engage certain business process having dependencies to that product
Completion of the product advancing the ability of the organization to implement an associated ISO, ITIL or SEI process.

The long term quantitative metrics will be those normally associated with the ITIL, ISO, business continuity planning or other process. Another long term qualitative metric that management will be able to identify will be the reduction or even elimination of effective but stovepipe implementation solutions to individual business processes (eg, IT service management, upgrade planning, disaster recovery) through the integration of these solutions via systems engineering.

Conclusion

This posting has presented a proposal for the application of systems engineering methods to an already deployed SharePoint system. This proposal employs the known and existing tools commonly and widely used in performing systems engineering in the development of new systems to a system that is already deployed but undefined. The primary advantages of post-deployment systems engineering are the efficiencies and process improvements made possible through the systematic and integrated application of methods to accomplish common tasks for deployed systems that are otherwise engaged using effective but stovepipe methods.

References

AIIM. (2010)
State of the ECM Industry 2010. Silver Spring: AIIM. Retrieved January 11, 2017, from http://www.aiim.org/pdfdocuments/39451.pdf

AIIM. (2015)
Connecting and Optimizing SharePoint – important strategy choices. Research. Silver Spring: AIIM. Retrieved January 11, 2016, from Association for Information and Image Management: www.aiim.org/research

AIIM. (2016)
What We Learned from the AIIM Community in 2016 and What We See in 2017. Silver Spring: AIIM. Retrieved from www.aiim.org/research

All, A. (2010, September 6)
Lack of Governance Can Cause SharePoint Headaches. Retrieved January 11, 2017, from IT Business Edge: http://www.itbusinessedge.com/cm/blogs/all/lack-of-governance-can-cause-sharepoint-headaches/?cs=43129

Bailey, M. J. (2013, June 13)
Stop SharePoint Project Failure. Retrieved from Slide Share: http://www.slideshare.net/MatthewJBailey/stop- sharepoint-project-failure Byrne, T. (2009, August 26). Do SharePoint Right Before It Does You Wrong. Retrieved from Information Week: http://www.informationweek.com/software/information-management/do-sharepoint-right-before-it-does-you-wrong/d/d- id/1082572

Efta, K. (2010, July 13)
Research Shows SharePoint Surge Continues but Strategies Lacking. NothingButSharePoint.Com, p. 1. Retrieved January 11, 2017, from https://www.nothingbutsharepoint.com/2010/07/13/research-shows-sharepoint-surge-continues-but- strategies- lacking-aspx/

FHWA. (2007, Jan)
Systems Engineering for Intelligent Transportation Systems Guide. Retrieved from United States Department of Transportation - Federal Highway Administration: https://ops.fhwa.dot.gov/publications/seitsguide/

Kossiakoff, A., Sweet, W. N., Seymour, S. J., & Biemer, S. M. (2011)
Systems Engineering Principles and Practice. Hoboken, NJ: Wiley & Sons.

McNeice, I. (2014)
The Anatomy of a SharePoint Strategy. Berkshire: Morgan & Wolfe. Retrieved January 11, 2017, from http://www.morganandwolfe.com/anatomystrategy.pdf

Microsoft. (2013)
SharePoint Adoption Guide. Redmond: Microsoft. Retrieved January 11, 2017, from http://download.microsoft.com/download/F/6/5/F65D8AB6-772F-400B-8982-7D6439FA7D9B/Sharepoint_Adoption_Guide.pdf

NASA. (2009, Oct 19)
Preliminary Design Phase. Retrieved Feb 14, 2017, from Assurance Process for Complex Electronics: http://www.hq.nasa.gov/office/codeq/software/ComplexElectronics/l_prelim_design.htm

Neal, W. (2014, April 4)
4 Common Reasons SharePoint Projects Fail. Retrieved January 17, 2017, from CMS Wire: http://www.cmswire.com/cms/social-business/4-common-reasons-sharepoint-projects-fail-024730.php

Public Law 107–347. (2002, December 17)
Public Law 107–347, Federal Information Security Management Act of 2002. United States Goverment Printing Office, 72. Retrieved Feb 3, 2017, from https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf

Williams, R. (2011, August 25)
Guiding a Successful SharePoint Implementation. Retrieved from Slide Share: http://www.slideshare.net/hawaiianmetal/guiding-a-successful-sharepoint-implementation

tbd

Share via