Developing Functional Specs Can Be Simple

Functional Requirements Part C

As Ron Foster, the CRM vendor, and Pat are reviewing the CRM project status before the project team meeting starts, “Pat, you have finished your business project document and functional specs in record time. You are good to go into your planning stage”.

“It seems the functional specs took a lot of time”, said Pat. “Is this true for all companies during a CRM application implementation?”

“Your time for drawing the business process charts was about normal”, explained Ron. “That’s because your team and users were always available for the scheduled meetings.”

“You mean that isn’t always true”, asked Pat.

“Afraid not”, explained Ron. “You would be surprised how some companies stall progress by: keep changing their minds about how things work and then have to research it and then schedule another meeting.”

“What about a small company with, say, 5 or 10 employees?”

“My advice goes along these lines. And it goes for almost any size company for that matter. On-premise CRM systems today are rich in function. Therefore, unless the detailed process charts indicate the need for lots of tailoring and/or integration, I say go with the out-of-the-box solution if 90% of the function is there.”

“What about the other 10%?” asked Pat.

“Chances are it will wait and you can create a phased plan. Realistically, some of that 10% will just go away as not really needed.”

“What about technical specifications? And what are they?

“Well Pat, technical specs are usually not needed for an out-of-the box solution. They are needed for a customized project. A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on. On the other hand, a technical specification describes the internal implementation of the program:

It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc. For example a house construction project needs for technical and functional specifications.”

“This is good Ron. We still have a few minutes before the team starts arriving. Do you mind giving me a couple of real life examples?”

“ Pat, as you know, a typical functional specification might state the following: When the user clicks the OK button, the dialog is closed and the focus is returned to the main window in the state it was in before this dialog was displayed. It can be informal, in which case it can be considered as a blueprint or user manual from a developer point of view, or formal, in which case it has a definite meaning defined in mathematical or programmatic terms. When you design a product, inside and out, the most important thing is to nail down the user experience. What are the screens, how do they work, what do they do. Later, you worry about how to get from here to there. Fortunately a good out-of-the-box solution has already done this.”

“I like it. What about the technical specs?”

“A good example might be using . When the user clicks Log In, the following checks are performed on the server: and so forth.”

“Thanks Ron. That was very helpful. After our review this morning, what will be the next step?”

“We will get down to planning for installation and implementation.”

Streamline the Development Process

Functional Requirements Part B

Lou, the company CEO, blazes into the meeting room where the Process Team is waiting on him. “Chris, are you trying to turn this place upside down? I played golf over the weekend with some friends. When I mentioned CRM, a lively discussion started. They started telling me about CRM chaos and such. What’s going on here? Yes, I approved the project costs and buying the CRM software. I figured you did your due diligence. You’ve had almost a month. They even told me about a company trying to build it themselves spending $250,000 and nothing to show for it till after two years. It makes me nervous.”

Chris straightened his tie and with executive composure responded, “Lou, we have finished documenting the details of each business area complete with the functional specs in record time,” explained Chris. “That’s why I was excited when you asked to attend the Process Team update meeting.”

Lou sat down and proceeded, “How will we avoid this CRM chaos that I hear about”. He leaned forward as he asked “What are you doing about it?”

Pat, the Process manager, was thankful that Chris had briefed him about Lou. Lou was a typical executive. Keep it simple and to the point. Talk in layman’s terms; no techie talk here. “Lou, we have detailed business process charts, reports defined, and starting functional requirements with output definition. The users have been intimately involved. We needed a document that explained the CRM application pictorially and the flow to included pictures of the screens that the user will see and interact with”, explained Pat. As Pat turned toward Sue from IT he continued, “Sue will clarify the idea of functional specs for you.”

Sue shifted in seat and smiled. “Pat, functional specifications are the blueprint for how we want our CRM application to look and, feel. We needed a simple document that illustrated the CRM application pictorially showing the screens the user will see and interact with. And, we have already started planning for integration with our accounting system.”

Lou, with a puzzled look asked “I saw the copy of the first draft with pictures of the actual screens. It was impressive and easy to follow even for an old truck driver like me. How did you do that so quickly?”

As everyone laughed and repeated “truck driver?” they started to relax. Sue spoke up, “We found a functional specs example on the web at http://www.mojofat.com/tutorial/designdoc.pdf and I printed an example for you” as she passed out copies to everyone.

Lou’s mouth dropped and his eyes widened. “What is this?” he exclaimed.

Sue laughed and said, “Why, that’s a screen drawing from a customized, start from scratch system?

After Lou looked at the image for a minute he frowned, “This doesn’t look like your spec document. Did you have to develop this and then create a screen from it?”

"Absolutely not. Our vendor Ron arranged for us to have access to a demo system to help us,” explained Sue. "We found each of the screens in the CRM program we needed, easily took screen shots, and from there we copied each screen into our functional specs document.”

