project developer banner project developer banner project developer banner project developer banner project developer banner project developer banner project developer banner

What CRM Sales Software Is Right For You?

By Thomas Eklund

Are there any principles that help you to decide, what CRM sales software, or contact management or other type of sales software is the best solution for your company, and what solutions you may want to avoid?

Yes, there are.

Generally speaking, similarly to the way you can develop further many other personal and professional undertakings, there are two ways how you can proceed.

  • You can explore some alternatives, and then go with what seems like the best option. This approach is easier, but the failure rate is naturally higher.
  • Alternatively, you can determine what you need and want - and why - and how you can get it. This approach requires more work upfront, but makes it much more likely, that you will actually also get what you need and want.
  • Let's say, that you want to have sales software that actually, in reality, helps your company to increase sales profitably. If that's the case, you can set this as an objective, and figure out the way to make it happen.

This article addresses topics that are primarily related to the latter, second approach.

In the case of determining what CRM sales software is right for you, you want to proceed in steps.

You want to explore the existing alternatives, but before locking into anything, you want to determine, what your ideal solution looks like, what functionality parts and features it should have, and why it should have them. That knowledge gives you the basis for comparison and helps you to decide, which vendor and developer can deliver what you need and want.

These steps can take you there:

  • Investigate the options that are available.
  • Set goals:
  • Do business analysis; talk to the application's future users and determine, what they believe is needed.
  • Define the sales process.
  • Define, how sales auditing will be done.
  • Define, on as detailed level as feasible and possible, what your ideal application looks like and how it should function. Define, how your sales process should be built into a software application.
  • Figure out the best way to achieve the goals:
  • Pool alternative solutions, and from the results assemble the path to the most optimal outcome.
  • During the individual steps, define the obstacles that need to be overcome, and how these obstacles will be handled, so that the needed solutions can be put in place.
  • Implement the action plan. Remain flexible; as needed, generate alternative options and change individual components of the plan, without giving up on the important objectives.

Implementing these steps successfully makes it very likely, that you will increase your company's total sales and, along the way, will generate increased earning opportunities for the sales personnel. The positive ripple effects can go way beyond making sales people happier, because when your company brings in more money, it is likely that everybody who works for it is better off.

This is doable, but there are many areas that need to be addressed. It is a lot of work, but the results are worth the efforts that they require.

This article explores these steps and topics primarily from software application selection and development perspective.

Next article provides a sales CRM example (SalesGetter CRM application prototype) that has been customized for a sales process.



Investigate The Options That Are Available

Unless you already are very familiar with the contemporary sales software options that are available, the starting point should be researching and reviewing what the software vendors offer. Search engines provide links to the relevant information.

Make a list of different functionality parts and features, and read some articles that compare different alternatives.

This is a creative step. Keep an open mind, don't exclude features yet - you can do that later. If interested, see element pooling topic for additional information. (The latter article is part of another website that addresses creativity management and development related topics.)

This process has its problems.

  • First, it can create information overload. Organizing information can be helpful here, and even more so, spreading the work over longer period of time can help.
  • Dividing the work between different project participants can, of course, speed up this step. This approach can succeed, if the participants work together extremely well and learn thoroughly from each other. Either way, you need at least one participant, who has a complete picture of the results, and can build on it during the next steps.
  • You don't really know, how long this step will take. Of course, you can set deadlines, but by doing so, you may compromise on the quality of the outcome.
  • So, plan accordingly. As needed, explain to others, why allocating more time and being as flexible as possible about the deadlines during this step can increase quality.
  • If interested, see Optimization Management: Quality, Cost and Schedule article for additional information.
  • Keep in mind, that this step is a starting point. Once you review applications and leave your contact information, software vendors sales representatives start contacting you. That can be useful, because you can ask them clarifying questions. At the same time, software vendors sales reps, of course, will try to close the sale on you. That's their job. Your job, at this point, is simply to gather information. Eventually, you may use their services, but before doing so, you have several more steps to go.

With the next steps, you will set the goals for your project.

If you know where you want to be, you can also figure out solutions for getting there.


Goal Setting - Difficult, But Necessary

