Current section's content:

creative thinking achieve goals creative entrepreneur creativity trainer creativity training manage creativity creativity program creativity business analyst it project manager business creativity project developer achieve objectives creativity management risk management business management innovation new product development project manager

Sales CRM Software Development Example

By Thomas Eklund

This article's content is related to the sales software application selection and development discussion presented in the article What CRM Sales Software Is Right For You?


- Establishing the Initial Goal Oriented Structure
- Mismatched Usage of Choice Based Structure
- The Outcome
- What Went Wrong?
- It Is Not The Plan, That Helps
- Paradigm Shift

Establishing the Initial Goal Oriented Structure

Goal oriented project structure development process is focused on identifying the goals and the steps that need to be taken, one step at the time, from the goals towards the starting point.

  • Let's say, that a company's management has a meeting, where the management members discuss how to increase company's total revenue and profitability.
  • What can help us to increase company's total revenue, and do so profitably?

Here, different departments may contribute their thoughts. The Sales Manager may state something like this:

  • Our sales software is outdated. We have done some research on this and based on our findings I believe, that the sales software, that contains specifically designed, customized functionality, can help to increase total sales profitably, which also means that it helps to increase total revenue profitably. I have spoken about this with our IT Manager as well.

So, people at the Sales Department have already done some research, investigated the options that are available, and know, that there is sales software out there, that can help to increase sales profitably.

For the planning purposes, we want to state the project's goals and the preceding steps. (In the project's structure, each such step can be a group of steps, which will be then broken down further.) Let's say, that we state the goal simply this way:

  • "We need sales software, that will help us to increase sales profitably."
  • So, before that we need to
  • have such software installed and the users trained.
  • Before that we need to
  • have such software developed.
  • Before that we need to
  • decide, who will do the development and/or what company's software we will use, and, we need to decide the budgetary and development time related questions.
  • Before that we need to
  • decide, what features do we actually need and want in the software.

The initially outlined steps are actually groups of steps, and form the project's structure. Each structural part can be divided into one or more additional steps and projects on its own. Project's structural steps should be linked to the project's goals, and additional steps should be linked to the structural steps.

This will provide at any given point during the project answers to the questions: "What are we trying to achieve here?" Project plan is then implemented in the opposite direction, from the beginning to completion. Just like during the planning the preceding steps necessitated each other, during the project plan implementation, the steps build on each other.

  • For example, during the first group of steps, when we decide what features we need and want in the software, we are looking for features, that help our company to increase sales profitably - that is, are related to the project's goal(s).
  • Finding out, what the optimum set of features is, requires business analysis.
  • During the next group of steps, we are not looking for just any sales software, or sales software vendor. We are looking for sales software and sales software vendor, that can furnish us the software with the features that we know we need.
  • During the next group of steps, when we have the software developed, we focus on making sure, that we have the needed features in place, and are doing the work within the budget that we have agreed on.

So, we are thinking from the goals to the starting point, and then again from the starting point to the completion of goals. In each case we have relationships between the project's elements.

Thinking this way may seem strange at first, but if we don't start out this way and then stay true to achieving the goals, then during the actual development process people can easily lose focus, start wandering around and forget, what really matters.

Goal oriented project development approach may require flexibility and direction changing, too. For longer projects, goals and project structure may have to be reviewed regularly. For example, this applies to business management, which, in essence, is very similar to a big and complex project's management.

Of course, the above example is not the only way to think about sales software development. For example, we could have started with stating, that we need new sales software, and the reasons why we need it. As part of business analysis, we could have explored those reasons, and derived the goals for the project from there.

The point is, that doing the initial planning so, that we think back from the goals, as is explained in the previous part, One Creative Approach Versus Another, can help us to establish the steps, that lead to achieving the goals efficiently and effectively.

This may seem silly, that we need to think this way, but in reality people do have problems with staying focused on the project's goals, which also means, that they don't achieve the project's goals, which then leads to lost opportunities and other problems.

On the article What CRM Sales Software Is Right For You? discusses some steps in that process, focusing above all sales software functionality selection related topics. Sales Software CRM Example article on provides an example of a customized sales software.

However, the goal focused principles that are featured here apply to all sorts of situations, personal and professional, where goals need to be achieved. Similarly, choice based creativity can be used in a wide variety of situations. Just make sure, that you use the right approach in the right situations - and in the right way, too.

That's why CreativityModel Method is useful. Learn it once, use it for the lifetime, for your own benefit and for the benefit of others.


Mismatched Usage of Choice Based Structure

Here's an example of what can happen, if the project leader proceeds in a different direction, moving from one step to another based on simply what seems right at the moment - handling, in essence, in choice oriented manner a project, that requires goal oriented management.

Let's say, that at the meeting which is described above, the sales software implementation project was given to the IT Manager to handle.