Leaning forward toward Lou, Chris stated, “We only used screens that we knew we would have to modify for our needs. If we used that sample document we just showed you, we would have to draw it out on paper and then use a drawing program to create it.”

“Wow,” said Lou. “That sounds like a time saver”.

“Lou, if we used that method it would take months coming up with a functional spec document. And I don’t even want to think about the technical specs needed to explain every detail of what to do with each button and other choices so that the developers can program the application.”

“That’s quite a savings and a quicker method of getting something in the hands of our people,” said Lou.

Pat jumped in, “This is what companies go through developing from scratch. I also read the other day about a company developing their own CRM system. It was $260,000 and two years before the users had something to use. Unfortunately that is the story of many companies trying this and giving up after two or even more years.”

Lou leaned back and in a thoughtful way said, “So far I’m impressed with the results of this team. So what part does Ron play?”

“Ron Foster,” explained Chris “has been contracted to help with this first phase. Our detailed process charts have validated that his system will do everything we want. Ron’s consulting fee is very cost effective compared to starting from scratch.

“I can imagine,” said Lou.

Chris continued, “We have started talks with Ron to take over the Process Manager function as an outside consultant as we approach the installation and customizing phases. Pat does a great job but he still has his own responsibilities here. He can continue doing his job and stay involved in the process as our internal contact to ensure we stay in control.”

“Who will customize for us?” asked Lou.

Chris pulled out a PowerPoint presentation overview. “As you can see on the first chart, our vendor will do the customizations. Although someone in IT may learn to do it, Ron and his team know the product intimately and can move fast. Their hourly rate seems high and Ron has given us a nice fixed price quote. Either way we will implement Phase One within the next two months and our users will be productive right away.”

“That sounds good. If you would please run the numbers by me along with projected benefits, I can be confident of our funding. Also how will training be accomplished?”

Pat spoke up. “The next chart shows how Ron and his team will work with us to develop the training plan. Ron’s training specialists will train our users.”

Sue pushed her hair back and said, “The exciting part is this will improve our training for current and new employees. The process charts lets each user walk away with visuals to help them understand their work flow.”

Lou thought about what he has learned and as usual he pushes the envelope a little. “This is so impressive there must be more?”

Pat jumps up and excitedly says, “You can bet on it. To ensure the readiness of the user, there is a test on their computer that they will take. When they can pass it, they will be given access to the new system. This saves testing time in the classroom and helps ensure that each user do their work without frequently calling the help desk.”

“That is so clever,” said Lou. “I love saving time and money. Sue, where does IT play in this scenario? “

“Good question. The most exciting thing for us is that we are in control of customizing our system to enforce our business objectives and planning for integration with our accounting system.”

“OK” said Lou as he stood up to leave. “Please invite me to your next team meeting and ask Ron to join us. I’m excited. Let me know if anything slows down our development timing so I can address any issues.”

After Lou leaves, Chris says, ”See what executive buy-in does!”

Start at the End

Functional Requirements Part A

Now that you have assembled your Business Process Team (Executive Sponsor/Champion, Process Manager, and IT person), you most likely have identified the business function groups that you will interview to develop very detailed process charts and the goals and objectives documentation.

Each business function group (e.g. Sales, marketing, customer service, IT, case management, manufacturing, research, front office, and back office to name a few) will include the managing executive, key managers, and key employees. As the interview process advances, the Business Process Team will start to take notes regarding the “wish list.” The Business Process Team will start to draft functional specifications.

For functional specifications here is the real deal – start at the end.

What you say? That’s right. Most people start drafting functional specifications with what’s needed for input. After all computer applications are based on:

Input > Process > Output

The key element of output is reports. Such a key element for managing the business allows for being proactive versus reactive (remember the 70% of work hours spent in meetings handling the crisis of the day or hour?). Imagine implementing a great CRM system and then managers start complaining and requesting reports thereby slamming IT into overload. And then imagine the requested report has a column of data that is not captured anywhere. Well, you may know the drill of revising the process charts, database, screens, etc. That’s why detailed process documentation is mission critical.

Reports examples:

Report scenario 1

A key measure is capturing time spent on activities such as phone calls, meetings, composing and sending emails, and other tasks. CRM can easily capture this data if planned for. Therefore as time spent starts spilling into overtime, it will start throwing costs out of control. A report of early alerts will allow the management team to be proactive. For sales this might be opportunities that have sticking points in the sales process. For customer service it could be too much time handling complaints. For a medical facility it could be having patients waiting too long after their appointment time before seeing the doctor. Be sure that all the required data is captured.

Report scenario 2

Suppose a report is requested by the marketing business function group for Lead Source Effectiveness. A report is designed that by lead source includes % Total Leads, % Qualified Leads, % Became Revenue, Revenue from Won Opportunity, % Overall Revenue, and Average Revenue per Lead.