Take a moment, and try to imagine yourself as your company's sales management team member.

Next, try to imagine, that you don't have as good sales software solutions available to you as you would want to have, but you do know, what features the ideal solution would have and how it would function.

This knowledge makes your life much easier, because now you can work with your IT people and focus on figuring out, how to materialize your ideal solution in real life.

However, if you don't have this knowledge, your professional life will keep pulling you in different directions, creating questions without offering definitive answers. That will mean additional problems.

As sales management team member, if you control or influence budget usage, then unless you knowingly isolate yourself from the outside distractions, you probably get from different sources all sorts of sales software offers that promise everything from outstanding ROI to excellent user and customer satisfaction.

The same applies, if you are IT management team member, who is working on getting the company an excellent sales software.

Without the necessary points of comparison it can become pretty difficult to decide, how likely it is that a specific sales software offered, or a new development direction, can deliver any actual improvements cost effectively for your company.

The proposed solutions probably cost quite a bit. If you do accept an expensive solution and it doesn't produce the needed results, you will be in trouble.

On one hand, you could try one option, and then another, and then yet another, but by doing so, you probably will exhaust your budgets without achieving enough in return. In addition, that will curb the participants enthusiasm.

On the other hand, until you don't have a sales software solution in place that actually does produce improved results, your current problems are likely to continue.

Here, we have that age old problem: if you don't know, where you are going, any road will take you there.

However, "there" will not increase your company's total sales profitably, and will not make the salespersons and the sales management better off - unless, by a very large number of lucky coincidences, it happens to be the right solution.

Well, you probably don't want to leave your company's sales increases to lucky coincidences.

So, the path towards the solution really starts with defining the ideal solution.

Knowing, what you need and why, will give you the needed points for comparison, so that you can decide, which offers contain the needed features and functionality. From there, you can find cost effective paths toward obtaining the right sales software solutions.


Business Analysis and User Interviewing

Ideally, the sales application will be set up so, that the future users will actually want to use it. Involving the users as participants in the software application functionality and feature determination process can be very helpful here.

This is one of the reasons, why the process of determining software application's features should involve business analysis and interviewing the application's future users. As much as possible, it is advisable to involve in this process either all the future users, or in the case of bigger companies, user group representatives.

Another reason is, that if you really want to determine, what kind of application would be the best for your company, you should do the business analysis and prototyping similarly to the way it should be done, when custom applications are built. This way you will have a collection of functionality areas and features for an application, that is put together based on your company's actual needs. Using this information, you can decide, which solution gives you the best outcome when you take into consideration your available budget, technology you want to use, and planned development time.

You could skip this business analysis and user interviewing step, take the vendor research information that you collected, and discuss that with your sales software application's future users. However, if you do that, you will narrow down your options, and will start selling to yourself and to your company the software, that the vendors want to sell you. That is, you will start doing one or more vendors work for them.

There is nothing necessarily wrong with that particular software, but how do you know, that these functionality areas and features that you discovered during your research, include everything that your company really needs? The vendors, no matter how good they are, cannot possibly cover every company's all the needs in what they offer out of the box.

Further, if you at this point let a vendor's representative do the business analysis and user interviewing, in order to determine the application's functionality areas and features, then the outcome will inevitably be based on what that vendor offers, and not necessarily on what you need.

Your best option is to use an impartial professional for this step, who is not trying to push you any specific vendor's agenda, or his or her own agenda. Impartial professional means just that. Impartial and professional.

Database application development related business analysis and user interviewing, when done professionally, means that among other things the business analyst determines, what the application's future users currently do and how they do it. Both currently used business practices, organizational structure, software used and other means of assistance, including even information that the users have on paper, should be taken into consideration.

In the process, relevant subject matters and their characteristics are identified. This information is then used for prototype building, and for back end table structure and user interface development.

If interested, see Subject Matters and Workflow Role in Software Application Development for additional information. Leadership, Management and Development: Personal Experience includes also some relevant general information.

This process is somewhat similar to an architect's creating a custom developed house for you, or a tailor making a custom suit or a dress for you.

