Moving into SAP Functional Development : Gaining Control of Change Control - Change Management Best Practices and Approaches (part 3)

12/27/2013 8:49:45 PM

5. Clear Two-Way Communications

The difference between implementing changes correctly and implementing them otherwise can boil down to sound communication. According to the American Heritage Dictionary, 2nd ed. (Boston: Houghton Mifflin, 1982), communication is defined as “the exchange of ideas, messages, or information, as by speech, signals or writing” and represents another best practice for implementing change. Thus, as the organization tasked with managing change, the change management team must

  • Understand that communications can always improve, and therefore strive for continuous improvement

  • Communicate through a standard forum, and in several media if possible, based on the audience

  • Embrace feedback, so as to improve communication quality and quantity

To facilitate the preceding goals while practicing continuous improvement, a communication plan should be put in place. The communication plan seeks to reach all stakeholders, soliciting both input and feedback. It identifies the various stakeholder audiences, embraces different and effective communications media, and continuously looks for ways to improve.

Key challenges to creating and maintaining a good communication plan include differing physical locations, assumptions, knowledge, expectations, effort, time, perceptions, barriers between IT departments, barriers between business organizations and IT, and a lack of feedback/two-way communications. To minimize these differences, the following toolsets and approaches are often used:

  • Monday meetings between the business and IT/SAP TSO

  • Regular weekly SAP TSO staff/follow-up meetings

  • “ERP Team” or other core mySAP Team meetings

  • Published meeting minutes

  • Dialog between management and business/IT groups

  • Project plan schedules with clearly identified tasks, milestones, and responsible parties

  • Business-unit representation within and between the various IT teams that make up the SAP TSO

  • Change management Web site or intranet site

  • Email between and within the various groups, including the use of standard email distribution lists

  • Shared information/knowledge management repository, for example, a collaboration site hosted by SharePoint Portal Server, or a Lotus Notes database, or even a simple file share for starters

  • Various “feedback” approaches (covered later)

  • Department-wide team-building exercises and other non-work-related activities where valuable informal communication can take place

Although the preceding list represents a nice variety of potential communication methods, the next section illustrates what many of my SAP clients actually do in their real worlds of end users, customers, and deadlines.

6. Communicating Changes in the Real World

