Handling Changes and Continuous Improvement

Change management, or configuration management, addresses the need for a controlled, defined process for managing change in the software development setting. In the case of vendor-provided software and services, it is critical to introduce a structured process for managing change so that you retain control of your applications.

Change requests may originate from several directions, or requestors:

• CRM business owner (CEO, product manager, marketing…)

• Customer feedback

• CRM administrator

• Tester

• Vendor

Change requests must be organized and managed so that they are addressed according to their real priority and so that no request gets lost in the shuffle. To do that you might want to introduce a change log, a structured request form, and procedures for managing requests. The following steps serve as an example procedure for handling change requests:

1.	Receive change request and log into the change log (the status of the request would be set to: proposed)
2.	Classify the request type as one of the following: update with no programming required (add, change, delete) software change (cosmetic, functional, or bug fix) new feature or enhancement
3.	If the request is an update, perform the following: get signoff from authorized agent (business owner) perform update and verify close out the request in the change log (status: complete)
4.	If the request is a software change or new feature, the relevant party (noted in parentheses) will perform the following steps: a. Evaluate and assign priority to the request (business owner) b. Determine the scope, feasibility, and cost of the change (technical manager/architect and developer team) c. Approve change (business owner)—status: approved d. Add change to schedule and send approved change list to vendor team (assign the change to a release package) e. Return completed changed software (vendor team) f. Perform regression testing (test team) g. Close out change request—status: complete h. Publish updated site software (release the changed software package).
5.	It is recommended that the following information be logged for change management tracking and reporting: Change log (one entry per change request) Release # Change request # Requestor Requestor type Date initiated Date completed Status (proposed, approved, complete) Priority (high, medium, low)

Selecting a Project Approach

CRM projects are quite different from traditional software development projects. The business requirements for software development projects are usually well understood and finite in nature. They are specific to the needs of a departmental tactical solution, and are managed with a clearly structured approach. Requirements for CRM projects, on the other hand, typically evolve as the project unfolds.

Software development delivers tactical solutions to defined problems, specified to solve departmental concerns. CRM delivers dynamic enterprise applications, with a focus on the strategic support of new business models.

Selecting a project approach is based on organizational factors as well as on technology factors. CRM projects often involve modifying or repurposing multiple application systems, for business goals defined and shared by several organizational units.

Three basic project approaches can be used successfully on CRM projects. They include

• Unstructured

• Structured

• Pragmatic

Unstructured

The unstructured approach sets up an environment of constant learning. Mistakes by team members are welcome and are considered a necessary part of the learning process. They are part of how we learn, and are almost as valuable as no mistakes. Project advances in the unstructured approach will occur in an opportunistic fashion, with the team prepared to move quickly when opportunities arise.

This approach requires a high degree of political flexibility and organizational willingness. CRM teams must be allowed to operate outside the usual protocols, depending on the requirements of the individual project.

Structured

The structured approach makes the process explicit. It's for situations in which the process is predefined and planned in detail in advance. It's a better approach for technology projects in which the terrain is well known, and implementation solutions are built in mature technologies. In structured approaches, the required skill is in laying out the schedule and managing for success. Structured approaches add overhead to a project. You'll be spending time in steering committee meetings, selling and defending project goals and progress. Time will be spent preparing presentations, responding to queries, and explaining project progress.

The structured approach requires adequate time and top-down support. It emphasizes appearance, perception, and communication of project goals. Mistakes are not allowed in the structured environment because the learning is expected to take place ahead of time. Project steps are predefined based on the knowledge acquired, and project goals are about execution, not discovery.

Pragmatic

The pragmatic approach combines aspects of both the structured and unstructured approaches, and defines the required supports to be successful. It utilizes predefined time boxes, with flexibility within each time box, and the agility to reconfigure time boxes if needed. The pragmatic approach expects some learning and discovery to take place, but not so much as to derail the project. It acknowledges the value of learning through mistakes, as does the unstructured approach, but it mandates that mistakes are acceptable within defined and limited boundaries.

This pragmatic approach builds in mechanisms for making midcourse corrections. It requires the ongoing involvement of project sponsors because their direction helps keep the project on course and out of difficulties. The pragmatic approach requires the combination of the sponsorship of a champion who can help sell the project within the organization, and the reliance upon interested parties. Thus, it finds and invites the collaboration of natural allies in building organizational support for project goals.

Choosing the Best Approach

To choose the best approach, you need to think about what your organization can support, what its preferred styles are, and how flexible your particular project sponsor can be. Sometimes the personality of the project sponsor and/or stakeholders will dictate the tone of the project approach. Sometimes another factor, or set of factors, will determine the choice of approach. In either case, the approach will set the tone for the entire project and as such, should be selected with care. It is often an organization's first encounter with alternative methods, and can be a valuable introduction to them if handled with precision. Table 17.1 summarizes the three approaches for CRM projects.