In this case, the difference is, that after you will get the blueprint, different options for implementing it, and the cost estimates, you will decide, which alternative you will actually go with and who and how much should actually customize your production environment sales software application.


Defining Your Sales Process

If your company already has a formally defined sales process in place, that is also implemented so, that it is in reality followed by the sales personnel, feel free to skip to the next subsection.

Sales is a process. There are the meet-and-greet stage, needs and wants exploration stage, and so on, up to, hopefully, closing and follow-up. Sales process is a systematic, step-by-step description of the interactions between the seller and the buyer.

It doesn't matter that individual sales instances differ and some of them start at a later stage than others, or that some sales instances seem to skip some stages. These individual sales instances can still be tracked by the same structure, that is, the same sales process.

If your company does not have a formally defined sales process in place, or uses many different sales processes, you want to do some research on the sales process defining topic, so that you can put in place one, formally defined and enforced sales process. You may want to start with a generic sales process, and customize it for your company's needs.

You want to define your company's sales process, because the company specific sales process can be built into your sales software. Once that is done, sales management can define at any given point who is handling what accounts, at what stages the accounts are, how many accounts are in particular process management stages, and other relevant information.

Similarly, individual salespersons can easily access, review and organize their sales activity information. Other tools, discussed below, help to generate new sales instances, that are customized for specific products or services and target markets.

Further, application users can track and audit how sales is being handled on a much more detailed level, keep the activity components that produce sufficiently good results, and figure out new ways for improving these components, that do not perform sufficiently well.

Both sales management and individual salespeople can benefit from sales auditing. We will address this further below.

Another reason, why you want to define your company's sales process and have it be built into your sales software, is sales process management: the individual parts of the sales process can be managed.

While sales management has to be done by sales management team members, sales process management can - and should - be done by both the management team members, and individual salespersons as well, who manage their own results. This approach to sales process management lessens the sales management team members workload by spreading the relevant work between all the salespeople, and gives the salespeople tools that help them to improve their own results.

Implementing a formally defined sales process may seem rather difficult at first.

How will you ask your salespersons, including sales management members, to follow one and the same process from certain point on, if they are not used to doing so?

However, in reality, the salespersons do not necessarily have to do anything differently for the sake of the company adopting a formal sales process. The sales process should be formulated so, that the salespeople can identify the relationship between their actions, and the stages of the sales process.

Once again, individual sales instances can differ, that does not render the sales process invalid or unusable.

If interested, see the Sales CRM Example subsection, and especially the Sales Process Management in a Nutshell part of it, below for additional information.


Sales Audit

You probably want to use your sales software for different purposes: for contact information, for recording, who contacted whom, when and why, and what the results were, and so on.

Adding sales auditing, or, more specifically, sales process management auditing, to this list of must have functionality is also a very good idea.

Sales auditing, in this context, means that the sales software application users can find out what did go right, and what did go wrong with the sales process management - interactions between the sellers and the buyers - and then decide, what they will do about it, so that they can spend their time more productively and increase the total sales.

For example, sales management team members should be able to see any time they access the sales software application, how effectively individual salespersons are handling specific sales process management stages and specific types of customers, and what can be done to increase individual salespersons performance and the total sales.

It is advisable to set up the sales software application so, that individual salespersons can find out this information about their own performance as well, and address the areas they need and want.

So, the application users should be able to

  • Assess the total sales, the number of sales processes handled, the cost of individual sales processes and the closing ratio.
  • Assess the number of sales processes handled, so that they can find out, if there are patterns, that indicate that the sales processes are breaking down at certain points more often than is expected.
  • Assess the closing ratios per product, service and customer type.

In each of these areas there are remedies that can be applied, to improve the results.

It should also be noted, that when such detailed information is available, sales forecasting can also be set up with increased accuracy.

All this information can be accessed dynamically, any time when access to the software application is available.

Sales auditing looks back, at the already generated data. Sales process management is forward looking, and deals with the present and the immediate future - actions that a salesperson is taking, and can take next. Both types of information and tools and reports that use this information, should be available.

If interested, see the Sales CRM Example subsection, and especially the Using Sales Process Management For Results Improvement part of it, below for additional information. That subsection provides more specific examples of how sales process management auditing can be used for increasing sales.