Our IT Manager's name is Max and he works for a medium sized company. Max is a systems person, a hardware guy, and he is very good at it. He is an excellent network administrator, and likes to research and explore new hardware and device options.

Max has to deal with software development, too, but software development, and especially customized software application development for a specific user group, is not something that he is very comfortable with. He sees customized software application development as a pain in you know where. When he does it, it requires a lot of work from him, but because he doesn't do it very well, the users end up being unhappy with his work in this area. Additionally, he sees every additional software application as something that requires management time from him, but provides very little value in return to him.

He doesn't want to say any of that to the application users, or ever bring it up. He doesn't like to outsource software development either. So, as much as he can, he simply tries to use out of the box solutions, trying to find compatible solutions that require the least of his time. He has also worked with some software vendors, who in addition to selling him their solutions, promised to do the customization for him "just the way his company needs it."

It's not that Max is lazy or doesn't care about the end users well being. That's not the issue. It's simply the case, that in the complex world of conflicting interests, limited budgets and other resources, but seemingly limitless needs, getting professional customization of software applications done for the users is not on his priority list. Some light customization, that, yes, he can get done, especially if the application happens to be a highly visible one, that other management team members and/or the general public use, too. However, he knows, that he is not very good at software development and customization, but he is not sure, what he should do about it.

So, when he has a choice, he prefers to do other types of work. Because he largely controls how the IT budget is being spent, he also largely controls what types of work he does and how he works.

After the company management team meeting, where Max accepted the request for new sales software, he discusses the topic with the Sales Manager, and tells the Sales Manager, that he knows some excellent software packages. Sales Manager tells Max about some features, that he is interested in seeing in the new sales software.

Max also discusses the possibility of getting a new sales software for the company with couple of salespersons in his company, with whom he gets along especially well. The discussion is general in nature. Salespeople play along, but are skeptical, because they have heard promises of getting a new and better sales software before.

Thereafter, Max does some Web research. He doesn't feel that he needs to do a whole lot of research. After all, he already knows quite a bit about sales software. However, new sales software is a relatively big purchase for the company. So, in addition to the features that the Sales Manager listed, Max wants to have a list of features that he can recommend, and also, preferably, one or more specific vendors that he can recommend.

