Vue Software

Tag Archive for 'Implementation'

Time to Burn the Ships!

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5 out of 5)
Loading ... Loading ...

Why do large system implementations often fail or get delayed? Depending to whom you ask, you’re likely to get a different answer: the requirements were not understood properly, the data was too complex, processes were not documented, key stakeholders were not involved enough, there’s too much red tape, my team/manager is incompetent, we picked the wrong solution, etc. I’ve observed that the bigger a project or program is, the more likely people are to feel that they can’t affect the outcome. Large project teams seem to have a low internal locus of control.

In 1519, Captain Hernán Cortés and his army set out on one of the greatest conquests in the history of the world. Cortés was going to accomplish his goals no matter the consequences, despite being up against incredible odds. When he arrived near Veracruz with 500 soldiers, a dozen horses and a few cannons, the first thing he did was burn his ships so there could be no retreat. He told his men “You can either fight or you can die”. Returning to Spain was not an option anymore. By burning his ships, he not only cut off his only means of retreat, but also made his soldiers fight harder. They were all fully committed to the cause.

I cannot condone what Cortés later did to the Aztecs, but burning the ships probably played a major role in the outcome.  Most project managers will say that failure is an option and have a “do-or-die” attitude, yet when things start going wrong, the managers usually start looking for excuses. Likewise, when blamed for delays, the project team will often start looking for their own excuses or try to jump back on the ship.

I challenge you to think about your objectives and about at least 5 factors that could make it difficult to reach them. Now, get rid of these excuses.

Tags: , , , ,

Related Posts:
New home for my sales performance management blog
Incentive System Implementation Success Story

With Great Power Comes Great Responsibility

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5 out of 5)
Loading ... Loading ...

When selecting a new SPM system - or any COTS system - people want a solution that will meet all their current needs…  but they also want a solution that will meet any of their future needs.  What are those future requirements?  They are unknown at the time of purchase.  It should not be a surprise that flexibility of a solution is often one of the top criteria for its selection.

But with great power comes great responsibility…  The more flexible a system is, the easier it will be to make design decisions during implementation that could potentially have a negative impact in the future.

Flexibility also often comes at a cost.  Many “less flexible” solutions (often SaaS solutions) are often less flexibility than other enterprise solutions.  However, they still meet all the requirements of most clients, and it is this lack of flexibility that can allow them to be deployed in a shorter time frame.

Companies should really consider how far in the future they really should be looking.  Are the requirements between today and 3 years from now really going to evolve that much?  Looking at a more than 10 year horizon for a piece of software is an eternity.  Furthermore, with an on-demand solution, it’s easy to switch to another solution at anytime… and with an on-premise solution, upgrades every 2-3 years will be required to maintain support from the vendor.

Finally, if for some reason your requirements are really so complicated that they are not supported by a leading SPM solution, ask yourself if your compensation plans really make sense.

Tags: , , , , , ,

Related Posts:
Super Bowl, Oscars and Olympics
Salary Equality Sucks and Goodbye Marx

Sales Performance Management Implementation Catch 22

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 3 out of 5)
Loading ... Loading ...

I know I said that building should only start once design is completed…  this would be ideal, but it’s not always possible.  Why not?  People often wait to finalize the compensation plans before starting the planning process.  Typically plans are not until a few months before the next fiscal year, so that usually leaves very little time for implementation.  What more, the analyze and design phases rely on those plans to be completed. 

So can we start implementing without the comp plans?  It depends.  More often than not, we have a very good idea of what the plans will look like, how the calculations will be performed, which bonus exist.  The information that is lacking is the quota amounts, bonus amounts, or which particular bonus applies to whom.  Even without this information, it is possible to start working on the analyze and design phases.  

With this in mind, if we can map out all the information we know, it will be possible to take big leaps in our initial phases, and even in implementing major components of our sales performance system.  Once the missing details become available, it will be time to revisit the documents to keep them up to date.  

This should give more time to properly implement the system without cutting corners, and to meet the deadlines.  Like I said, this is not an ideal scenario, but it is much better than waiting until 3 weeks before the required “go-live” date to start implementing. 

Tags: , , , , ,

Related Posts:
Which SPM Vendor “Sucks” the Most?
8 Predictions for the Incentive Compensation Industry in 2009

6 Phases of the Sales Performance Management Delivery Model

1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 3.25 out of 5)
Loading ... Loading ...

he SPM Delivery Model consists of 6 phases:
• Analyze
• Design
• Build
• Test
• Acceptance Test
• Deployment

SPM Delivery Model

SPM Delivery Model

Analyze Phase: The analyze phase consists of describing functional and non-functional requirements.  At the end of the implementation, we should be able to look at the system and confirm each requirement is met.

