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:
|
3. | If the request is an update, perform the following:
|
4. | If the request is a software change or new feature, the relevant party (noted in parentheses) will perform the following steps:
|
5. |
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
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.
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.
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.
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.
Project approach is selected based on organizational factors and technology factors.
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 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.
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.
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.
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.
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.
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.
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.
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.
3.145.85.151