Looks like a great report and is included in the initial implementation. Then the CEO wants the revenue from Lost Opportunity included in the report. Whoops. The opportunity is tagged won or lost but the revenue lost is not captured. Looks like more rework is required before the report can be updated.

In summary, the first key element of CRM success is starting functional requirements with output definition. The form can be an online listing, printed report, or preparation for export to a spreadsheet like MS Excel. If a field is required from a legacy system like payroll or inventory, then planning for integration can be done.

As always, comments are welcomed.

It All Starts Here

A CRM installation has little chance to succeed unless all of the business functions are documented in detail.

It’s like a house without a foundation

It’s like flying a plane without an instrument panel

If a business process is not documented and used by all the employees, there is no process. Bold statement you say. Try to implement a workflow written in prose like a nonfiction book. It becomes a Standard Operation Procedures manual (SOP) sitting on a shelf.

What are some symptoms of a business without detailed process charts?

• 70 % of work time spent in frequent meetings making decisions about handling the latest crisis.
• Managers having to spend most of their time putting out fires
• An executive spending 14 hours a day at work since “the place will fall apart if I’m not there”. He/she is stressed because the family is ignored and taking some quality time off is a fantasy
• The boss has to micromanage to get something done correctly.
• Ask three people how a simple process is done and you get three different answers
• Frequently having IT change programs and systems

You get the idea. So how do you do it? First, someone has to have the responsibility and the time to do it. This Process Manager (PM) must first interview the C-Level Executives

You won’t get the detail needed but you will get a 100,000 foot level of how a department works and interfaces with other functions. You will also get goals, objectives, current problems, and a “wish list” for the CRM system. The documentation will include process charts (usually done in something like Microsoft Visio). A chart for each business function is drawn. It includes the tasks that must be done by whom and any interaction between different people involved. Examples include processes of selling, reimbursing employees for expenses, taking an order and following what happens all the way to shipping the product or providing the service, and handling complaints. The first drafts of these “as-is” processes are reviewed with each executive and revised until the executive says “that’s the way we work.” Also write down the goals, objectives, and a wish list and review it until the executive says “if we can get that, we will increase profits, streamline our operations, and save money thereby impacting our bottom line.” Also including target percent increases and decreases documented is valuable.

Lastly, review the charts and documents with each executive including the CEO/Owner as a group. In my experience you will most likely get comments like “I didn’t think we worked like that” or “do we do such and such?” At that point you must get a consensus of opinion and start to build the “to-be” charts.

The next blog will cover getting down to the detail level.

You can get started today. Assign a person as PM. I find that a two member team of the PM and someone from the IT department working together is best. If an outside PM is contracted, the internal IT person and PM can still work with together as a team. Also an executive sponsor should be assigned to oversee the process from start to implementation. For example, the internal sponsor can facilitate requiring the necessary managers and employees to be available when needed.

Get started now because you need the resulting documentation to make a decision about which software system to buy, customize, and implement or the one you have already bought as you follow this blog.

Don’t even think about developing it yourself. Current popular systems on the market today are very robust. The last article I read about a midsized company developing a customized system since “we are so unique” spent three years and $250,000 implementing the first release. Some time ago, IBM with all its resources, tried to do the same thing. After two years and $2 million dollars in costs with nothing to show for it, some executive finally said “stop this nonsense. We better buy something and customize it.”

So, whom do you have in mind for your Executive Sponsor? When will you start?

Questions and comments are always welcomed.

CRM is NOT a software product

Customer Relationship Management (CRM) is not a set of software products. It is an ongoing process. Exercise and eating the right foods in the right way versus dieting to lose weight is a lifelong process that becomes an integral part of a persons daily life that also includes such personal habits of brushing your teeth, self-education, and raising children.

It is a vital business life cycle. The ongoing alignment of the basic building blocks distinguishes an elegant seamless CRM implementation which successfully builds mutually valuable relationships.

CRM is a multifaceted process, mediated by a set of information technologies, that focuses on creating two-way exchanges with customers so that firms have an intimate knowledge of their needs, wants, and buying patterns. In this way, CRM is intended to help companies understand, as well as anticipate, the needs of current and potential customers. Functions that support this business purpose include sales, marketing, customer service, training, professional development, performance management, human resource development, and compensation. Many CRM initiatives have failed because implementation was limited to software installation without alignment to a customer-centric strategy.

Key success factors are planning that includes Documenting and Reengineering a Company's Business Processes.

Business Modeling Customer Relationship Strategy, Goals and Outcomes: Numbers and description of whether goals were met and models of customer segments and game plans worked as hypothesized.

Would you believe that CRM can be a vital part of an organization that does not do sales and marketing?

Implement CRM - How to do it

Welcome to Implement CRM at your company. We will post blogs to help

• You fully understand the fastest growing space for Small and Medium Business - Customer Relationship Management, and
• Learn what it takes to implement CRM yourself or with help.