RollTop

How To Write a Winning Proposal

 In today's economy, sales people have to write more proposals, and better proposals, than ever before. As the industry has become more competitive and complex, customers have become both more confused and more demanding. As a result, they are likely to listen to a presentation, nod their heads, and mutter those dreaded words, "Sounds good! Why don't you put that in writing for me?"

Why Do Customers Want Proposals?

Writing proposals is about as much fun as having your teeth drilled. And reading them isn't a whole lot better. So why do customers ask for them?

One motivation is that the customer wants to compare offers from various vendors to make sure they buy the highest value solution based on your differentiators and value proposition. At a simpler level, they may just want to compare prices, clarify complex information, and gather information so that the "decision team" can review it. And let's face it, sometimes they just want to slow down the sales process and they figure that asking for a proposal will keep the sales rep busy for a few weeks.

Whatever the customer's motivation, the fact is that proposal writing has become a common requirement for closing business throughout the entire business world. Today, people who sell everything from garbage collection services to complex information technology have to create client-centered, persuasive proposals.

What Goes into a Winning Proposal?

Your objective in writing a proposal is to provide your client with enough information—persuasively presented information—to prove your case and motivate the client to buy your services or applications. That sounds pretty straightforward.

So why do the vast majority of proposals start out with the vendor's company history? Does the author believe there is something so fundamentally compelling about their origins that clients will immediately be persuaded to buy?

And why do a huge number of proposals focus entirely on the vendor's products and services, but never mention how those products and services will help the client solve a business problem or close an important gap? Does the proposal writer believe that facts alone are enough to motivate a prospect to say "yes"?

Winning proposals must be client centered, not company- or product-centered. Most people buy because they're looking for solutions to pressing problems, additional resources to close gaps, or the means to cope with difficult issues. What this means is that a proposal is not a price quote, a bill of materials, or a project plan.

Each of those elements may be part of a proposal, but they are not sufficient to make a persuasive, client-centered case.

In our experience, there are four categories of content that proposals must contain to maximize your chance of winning:

1. Evidence that you understand the client's business problem or need
   People view major buying decisions with anxiety. The bigger the decision, the greater the anxiety. They know that even a well-intentioned vendor may end up wasting their time or their money or both. One way to reduce their anxiety and minimize their perception of the risk of moving forward with you is to demonstrate that you clearly understand their problems, issues, needs, opportunities, objectives, or values. Whatever is driving the client's interest, you must show that you understand it and have based your solution on it.
   
2. A recommendation for a specific approach, program, system design, or application that will solve the problem and produce positive business results
   It may surprise you to learn that most proposals contain no recommendation at all. What they contain instead are descriptions of products or services. What's the difference? A recommendation explicitly links the features of a product or service to the client's needs and shows how the client will obtain positive results. And it contains language that unmistakably shows that the vendor believes in this solution: "We recommend" or "We urge you to implement"
   
3. A compelling reason for the client to choose your recommendation over any others
   This is your value proposition. Remember that you may write a proposal that is completely compliant with the customer's requirements, that recommends the right solution, that even offers the lowest price, and still lose. Why? Because a competitor made a stronger case that their approach offered a higher return on investment, lower total cost of ownership (TCO), faster payback, or some similar measure of value that matters to the customer.
   
   NOTE: Most proposals don't contain any value proposition at all. They contain pricing, but no estimation of the rate of return the client will get from choosing you. Failing to address the client's needs and failing to present a compelling value proposition are the most serious mistakes you can make in writing a proposal.
   
4. Evidence of your ability to deliver on time and on budget
   Most proposals are pretty good in this area. You want to show the substantiating evidence that helps answer the question, "Can they really do this?" Good evidence includes case studies, references, testimonials, and resumes of key personnel. You may also include project plans, management plans, company expertise, and other forms of evidence (white papers, awards, third-party recognition). Avoid throwing in everything. Keep the evidence focused on the areas the customer cares about.

These are the essentials. Every scrap of data, every figure, every paragraph in your proposal must contribute toward providing one or more of them, because they directly address the three key factors on which every proposal is evaluated:

1. Responsiveness: Are we getting what we need?
2. Competence: Can they really do it?
3. Value: Is this the smartest way to spend our money?

Some Tips for Maximizing Your Win Ratio

If you follow the basic structure outlined above—first summarizing the client's needs, then showing their potential for gain or improvement, third recommending your solution, and finally substantiating that you can do the job—you will see an increase in your win ratio.

But there are two other principles that can push it even higher. In fact, one way to remember these is to recall that there are two "Ps" in successful proposal writing:

• Personalization
• Primacy

Personalization