Documents As Means of Communication

Generally speaking, there are two types of documents that describe to the software application developers, what the users need and want: specifications and prototype.

Both are used for more than one purpose, but for our discussion the important aspect is, that both are also means of communication.

Both can have variations, versions and additional documents added to them, and both can be called with different names.

Depending on the project type and software development methodology used, the need for these documents and their nature, what parts they contain and how thorough they should be before the application development process starts, can vary as well.

Software development methodologies vary from predictive to agile, with different versions in between. What software development methodology is the best option for you, depends largely on your situation.

If you have in-house developers, or you work closely with a developer who works as an independent contractor, or with a development company, and you have the necessary budget, then you may want to proceed with the sales software customization so, that you will use the software development methodology that the developers prefer.

If you have not decided yet, whom you will work with on your sales software customization project, then you are less bound by existing commitments and developers preferences. In that case, you can set the structure for the project, that will ensure that the quality is as high as you need it to be, without exceeding the price that you want to pay, and select developers, who can most cost effectively produce the outcome that you need.

For your sales software application selection and development purposes, you probably will end up working with an existing software vendor's technologies, that is customized for your needs.

As we discussed above, in previous parts of this subsection, before you select whom to work with and how to spend your budget, you probably want to have a clear idea, what you need and where you are going with this project.

This means, that for this type of project, you probably want to work in at least somewhat predictive manner. That is, you probably want to specify upfront, what functionality the application will contain, and even how the user interfaces will look like, and other usability aspects, in addition to specifying all the other technical and cost-related details.

I'm using the word "probably" here a lot intentionally. When it comes to sales software application selection and development, there are lots of different options available. However, when you, as a customer, work so, that you select between different vendor and developer alternatives, you are better off, if you know what you need and want, and then select the best sources for getting it.

When you work this way, then you need to use software development specific documents as means of communication, because, as is described below, these documents can be very helpful in the software vendor and developer selection process.


Why You Want To Be Proactive

When you hire software application developers, as part of the application development process, they usually put together documents that describe the application.

For your sales software application selection and development, you want to use a different, more proactive strategy for the following reasons.

First, sales is important enough - it is company's lifeline and revenue center. So, as we discussed above, you want to define the functionality areas and features that are set up for your company's needs, not for some generic entity, so that the application users have tools available to them that help to increase your company's sales.

Second, customized, well functioning sales software is probably a relatively big expense. It is better to get it right.

Third, for sales software, you most likely will choose between different vendors and, perhaps, between both vendors and developers.

Software vendors, naturally, like to present you their solutions and tell you, how they can customize their solutions for you. That is certainly useful information, but it is only one side of the coin. Here we have the same dilemma, that we discussed in the Business Analysis and User Interviewing part of this subsection. If you don't know, or cannot convey clearly, what it is that you need and want, you are in a disadvantage, because the other party will then limit your options with what he sells. However, that may not include the functionality and features that you need, set up the way you need, in order to increase your company's sales profitably, so that the new sales software would be a good investment. Then, instead of your needs and wants determining which sales software application you will buy, vendor salesperson's abilities as a salesperson will determine, what you will end up with. That, however, will not necessarily increase your company's sales by much, or make the whole deal otherwise a good investment for your company.

So, you want to make sure, that your company's sales application related needs and wants are documented, so that you can communicate this information to different software vendors and developers, and negotiate the most suitable terms and outcome for your company.

It is to your advantage to be proactive about putting together the first usable version of the needed documents, so that you can use them during the application vendor and/or developer selection, during the relevant communication and negotiation processes, and later also during the development processes.

Then, during the selection process, in addition to specifying other needed aspects, when you talk to the software vendors, you can ask them something like this:

  • "Here's what we need. Can this be done using your technology? Are there any functionality parts that we listed, that cannot be implement, using your technology, or any conflicts or complications that you see between what we need, and what your technology allows us to do? How do our needs affect the total cost?"

When you talk to the developers, you can ask them something like this:

  • "Here's what we need. Can you do this, and if so, what is your price, and how long will the development take? Are there any functionality parts that we listed, that you cannot implement? Have you done something similar before (using the technology that we have selected), and if so, can you present examples of your similar work and provide references that we can talk to about your work?"

