Addressing Change Management

                 

 
Special Edition Using Microsoft SharePoint Portal Server
By Robert  Ferguson

Table of Contents
Chapter  20.   Example Scenario 1 ”Planning a Deployment


While the process of managing change merits complete volumes in and of itself, we would be amiss if change management was not covered at least briefly from a deployment planning perspective. Once a workspace and dashboard are close to being completed, thought must be given to how future changes will be promoted into the eventual productive implementation.

ABC Company believed that they had an adequate "change management" approach integrated into how they planned and deployed IT solutions for business problems. In reality, though, as we uncovered previously, a number of issues spoke to major change management shortcomings. For example

  • Changes to production resources previously resulted in many hours of unplanned downtime

  • A lack of "test" or "technical sandbox" resources previously necessitated implementing changes directly into production environments

A quick review of change management, outlining its value and importance in terms of maintaining a highly available portal solution, is in order.

Change Management Overview

A productive SharePoint Portal Server environment is not expected to remain static. That is, as business requirements, software upgrades, OS and hardware updates, and more changes are requested /required, the environment will evolve over time. While this evolution is good in terms of keeping a customer's employees productive and informed, an enormous opportunity to introduce instability into the production environment exists. Therefore, if these changes are not managed well, and managed consistently, the result over time will be not unlike the state of many currently deployed enterprise portals ”somewhat unreliable, prone to unscheduled downtime, and more difficult to manage than required. Traditionally, change management in PC server-based environments has been poor, the result of few mission-critical systems in these types of environments until perhaps four or five years ago. The successful PC server-based enterprise application projects have embraced what can only be described as a "Mainframe mentality " to change control ”these folks have taken change control seriously, and it shows in their high system uptimes and low unplanned outages. The following has been written in an attempt to provide initial change management/change-control procedures ”if this is adhered to and updated as required, the result will likely be a more available SharePoint Portal Server system, and ultimately happier , more productive end users.

Implementation Overview ”Phases of Implementation

To understand the role that change management plays in an enterprise solution, it is important to understand the evolution of that solution in terms of phases of systems development ”these phases tie nicely into our "system landscape" approach previously discussed.

The solution phases below are based on a typical implementation of an enterprise portal solution, the timeline of which might typically consume four weeks to perhaps many months or more:

  1. Pilot Phase ” This phase allows the customer to examine, test, evaluate, and explore the proposed Microsoft SharePoint Portal Server solution. This phase is necessary to " prove " that indeed the portal will solve the business problems at hand. It is also important in terms of ensuring that accurate training, development, and deployment plans can be made, and the enterprise portal project effectively estimated from a cost and time perspective. This phase may last from a week or more to perhaps a month in large enterprise-wide pilots. A preliminary hardware sizing may be beneficial at this point, to ensure that the pilot solution is configured adequately from the beginning, so as to best set the stage for the next phase.

  2. Development Phase ” Building upon the hardware/software solution prepared in support of the Pilot Phase, this phase consists of customer and/or consulting personnel configuring and customizing the system for use in the target business area(s). This phase occupies the bulk of the project plan, and typically continues throughout the life of a solution (though perhaps less intensely on initial business areas, to focus on new business areas/opportunities). Initial maintenance upgrades and bug fixes are performed here as well, resulting in a fairly stable environment for continued development and the next phase. During this phase, it is also critical to begin planning for the expected configuration testing and pre-productive deployments ”changes in business assumptions, implementation plans, and server/software technology roadmaps must be visited.

  3. Training Phase ” Like the Development Phase, this phase also begins when the Pilot Phase ends. Training of development and technical support organization personnel occurs first. Training of end user and other personnel begins once a preliminary level of configuration and/or customization has been completed. This phase is ongoing in some capacity throughout the life cycle of the solution.

  4. Pre-production Test/QA Phase ” This ongoing phase begins when the first configuration, integration, and quality assurance testing is performed on development results fed from the Development Phase. It continues, as required, to test the necessary changes and provide for change management throughout the Production Phase. Note that the final end-to-end Production SharePoint Portal Server hardware sizing is typically completed during this phase.

  5. Production or Production Roll-out Phase ” This phase begins when company organizations and business processes become dependent on the data being hosted or managed by the Portal.

System Standardizing ”Minimizing Change Management

