ZDNet Must Read:
The ERP devil's triangle
IT failure arises from core dynamics between enterprise software sellers, buyers, and third-party consultants and integrators. The ERP devil's triangle describes how conflicting agendas and cross-linked goals cause failures.... Continued »
August 28th, 2008
Google Apps dashboard: Serious about the enterprise?
Google is developing a system status reporting dashboard for its Apps Premier product line. This decision provides further evidence Google is serious about becoming an enterprise software vendor.
CNET’s Dave Rosenberg posted the announcement email, describing the dashboard’s incident reporting features:
- A description of the problem, with emphasis on user impact….
- A continuously updated estimated time-to-resolution….
For most minor incidents, that should provide sufficient information to users regarding problem status and expected recovery times. For more serious problems, Google’s plans go much further:
[A] formal incident report within 48 hours of problem resolution. This incident report will contain the following information:
a. business description of the problem, with emphasis on user impact;
b. technical description of the problem, with emphasis on root cause;
c. actions taken to solve the problem;
d. actions taken or to be taken to prevent recurrence of the problem; and
e. time line of the outage.
Finally, if things get really bad, the email promises in-depth consultation with customers on an individual basis:
[W]e’ll support your internal communication process through participation in post-mortem calls with you and your management team.
When an incident first occurs, reporting is limited to status, availability, and predicted resolution times. For more severe situations, that basic status reporting will be supplemented by a business-oriented description of the cause, scope, and impact of the problems. Finally, following the worst downtime issues, Google will present a transparent and detailed analysis.
THE PROJECT FAILURES ANALYSIS
Google joins the ranks of Salesforce.com and Amazon, both of which offer industry-leading incident reporting to end-users. The Salesforce reporting service has been around a long time, while Amazon instituted theirs following a series of serious downtime incidents earlier this year.
I’m rather shocked to see Google’s willingness to participate in detailed post-mortem analysis discussions with customers. For such consultations to offer any value whatsoever, the company’s representative must be knowledgeable regarding both the business and technical implications of downtime events. People with this experience don’t grow on trees, especially if they are also strong communicators, so this represents a significant resource investment.
Although Google may offer this service level to large accounts such as Cap Gemini, I doubt smaller customers will receive any personalized attention whatsoever. After all, Google isn’t known for providing stellar customer service; actually, the company’s customer care record sucks widgets. Only time will tell whether Google can successfully transition from its mass market consumer mentality to becoming a trusted, service oriented enterprise vendor.
Great status reporting systems, while important, don’t turn consumer application companies into enterprise software vendors. However, the business focus and directional strategic intent of this investment are clear.
[Via Charlie Wood. Image source: iStockphoto.]
August 27th, 2008
MediaMax / The Linkup: When the cloud fails
Online storage service MediaMax, also called The Linkup, went out of business following a system administration error that deleted active customer data. The defunct company leaves behind unhappy users and raises questions about the reliability of cloud computing.
According to Nirvanix, which along with MediaMax was spun out of a company called Streamload, a faulty script caused the problem:
Streamload offered unlimited and then 25 GB of free storage for quite some time. This resulted in a tremendous amount of data stored in a few million free, non-active accounts for [nine years]. Streamload was literally paying for former users to store 100’s of terabytes of old, inactive data for free. In preparation for the split of the two companies, and subsequent move of the MediaMax application to SAVVIS, it was determined that the inactive data from former users would be purged on the Streamload/MediaMax storage system, thus shrinking the overall storage needs and costs for the new MediaMax company. During this process, a system administrator ran a script that misidentified active account data and disassociated physical files from their owners.
Although The Linkup lost a ton of customer data, CEO Steve Iverson told Network World he’s unsure how much is gone:
Iverson says at least 55% of the data was safe. How much of the remaining 45% was saved is not clear, he says. “We know there was definitely a lot of customer problems, and when we looked at some individual accounts, some people didn’t have any files, and some people had all their files.”
THE PROJECT FAILURES ANALYSIS
As with most failures, this story is fraught with complications and contradictions. Besides finger pointing and back-biting, which I suppose is to be expected, confusing corporate relationships coupled with a seemingly bizarre level of process and technical carelessness lend a weird flavor to the whole mess.
The human drama is documented in links from this post; more importantly, two significant and highly connected issues were at play:
- Business process failures. Apparently, the company allowed a lone system administrator to perform tasks affecting the company’s core business without sufficiently performing dry runs. I suppose this point is self-evident: scenario planning is critical whenever IT handles irreplaceable data. Management is responsible for establishing all operating plans and contingency procedures before IT executes data-threatening procedures.
- Technical failures. Given the high stakes and the script’s intended goal, the company should have performed intensive testing ahead of time.
I asked Newsgator’s VP of Software as a Service (SaaS), Jeff Nolan, to comment. Jeff questioned why the company maintained so much historical data:
Beyond meeting legitimate business and regulatory requirements, retaining years of old, inactive data adds unnecessary risk and cost.
There was also a process failure. Newsgator takes active steps to isolate problems and prevent this type of damage. In addition to sandbox testing, which is computer science 101, we require two-key authorization: the sys admin can only run these types of scripts after a second person has given approval. A well-defined system of checks and balances prevents problems.
While this case is an interesting footnote in the history of IT failures, the larger implications relate to cloud computing. On this subject, Larry Dignan says:
[The cloud’s] growing pains, which are more evident each day that we rely more on service-based software efforts, indicate that you can’t really trust the cloud at this juncture. It’s too early and providers are learning as they go.
Despite being a cloud-based failure, the underlying problem is human error and poor judgment. This cloud failure is no different from any other IT problem, where immature process coupled with lax management oversight resulted in catastrophic meltdown.
[Via George Ou. Image from iStockphoto.]
August 26th, 2008
FAA computer failure slows nationwide air traffic
A computer problem at the Federal Aviation Administration center in Atlanta has created air traffic problems across the country.
From WSB Radio in Atlanta:
FAA Computer Problems: Failure in the system that processes flight plans in the eastern U.S. FAA says no danger is involved. System that processes the information for the east coast is based in Atlanta. It has been moved to a facility in Utah which usually processes only west coast flights. Flights across the country are backing up.
Here’s a screen capture from the FAA, showing delayed flights:
Information on the outage is still sketchy and I’m looking forward to learning whether this is a hardware or software problem. Either way, sounds like a truly massive outage.
Update 8/26/08 10:15 pm EDT: According to CNN, things are back to normal:
Airports experienced hours of flight delays Tuesday afternoon after a communications breakdown at a Federal Aviation Administration facility, the administration said.
The facility south of Atlanta had problems processing data, requiring that all flight-plan information be processed through a facility in Salt Lake City, Utah, overloading that facility.
“The situation is pretty much resolved,” FAA spokeswoman Diane Spitaliere said.
Sounds to me like an unexpectedly large breakdown, for which full scenario planning had not been performed. All the same, considering the scope of effort required to transfer flight processing across the country, it could have been much worse.
[Via Twitter.]
August 26th, 2008
Failed government IT: ‘The mother of all databases’
The “IT system used to identify terrorist threats that has been crippled by technical flaws,” according to a memo from the House of Representatives Committee on Science and Technology. The failed system is part of a “central US government repository of data on international terrorist identities…described by Vice Admiral (Ret.) John Scott Redd as ‘the mother of all databases.’”
This enormous database, called the Terrorist Identities Datamart Environment (TIDE), is operated by the National Counterterrorism Center (NCTC) to support the “government’s various terrorist screening systems or watchlists.”
My take. I was initially skeptical of the allegations described in the House “Inspector General memo” because it raises highly technical issues in a political context. However, my impression changed substantially after studying the more detailed “Subcommittee memo,” which exhaustively documents the investigative sources forming the basis for the allegations.
Given the careful documentation, I believe the memos accurately portray current project status. While I have no opinion regarding specific descriptions of misappropriation of funds, the project management and contractor oversight flaws certainly ring true. From a technical perspective, the allegations are sufficiently detailed to appear rooted in fact.
The official NCTC response, described at the end of this post, offers little reassurance to those concerned about government waste on IT projects. Apparently, even the nation’s most substantial national security projects are subject to failure and allegations of malfeasance.
This isn’t the first government IT failure and certainly won’t be the last.
INSPECTOR GENERAL MEMO
The House Committee on Science and Technology impact memo, written to the Office of the Directorate of National Intelligence (ODNI) Inspector General, frames the issue:
The Subcommittee has learned that the TIDE database is suffering from serious, long-standing technical problems. The Subcommittee has also learned that a critical NCTC initiative, named “Railhead,” which is intended to replace TIDE with enhanced capabilities has suffered from severe technical troubles, poor contractor management and weak government oversight. As a result, potentially hundreds of millions of dollars have been wasted, delivery schedules have slipped, contractor employees have been laid off in order to restrain escalating costs, and the NCTC is now scrambling either to fix the technical troubles or possibly to abandon the program altogether. The end result is a current IT system used to identify terrorist threats that has been crippled by technical flaws and a new system that if actually deployed will leave our country more vulnerable than the existing yet flawed system in operation today.
—
Some Railhead insiders allege that a significant portion of the estimated $500 million dollars spent on Railhead has been inappropriately used to renovate a building of one of the prime contractors, The Boeing Company, into a Sensitive Compartmentalized Information Facility (SCIF) in Herndon, Virginia. These individuals have also questioned the technical solutions endorsed by the government to replace the current TIDE database, the qualifications of some of the Boeing subcontractors and potential conflicts-of-interest between the program director of another key Railhead contractor, SRI International, and the government’s Railhead program manager because of their alleged close personal ties. In short, documents obtained by the Subcommittee suggest that, despite hundreds of millions of dollars invested in Railhead and years of development, the government has little to show for its efforts.
—
Like many of these programs, the flaws and failures on Railhead have been exacerbated by weak government oversight, poor contractor management and lack of contractor accountability for the program’s performance. Turfbattles among contractors, particularly between the design team and development team, have hampered the sharing of critical technical data that has impaired the success of the Railhead program. In addition, one list of Railhead staff from January 2008 identifies a virtual army of 814 private contract employees from dozens of companies involved in Railhead and only 48 government officials keeping tabs on this mammoth and critically important national security program. In fact, an estimated one dozen government slots on Railhead have been vacant for more than one year. A combination of these management problems and technical troubles seems to have doomed the Railhead program to failure.
SUBCOMMITTEE MEMO
The Inspector General memo was based on worked performed by the Subcommittee on Investigations and Oversight. The more specific technical memo adds depth and detail to the allegations:
Among the largest and most expensive programs currently being funded by the ODNI is a program at the National Counterterrorism Center to improve and replace its current information technology systems, including the TIDE database, in order to enhance information sharing among federal agencies and improve access to counterterrorism intelligence data collected from more than 30 separate government networks that feed data into NCTC.
—
Documentation obtained by the Subcommittee points to a host of technical problems on Railhead, potential contractor mismanagement, contractor disputes, agency turf battles, poor government oversight and schedule delays that have hindered and hampered legitimate information sharing efforts on the program, have resulted in the potential waste of hundreds of millions of taxpayer dollars and placed the government’s key counterterrorism information sharing initiative in jeopardy of failing.
—
But technical problems on the current TIDE database appear to be hindering those efforts, and its successor –Railhead — is on the verge of collapse.
The original TIDE database, built by Lockheed Martin, replaced the Department of State’s TIPOFF database, designed and built by The Analysis Corporation, in the wake of the 9.11 terrorist attacks to automate the terrorist watch list. The TIDE database was built in Oracle as a relational database management system (RDBMS). This original database, however, suffers from basic design, management and maintenance ‘ inefficiencies and problems. For instance, only about 60% of the data, including names and addresses, mentioned in CIA cables provided to NCTC are actually extracted from these messages and placed into the TIDE database.
The TIDE database has evolved overtime as both contractors and government employees have attempted to expand and enhance the database to improve their own use of the system. But none of them appear to have taken into account the overall design or engineering architecture of the entire system. As a result, there are now dozens of tables or categories for identical fields of information making the ability to search or locate key data inefficient, ineffective and more time consuming and difficult than necessary.
In addition, the TIDE database relies on Structured Query Language (SQL), a cumbersome computer code that must utilize complicated sentence structures to query the tables, rows and columns that encompass the TIDE database. Without proper documentation on whether a table contains information on names, addresses, vehicles, license plates or an individual’s nationality, for instance, analysts have no valid mechanism to conduct a search of these “undocumented” tables.
Without a detailed index of the data stored in each table in TIDE, the SQL search engine is blindfolded, unable to locate or identify undocumented data. The current TIDE database is composed of data fields that are presented in 463 separate tables, 295 of which are undocumented, according to one internal Railhead document. As a result, critical terrorist intelligence in the TIDE system may not be searched at all. “Existing TIDE data model is complex, undocumented, and brittle,” the document notes, “which poses significant risk to RLSI [Railhead Lead System Integrator] data migration and modeling.”
GOVERNMENT RESPONSE
The NCTC provided a vague and general response to the allegations, saying the conclusions are:
[I]nconsistent with the facts. The letter implies that there exists a risk to our nation’s security related to the implementation of NCTC’s information technology program, commonly known as Railhead. There has been no degradation in the capability to access, manage and share terrorist information during the life of the Railhead program.
Railhead is a multiple contract venue to support the operations and maintenance of existing IT systems; it replaces and builds new functions for the Center. Fundamentally, it is a series of technology (primarily software) upgrades implemented between now and 2012, rather than all at once to improve mission capabilities for many systems.
[Via an unnamed reader who referred me to the Ars Technica story; I’m always grateful for reader submissions of failed IT projects. Anonymous submissions are welcome. Requests for interview to both the ODNI and the Subcommittee were not returned.]
August 25th, 2008
Office 2.0: ‘Conversations’ prevent IT failure
Cultural issues are among the key drivers causing acute IT problems. Project failure rates remain high in large part because these drivers are difficult to identify and diagnose.
Many organizations accept information silos as a cost of doing business, despite the clear negative impact of these boundaries in communicating project status, problems, and potential points of failure. In extreme cases, projects fail and management claims complete ignorance of any problems whatsoever. Yes indeed, these are Dilbert moments.
The importance of conversation becomes magnified when we recognize the term information silos really means “people don’t talk with one another.” Sal Rasa, an innovative organizational development colleague of mine, elaborates:
Living in a Web 2.0 environment changes our perspectives on knowledge sharing and traditional organizational dynamics frameworks. “Conversations” become understood as critical….
It’s easy to sidestep the human dimension of success and failure, focusing instead on abstract notions of culture and politics. Consultant and blogger, Susan Scrupski, sent me an email making clear that self-serving individuals are responsible for project failures:
It’s not culture, but rather hubris and ego that blows up what could be fantastic product design or customer experiences. When people can’t work out their differences on a human level, brilliant projects are canceled and abandoned.
Still, culture can have a dramatic impact on success and failure across a range of industries and sectors. In a conversation about public sector financial waste, Suffolk University professor of organizational ethics, Lydia Segal, told me:
So you have rules designed to stop waste that now cause it. The waste is built into the rules and reinforced by the myopic organizational culture that those rules fostered.
Changing an organization’s culture to support successful IT involves establishing new attitudes toward organizational communication. Most organizations will continue to experience unacceptably high rates of IT project failure until they explicitly redefine work processes to reduce communication boundaries.
IT success rates will only improve when organizations initiate systematic efforts to institutionalize greater information sharing.
============
The upcoming Office 2.0 conference includes numerous sessions examining processes and technologies forward-thinking organizations have used to overcome information boundaries. If you’re interested in these issues, I recommend attending or sponsoring this conference.
ZDnet blogger, Dennis Howlett, comments on the Enterprise Irregulars’ connection to Office 2.0; another ZDNet colleague, Oliver Marks, is a conference speaker.
August 22nd, 2008
‘Debunking IT Project Failure Myths’ [podcast]
According to various studies, at least 30% of all IT projects fail in some important way. Failure rates seem to have plateaued at this level because most organizations don’t really understand why their IT projects go down. As a result, failures persist, with some organizations even proclaiming, “We’re not at fault because we did everything right.” Such attitudes are misguided.
In his recent report, titled “Debunking IT Project Failure Myths,” Lewis Cardin, a former CIO and currently senior analyst at Forrester Research, states:
Firms commonly use three metrics to decide whether a project effort is successful: Did the project meet its schedule, stay within budget, and deliver on requirements?… Firms use these same measurements to establish project success rates simply because they are so obvious and business execs easily understand them. IT execs often get measured on these outcomes and are held accountable for the results delivered by project managers; when a project is deemed a failure, this accountability can be bad news for IT. The problem is that this IT accountability is frequently misplaced. Worse still, the conclusion of failure is often incorrect.
Translation from the trenches: the real sources of IT failure lie in issues like project management culture, which neither IT nor most business people are comfortable analyzing, let alone fixing. Lewis’ research describes four critical dimensions that project stakeholders frequently misdiagnose, resulting in repeated failure:
Unresponsive governance, which leaves project decisions hanging. IT project governance has the role of project approval, problem resolution, direction-setting, and communication with business stakeholders…. Unless the cause of this delay is visible and shown to be for governance reasons, someone is going to point fingers — months later — to defective project management and not the real source of the delay.
Lack of communication from change management, which leads to false conclusions. Business managers may change requirements during project execution…. At project completion, the business has forgotten about the improved value component while memories are crystal clear about the increased dollar and time investment. A project has a high probability of being tallied under the failure column when in fact it may have been a noteworthy success.
An unrealistic project plan, which dooms the best project. All too often, when these projects go on the rails of the original project plan, PMs must spend more time on damage control with steering committees and project resources rather than on execution — doubling their work when it is least desirable to do so.
First-number syndrome, which makes business execs forget it’s an estimate. When projects are first sized, which is likely to occur before they are approved, estimates of cost, time, and resources are preliminary with a wide confidence interval…. But business execs remember the number and forget how uncertain it is…[and] may see this simply as increasing costs, not as the inevitable result of greater knowledge.
Issues such as executive sponsorship, business case, usability, and vendor integrity play a large role in determining the outcome of IT deployments. Unfortunately, most organizations don’t pay sufficient attention to these key areas because they’re hard to measure. Nonetheless, IT project success is not possible without paying careful attention to the real causes of failure.
ABOUT THE PODCAST
I urge you to spend 12 minutes and listen to the attached podcast. Lewis and I explore these issues during a provocative and informing conversation. The discussion of change management and the cultural determinants of IT failure alone is worth your time.
August 19th, 2008
The triple sins that cause IT failure
Why don’t more organizations recognize potential IT project problems before they escalate into full-blown failures? Bruce F. Webster believes many companies reject good solutions to fix bad projects for three reasons: internal politics, budget, and fear/pride.
Bruce’s column in Baseline describes three sins that make failure almost inevitable in many organizations:
Internal politics. Large internal IT systems…usually involve several different groups, each of which may or may not be all that happy about having to work with some of the others, but are forced to do so for various budgetary, departmental, or business alignment reasons.
Budget. This may seem counter-intuitive, but management often finds it easier and safer to have a project drag on year after year, ultimately costing large sums of money, than to spend a relatively small (but still painful) portion of that amount up front and fix the problems now.
Fear/pride. Fear and pride can be closely related, particularly when the issue is admitting you made a mistake. This is particularly true if a key manager, architect, team leader, or developer has championed or defended a given approach that turns out not to have worked.
Organizational inertia, the decision-making gridlock that arises when conflicting personal agendas and viewpoints prevent team consensus, lies at the heart of many failures.
While experienced CIOs may recognize that politics and fear cause failure, simply wishing the problem away accomplishes nothing. Instead, wise leaders must take active steps to change organizational attitudes toward failure itself. In fact, it can be healthy for companies to prune back their project portfolio periodically, encouraging natural selection to leave only strong projects untouched.
Facing the inevitability of failure, what’s a responsible CIO to do? Aside from seeking new employment, transparency is the best weapon in the fight against corporate inertia. Exposing self-interested agendas to the harsh glare of daylight is the surest way to keep the system honest.
And that, my friends, is precisely what’s needed to improve IT project success.
[Image via http://home.att.net/~s.l.keim/Sermon.htm.]
August 18th, 2008
12 early warning signs of IT failure
High rates of IT project failure persist because most organizations don’t understand the real reasons why their projects fail.
Executives often blame the project manager for planning or budgeting errors without recognizing their own contributions to failure. Don’t ignore the early warning signs of failure; they’re a loud siren if you listen carefully.
A research paper by two academics and a business consultant, Early Warning Signs of IT Project Failure: The Dominant Dozen, sheds light on the underlying causes behind many failures. The paper provides a framework for examining early-stage IT projects to identify and prevent downstream problems.
Sensitivity toward early warning signs [EWSs] can increase project success rates by giving advance notice of potential points of failure. For example, the team can shore up weak executive sponsorship if it identifies the problem sufficiently early. The paper groups causes of failure into two categories: people-related risks and process-related risks.
Here are the top people-related risks:
- Lack of top management support
- Weak project manager
- No stakeholder involvement and/or participation
- Weak commitment of project team
- Team members lack requisite knowledge and/or skills
- Subject matter experts are over-scheduled
And the most important process-related risks:
- Lack of documented requirements and/or success criteria
- No change control process (change management)
- Ineffective schedule planning and/or management
- Communication breakdown among stakeholders
- Resources assigned to a higher priority project
- No business case for the project
Note that technology failures aren’t included anywhere in the list. As the authors say:
[I]T projects almost never fail because of technical causes, despite the fact that people and process problems may manifest technically…. Technical risks cannot be eliminated, but they can be managed.
Truer words were never spoken! We live in an imperfect world of sometimes-frail technology; software has bugs, the cloud goes down, and technology glitches interfere with well-laid plans. The real key to project success: strong project leadership combined with a top-down organizational commitment to instituting thoughtful project processes.
If this seems easy or trivial to you, then I suggest following the lead of Nepal Airlines’ risk mitigation practices. Your results are likely to be the same as theirs.
[Via Francine McKenna. Image via victorysiren.com.]
August 15th, 2008
Implementation complexity enables higher software prices
According to an interesting post in CIO Magazine, recent price increases by both SAP and Oracle were made possible by implementation complexity and the difficulty of replacing existing systems.
CIO explains:
[O]ne of the complaints customers have about these products is the huge implementation costs of putting them in. Said a different way, they’re so complex that very few companies can afford to take on the cost of getting them installed and working. Consequently, reducing prices on the software probably wouldn’t grow the customer base, because most companies can’t afford the total cost of owning them.
In other words, enterprise software customers believe they have few choices and therefore willingly pay whatever vendors ask. For their part, software suppliers are aware of this dynamic and take full advantage of their incumbent position.
It’s a one-sided perspective but compelling nonetheless.
[Image via Univ. of Warwick]
August 14th, 2008
SAP: Transparent SME ‘deep dive’
Following it’s Business Objects Influencer Summit, SAP held a small and medium enterprise “deep dive” event for bloggers, analysts, and press. Both SAP’s strategy and the company’s openness were impressive.
SME portfolio strategy. Jeff Stiles, SAP’s Senior Vice President for SAP SME Solution Marketing, articulated a coherent product offering that segments the market along several dimensions:
- Customer size
- Business and organizational complexity
- Growth rate and trajectory
- IT infrastructure capability
- Preference for on-premise vs. software as a service (SaaS) solutions
In a follow-up email, Jeff commented:
The other thing that should be considered is how an organization competes (do they need to deeply customize the solution to fit their unique needs?)
SAP’s offering to the SME market consists of the following:
Business One: SAP’s product for “small businesses that have outgrown their accounting only applications.” Appropriate customers will generally be under 100 employees with 30 users.
Business byDesign: SaaS offering for “fast-growing midsize companies, with limited software & systems, that don’t want to build a large IT backbone.” While the target market for byDesign appears to overlap Business One and All-in-One, the hosted aspect is one strong point of differentiation.
All-in-One: Aimed at “mid-size companies looking for a solution that meets their demanding industry requirements and helps grow and scale the business.” This product can handle much of the business complexity addressed by SAP’s large enterprise suite, but is designed for smaller companies.
The following graphic summarizes these points (adapted from an SAP-supplied slide):
The clarity and quality of SAP’s SME strategy has come a long way over the past several years. As Dennis Howlett commented on Business One:
My past experience with BusinessOne is of a solution that was relatively stagnant in the market, of less than competitive functionality and suffering from performance issues. That was two years ago. Today, the product is improved from every angle. Performance has been beefed up significantly, quality has improved but most important, smart VARs have figured the current iteration provides a genuinely viable alternative to Microsoft products.
Implementation innovations. From a project failures perspective, I want to highlight the SAP Best Practices component of All-in-One. Rooted in work started in the mid-1990s by SAP’s Simplification Group, SAP Best Practices advances the implementation state of the art.
Here’s SAP’s slide on this topic:
In my view, productizing knowledge represents one of the best opportunities for reducing software implementation time and expense. On a directly related note, I also believe that packaged services will ultimately form the basis for all but the most complex implementation consulting efforts across the enterprise software industry.
Software vendors and consultants can improve implementation efficiency through standardized implementation road maps, structured pre-configuration analysis, and consistent information sharing from pre-sales through go-live. However, given the organizational complexity around selling and deploying enterprise software, combined with technical configuration challenges, achieving these goals has been elusive.
It’s worth mentioning that some third-party consultants and system integrators resist implementation efficiency because it reduces billable hours. Although many consultants hate failure, I believe third-party billing churn continues to be consulting’s dirty little secret.
Although I haven’t spoken with SAP customers about specific Best Practices-based implementations, both concept and presentation pass the smell test. [Disclosure: For many years, starting in 1996, my company was deeply involved in developing the first generations of SAP’s rapid implementation tools. I have no such relationship with SAP at present.]
What’s missing. While SAP’s small and medium enterprise positioning has become crisper over time, several points remain confusing:
- The positioning still needs additional focus and clarification. For example, overlaps between byDesign and and the other products need further definition. In addition, the line between All-in-One and the larger Business Suite product remains somewhat fuzzy.
- SAP’s statement of long-term commitment to byDesign needs reinforcement. Changes in byDesign’s product release strategy, combined with the company’s historical large enterprise focus, could make potential customers skittish about adopting this offering. If SAP is serious about byDesign, it must put a definite stake in the ground and make clear its intention to remain solidly behind this product for the long haul.
Transparency and openness. The SME deep dive raises the bar on communications by enterprise software vendors. Led by Jeff Stiles, SAP executives, partners, and customers accepted challenging questions from the small audience (30 people). To his credit, Jeff allowed the full-day schedule to drift based on audience interest in particular topics. While many of the questions were tough and analytical, the answers were straightforward and reflected confidence in the offerings.
SAP blogging. Many of the day’s most insightful questions came from Enterprise Irregulars attending as guests of SAP’s blogger outreach initiative: Vinnie Mirchandani, Dennis Howlett, Brian Sommer, Sandy Kemsley, and myself. Run by SAP’s Mike Prosceno and Stacey Fish, the program offers bloggers unprecedented access to SAP senior executives and information. With this program, SAP sets the enterprise software standard in providing transparency to bloggers.
Note to other enterprise software companies: transparency is a sign of confidence and demonstrates you have nothing to hide. Let’s see you step up and meet the openness challenge.
Michael Krigsman is CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures. Click here to discuss this post with him on Twitter.
See his full profile and disclosure of his industry affiliations.
Recent Entries
- Google Apps dashboard: Serious about the enterprise?
- MediaMax / The Linkup: When the cloud fails
- FAA computer failure slows nationwide air traffic
- Failed government IT: ‘The mother of all databases’
- Office 2.0: ‘Conversations’ prevent IT failure
Most Popular Posts
- 12 early warning signs of IT failure
- The triple sins that cause IT failure
- Bank blames user; gets caught
- SAP: Transparent SME 'deep dive'
- Implementation complexity enables higher software prices
- 'Debunking IT Project Failure Myths' [podcast]
Top Rated
- Bank blames user; gets caught+13 votes
- Failed IT causes major Georgia Blue Cross health privacy breach+12 votes
- Don't trust Google with your data+11 votes
- IT failures roundup: Airports; jail system; angry travellers+9 votes
- 12 early warning signs of IT failure+7 votes
- Jobs acknowledges MobileMe failure+5 votes
- Heart pacemakers vulnerable to attack+5 votes
- FAA computer failure slows nationwide air traffic+4 votes
Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