During his research, Max does find information that he considers very useful. Further, as a result of his inquiries, sales software vendors salespeople start contacting him. The vendors salespeople are above all interested in finding out, who makes the software leasing decision at his company, how soon his company plans to make the software leasing decision, how many users there will be for the software, and how big his budget is. (Generally, the software vendors don't really sell software, they lease the rights to it to their customers.)

Max discusses the relevant topics with the vendors sales representatives, and also asks questions about functionality parts that interest him, pricing and delivery time.

Some of the vendors sales representatives want to talk to the Sales Manager as well, but Max says, that at this point he is simply gathering information, and will talk to the Sales Manager himself.

Next, Max sets up a meeting with the Sales Manager, who asks one senior salesperson to attend as well.

Max presents his findings and his recommendations. Both the Sales Manager and the salesperson attending the meeting ask clarifying questions. Max takes notes and promises to find out the necessary additional information.

The participants feel, that they are making good progress and set up the next meeting's date and time, so that the three of them can discuss the sales software selection related topics further.

Max contacts couple of vendors representatives, who in his opinion have especially promising software solutions to offer, and discusses the topics and the questions that were brought up during the meeting.

Then, a new salesperson from another software company calls. He explores Max needs and wants, and has really good answers and solutions to offer. He promises Max help with other software projects as well that Max is currently working on and Max likes the solutions that he offers. Further, he says, that if Max company provides feedback on the new sales software while they are using it, then they can get a substantial discount on the deal. He also wants to speak with the Sales Manager, so that they can discuss the feedback providing related features, and make sure, that none of it will inconvenience Max company's salespeople. Max puts him on hold, talks to the Sales Manager, and transfers the call to him.

Sales Manager does like what he hears, too, but asks Max after the phone call, if there are other companies that offer similar deals. Max says, that at this point this seems to be the best offer.

Max company leases the sales software from the last vendor.


The Outcome

The new sales software may make salespeople's life easier, which is definitely a good thing. But maybe it introduces new problems. Maybe the usability of the application is better than the previous one had, maybe not. Maybe the new application introduces some new useful features, but maybe it is missing other equally useful features that the previous application had.

Maybe the Sales Manager had expertly done enough business analysis and knew, what specific features were needed, so that his company's sales personnel would be able to increase sales, and insisted that these features must be present. If the application development team did also a good job, the new application works well and is being fed data as needed, it most likely does help to increase sales.

Otherwise, the most likely outcome of this project is, that it will take some time before it's clear, that the new sales software provides very little help in areas that can actually help this company's salespeople to increase sales.

In that case, most likely it is unclear to the salespeople, including the Sales Manager, how the new software is supposed to help to increase sales, and the initial objective, that "We need sales software, that will help us to increase sales profitably" simply will not be mentioned any more.

Even if the Sales Manager did not know, what specific features he needed, could it have happened that Max and his company ended up with a great sales software, that actually helped them to increase sales? Yes, absolutely. Such a possibility exists. By chance, that could have happened. However, if achieving a specific outcome for a project is important enough, do you want to leave it to chance?

If we don't know, where we want to be and how we plan to get there, we have no basis for comparison either.

If it so happened, that the selected software did contribute to some marginal improvements, people could have sung praises to Max, and there would not have been any reason to point out, that the solution is far less than optimal. Without business analysis, nobody really knows, what the optimal solution is.

Further, when we expect a software development project to produce savings or revenue increases, we should do relevant ROI analysis as well. If we expect to increase sales, we should state, by how much and how we will expect to achieve that objective, that is, on what bases such estimates are done. Otherwise, the team that develops the software may produce good results, but these results may be deemed insufficient by some management team members, whose undocumented expectations were higher.


What Went Wrong?

The above sales software selection process may have been longer and more thorough. The people involved may have held more meetings, and the Sales Manager may have been more involved.

The details of the "more of the same" type of actions that were, or were not taken, are less important. More important is, what was left out. To put it differently, because we are trying to achieve goals, we want to make sure that these actions were taken that actually help us to achieve goals.

Both the IT Manager and the Sales Manager are capable professionals and good, ethical people.

Both the IT Manager and the Sales Manager did, what they believed to be in the best interest of the company.

So, those areas are not the sources of the problems.

The IT Manager himself thought, that he has done his homework and recommends the best alternative for his company. So, he conveyed that to the Sales Manager as well.

Further, perhaps the Sales Manager did not want to interfere too much in what seemed like the IT Department's project and choice to make. Maybe he felt that it is better not to step on the other guy's turf too much.

Maybe the vendor's salesperson expertly closed on Max objections.

Good for him.

Or, maybe Max chose a specific option, because its technical aspects appealed to him - "Hey, guys, let's use The-Well-Known-Sales-Software-Company, and let's develop it in the cloud!"

Or, maybe the company that Max works for is a subsidiary, and Max chose something that the parent company recommended.

However, what does any of it have to do with increasing our company's sales, which is our goal here?

Not much.


It Is Not The Plan, That Helps

It's not like Max didn't have a plan. Oh yes, he did. Do some Web search, talk to the Sales Manager, and go from there. That was his plan, and he did implement it, too. He could have made it into a nice project plan, with deadlines and deliverables. It's unlikely, that any of it would have made any significant positive impact.

Of course, the plan that Max had, did not contain steps that were derived from the goals towards the starting point so, that the steps necessitated each other. Neither did he have a plan, that contained steps that built on each other, so that they effectively and efficiently helped to achieve the project's goals.

Max simply made up the project steps as he went along. With his plan and its implementation, Max moved from point A to point B to point C and so on, based on the choices that he made at the moment. Those points were connected primarily by the choices that Max made, and could equally well all have been more or less different than they were.

Above, in the "What Went Wrong?" part are shown some of the possible scattered project development points.

It's not the plan, that helps, it's how you make and implement the plan, that makes the difference.


Paradigm Shift

If you would have asked Max about doing business analysis, then he may have told you, that he is doing business analysis, and doing any more of it would be a waste of resources, because he doesn't have more time for it and there is no need for it either.

He probably would have said something like this - and, there certainly is logic to his reasoning. From his prospective, he needs to get his plan implemented as quickly and efficiently as possible. Accordingly, he can consider it unnecessary and wasteful to spend more time and other resources on steps, that in his opinion do not contribute to implementing his plan.

However, when we look things from the goal oriented prospective, the priorities change. Then, finding out, what functionality areas and features are needed for increasing sales in Max company - and why these, and not any other functionality areas and features are needed for their application - forms the very basis for the next steps and actions.

Then, the technical aspects of the development process would matter to the degree, that they help to achieve the needed goals. Not more, and not less.

Then, it would make sense for Max to fight for getting the needed solution for the users, if doing so is necessary. If the company's management, or a parent company, or any other outside entity would have recommended a solution that was not in accordance with the users needs and wants, as it was documented in the business analysis based findings, then it would have made sense for Max to point out, that such a solution is not in the best interest of the company.

The same applies, if a vendor's salesperson would have tried to sell him such a solution.

Ability and willingness to both look things from the goal oriented prospective, and implement solutions in a goal oriented manner, can make a difference.

Getting there is not necessarily easy, because in real life, we still have to deal with very complex situations and professional and personal challenges along the way. Further, the payoff is not always so obvious either.