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.


Leave a comment

Good RFPs lead to better proposals

white arrows painted on ashpalt

Get all suppliers headed in the same direction.

Is a Request for Proposal (RFP) or Request for Quote (RFQ) in your future? To make sure that your RFP does not become a “Request for Problems,” consider the following advice:

  1. Engage the right team. Include a cross-section of stakeholders to develop the RFP and to evaluate proposals. 
  2. Send the RFP only to 2-3 qualified parties. By the time you reach the RFP stage, you should have a good idea of which suppliers can best meet your needs. Do not waste the supplier’s or your time just to get pricing information.
  3. State the evaluation criteria up front. Share the “high level” criteria such as fit with business needs, ease of use, supplier qualifications, etc. Spare the details.
  4. Provide project background information. This sets the stage and gives the supplier a reference point.
  5. Provide a proposal outline or response template. This  permits you to compare proposals on a level playing field. A clear outline will elicit better responses and a template should make responses easier to evaluate.  Limit the response length in certain areas as you see fit.
  6. Make it easy for the supplier to respond. Be specific with your request for information.  Avoid asking for superfluous information, and instruct the supplier to be brief.
  7. Provide a single point of contact. Typically, Supply Chain or Procurement is the contact. The single contact will ask the end-user of the product/service for help in answering questions in their domain. This levels the playing field and keeps politics out of the equation as much as possible.
  8. Request customer references–and check them! Assume that suppliers give only positive references. If you have contacts within other organization, then call them as well. Ask the same questions of each reference, including questions like, “Would you choose this supplier if you had to do it again?”
  9. Impose a “quiet period” from the RFP issue date through supplier selection.
  10. Provide feedback to ALL suppliers. After selecting a supplier, remember to give feedback to those who did not win the bid. Surprising, many organizations forget this common courtesy.

See the IT Insight archives for further reading on this and other topics related to software evaluation, selection and life cycle management

© 2013 Lexicon Systems, LLC.

Advertisements

Fresh off two software selection projects, I am reminded that software should benefit its users, not the IT group. A well-designed software application–or commercial software implementation–starts with documenting clear, solid business requirements.

Solid requirements (prioritized business needs) are critical to success. Good business requirements, coupled with objective evaluation criteria, can help a company to identify a short list of vendors and select a solution that best meets their needs, fits the company’s IT maturity and culture, and that users will adopt.

what happens in vagueness stays in vagueness

Business requirements must be clear, not ambiguous, to both users and IT.

Consider the following tips when developing business requirements. When eliciting requirements, the business analyst should:

  • be clear, not ambiguous.
  • document business needs in terms familiar to the users–not IT terms.
  • help stakeholders reach a consensus on needs (“what” the software does).
  • help the stakeholders to develop standardized business process work flows that are simple enough to use day in and day out. The software implementation will reflect these work flows, which “behind the scenes” are well thought out and can handle exceptions with built in “business rules.”

When eliciting requirements, the business analyst should not:

  • document “molecular” requirements; each should be “atomic” and describe a specific need.
  • discuss the software features or look and feel (“how” the software does it) This will happen after software selection, during design.
  • allow certain stakeholder’s opinions to override what is best for the group as a whole.
  • help stakeholders to develop different work flows for different locations. Use “business rules” to address differences and to allow consistent, enterprise-wide data roll-up and reporting.

Read more about an approach to well-designed software.

Click here for a wealth of articles on software business requirements, evaluation and selection, and managing the IT systems life cycle.

 


Leave a comment

Mobile, social, cloud and big data collide to make the “perfect storm”

You arrive at the airport for a business trip, having left your computer behind. You stash your smartphone and iPad in your luggage to pass through security. As you wait to board the plane, you read e-mails, check in with your team and review a presentation–all on your mobile devices.

Tablet Global Connections

Mobile, social, Cloud, and big data are four of the fastest-growing information technologies. They connect us globally in ways unheard of just five years ago. Their combination creates a “perfect storm” that can cause IT departments huge headaches or generate great business opportunities. Also, they may have unintended consequences, perhaps a smaller carbon footprint for the organizations that embrace them.

Click here to read The Perfect storm of mobile, social, cloud and big data.


Leave a comment

$Dollars still drive EHS software decisions

A large manufacturing client of mine recently completed a software evaluation and selection process. The project stakeholders used a set of objective evaluation and selection criteria to arrive at a decision. Interestingly, these criteria did NOT include cost. If in, the final evaluation two software solutions were rated equal, then cost could be a deciding factor. My client and the software vendor were excited to move forward with implementation at warp-speed, as the clock was ticking towards internal deadlines.