During the selection process and afterwards, you may have to change some of the initial requirements. However, starting the vendor and developer selection so, that you are able to communicate clearly what you need and want, will provide a much more secure negotiating space for you.

Further, it is very much to your advantage to be specific about your needs and wants. Otherwise, if you have money to pay, many people whom you will talk to, will promise you a lot, just to get your business. If you give your business to a vendor and/or developer, knowing and clearly communicating what you need and want, your chances of also getting what you need and want will be much higher.


How Much Documentation Do You Need To Prepare?

Software application specifications are usually written descriptions of the application and its parts They may contain diagrams and other technical information, that tends to be abstract for non-technical readers. Further, unless the specifications are put together very thoroughly, they may contain parts, that can be interpreted differently.

Software application prototype is a representation of the written application specifications, rendered into a format that can be inspected and tested.

Prototype is a step from written application specifications towards the production environment application.

In some instances having a prototype produced for you as part of the application development process is more like luxury. In some instances it is more like must have.

Similarly, the specifications that you prepare can be very thorough, or rather general or even sketchy.

There is a trade-off here.

More thorough documentation helps you to explore your needs much better. The documentation preparation process itself helps to uncover and clarify needs. Similarly, more thorough documentation can be made to work so, that it helps to ensure, that you get what you need and want. If the vendor and/or developer agrees to something, and you have it clearly documented in writing, you can insist on having what you documented also as part of the production environment application. Otherwise, it's all just talk, that can be forgotten or interpreted in many different ways.

On the other hand, putting together more thorough documentation tends to require much more time, labor and money.

This is largely a situation and budget related judgment call. Here are some points, that you may want to consider.

  • The more certain you are at this point (after the steps listed above), that quite a few different vendors can provide sales software solutions that meet your needs and wants, the less thorough need these specification be, that you, as a customer, use for vendor selection.
  • However, if you don't go through the documentation preparation process thoroughly enough, you may end up with less than sufficiently thorough understanding of your needs and wants as well. If you think about your needs and wants only in general terms, then, indeed, it may seem that many different vendors can provide sales software solutions that meet your needs and wants.
  • Essentially the same applies to developer or development company selection, whose assistance you will use for your application customization. If you are familiar with the developer's work, or the developer has enough examples of his or her previous work that you can evaluate, and you like what you see, you can get by with less documentation before you will select the developer.
  • However, if you approach the developers with a thorough documentation, you can be more certain, that the developer understands you correctly, and makes the decisions based on correct understanding of your needs and wants. Sketchy documentation can be interpreted differently.
  • Software prototype is much less abstract for the users than specifications are, and allows users to evaluate the planned application better.
  • There are different reasons for putting together software prototypes. Being able to address usability related issues is one of them.
  • Usability engineering is an area, that is often overlooked and not addressed particularly thoroughly. However, application user satisfaction is closely related to usability.
  • My question is: Why to take chances, that the users will find the application difficult to use and, therefore, will not be happy with it? What makes that worthwhile? Small percentage of money and time saved? Probably not.
  • On one hand, if you are familiar with the person's work, who will handle the usability related aspects, and you have enough reason to believe, that he or she will do a good job on your sales software as well, you have less need for working on the prototype before you select the vendor and developer for your application.
  • On the other hand, prototype is also a communication vehicle. Your vendor and developer selection processes will produce satisfactory results with a higher degree of safety, if you have both specifications and a prototype ready before you select the vendor and/or developer, so that you can use both of these documents the way it is described in this subsection's part Why You Want To Be Proactive above.
  • There are different kinds of software application prototypes that you can use. Some static versions can be generated relatively quickly and inexpensively. These versions are better than nothing, but they tend to be much less useful for usability improvement purposes than are at least partially dynamic versions.
  • Ideally, with the prototype, application usage situations can be simulated for the users, so that their assistance can be used for usability improvement purposes, and for finding missing links between planned functionality parts.
  • There are other, application development related purposes that prototypes and their versions are used for. These topics are beyond the scope of this article.