Table 17.1. Three CRM Project Approaches

Approach	Description	Requires
Unstructured	Constant learning	Consistently strong sponsor at mid-level Political flexibility and organizational willingness Mistakes welcome
Structured	Predefined	Time and top-down support Emphasis on appearance, perception, and communication of project goals No mistakes allowed
Pragmatic	Predefined time-boxes with flexibility within them	Combination of sponsorship of a “champion” and reliance on interested parties Willingness to make mid-course corrections Ongoing involvement of sponsors Careful mistakes

Project approach is selected based on organizational factors and technology factors.

Continuous Corrections

The point of using iterative approaches in CRM development is to provide a fluid process that can manage ongoing change. By maintaining a dynamic model, you can position your project to adapt quickly and adjust to new business requirements as they come up.

It's Always Just a Draft

It's always a challenge to determine when a software design model is complete. Actually, it's a trick question. A model is never complete, because the real world is constantly changing and updates are to be considered the norm—not an unusual thing.

So, our models of changing reality have to be changing as well, to reflect the latest information. In this way, any model you develop will be incomplete and you can think of it as a draft—a draft that is never fully completed.

Don't Stamp Draft on It

We understand that our model is dynamic and ever-changing, by definition. Therefore, we don't need to label it as a draft. Rather we need to educate and set expectations that modeling is fluid and dynamic models are always under development—subject to business and technical updates.

For example, in a project where the corporate culture tends toward monolithic, committee-driven decision-making, the tendency is to couch everything in terms of where you are in the committee's decision-making process. If something is not official, you publish it with caveats about how it's just a working draft and nobody should get excited about it.

But publishing a model as a draft contradicts our understanding of what a model is, so it should be avoided whenever possible.

Small Decisions Versus Great Big Ones

It is better to make a series of small decisions, with the ability to adjust at any time, rather than create monolithic decision-points that act as bottlenecks to getting anything done. When you cultivate an environment and expectation that we will continually adjust, change, and grow, people come to realize that small changes are easier than monumental ones, and can adapt a little at a time.

Being nimble and flexible requires paying attention to the small decisions, and keeps you from getting stuck on the big ones. Change then becomes an ongoing reality, which is accepted in small steps—eating the elephant in small bites rather than one great big one you choke on.

Convey Corrections

You're going to have to provide corrections, changes, and updates to the vendor software and services that you are using. The question is, what's the best way to do that?

Ideally, you can just talk things over and arrive at a mutual understanding of the necessary corrections. In very small projects, or on teams that have worked together for so long they can pretty much read each other's minds, this can truly be the most effective way to do it.

For everyone else, perhaps a little more is needed.

Think about what goes into a conversational solution, which typically goes something like this:

• We identify that there is a problem

• We acknowledge each other's feelings and try to soften the blow

• We each take turns at articulating the problem

• We each take turns at articulating the solution

• We arrive at an agreement

• We celebrate our solution and pat each other on the back

• Everybody leaves happy, feels recognized, and knows their ideas were heard

Okay, maybe that's an idealized version, but it provides a skeleton of what we'd like to happen in any such transaction. That skeleton is an example of what we call a model. It is an abstraction of reality that enables us to focus on particular aspects of reality. In this case, we focused on the pattern and emotional content of transactions. We disregarded the medium, the actual people involved, and so on. In so doing, we are able to zero in on the aspects of the situation that we want to formalize, and suspend the rest. That is, exactly what you want to do in conveying corrections to a vendor.

Maintain a Model

As shown previously, a model can be as simple as a series of steps that are identified and formalized. It can also be depicted graphically, or numerically. The important point is that you maintain a formalized way of representing complex aspects of your project so that the people working on the project have a road map to the requirements and any changes that must occur.

Decide What's Enough

As mentioned previously, it's always just a draft. When the model you're developing seems to say what you want it to say, consider it done for now. You might want to run it by someone else on your team and see if it makes as much sense to them as it does to you. Another pair of eyes will usually help turn up issues that are not clear in your model, and you can slowly work toward more clarity.

Model Fluidity

The reason that CRM projects can benefit from the use of models is that models are more fluid than computer programs, and can be updated more easily. They originate in the design stage of a project, and give you a mechanism for recognizing design problems and identifying desired changes before the programs are actually written in computer language. Making changes at the early stages of a project rather than waiting until you see the actual system can take many hours off the development time required.

Model Corrections

Your model becomes a guide to the desired corrections. It documents the existing reality of your requirements and how they have been agreed upon between your team and the vendor. To change the agreement, go back to the model, make updates, and review them with the vendor just as you did the original requirements. Gain agreement on corrections and sign off a new version of the model.