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

Learn from the experts and share best practices at September Sustainable Performance Forum

I am pleased to announce my upcoming presentation, “Business Requirements and Software Selection Best Practices” at the Sustainable Performance Forum, 25-26 September in Chicago, IL. The #Enablon #SPF Americas 2014 program features thought leaders on environment, health & safety (EHS) and sustainability, information technology (IT), and Risk. 

Former NASA astronaut, navy fighter pilot and test pilot and Boeing Chief Technical Pilot John O. Creighton will deliver the keynote talk on risk.

The Keynote panel features senior executives from industry, leading EHS subject matter experts and industry analysts. Author and writer Anna M. Clark will moderate the panel. Enablon CEO Dan Vogel, CTO Marc Vogel, Vice President Pascal Gaude and Enablon North America CEO Philippe Tesler will present their vision and company roadmap.

The Enablon team will lead program tracks on six different Enablon software solutions. Each track will include a session on issues & trends and a case study, in addition to presentations on the solution set and product road map.

Customers will have the opportunity to collaborate with subject matter experts and Enablon on future product enhancements. 

The program features two new tracks this year, beyond solution tracks and software training:

  • Technology Enablers–cross-platform, innovative information technologies
  • Implementation Strategies–best practices for business requirements and software selection; implementation, and more.

SPF also offers networking opportunities like industry roundtables and a gala dinner, and Lunchtime Expert series talks. Learn more here.

Advertisements


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.

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.