Design Phase: The design phase consist of planning how the system will meet the requirements.  The major deliverables include a functional design document (larger systems may have multiple such documents for each major component.  It will also consist of a solution design document, providing more details about the implementation.  This solution design should have “just enough” information.  Too little and the implementers will be left guessing and interpreting the design.  Too many details will cause the document to quickly become meaningless by not being kept up to date as the system evolves.  The design phase also includes planning the tests, and as I discussed before on this blog, to create test scenarios.

Build Phase: The build phase is repeated for each compensation plan, or for each major component which can stand alone and produce verifiable results.  Unlike a pure rapid prototyping methodology, it is a good idea to only start building when the requirements and design phases are well defined to ensure a strong design.  Unlike the waterfall model, this avoids a “big bang” approach, trying to integrate all plans at once over a long period of time and hoping everything will work.

Test Phase: Testing should be performed after every small build iteration, to ensure the use cases defined in the design phase work as expected.  This goes beyond unit testing and test multiple conditions and integration with previously developed plan.

Acceptance Test Phase: Once we are done developing and testing every plan, we are ready to put it all together and either load data from a previous month, or load the data with which we are going live.    This is where the stakeholders will agree and sign-off on the implementation.

Deploy: Go-live time!

Tags: , , , , ,

Related Posts:
SPM Delivery Model - Intro to Development Life Cycles
Enterprise Incentive Management News

LeapComp featured in Arcadia Solutions’ Q3 Newsletter

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 3 out of 5)
Loading ... Loading ...

My entry on Offshoring SPM Communication Challenges was featured in Arcadia Solution’s quarterly newsletter.  Arcadia Solutions is a business and technology consulting firm with a division focused on incentive compensation solutions. Their newsletter also has 2 good articles:

 

The first article is called “On-Demand vs. On-Premise - What works for you“.  Arcadia identified 3 key issues which drive this decision: comp plan complexity, technological capacity and data integration complexity. 

 

To this list, as I talked before a few times on this blog, I would add a few more drivers: the cost structure (subscription fee per person per month for on-demand rather than a larger upfront fee, the number of participants, and the number of transactions (on-premise applications can usually handle a bigger load).  On-demand (also called Software-as-a-Service SAAS) offers many other benefits such as generally quicker to go live and easier to implement, frequent automatic updates and lower operating costs.  On-premise SPM solutions can offer more integration flexibility, and more control (such as direct access to the database which is usually not the case with on-demand solutions). 

 

The second article is “Build vs. Buy - How do I Decide What’s Best for my Unique Business” and discusses some of the pros and cons of buying a commercial-off-the-shelf (COTS) software versus building  a custom system. 

 

This is something I have not written about, mostly because I didn’t think it was a question companies were still asking themselves, with so many mature COTS solutions available.  Unless there is a need to perform something that a COTS application cannot do, there should be no reason to build a custom application.  If there is something an ICM COTS cannot do, it might be time to review your comp plans!

Tags: , , , , , ,

Related Posts:
Webinar: Demystifying the Complexity of Sales Performance Management – Business vs Technology
Incentive Compensation Meets HR at The Super Sexy HR Carnival

EIM Solution Maintainability - Should you care about this?

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

People often consider buying an Enterprise Incentive Management (EIM) solution based on several criteria including cost, performance, ease of implementation, support, etc. One factor that if often overlooked in my opinion is the system’s maintainability.

What is Maintainability?
ISO 9126 defines maintainability as the ease with which a software product can be modified in order to:
  • correct defects
  • meet new requirements
  • make future maintenance easier, or
  • cope with a changed environment

Why is Maintainability important?

The ability to modify a software system is obviously important for any type of system, but it is particularly important for an EIM solution. Why? Because compensation plans, organizational data, quotas, etc typically change at least once a year. Modifying this information is not a task equally easy to perform in all software packages.

How to find out if a EIM solution is maintainable?

Any vendor will say their solution is maintainable… only an opinion from an unbiased person with experience implementing the particular EIM solution will be able to give a true account of how easy it is to maintain the application.

Effective dating plays a big role in maintainability. Being able to modify the information at anytime, but with changes effective only at a certain date, is critical to maintain a system.

Another key aspect of maintainability to consider the impact of year end on the plans. Some of the important information to find out is:

  • Are the plans still going to work at year end?
  • If plans need to be modified, how big of a change is it?
  • How easy is it to modify the quotas?
  • What about the rate / lookup tables?
  • If formulas are embeded within the tables, do those need to be modified as well?
  • How easy is it to move people in different positions?
  • What do I do when people leave the company?

It is not atypical to see a somewhat complex logic which could be impacted by a simple change. For example, a formula referencing a table which contains another formula pointing to a quota. If the quota values can just be updated, it’s not a big deal. If a new quota needs to be created, then the formula will also need to be updated to reflect the new quota.

Another example is when an EIM solution needs to be able to handle last year’s orders at last year’s rates. Depending on the system, this could mean creating new rules, new formulas, new tables, new quotas, etc.

It may not all be about the Product

Implementing a software package is a bit like custom development. A quality architecture results in the possibility to re-use components. Some programming languages are easier to maintain than others; as we discussed, the same goes for EIM solutions. However, no matter how good a programming language, a bad programmer can make the maintenance a nightmare. A bad EIM implementation team can also make the system’s maintenance very hard, no matter how good the product is.

The bottom line:

Finding out the details about how maintainable an EIM solution is, is as important as finding out other characteristics such as how easy it is to implement it. You do not want to have to re-implement every plan every year; not only because it is time consuming, but also because major changes imply bigger risks.

The first part of the battle is to select an EIM solution which will make maintenance as painless as possible, but the battle is not won until the solution has been implemented properly.

Tags: , , , , , ,

Related Posts:
SaaS – Future or Buzz?
Anonymous Incentive Compensation Vendors Webinar