Communicating Your Requirements
After your requirements are defined—including goals and objectives, diagrams and models of pertinent information, business processes, and the business events that organize data and processes—it is time to communicate your requirements to your selected vendors.
Requirements are communicated on an ongoing basis. That's right, you don't just tell them once and walk away; you have to stay with the process:
1. | First you transmit your requirements documents. It is often useful to set up a face-to-face meeting to review the requirements and make sure you are communicating effectively. |
2. | Next, you'll need to confirm that your audience, the vendor, understands what you need, and feels able to deliver it. It's important at this point to listen to the vendor's feedback and address each point in your requirements individually, to make sure you are understood, and that you understand the vendor's ability to provide it. |
3. | The third step is to correct the misperceptions, clarifying what you initially intended, because there will be misunderstandings. You will also probably find that as you go over your requirements with a vendor, some of them will change as you discuss the need and it's technical feasibility. It's important to capture these changes and make sure you update the original documentation to reflect the new resolution. |
4. | When you are satisfied that you've come to terms with the vendor and all parties are in agreement, you should send the updated requirements documents and once again make sure the vendor agrees that you've captured all the updates correctly. |
Who Are You Communicating With?
Different resources will require different modes of communication and different messages. Here are some of the types of people that might be recipients of your message, along with suggestions for communicating effectively with each.
Vendor Resources
Vendor resources might include sales personnel, technical consultants, or service representatives. When setting up a vendor relationship, communications should be formal and written so that your expectations are documented and you have an audit trail to refer to in sorting out misunderstandings. After you have established a working relationship, you might be comfortable working informally with service reps or technical experts you call on for troubleshooting. Informality is okay for the day-to-day communications, but significant points and agreements should be followed up with at least a confirming email.
Your Team
It's important to communicate to your staff what you're doing and why. You can engage them in generating ideas, build enthusiasm by communicating goals and rationale, and offer incentives for performance. Your team will help you monitor data and service quality from your selected vendors.
Communications with your team should include the formal requirements documents that are targeted to vendors, and also can include a variety of training and awareness techniques such as
Web announcements
Annotated presentations delivered via email
Email announcements containing relevant information
Lunch 'n Learn presentations delivered in person
Partners
Alliance partners might need copies of your formal requirements documents to enable them to participate in your project. With NDAs in place, you can share at least the nonsensitive information with your partners.
What's the Plan for Communicating?
Depending on the size of your project, you might need to develop a formal communications plan for keeping all interested parties informed. The process for developing a communications plan includes the following steps.
Make a Plan
Communications plans should include the following information:
Audience
Selected method(s) of communicating
Expected frequency of communicating
Channels for response and interaction with participants
Share the Plan
The first step to improved communications is sharing the plan you've developed with all project participants. This enables people to know what to expect. It also gives them the opportunity to contribute by either taking responsibility for their part of the plan or by helping you to meet yours.
Communicate Redundantly
It's better to err on the side of over-communicating than end up giving too little information. Stop short of deluging all project participants with all messages, but selectively make sure you keep people in the loop. One of the functions of the communications plan is to identify who needs to receive what information at what point, which will reduce your list of recipients.
Leave an Audit Trail (Email or Other)
One of the goals of formal communications is to leave an audit trail so that the current state of agreements can be ascertained, including points that might have been renegotiated along the way. It's no substitute for a signed contract but might keep you out of trouble. Also, people tend to think a little more when putting decisions, terms, and information in written form.
Owning a Business App
Part of your role as the business owner or project owner is to communicate the requirements for your CRM systems. To play this role effectively, you need to understand what's involved in owning a business application, including the responsibilities you'll have and the benefits you'll enjoy.
What Owners Do
CRM system owners are responsible for identifying and procuring the resources for a CRM project. They must estimate the cost and benefits and organize investors to support the effort.
System owners also must define the business requirements, setting expectations and being the ultimate arbiter of whether the system meets the expectations. This means they must set out the goals for the application, communicate the goals, and hold project participants accountable for their delivery.
What Owners Get
The advantage of owning a business system is the opportunity to improve your business. You have a unique opportunity to clarify your business model and define specifically how you want to do business, and then to embed that process into an automated system.
What Owners Supply: Business Requirements
The business requirements document is a means of specifying business processes and the applications that support them. You can adopt a formal modeling language, such as the Unified Modeling Language (UML), or for smaller applications you can simply draw how you see your application operating.
Requirements definition involves visualizing your system. You will need to surface the assumptions and make sure that team members align their assumptions so that everyone is working toward the same vision.
For example, in a restaurant CRM implementation, one company needed to maintain their reputation for extremely high levels of service with an increasing customer base. To do this, they decided to track customer information, dining history and preferences, and make that data available to all staff members by building and maintaining a customer database. The elements or components of their implemented solution were the following:
Adjust business processes
Treat all service interactions as an opportunity to obtain relevant customer information
Input the obtained customer information into the customer database
Build clients proactively by treating every customer as if they were a “regular”
Track customer information electronically
Maintain a database including information on all customers
Analyze customer information to identify top customers and trends in their buying behavior
Conduct email campaigns using customer-supplied email addresses
The model that depicts these elements of the solution is provided in Figure 16.2.
Figure 16.2. The diamond model for restaurant business processes depicts the elements of the restaurant service solution, which includes adjusting business processes and implementing electronic tracking of customer information.
Building Proactive Communications
Part of the role of the business owner is to ensure project teams and project managers understand the goals of your CRM strategy and its applications. Proactively communicating to project teams and managers enables them to support and carry out the project objectives and action plan as proposed. Other mechanisms that can be employed, depending on project needs, include
Targeted training— Training that is tailored to the needs of a CRM audience, which helps teams set expectations and managers understand the objectives.
Handbooks— Depending on the goals of the CRM project, the team might want to develop handbooks of project information for dissemination among the groups that are affected.
Overviews— Overviews presented to management, employees, customers, and suppliers can introduce the goals of the CRM project and head off confusion and scope creep.
Intranet delivery— Defining a home page for the duration of the CRM project to store project contacts, goals, handbooks of project information, schedule, and deliverables is a useful way to facilitate the communications on a large project.