Customers expect more today. Why? In part, because they have been trained to expect more, because of the business community's emphasis on excellence in customer service, focus on "total quality," and increased competitiveness of the market.

You can't give customers a boilerplate proposal in today's market. You have to include their name and their company's name throughout the proposal. You have to acknowledge that you have listened to them and remember what you learned about them from previous interactions.

Here are four conclusions that emerge from the reality of heightened customer expectations:

• Effective sales people do not deliver one message
  They do not treat customers as demographic units. They engage in conversations, they listen, and they view customers as individuals.
  
• Effective marketing and sales require a combination of content and insight
  You must have something worthwhile to say and you need to say it in a way that shows the audience that it's relevant to them.
  
• Boilerplate messages may be worse than no messages at all
  because they sound "canned" and undercut the rapport we've created with customers.
  
• Use the customer's language and refer to issues from their business and their industry
  If you use the jargon they use and if you show familiarity in the cover letter and executive summary with what's going on in their business and industry, they will assume that the entire proposal has been personalized to them.

Unfortunately, most sales people resort to "cloning" as a means of getting their proposals done quickly. They borrow a proposal that somebody else has written for a different client, use the Find/Replace function in Microsoft Word to change the client's name, and print it! That's about as personalized as a can of spinach. (Plus they run the risk of having the wrong client's name show up somewhere in that proposal. You can imagine what that does for rapport and credibility.)

The Primacy Principle

What is the "primacy principle"? It's the tendency we all have to judge future experiences based on our first one. You might call it the principle of first impressions.

For example, if we go to a new dry cleaner in our neighborhood, and they end up losing a couple of our shirts or blouses and are rude to us, we'd have to be masochists to go back. It may be that they are normally very efficient and polite, and a combination of circumstances conspired to produce a negative impression on us. But we'll never know. We'll never go back. Research indicates that the primacy principle is so strong that it takes at least seven positive experiences to overcome a first negative impression. (Or, conversely, seven negative ones to overcome an initial positive experience.)

So what does this mean for proposals? It means we must put the things up front in our proposal that the customer cares about the most. It means don't send a boilerplate cover letter. Don't write an executive summary that's all about you. And don't call your proposal something generic and pointless, like "Proposal."

The Solution

The primacy principles tells us that it's vitally important to understand the client and then structure the message correctly. Put the customer's most important business issues first. Put the goal or outcome they want the most first in your list of outcomes. And structure your substantiation in terms of the things that matter the most to the decision maker:

• Meeting a perceived need
• Delivering superior value or return on investment (ROI)
• Complying with the specification
• Proven vendor competence

Don't guess! If you don't know what the customers care about, ask them.

Ref: http://www.technologyevaluation.com

Creating a Custom Large List Selector

Creating a Large List Selector

Solution Approach

In some applications, end users may have to choose a value from a list of thousands or perhaps millions of values.  These values cannot be realistically displayed in a dropdown list or a listbox on a web page.  When the number of values exceeds 500, Iron Speed Designer automatically creates a default Large List Selector.  The number of items before a large list selector is displayed can be changed by modifying the MaxGeneratedItems pass-through attribute property.  However, the default large list selector may not be ideal in all situations because you may want to display additional columns, or provide different searching and filtering capabilities than provided by the default large list selector.  This is fairly easy to accomplish in Iron Speed Designer.  You can create a custom Show Table page and use this as a custom large list selector by making slight modifications to the layout.
This example shows how to create a “Customer Selector” page that can be displayed in a popup window, and that contains links that populate a text box in the opening page when clicked.  This example is part of the AcmeOMS sample application included with Iron Speed Designer.
To create a custom large list selector, modify the page to display a Lookup link.  This link will open the large list selector and pass the associated textbox field as a “target” to receive the selected value.  The large list selector page is a standard Show Table page modified to display a Select link.  When the user clicks on the Select link, a small Javascript function sets the selected value in the target textbox.  The following step-by-step instructions walk through each modification.
The Add Order page below was modified to display a Text Box for the Customer field followed by a Lookup hyperlink.  The Lookup hyperlink will allow the end user to search and select a customer from a popup window.

Procedure

Step 1:  Select the page in Iron Speed Designer’s Application Explorer where you would like to display the Lookup link, and select the Design  tab, e.g.:

…\ Sample Applications\AcmeOMS\Orders\AddOrdersPage.html

Step 2:  Change the CustomerID field on the page to a textbox from a dropdown list.  Double click the field to display the Page Properties dialog and change the Display Style on the Display tab to Textbox.
Step 3:  Switch to the HTML tab and add the following client script code inside the page’s layout.  This script can be added right below the line containing the link to the style sheet.  Change the URL if appropriate.

The above Javascript defines a function called OpenCustomerSelector that takes a parameter called “target”.  The function opens a browser window for a URL passing the “target” URL parameter.  The “target” URL parameter is the ClientID of the textbox that will receive the selected value.  In the AcmeOMS example, this would be the CustomerID textbox displayed on the Add Orders page that will receive the selected value.

Step 4:  Add the following HTML/DHTML inside the page’s layout immediately after the CustomerID textbox to display a Lookup hyperlink.  The following code will call the OpenCustomerSelector Javascript function defined above with a ClientID of the CustomerID textbox field.  The ClientID is the Microsoft .NET Framework ID of the CustomerID textbox.
C#:

  Lookup...

Visual Basic .NET:

  Lookup...

Note that C# pages refer to the page class as “this” and Visual Basic .NET refers to them as “Me”.  Also note that C# is case sensitive, so ClientID must be specified with ID in upper case.
If your CustomerID textbox is inside a table, then you need to use an alternate way to retrieve the Client Id since there are multiple rows on the page containing the CustomerId field.  To find the unique CustomerId for the row which was clicked, use Container.FindControl("CustomerId").ClientId as follows:
C#:

'); return false;">

  Lookup...

Visual Basic .NET:

'); return false;">

  Lookup...

Step 5:  Create a new show table page that will be displayed when the end user clicks the Lookup hyperlink.  The easiest way to create this page is to select File, New Page menu and select the Empty Page template since no header, footer or menu is required on the popup window. 
Step 6: Drag and drop a Show Table panel on the page and press the Configure button to display the Panel Wizard.  Select the Customer table and the desired set of fields to display on the page.  Select the set of fields to be searched by the Search control on the page and any filters to display.   Press Finish to configure the table panel.  Using the Design tab, change the layout to your satisfaction.

Step 7:  Switch to the HTML tab and add a Select link to the row.  When the user clicks this link, the CustomerID of this row will be inserted into the CustomerID textbox on the underlying page and the popup window is then closed.

 Select

When the end user clicks the Select link, the UpdateTarget function will be called with the CustomerID of the current row.
Step 8:  Add the following client script code inside the page’s layout.  This script can be added right below the line containing the link to the style sheet.  Change the URL if appropriate.
C#:

Visual Basic .NET:

The above Javascript defines a function called UpdateTarget that takes a parameter called “selectedValue”.  The function retrieves the “target” URL parameter from the URL and sets the .value to the selectedValue parameter passed to the function.
Once the value for the target variable is set, the current popup window is closed.
Step 9:  Bind the CustomerID field value to display the ID of the customer for each row.  Launch the Page Properties dialog from the Tools menu, navigate to the CustomerID field in the tree on the left.  Go to the Bindings tab and select the CustomerID field.  On the Display tab select the Literal Display Style.
Step 10:  By default all pages displayed will be added to the session navigation history so that pressing the Cancel button on the page will go back to the previous page.  To ensure that the popup window is not added to the session navigation history, override the UpdateSessionNavigationHistory function and do not call the underlying base function that would add this page to the history.
This should be added in the code-behind file for the CustomerLargeListSelector.aspx page.  In C# this would be CustomerLargeListSelector.aspx.cs and in Visual Basic .NET it would be CustomerLargeListSelector.aspx.vb.
C#:

protected override void UpdateSessionNavigationHistory()

{

     // do nothing

}

Visual Basic .NET:

Protected Overrides Sub UpdateSessionNavigationHistory()

     'Do nothing

End Sub

Step 11:  Build and run the application.  The Customer Large List Selector page is now ready to use.

Learning:Restore Focus after TextBox Automatic Postbacks

Restore Focus after TextBox Automatic Postbacks

Introduction

Postbacks triggered by a DropDownList or a Check Box are hardly noticeable. However it’s a different story when an UpdatePanel refreshes its content after a partial automatic postback. Specifically, two side-effects will occur. Loss of focus: None of the controls on the page will have the focus unless it is explicitly set in the server-side code. Loss of data: Any data changes made between the moment when the postback is triggered and the moment when the postback is finished are wiped out. For example, a user enters data in a Text Box and presses the Tab key to move to the next field and begins typing. Seconds later, the content in this text box disappears and the user is forced to reenter the data. In this article, I will show you how to save time and prevent the above scenario from happening.

Solution

The root cause of these issues is derived from the way an UpdatePanel is refreshed on partial postback. When an ASP.NET page receives the result of a partial postback, it clears out the current content on the UpdatePanel and resets the inner HTML to a newly received result. All of the DOM objects within the UpdatePanel are destroyed and recreated, resulting in the loss of focus and data. The best solution, of course, is to avoid postbacks in the first place. However, there are times when developers use postbacks for convenience instead of business logic. If the business logic of the postbacks requires no new data from database, (i.e., all information is already available on the client-side), then it can and should be handled with client-side JavaScript code. However, if new data is required, there is an alternative solution in PageMethods, which is used by Iron Speed Designer’s popup text and image. PageMethods sends to and receives from the server much less data than partial postbacks. They apply the results to existing DOM objects instead of destroying and recreating them, thus preserving the focus and data. If the two solutions above are not applicable to your page and postback is your only option, there is not much you can do to prevent data loss. The best you can do is to make the server process as fast as possible. However, you can prevent focus loss, or more precisely, restore focus with some JavaScript code.

Implementation

The following JavaScript code is modified from Yuriy Solodkyy’s blog.... Append it to the end of ~\ApplicationWebForm.js for existing projects. You may also append it to a code template in Iron Speed Designer’s installation folder here: \ProjectTemplates\vs200x\cs(vb)\ApplicationWebForm.js. This will ensure that changes are applied to future projects. JavaScript var lastFocusedControlId = ""; function focusHandler(e) {     document.activeElement = e.originalTarget; } function appInit() {     if (typeof (window.addEventListener) !== "undefined") {       window.addEventListener("focus", focusHandler, true);     }     Sys.WebForms.PageRequestManager.getInstance().add_pageLoading(pageLoadingHandler);     Sys.WebForms.PageRequestManager.getInstance().add_pageLoaded(pageLoadedHandler); } function pageLoadingHandler(sender, args) {     lastFocusedControlId = typeof (document.activeElement) === "undefined"                 ? "" : document.activeElement.id; } function focusControl(targetControl) {     if (Sys.Browser.agent === Sys.Browser.InternetExplorer) {       var focusTarget = targetControl;       if (focusTarget && (typeof (focusTarget.contentEditable) !== "undefined")) {         oldContentEditableSetting = focusTarget.contentEditable;         focusTarget.contentEditable = false;       }       else {         focusTarget = null; } try {           targetControl.focus();           } catch (err) {}       if (focusTarget) {         focusTarget.contentEditable = oldContentEditableSetting;       }     }     else {         targetControl.focus();     } } function pageLoadedHandler(sender, args) {     if (typeof (lastFocusedControlId) !== "undefined" && lastFocusedControlId != "") {       var newFocused = $get(lastFocusedControlId);         if (newFocused) {         focusControl(newFocused);         }     } } Next, in ~\App_Code\Shared\BaseApplicationPage.cs (vb), find the method Control_ClearControls_PreRender() and insert the commented code block “Register RestoreFocus.” C# protected void Control_ClearControls_PreRender(object sender, EventArgs e) {     this.ClearControlsFromSession();     // Register RestoreFocus     if(!IsPostBack)       ScriptManager.RegisterStartupScript(this, GetType(), "RestoreFocus",         "Sys.Application.add_init(appInit);", true); } VB .NET Protected Sub Control_ClearControls_PreRender(ByVal sender As Object, ByVal e As EventArgs) Me.ClearControlsFromSession()     ' Register RestoreFocus    If Not IsPostBack Then     ScriptManager.RegisterStartupScript(Me, [GetType](), "RestoreFocus", _         "Sys.Application.add_init(appInit);", True)    End If End Sub Now all pages will return the focus to the previous owner before postbacks.

Conclusion

Text Box automatic postbacks may cause loss of focus and data. The best solution is to avoid them. But if using automatic postbacks is necessary, try restoring focus with JavaScript code.

What Is ERP in 2010?

Introduction

When Gartner introduced the term "ERP" in 1990, it applied primarily to manufacturing, specifically the planning and management of the resources needed to produce particular goods. Today, however, every business decision maker realizes that his or her enterprise relies upon resources, and that planning is essential to optimize how those resources are acquired, allocated and used. This means that the definition of "ERP" is evolving and expanding to include multiple critical business functions. This dynamic has significant implications for every type and size of organization. Below, some observations and recommendations intended to aid navigation of this roiling evolution.

Analysis

"Another manager in my business asked me to define ERP today and I didn't really have a good answer for him," Focus contributor Patrick Mills posted recently to the Focus Finance Group. "How would you guys define ERP and what does it encompass?"
"The key word is 'enterprise' - software systems that can potentially address most, if not all, of the critical processes and functional areas in a company," replied Focus contributor Paul Sita. This varies, based on whether you are in manufacturing, distribution, services or other kinds of industry. But anything that can be considered [a true] ERP solution has to address the breadth of the organization. Most customers do not implement all that functionality, certainly not in the beginning. However, they grow into it, and the integrated nature of ERP systems, by definition, brings value to whatever sub-set of applications you do implement," Mr. Sita added.
However, Focus contributor Richard D. Cushing pointed out that reality often differs from the ideal. "Unfortunately, what I call 'traditional ERP' is often nothing more than an 'everything replacement project.' Enterprises of all sizes decide it's time to tear out their core systems and replace them with something that they believe - or have been told by their reseller or vendor - will make them faster, better or more efficient. Unfortunately, the results are often disappointing." Mr. Cushing added that "the new ERP" should focus on "'enhanced readiness for profit,' which is what companies doing traditional ERP are really looking for but all too frequently cannot find."
From a slightly more technically focused perspective, "ERP (formerly called MRP [for "manufacturing resource planning"] is about bringing standalone databases together," said Focus contributor Rick Rude. "From a financial perspective it would be bringing Accounting & Finance and pulling in Payroll," Mr. Rude offered as an example. "Historically, MRP was built for Manufacturing to track projects," Mr. Rude added.
Today, however, ERP embraces so much more than the tracking of manufacturing projects that many users have trouble deciding where ERP ends and related but different business functions begin. Among the most frequently mentioned of these other functions is CRM, according to Focus community members. Charlie Ellis, a member of the Focus Sales Group, recently asked, "If I buy an ERP system, do I have to purchase a separate CRM system? Is that [CRM] a module that can be included in an ERP system?
"These terms are becoming blurred so the answer depends upon which ERP or CRM system you buy," said Focus Expert Simon Gantley. "There are a lot of CRM systems that include a lot of ERP functionality, for example NetSuite, EnterpriseWizard and Siebel [which is now owned by Oracle]. There are also ERP systems with CRM modules such as SAP," Mr. Gantley added.
"Normally CRM is not included as part of ERP. An ERP system allows you to integrate engineering, customer service, planning, materials, manufacturing, finance, and human resources across a single facility or across multiple locations. However CRM systems help you track and manage your customer relations, said Focus contributor Betty Feng.
"CRM systems often provide 'pre-sales-to-order'-type capabilities to help land the sale/contract that then is processed and fulfilled in the ERP system modules," added Focus contributor Len Green. "CRM also can help with after sales service management and improved company-wide views of customer activity."
Beyond CRM, many decision-makers considering or pursuing ERP deployments seek guidance regarding specific ERP modules and features. For example, Focus Operations Group member and operations manager for a 250-person manufacturing company Todd Lang recently asked, "What are some top ERP modules to consider when buying?"
"The modules need to map directly to your needs and the solution that you purchase needs to allow you to unbundle unnecessary modules," affirmed Focus contributor Scott Priestley. "Understanding your quote-to-cash-flow [processes] is the first step" in making the right ERP feature, function and module choices, Mr. Priestley added. He then offered examples of specific questions Mr. Lang and any other decision-maker pursuing or considering ERP should ask before choosing a solution:

1. Do you need sophisticated financial integration between different businesses, locations, continents, etc?
2. How tightly is product design/engineering integrated into the quote-to-cash-flow [process]?
3. Is robust, integrated Quality/ISO functionality a requirement?
4. How do you do HR/Payroll?
5. Do you have a mature IT team that can support a modern system going forward?

Focus contributor Robert Israch offered some additional questions worth considering.

• Is sales, marketing, and support included or must [your ERP solution] be integrated with other applications?
• How do you manage customer renewals and up-sells?
• Do you have multiple locations and/or vendors/partners who need to access certain parts of the system and that you need to collaborate with across locations?
• Do you need access to the system 24/7 and from multiple locations and on the road?
• Would you like KPIs [key performance indicators] and dashboards built in to the applications? Should they be real-time?
• Do you want visibility across leads, sales, customer transactions, services issues, inventory, fulfillment, cash flow, payables and receivables, etc?
• Do you require having your systems managed on site or would you prefer to reduce software and hardware management and total cost of ownership by using a SaaS [software as a service] ERP vendor instead?"

 

Conclusion

Clearly, effective ERP solution selection and deployment relies heavily upon comprehensive assessment of specific business needs. This point was emphasized in the response to Mr. Lang's question offered by Focus Contributor Steve Christensen. "The first question would be why do you need an ERP [solution]? What systems do you currently use to track your business? What is missing in your business systems that lead you to consider a new ERP [system]? There are much more cost-effective, less disruptive and better systems [you can use] to run your business than going the route of a full ERP solution," Mr. Christensen said. He added that even SaaS-based ERP solutions can be "intolerably inflexible" in meeting business needs, if not chosen based on effective assessment and prioritization of those needs.
Clearly, ERP selection and deployment decisions can be daunting, and can have significant effects on how a business does business. Decision makers considering or pursuing ERP must begin by assessing specific business needs carefully, and ensuring that all candidate solutions and vendors are aligned with those needs. Such an approach can ease and speed the path to ERP success, while any other approach risks disappointment, inconsistent use and little or no business benefit. 

Ref: http://whitepapers.technologyevaluation.com

5 Steps to Successfully Conducting and Rating Software Demos

So, you’re the guy/gal who’s been put to the task of choosing your companies next enterprise software solution? Well, if you’re reading this, you’re most probably well on your way to choosing that software by now. You’ve made your proposal to your stakeholders; you’ve gathered your requirements and prioritized them; you’ve gotten a handful of software vendors to complete your RFI. So now what? Well, there’s still one very important step that needs to be taken: seeing the shortlisted products in action!
There are five important steps to successfully conducting and rating on-site software demos.
1.    It’s All in the Script: Developing a Demo Script
2.    Requesting a Product Demonstration
3.    Inviting Vendors On-site to Show Them Your Environment
4.    The Demo: Lights, Camera, Action!
5.    Rating the Demonstration, the Vendor, and the Product
General Information about On-site Demos
The on-site software demo is the ultimate opportunity for vendors to demonstrate the capabilities of their product(s) to potential clients—and let’s face it; one of the last things they’ll do to either make or break the deal (apart from the pricing proposal). A demo gives perspective software buyers—like you—a chance to see if your impression of what the vendor says it provides will hold true to its claims—and if the reality of those claims will be satisfactory for the needs you’ve outlined.
Vendors will demonstrate real-life scripted scenarios as described in your demonstration script and are usually presented over a span of several days (usually half a day to one full day per vendor).
#1 It’s All in the Script: Developing a Demo Script
Every great performance starts with a great script. A scripted demonstration is an essential part of your selection process, and providing vendors with your own unique demonstration script will help ensure that the vendor addresses every factor that is important to you, including

• the importance of a specific feature—relative to your business needs
• some of the risks involved in implementing their system
• the adaptability of their software to your changing business needs

The demo script should cover the following areas:

• company introduction
• system overview
• menus
• features
• system navigation
• customization capabilities
• report writer
• security features
• support
• and more…

If you request a demonstration but do not provide a script to follow, there’s no guarantee that the vendors will show you parallel functionality to compare. They may show you what they think are the most impressive features—which don’t necessarily cover the requirements that are most important to you. Ultimately, the demo script should be designed in such a way that enables vendors to show you how the software will increase your organization’s performance—in some visual and measurable way.
The script should be presented to only the top two or three vendors on your shortlist. Too many product demonstrations can lead to confusion—and leave your software selection team wondering which vendor had which features.
In order to give each vendor equal opportunity at the demonstration stage, it’s important to provide every vendor with the same detailed demonstration script. The script should be given to them at least 2 weeks prior to their scheduled demonstration date. This will allow them more than enough time to prepare.
Professionally written demonstration scripts can also be purchased online. They cover a variety of software systems and often focus on industry specific solutions. They provide an apples-to-apples comparison of criteria, which ensures consistency. A scoring system is already defined for you, which can save you time during the rating process.
#2 Requesting a Product Demonstration
To ensure the product demo goes as smoothly as possible, you’ll want to be sure that the shortlist of vendors are informed well in advance. The way to do is by

• sending them a letter requesting a product demonstration
• re-stating the scope of the software selection project and your business’ needs
• proposing a time frame for any requests for clarification of the script
• proposing a time frame for confirmations of demo with all pertinent details

Each vendor will be given the opportunity to clarify any terms that might seem ambiguous, or examples of business rules with your selection team prior to the demonstration.
Your selection team should not ask the vendor to customize the software any more than is necessary to demonstrate the real-life situations described in your scripted scenarios. However, to limit follow-up questions and subsequent demonstrations, each vendor should be encouraged to demonstrate all the items that you have listed.
#3 Inviting Vendors On-site to Show Them Your Environment
While it’s important for your company to see what a vendor’s product can do, it’s equally important for the vendor to know what type of environment it will be working with—if its software is chosen. Inviting vendors on-site to see your environment will give them a better understanding of what to prepare for the demo, as well as enable them to provide you with a more accurate proposal at the end.
This will also be the opportunity for the vendor to ask you specific questions about your current system, as well as the functional areas of the company. Having key staff present during these visits is recommended (thus, you may want to include staff from your IT department). Your public relations (PR) staff may also want to arrange a tour of the facilities so that the vendor can meet with the key users who will actually be using the system.
You have provided them with your demonstration script, and you’ve allowed them to see your environment. Now it’s up to them to wow you!
#4 The Demo: Lights, Camera, Action!
It’s show time! The time for the vendors to make their product(s) shine. Vendors often have very different ways of conducting their product demos. Some design theirs using PowerPoint slides with lots of bullet points and fancy fly-ins. They’ll often start by going over their company’s details, strategies, and future goals. Then, they’ll move on to discussing specific problems companies—like yours—may be having, and finally they’ll show you how their software can solve them all. Right!
This, my friend, is not a product demo. It’s a marketing piece—and it’s not showing you much of anything!
You shouldn’t have to endure a software demo. It should be conducted by the vendor in a way that makes it exciting for the audience. Using real data (preferably yours)—along with your demo script, the vendor must walk you through the demo like a finely crafted play. They’ll show you some fluff (they always do!), as well as a few of the cool and unique features. However, it’s important that they stick to your script. You’re the director, and they’re the actors—with a fine support cast (and a big bag of props!).
Crashes during the demo should be unacceptable. Think about it; if the software doesn’t work well in a demo environment, how’s it going to work in your real life environment? There may be a good reason why something went wrong during a demo; so don’t be afraid to ask.
You’ve put a lot of time and money into your software selection project already, so make sure that your selection team sees everything they need to during the on-site demo, in order to help you make an informed decision.
# 5 Rating the Demonstration, the Vendor, and the Product
Each person from your software selection team attending the on-site demo should participate in scoring the vendor’s scripted performance—for each factor demonstrated.
Breaking down the vendor’s demonstration into different sections (each of which represents a percentage of the overall evaluation score) will facilitate the scoring process.

• functionality or performance
• ease of use
• process and flow
• flexibility
• adherence to your script

The bidders are evaluated based on product functionality, ease of use, and process fit.
Product Functionality
The product functionality section is a list of features and functions for which the selection team would like a detailed product demonstration. Over and above these features and functions, vendors should provide a detailed description of the hardware, software, and networking configuration used during the demonstration.
Vendors should also provide a statement regarding the amount of effort and skills required to set up the demo as presented. Each member of the selection team should score the vendors’ script execution performance for each factor demonstrated. This can be done using a rating scale.
Sample rating scale


Ease of Use
For each process demonstrated, the selection team must rate the user friendliness of the software product.
Process Fit
Members of the selection team will rate the way they see the process demonstrated according to how it fits their business processes and whether that can be considered an improvement or not.
After all the demonstrations are completed, the scores from all members of the selection team will be consolidated as a single score for the performance of each vendor.
Conclusion
So, was it all that it was cracked up to be? Did the vendor’s performance and its product blow you away; or did they fail miserably? The fate of this sales opportunity now lies in the hands of you and your software selection team. Given all the information you have received from the vendor until now, including their RFI responses and the demo, are you confident that you can make a better informed decision about the software you want and need?

SOA technology changes integration

"We could have lived with one interface, but we really wanted about five different screens," Anderson said. "But the cost alone made us say, 'OK, we'll need to put up with whatever they produce for the first one.'"

Before settling, VP Buildings looked for alternatives and found New York-based iWay Software Inc. and its SOA middleware. IWay's enterprise service bus technology could expose PeopleSoft functions as Web services. VP Buildings had experience with SOA technology and Web services because it manages its sales and manufacturing activities using homegrown Microsoft .NET applications, Anderson explained. The team members decided to use iWay's technology for the project -- and discovered that the SOA technology offered more benefits than they had initially realized.
Solving old problems with new technology
The VP Buildings situation is not unusual, according to Steve Garone, an independent industry analyst who is currently establishing his own firm. Companies are increasingly turning to SOA technologies to solve classic application integration problems. A broad variety of tools and standards are emerging in the SOA market, Garone said, but vendors generally fall into three categories:

• Platform vendors, which are building SOA functions into broad platforms.
• Tools vendors, which focus specifically on SOA, Web services and enterprise service bus technology.
• Infrastructure vendors, which are building SOA and Web services functions into their technology suites.

Like many IT projects, the vendor choice depends on a company's specific requirements, goals and existing technology environment, Garone said. Solving a particular business or integration problem with Web services can be a good way for companies to jump-start the process of moving toward SOA technology. Getting started with SOA technology sooner rather than later may accelerate competitive advantages enabled by the architectural approach, he added. But companies need to think strategically.
"If you're going to migrate and grow the SOA presence in the organization up from that initial project, you need to take a global view of the breadth and variety of resources throughout your organization that are going to have to be integrated down the line," Garone said.
VP Buildings builds on its SOA
VP Buildings implemented iWay's SOA middleware, which exposes PeopleSoft functions as Web services to its .NET architecture. The team built the five new interfaces in a Microsoft Windows form business application, which uses the .NET architecture and iWay SOA middleware to write data to the PeopleSoft application. The entire process happens in near real time, with the customized interfaces designed exactly as VP Buildings wanted. They rolled out the new system in May.
"Now we have an interactive capability to query or supply data to PeopleSoft," Anderson said. "We'll do other things that we would have avoided in the past because they would have required a custom interface."

This article originally appeared on SearchDataManagement.com.

5 Best Practices for Ensuring a Smooth Software Implementation

You’ve gone through months (possibly years of preparation) and now you’re down to the final stages of your software implementation project. No matter how successfully you have executed the project to date, it can all fall apart if your service provider (software vendor or value added reseller [VAR]) can’t do its job properly!
As a stakeholder in charge of your company’s IT purchasing decisions, you’ll want to be sure that the service provider you choose will be the right one for your needs. It’s no secret that there’s a lot of time and money at stake in such an undertaking and you’ll want to do everything possible to ensure a smooth transition from your legacy system to your new system.
How will you manage change, resolve conflicts, and keep your implementation running as smoothly as your evaluation and selection? here are the five best practices that (I believe) will help ensure a successful and seamless implementation.
• Best Practice #1: Proper Planning
• Best Practice #2: Continuous Monitoring
• Best Practice #3: Updating your Stakeholder
• Best Practice #4: Preventing Scope Creep
• Best Practice #5: Negotiating Additional Products or Services

Software Implementation Best Practice #1: Proper Planning

Make sure that your implementation plan includes specific deliverables for each milestone, a clear definition of the scope of each step, and contingency plans that you can put into action should the schedule begin to slip. Remember, your implementation plan must extend beyond the go-live date. As the organization continues to change, the process must evolve with it.
Some areas of your implementation plan that need to be carefully thought out (but are not limited to) are:
• Data conversion: Conversion of data from the old software system to the new should begins early in the implementation process. Testing should be performed to ensure accurate data is transferred into the new system’s database. If inaccurate data is converted, the erroneous data may have a negative domino effect throughout the organization.
• Disruption of business: Even the most successful implementations can disrupt a company’s business and lead to a reduction in productivity that can temporarily affect the bottom line. Detailed project plans can also contribute to shorter implementation timeframes.
• Training: Every system user must be fully educated so they understand how the new system will be integrated into the overall company operation. All users must be trained to take full advantage of the system’s capabilities. Failure to educate and train all relevant personnel will guarantee implementation problems.

Software Implementation Best Practice #2 - Continuous Monitoring

Monitoring should be integrated into all stages of the implementation project. As the implementation progresses, a careful audit of each milestone will help you ensure that the service provider is providing all of the products and services specified in the contract, and the internal implementation team is performing as it should.
Failure to properly monitor the progress of the implementation can also lead to scope creep (see Best Practice #4)—among other things.

Software Implementation Best Practice #3 –Updating your Stakeholders

Your stakeholders have been part of the project since it first got off the ground (all those months ago), so don’t keep them in the dark at the implementation stage. Ensure that your project champions, subject matter experts (SMEs), and service provider work closely together throughout the implementation so that everyone is on the same page. A poorly managed and maintained project is often a factor in implementation failure. Communication is critical for its success. Audit each implementation milestone and provide detailed briefings and progress reports to your stakeholders on a regular basis.

Software Implementation Best Practice #4 - Preventing Scope Creep

If scope creep happens, it’s often because we’ve allowed it to. Tasks change, deliverables aren’t met, and before we know it, our go-live timeline is shot to hell. Sometimes, scope creep is inevitable, however; a project plan that provides a focused and well-defined scope, and includes the appropriate resources (both human and budgetary) will help keep your implementation project on track—reducing the risk of creep.

Software Implementation Best Practice #5 - Negotiating Additional Products or Services

Remember: The people involved in the original negotiations during a software selection are not the same people assigned to implementing it. Ideally, your goal should be to tie payments to the achievement of milestones in the implementation process, however; be prepared to negotiate the cost of additional products or services as the need arises. While most contracts state the obvious in terms of the license agreement, and ongoing support and maintenance requirements, they often say little about what service levels are to be met in order for the implementation to be considered complete. If you’re uncertain, have the service provider draw up a service level agreement (SLA) or statement of work (SOW) and attach it as an addendum to your contract.

ref:http://blog.technologyevaluation.com