For most companies, including ABC Company, maintaining a fewer number of specific items ”whether they be a certain model of server, or type of disk drive, or manufacturer of network card ”will cost less in the long run and prove easier to manage than maintaining a mix of products that might better fit each variance and niche-requirement within a computing environment. For example, at ABC, they selected Microsoft Windows 2000 Advanced Server as the standard OS, even though plain ol' Server would have been adequate in quite a few instances. Similarly, they standardized on a single model of server, even though it provided additional processing headroom in some instances, and therefore cost a bit more up front than other models ”in the long run, the TCO would prove to be lower.

Additional reasons to standardize:

  • Fewer hardware spares to maintain (less costly than maintaining one of each component)

  • Take advantage of bulk-buying (quantity discounts , rather than "one of these" and "six of those" and "two of that")

  • Less training required for support staff (no requirement to spend budget money training the Operations staff in supporting different variations of the OS, for example, or tracking issues specific to a certain version of an OS)

  • The staff becomes very familiar and comfortable supporting fewer hardware platforms/ components (no requirement to spend budget money training staff in supporting multiple server models, for example)

  • Less unplanned downtime, as components are interchangeable (less risk of having to wait on a hard-to-find or out-of-stock part in the event of a critical server component failure)

System Guidelines ”"What NOT to Do"

While configuration guidelines and best-practices provide a foundation for building an enterprise portal solution, change management is also all about avoiding common pitfalls. That is, the goal of change management processes is also to avoid making common mistakes or engaging in poor practices that often compromise the integrity of the SharePoint Portal Server deployment. ABC Company decided early on in their portal deployment planning to follow change management best practices as outlined below:

  • Do not make firmware, hardware, OS, driver, or application software changes ”including updates/upgrades or applying service packs /patches ”without first testing these changes in the Technical Sandbox environment for an appropriate period of time ( ranging from one business day to more than a calendar month, depending on the scope of the change), and second getting sign-off from the appropriate responsible vendor (typically the vendor's organization for supporting SharePoint makes the most sense, though Microsoft itself and third parties may play a role here as well) .

  • Do not fail to adhere to the flow or "promotion" of changes or data from the Technical Sandbox (where infrastructure changes are first tested ) to Development (where data originates) to Test/QA (if it exists) to Training (if it exists) to the final Production solution. Failure to do so compromises the integrity of the Production platform, and therefore negates the presence of both the Technical Sandbox and/or the Development and Test/QA environments. The ability to maintain the history of data objects and configuration changes as they are moved through the Microsoft SharePoint Portal Server landscape is critical.

  • Configuration changes to the dashboard, the workspace, or any integration point may only be modified on the original Development system ” never perform these "development" tasks elsewhere! This is of significant importance regarding the Production system ” absolutely no changes must ever be initiated here, as this would imply a complete lack of adequate and appropriate testing.

  • Do not run additional enterprise applications on the same hardware platform responsible for providing Microsoft SharePoint Portal Server support, unless the system has been specifically sized and configured for both. For example, other business applications including email, database, or audio/streaming video applications typically reside on completely separate hardware platforms.

  • Do not run network- intensive applications within the private networks dedicated for the Microsoft SharePoint Portal Server and related back-end database, Exchange, IIS, or other " core portal infrastructure" servers. To ensure a better level of consistency in terms of end-user response times, the network requirements of the Microsoft SharePoint Portal Server environment should not be compromised.

Leveraging the System Landscape

One of the most basic tenets of sound change management or change control includes leveraging the system landscape to test changes to the environment. One method often used is a Change Control Checklist. A sample checklist developed with the help of an outside consultant for the benefit of ABC Company, used to promote changes into production, follows :

Figure 20.3. ABC's Change Control Checklist used by the technical support organization for promoting changes to Production.

graphics/20fig03.gif

Thus, in summary, sound IT change management practices are essential for maintaining a highly available and well-performing SharePoint Portal deployment. Doing otherwise risks the success of the project and the integrity of the overall solution, as well as impacts the entire end-user community, technical support organization, and more. Be safe, and practice conservative and consistent change management.


                 
Top


Special Edition Using Microsoft SharePoint Portal Server
Special Edition Using Microsoft SharePoint Portal Server
ISBN: 0789725703
EAN: 2147483647
Year: 2002
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net