In summary, less than thorough documentation can be put together much more rapidly and, accordingly, such documentation costs less.

Hiring a good business analyst for putting together thorough specifications and a prototype makes the vendor and developer selection processes more expensive and much more time consuming. However, the work that is being done upfront will shorten the development time later, and may even produce savings that way.

Most importantly, more thorough specifications will increase substantially the probability, that your company will indeed get the sales software application that meets the company's and the employees needs and wants.


Achieve Goals: Assemble The Path To The Most Optimal Outcome

When you develop or customize a specific application, like sales software, for a specific company and user group or groups, you can establish goals for the project and learn a lot about the users needs and wants before you start the application production process (the latter being application architecture development, table structure development, programming, usability engineering and so on).

I don't think that you can ever learn upfront everything that you need to know about the users needs and wants. Therefore, even trying to do that is wasteful. You can continue to explore and learn and deal with all sorts of unexpected circumstances throughout the project development process and may continue to do so after the application installation as well.

However, you can do business analysis and learn upfront enough, so that you can put together initial project development plan (structure) that is divided into milestones (structural parts), which contain initial or "default" project development component options, each of which is implemented unless a better alternative is specified.

Depending on your circumstances and preferences, you can determine, how detailed or broadly defined the milestones and the project development component options are.

Further, you may want to allocate extra resources (time, labor, and so on) to completion of each milestone. During the actual application production stage, use the extra resources up only when needed, and as much as you can, move or "roll them over" from one milestone to another.

After you have figured out and documented your sales software application selection and development related goals, you may want to explore different alternatives for achieving these goals.

If you know precisely what you need and want, and you believe that you have all the needed resources available to you, including money, time and labor, and there does not seem to be any problems with getting, customizing, installing and using the best possible version of your application, then, congratulations - carry on, implement the development plans.

However, if things are not as good, don't give up on your goals. If you have done thorough work so far, and you know what kind of sales software application can help your company and its employees, but you don't have all the needed resources available, or you have other types of problems that need to be handled, generate and consider different alternative solutions, and from the results assemble the path to the most optimal outcome.

For example, if you don't have enough budget for the needed application, perhaps you can use cost-effectively a temporary solution, that does include the most important features that help to increase sales? This way, you can test these features and, perhaps, also improve them. Further, if you already have features as part of one application, that you want to be added to another application later, then these features serve as a prototype, and most likely will make the next application (or application version) development easier and less costly.

Perhaps you can make a deal within your company, that when you increase sales by a specific amount or percentage of your cost, you will also get enough funding, so that you and your company's employees can have the sales software that you actually want.

This process requires goal oriented creativity. If interested, see the relevant article on for additional information.


Do You Need a Custom Designed Software Application?

When you consider different software options, you may want to consider, as one of the alternatives, getting custom designed and built application. For the right set of circumstances, custom designed and built application can deliver much more value than any other alternative can.

Of course, the same applies to sales software application selection.

Using vendor technology has certainly many advantages.

