News & Views

January 1, 2008 from CFO Magazine “Ever since 1963, the year it first issued shares in New York, Japanese electronics giant NEC Corp. has proudly reported its financial results according to U.S. generally accepted accounting principles. The $42 billion (in revenues) maker of computers, monitors, and semiconductors was so steeped in U.S. GAAP, in fact, that its Tokyo-based finance staff had little knowledge of Japanese accounting standards.

Then, in 2006, NEC’s auditors from Shin Nihon Ernst & Young began questioning how the company had recognized revenue for contracts that included multiple items such as hardware, software, maintenance, and support services. At issue was the company’s approach to a one-two regulatory punch: SOP 97-2, which governs how companies that sell software recognize the revenue; and VSOE, or vendor-specific objective evidence, a method for determining the individual value of each item within a contract in order to recognize partial revenue before the entire contract is fulfilled…”

180 View – Revenue recognition requirements often lead to manual systems for many companies. When seeking new systems and you have revenue recognition requirements, look for systems that are able to automatically move revenue from deferred to recognized according to business rules so there is no need to back it out of the general ledger and re-allocate it manually.

August 29, 2006 from InfoWorld – “The road to new software can follow a strange and convoluted course. I was feeling optimistic as I began a new consulting engagement for a national retailer, as part of a team developing an RFP (request for proposal) for a new HR/Payroll application. True, there were 12 divisions, and each one required a detailed process-flow-and-requirements definition. But having met with the key users in each area, I was confident we’d be able to sort everything out. In addition, we enjoyed the support of the VP in charge of HR, which helped us avoid many of the stalling tactics that typically occur during such efforts.

Months later we ended up with two three-inch binders of requirements, which we mailed out to vendors. Then we waited for their responses. Two vendors I’ll call “HRC” and “Acme Software” made the cut. Several weeks later they came in to show off their performing dogs and ponies.

The IT people immediately saw the technological advantages and superior functionality of HRC’s Windows-based offering. We also saw that Acme was trying to sell us a hasty retrofit of their mainframe software sitting in “a window.” Unfortunately, the users we were working for thought both offerings were essentially identical. In fact, since Acme had a persuasive representative with vast experience in payroll, and as our user team had a strong payroll (vs. HR functionality) bias, the retailers were starting to lean toward Acme.

Then, Harry, our project manager (whom I knew for a fine programmer, but no politician) surprised us all with a brilliant play. For some reason, he was always at odds with Bob, the key HR staffer who was leading the evaluation. Harry and Bob always took opposite positions. Anyway, during a lunch break, I overheard Harry confiding to Bob how much he liked Acme’s offering. A few minutes later, back in the conference room, the user team flipped its position and voted for HRC — our IT team’s choice!

From that point on, the evaluation moved steadily forward to select the vendor we knew would be superior. I thought we were home free. No such luck.

HRC submitted a two-page license agreement to be reviewed by the legal department and the users. By the time the negotiations were completed, the document had blossomed to 26 pages of performance guarantees, special clauses, and a dazzling array of stipulations.

Just as this process seemed to be winding down, we received word from the corporate executives that the deal was off! Too expensive, we were told; we’d have to purchase too much high-end hardware to support the system.

We were devastated. Our baby was dead. All we had to show were two three-ring binders of requirements. And I was out of a job. As it turns out, those binders were important. Several months later the information they held was used to redefine job descriptions and create critical enhancements to the existing in-house HR software.

Ultimately, 60 developers were hired to handle that workload. Sadly, I wasn’t one of them. But that’s not the end of the story. Nearly three years later, after a change of CIOs, a new management team (which still had a bias for payroll functionality) took over the reins of power. And guess what? They went right out and bought Acme’s HR/Payroll package.”

180 View – This article is a good case study of what not to do:

1. There is something terribly wrong if you have “two three-inch binders of requirements”. You’re not designing a system from scratch. You should be including only what’s important and what differs across systems.
2. The RFP was mailed. It should be sent electronically as a turnaround document.
3. Only 2 vendors made the cut from the RFP. You should be doing more diligence before cutting it down to only 2.
4. The 2 vendors “came in to show off their performing dogs and ponies”. The vendors should be given instructions to tailor the demonstration.
5. “Just as this process seemed to be winding down, we received word from the corporate executives that the deal was off! Too expensive, we were told; we’d have to purchase too much high-end hardware to support the system.” – Whatever happened to total cost of ownership? This should have been understood earlier in the process.
6. “Ultimately, 60 developers were hired to handle that workload. Sadly, I wasn’t one of them.” The so-called consultant had no business participating in the selection process if he also wanted to be involved in the implementation.

Whitepaper from QuickArrow – “Billable Services Organizations can benefit greatly from the use of a Professional Services Automation (PSA) solution. Choosing the correct PSA application is one of the most important decisions a services organization can make; as such, it can also be a daunting challenge. Many factors should be taken into account when comparing PSA solutions – some related to technology and others based on functionality. The goal is to select a solution that is compatible with your business goals and is easy to use.”

180 View – Although this article is written by one of the PSA vendors, you will find useful information that is written without the typical marketing spin.

February 23, 2006 from Managing Automation and based in part on an interview with Michael Burns – “Your list of requirements should match up with pre-defined critical success factors (CSF) — those things you must do well in order to be successful as a business, adds Michael Burns, president of 180 Systems Ltd., a business consultancy in Toronto. “If a requirement can’t be mapped directly to a CSF, then it’s not critical.”…

When creating your RFP, Burns suggests asking vendors to respond not with a yes or no but with a number between one and seven. “When they say yes, that can mean anything,” Burns says. You can get more specific through a numbering system, where a “6″ might indicate that a feature is available in the current release of the software, a “5″ that it will be available in six months, and a “1″ that it would require a major modification or workaround. Combining your weighted requirements with these weighted responses will give you a way of scoring vendors to determine which makes your short list, he says.

You might be tempted to skip the reference check process, assuming you’ll get only positive responses. However, according to Burns, “forty percent of the time, the reference is not a positive one,” he says. “It’s amazing how little vendors know about their customers.” Burns offers a checklist of questions to ask each reference and advises that you tell each one a little about yourself before asking any questions so that they have a level of comfort with you.
Don’t spend time on system demonstrations until you’ve narrowed your list to a handful of finalists. You can even take a two-pronged approach, Burns suggests, where the first demo is done over the Internet and the second one is more in-depth. In all, you should attend no more than four demonstrations, and limit each to two to three hours, he says. Ask demo attendees to identify major strengths and weaknesses, he says.”