Lexicon Systems, LLC Blog

lex'•i•con: the vocabulary of a branch of knowledge. Thoughts on environment, health & safety (EHS), sustainability and information technology to support them.


1 Comment

Increasing the probability of software implementation success

Last week I attended a Webinar that focused on the leading environment, health & safety (EHS) software companies. During the Q&A period, an attendee commented that, while the software may lead the market, the firms that implement the software may not be up to snuff. This results in problematic implementations and unhappy clients.

At a business lunch the next day, a colleague asked why some EHS consulting firms are less successful than others when it comes to implementation. I replied that implementation success is not about the software alone. No matter how feature-packed, intuitive and functional the software package, it takes more than software-savvy subject matter experts and EHS-savvy software engineers for a truly successful implementation. The implementation team requires proven methodology, good project management and social skills, and the ability to foster user acceptance.

  • proven methodology is important throughout the entire software life cycle–from concept through business needs analysis and software evaluation and selection to  design, system configuration, rollout and support. Proven methodology helps to reduce the margin of error and ultimately saves the  client time.
  • project management skills are important in planning, budgeting and tracking, and critical in managing “scope creep.” Project management skills are critical in areas such as IT risk management and identifying and recommending solutions to issues as they arise.
  • social skills are important since enterprise-scale IT projects involve different stakeholders with competing agendas. Members of the implementation team must be able to communicate with people at many levels and in various functions within the client organization. Some of the members must excel in facilitation skills, particularly when the group must reach a fact-based consensus. They must be able to work without showing bias towards certain stakeholders or software packages.
  • user acceptance often will “make or break” an implementation. Fostering user acceptance requires organizational change management expertise, something often overlooked during large IT projects. Organizational change management activities should occur throughout the software life cycle, and include much more than training. Read more about organizational change management here.

If you contemplate starting an IT initiative in the EHS arena, or to manage other subject matter, make sure that you have a professional leading the effort. Hands-on experience in the above areas can increase the probability of success in software implementations. Of course, these are a select few of all of the skills required. Read more about IT program management here.

Advertisements


Leave a comment

Vendor reference call do’s and don’ts

In my 25 June 2012 post I introduced due diligence for software initiatives. When your organization issues a Request for Proposal (RFP), you should ask each vendor to supply customer contact information to allow due diligence. Here are twelve do’s and don’ts for reference calls…

  • Do speak with reference customers with business needs and/or implementation scope similar to yours.
  • Don’t extend each call beyond 30 minutes. Respect the software customer’s time.
  • Do prepare a list of questions that you need answered, and use it as a guideline.
  • Do use a combination of closed- and open-ended questions to allow you to gather good information you might not have anticipated before the call.
  • Don’t ask questions related to confidential contract information such as license or subscription fees or implementation costs.
  • Do ask what some of the greatest challenges were with the software project.
  • Do ask the customer if s/he would select the software and/or implementer if s/he could do it over again.
  • Do keep the number of people on each reference call from your organization to a minimum.
  • Do have the same people in your organization participate in each reference call.
  • Do consider whether you are speaking with a beta customer who adopted the software early, vs. a customer that implemented software when it was more mature.
  • Don’t hesitate to ask a reference customer to provide a short Web or face-to-face demo of the software in action.
  • Don’t limit yourself the references that the vendor provides. If you know someone within another customer’s organization, make a phone call.