Generally speaking,

  • the more other applications the new application will have to be integrated with,
  • the more you may have to deal with technology incompatibility issues,
  • the less important maintaining control over the application's architecture (and operating speed) is to you,
  • the less concerned you are about leasing vs. ownership issue (typically, you don't buy, but lease something from the vendor),
  • the less concerned you are about being locked into using a specific vendor's solutions and services,
  • the longer the software application will be used for,
  • the more users the software application will have,
  • the more widely the users are dispersed (in different locations),
  • the more mobile and over the Internet users the application will have,
  • the more standardized and widely used are the planned application's functionality areas and features,

the more you should favor vendor-based solutions.

However, if you need a highly customized solution, it certainly makes sense to at least consider, as an option, getting a custom designed and developed application. Whether or not this option is right for you, depends on number of variables, some of which are bulleted above.

Further, if you need a cost effective solution, you may want to hire a person who works on site, directly with the end users as project manager and business analyst, and for the rest of the application development tasks hires on as needed bases, on behalf of the customer, remotely located development team members on open markets.

The remotely located developers are not on the customer company's payroll and do not require any of the customer company's resources. They get paid only for the work they do; typically around $15 an hour.

Such technology connected organizational structure enables the customer company to have the necessary skills available on demand, for low cost, without paying anything beyond the direct cost of application development.

However, the downside of hiring developers for customized work is, that more emphasis has to be put on developer selection and development related quality control. Otherwise, different type of problems can arise.


Overcoming Obstacles

It is possible, that during the individual steps listed above, you will have to handle different types of obstacles. Most likely you will want to proceed in a goal oriented manner and figure out, how to handle the obstacles, so that the needed solutions can be put in place.

The principles that are applied here are based on CreativityModel Method and apply to all sorts of situations. However, the examples that are used here, focus on overcoming some possible sales software application selection and development related obstacles.

When you need to achieve specific goals, you want to figure out, what steps should precede reaching the goals, and what steps precede these pre-goal-reaching steps, and so on, from goals back to the starting point, thinking in a manner "because I need to achieve this, I need to do that." Then, you will implement the relevant string of steps in the normal order, from the first to the last, until reaching the final goals. In addition to using this type of goal oriented creativity, as needed, you want to mix usage of choice based creativity and generate additional options for connecting the steps the best you can.

In each situation you want to figure out the elements that you are dealing with (theme, goals, structure, content components). Doing some research on the relevant subject matters can also help to uncover important information.

For example, you may discover, that for doing a good job, you need more resources than was initially anticipated. You may need more time, or more money, or additional labor resources, or all of the above.

Let's say, that the objective is to get an approval for both more time and more money for doing business analysis, and specifications and prototype development, as is described in some of the previous parts of this subsection.

One or more people probably approve this request. Let's say, it's one person. If more than one person's approval is needed, proceed accordingly, taking also into consideration, in what order you need to approach them.

Every person is motivated by something. You need to figure out, what professional aspects of the situation motivate that individual the most, who can approve this request.

Ask around. There is nothing unethical about this. After all, you are trying to get your job done the best you can, so that you can benefit your co-workers and your company.

Essentially, you need to sell an idea, that you need more resources, to the person who can approve such requests.

Every situation and undertaking has some kinds of rules that apply. Your company or department specific rules may apply here. Ethical decision making, obviously, applies in general, as a rule.

Because you are selling an idea, and ideas are intangible, another rule that applies here is, that when you sell intangibles, sell the benefits, not the features.

Everything can be characterized differently.

So, you need to figure out, how to characterize most effectively the benefits that your having more resources available will produce, to the person, who can approves your request. Is it higher quality of the application? Increased certainty, that the application development related goals will be achieved? Salespeople being happier with the outcome? Increased ROI?

Further, you may discover that the person, who can approve your request, can be more easily influenced, if another person whose opinion he or she values, also supports your request. Then you need to figure out, which professional aspects of the situation motivate that person the most, and talk to him or her first.

The order of the structural parts of your request approval getting project is important. You can figure out the structural parts of your plan by finding out, what steps should precede the desired outcome. However, you want to implement the plan in the opposite order, from the start to the conclusion.

Otherwise, your actions can be less effective. If you first talk to the person whose opinion weights heavily with the supervisor who can approve your request, and then to the supervisor, the outcome is more certain to be positive. If you first talk to the supervisor, he or she denies your request, and you then talk to the person whose opinion weights heavily with the supervisor, then that order of your actions may create additional problems for you.

You may also encounter problems, when you work with salespeople. Salespersons are busy, and some of them may not be particularly interested in the new sales software application. For example, they may believe, that they are comfortable enough with their existing tools, and the new application generates too much transparency for them, or that the new application will require too much data entry from them, or that it may not produce any tangible benefits for them.

You need to uncover the objections, and address these objections. Lack of time is hardly ever the real reason. That means, that the person you want to interview, does not see enough value in the new application. You want to find out why the person thinks so, because that information can both help you to put together a better set of specifications, and also sell the application more effectively.

Are there some kinds of expectations, beliefs or values involved?

Find out the objections, give them some thought and as much as possible and feasible, figure out alternative solutions to the objections, and test the alternative solutions with the users.

That helps you to sell the solutions that are based on the objections. "Mark wanted to have the ability to add more than one account manager to a sale, if necessary. Now we have this feature, too."

You can find many useful additional features this way. Further, if you know what the individual salespeople are interested in and you can develop the specifications and prototype, and later the application accordingly, then with each salesperson you talk to, you can make the case, that there definitely is something for him or her, too, in the new application.

Be specific, and point out features that are both helpful, time and effort saving, and are likely to help salespeople to make more money.

Obviously, your statements have to be true, and equally obviously, the new application should contain tools that actually do benefit the salespeople - otherwise, why to bother working on it at all?

You may also encounter problems, when you work with the management team members.

Here, the objections may be more general in nature, and, thus, more difficult to deal with. For example, an individual management team member's objections may be based on past less than clearly profitable software projects, or even costly failures of big software projects.

You cannot change the past, but you can positively influence the future with your project.

As much as you can, try to uncover, what lead to the failed project in the management team member's opinion. You can both learn from that, and you can help to make sure, that the past mistakes will not be repeated.

You may want to involve the management team member in the project in the manner, that does not require too much of his or her time - for example, as an advisor, with whom you meet as frequently, as the management team member finds appropriate.

Further, some people whom you will talk to may be skeptical of software application's ability to help to increase sales.

Of course, it is not the software, that will end up increasing sales, it is the salespeople who will use that software, who will increase sales. However, just like better designed car takes you from point A to point B more securely, better designed sales software will help to increase sales.

If we give the salespeople, who want to make more money anyway, tools that will help them to do so, what reasons do we have to believe, that they will not use them for making more money?

This reiterates what we discussed before. Sales software, that is not user and company specific, and does not contain relevant tools, may indeed become a less than profitable investment. Before sales increase, you need people who use tools that help to increase sales, and who were appropriately trained on the new application usage. Before that, you need to figure out, what tools, functionality areas and features are needed, in order to increase sales.

One thing precedes another, and leads to another. Right actions, implemented in the correct order, lead to a successful outcome.

The examples that are presented here, are relatively general. Reality contains often complex nuances, that matter a lot. However, the same principles apply.

Naturally, the quality of the project elements that you use and how you them, contributes to the quality of the final outcome. You personal expertise, experience and abilities all have important roles here. This applies to project management, business analysis and other project development areas as well.

However, this is not an "all or nothing" type of scenario. You can learn from other people and from your own mistakes, and over time master increasingly detailed project components successfully.


Achieve Goals: Implement The Action Plan

Once you have your action plan together, implementation, just like planning, is likely to require a combination of goal oriented creativity and choice based creativity. Because you need to achieve specific goals, you want to make sure that you stay within the goal oriented creativity mindset and framework.

If your project's project development plan (structure) is established correctly, then following the milestones (structural parts) will take you to your goals. Within these milestones, you can move some resources around on as needed bases. Further, as was suggested above, as much as you can, move or "roll over" these extra resources from one milestone to another, so that you have a buffer zone of resources available to you.

This approach is easier to implement if during the planning stage you ask for more than what you think you will need, and during the implementation stage use what you have sparingly.

Development situations - unexpected circumstances and additional application enhancement needs and opportunities - may pop up throughout the project.

You have to balance each such situation for quality, cost and schedule (length of a step within a milestone, or an entire milestone). You may need to prioritize these three project development areas in each development situation. In each such situation make sure that your short-term goals are related to the overall project development goals, so that the outcome of the development process is coherent and consistent.

You may also encounter difficulties with generating the necessary outcome. When needed, use choice based creativity, do research and pooling, amass different options and try connecting-combining components in different ways.

Don't give up when you have temporary setbacks!

Often enough, your willingness to try different alternative solutions determines, whether or not you will succeed - and your project along with it. If you get tired of trying, think about the good that the project can produce. Find motivational power in the good that you can do.

While achieving the overall project development goals is important, especially for longer projects, make sure that the project development process itself is also pleasant and fulfilling for the participants. To put it differently, it's not enough to keep your eye on the goals as the prize. The journey there should be pleasant, too.

Next subsection contains a sales CRM example that is customized for a business process.