Communication tools and approaches like the following are used regularly by some of my customers. Some of these approaches are quite effective, but others are debatable. Judge for yourself:

  • Effective: Leveraging a comprehensive change control application—Quite a few SAP customers look to the capabilities found in a number of different change management applications or utilities to manage, track, and report against their projects and processes. I know of one case where a Web-based application was written specifically for the customer. In most cases, though, I subscribe to the “buy it, don’t build it philosophy”—the same philosophy that drives many SAP implementations in the first place.

  • Effective: Weekly change control status meetings, and project plan updates—In this case, the Change Control manager discusses current projects, pending projects, and resource issues/constraints with the entire team each Friday morning. These projects tend to drive most of the changes implemented in their release strategy, from hardware and OS upgrades to database migrations and SAP business enhancements. Updates to a master Change Control Project Plan provide for a single repository for all notes, updates, resource tracking, and so on.

  • Effective: Weekly change management status reports linked to a Web site—Like the SAP customer described in the preceding paragraph, another customer also meets regularly to discuss pending changes. However, each Monday morning, the change management team lead disseminates a status update to a standard email distribution list composed of key business and IT folks. The current and pending changes are prioritized by functional area or technology stack. The unique thing about this particular team lead’s approach is his use of a company intranet site to host all archived updates, status reports, and other commentary regarding each planned change or test project. Scheduling, deadlines, and resource requirements and commitments are highlighted here as well. The site also serves as a repository for change processes, a vehicle for feedback (another link generates an email back to the team lead), and more.

  • Questionable: One of my customers utilizes a very large dry-ink “whiteboard” mounted in the conference room where the change manager holds his meetings. There, in black and white, a running status update is maintained for each change wave—detailed changes, problems, and the person responsible for “fixing” the problems are all listed in a matrix format on the board. Of course, this approach is limited in that future status is difficult to communicate, the board tends to get messy after a change wave has been listed a month or more, you have to physically walk into the room to see status updates, and the risk of losing everything is possible if an enterprising member of the janitorial staff takes it upon himself to clean up the board.

  • Questionable: Another customer of mine takes the use of sticky notes to a new level when it comes to managing hardware and OS-based changes. Here, the data center’s operations manager also plays the role of SAP liaison to the business (in conjunction with the SAP Basis manager, who also owns the database layer). Planned changes, and the dates scheduled for the change, are noted and communicated via sticky notes and other labels that are physically placed on the server or disk subsystem that will undergo the change. As a change is promoted, the sticky note is moved to the next server or set of gears in the SAP landscape. In this way, a sticky note follows the change from development through production. I am by no means an advocate of this approach, but it would be unfair to say that it doesn’t completely work. On the contrary, it seems to work quite well for this operations manager. The approach in general is dangerous, though, in that we all understand that sticky notes are susceptible to “falling off” over time. And from a status perspective, it seems unlikely that such an approach facilitates keeping others in the loop. Besides, there’s only so much space on a note—updates or changes to the original plan must make for some really hard-to-read sticky notes.

  • Questionable: Another limited approach to hardware/OS change control involves the use of a binder or log, where future changes and planned upgrades are tracked. The originator of the change, the name of the wave (if any) that the change may be a larger part of, and the implementer of the change are tracked here as well. Although this approach is more “publicly accessible” than the sticky note approach, I still think that tracking and mapping changes back to the master project/change control plan is difficult at best. And I see a lot of opportunity for missed deadlines and similar lack-of-communication issues.

  • In the future? One of my forward-thinking colleagues envisions a day when devices and applications will be smart enough to track and communicate their own status within the larger scope of change control releases. For example, an entity scheduled to undergo a change would “know” it by virtue of a connection to a master project plan. When queried physically or via a Web browser, the entity would respond with a clear status communiqué, like “My processing microcode is scheduled to be updated from 2.41 to 3.10 on Monday. For schedule or implementation questions, please contact Dave Future. For technical questions, please contact Jan McKay. And have a great GlobalXYZ day.” All of this capability would be made possible through intelligence built into each entity, enabling it to “absorb” its Pert Chart bubble and information regarding relevant tasks, responsible parties, and so on. Finally, the actual upgrade would amount to simply pushing a physical or virtual “make it so” button, complete with feedback like “Are you sure, Dave? You might want to rethink this move, as I have been scheduled to run the monthly closing on Monday.” You saw it here first.

My recommendation is, of course, to employ all three of the first real-world communication plans described in the preceding list, as most of my other customers tend to do in one form or another. Some of the other approaches might have value, too, but only if backed up by “robust” communications vehicles like the first three.

  •  Moving into SAP Functional Development : Gaining Control of Change Control - An Overview of Change Management
  •  Performing mySAP.com Component Installations : Addressing General mySAP Post-Installation Tasks
  •  Programming .NET Components : Working with Threads (part 5) - Thread States, Thread Priority and Scheduling
  •  Programming .NET Components : Working with Threads (part 4) - Aborting a Thread
  •  Programming .NET Components : Working with Threads (part 3) - Blocking Threads
  •  Programming .NET Components : Working with Threads (part 2) - Creating Threads
  •  Programming .NET Components : Working with Threads (part 1)
  •  System Center Configuration Manager 2007 : Integrating Virtual Applications (part 3) - Creating Adobe Reader as a Virtual Application in ConfigMgr R2
  •  System Center Configuration Manager 2007 : Integrating Virtual Applications (part 2) - Activating Application Virtualization in ConfigMgr 2007 R2
  •  System Center Configuration Manager 2007 : Integrating Virtual Applications (part 1) - What Is SoftGrid?
    Top 10
    Review : Sigma 24mm f/1.4 DG HSM Art
    Review : Canon EF11-24mm f/4L USM
    Review : Creative Sound Blaster Roar 2
    Review : Philips Fidelio M2L
    Review : Alienware 17 - Dell's Alienware laptops
    Review Smartwatch : Wellograph
    Review : Xiaomi Redmi 2
    Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
    Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
    3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
    Popular Tags
    Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8