Since the EHS business and IT sponsors kept the executive suite updated, it looked as if formal approval would be easy. The company had strong business drivers regardless of the project cost. Of course, no project has unlimited funds. In the end, the project was approved–only after a lot of number-crunching and many revisions to the executive presentation.

Why? Executives run the business using performance-based metrics. Most C-level executives are trained to value a project based on “hard numbers” metrics such as cost saving, cost avoidance and Return on Investment. Often, they dismiss the value of compelling “soft numbers” associated with benefits that are harder to quantify, such as making decisions based upon solid data, the ability for users to adopt (and gladly use) the software, data entry at the point of activity, and productivity gains from EHS process automation, self-service reports and dashboards.

Image

Dollars, Euros, Pounds, Yen

Prepare a compelling business case based upon a good understanding of your business. While this does not require exhaustive research, you need to know where to look.

  1. Keep it simple. Find 2-3 relevant “hard numbers” cost avoidance and cost savings examples.   These savings alone could pay for the project in 3-5 years.
  2. Consider the total cost of ownership (TCO). This includes software license/subscription, maintenance and implementation fees PLUS the cost of internal EHS and IT resources, external consultants, hardware and other expenses over the lifetime of the software. Many organizations have tunnel vision and compare only license and implementation costs; TCO allows a more realistic and credible evaluation.
  3. Avoid selecting the low-cost option just to save a few dollars. If the software fits current, near-term and long-term needs, then it may be a good option. Reread item 2 above. You may wish that you had chosen a more “expensive” option, as it would save effort and money over the life of the software.
  4. When in doubt, seek expert advice. Seek assistance if you lack the know-how to prepare a business case for C-level or Board approval. The skills needed to develop a business case are very different from the skills needed to administer the software after implementation. This expertise may lie within or outside of your organization.

While dollars still drive EHS software decisions, look at the bigger picture. You will be glad you did!


Leave a comment

Work in the Cloud removes some operating systems barriers

IBM Cloud Computing

IBM Cloud Computing (Photo credit: IvanWalsh.com)

A little over two years ago I paid about $999 for a state-of-the-art Windows desktop with a small footprint, plenty of speed and a huge hard drive. When it failed just past the two-year warranty mark, I tried to replace the hard drive–but the hard drive was not the problem. My attempt to salvage the computer was fruitless, and the computer was essentially worth nothing. I took it to the recycling counter at my local big box store and received nothing in return, not even a $10 gift card!

This seems like an awful short life for a name-brand computer from a company that used to have a good reputation. My current notebook computer of the same brand had a “blue screen of death” issue when the unit was only three months old. And it has had intermittent startup problems ever since. I do not expect the notebook to last much longer.

In a recent meeting, I was asked if I was planning to switch to Microsoft Windows 8. My reply, after these two recent issues–which may or may not be related to software–was this:

I am getting close to where my work does not require a Windows-based system. I expect that my next computer will be a Mac.

This should become a reality soon. Some of my clients use Google Docs and GMail or Microsoft Office 365 in the Cloud. These are accessible from essentially any device with an internet browser, and your information resides in the Cloud. These and other options like OpenOffice.org  and Zoho remove some of “frills” or “bloat” from the desktop software counterparts and allow easy document sharing and collaboration 24/7.

If everything were operating system-neutral, then operating system does not matter. Form and function rule the day. It is some of the more specialized software programs that are available only as a Windows desktop client that tie me to my Windows notebook device.

Maybe the short life span of  my Windows devices will encourage me to try some of the other options available, at the same time allowing me to leave my computer at the office and use a tablet instead.

Should you have old computer equipment, repurpose or recycle it; you should not leave it in the dumpster or set it out on the curb on trash day, or stash in a computer “boneyard.” For ideas on what to do with old computing equipment, click here.


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.


Leave a comment

Should the enterprise upgrade to Windows 7 or Windows 8?

Organizations currently running Microsoft Windows XP need to do something, as support for this operating system (OS) ends in about 18 months.

“…enterprises using Windows XP …are entering a danger zone as all support for the OS will end in April 2014. Moving to a new OS for a large organization takes up resources, money and time, and according to Gartner, XP users will run out of time if they don’t act now.”

Source: Microsoft

Should they wait for Windows 8 to be released, or upgrade to Windows 7? A new Gartner report says that enterprises currently running Windows XP should upgrade to Windows 7, not Windows 8 (scheduled for release this month). Windows 8 has a total user interface redesign that will make user adoption a challenge for those who resist change.

When Microsoft releases Windows 8 to market, it will not be mature–many organizations wait until the first or second service pack is available–which could take a year. Gartner advises organizations to start upgrading to Windows 7 as soon as possible. Read more at shar.es/5HXRw.