August 25th, 2009

Five ways to avoid Enterprise 2.0 failure

Posted by Michael Krigsman @ 2:14 pm

Categories: CIO issues, Enterprise 2.0, IT issues, Project strategy

Tags: Performance, Enterprise 2.0, Social Software, Sameer, Business Ecosystem, Collaboration, Michael Krigsman

Great ZDNet blogger, Dion Hinchcliffe, recently wrote an excellent overview of why Enterprise 2.0 projects fail.

• Related: 14 Reasons Why Enterprise 2.0 Projects Fail

Accompanying analysis of failure with discussion of success helps teach lessons that arise from difficulty. In this spirit, guest blogger, Sameer Patel, describes ways to avoid failure and achieve successful Enterprise 2.0 projects.

Sameer is building an enterprise social business services firm that helps organizations accelerate business performance via the use of social computing concepts and technologies. Sameer consults to leading organizations and writes at Pretzel Logic - a blog about Enterprise 2.0 execution and social software. He can be reached at sameer.a.patel@gmail.com or on Twitter.

———

Enterprise 2.0 is not a category of software. Rather it’s a state that the enterprise achieves by leveraging social computing concepts and technologies, to accelerate business performance.

True performance improvements come from successfully shifting the nucleus of business process away from structured, data centric ERP systems, over to people centric platforms that break silos and artificial interaction firewalls. Carefully executed, the benefits can transform relationships between employees, customers, partners and suppliers to drive revenue, remove significant risk from marketing and product development initiatives, and significantly improve speed of execution.

Organizations can face significant execution risks that need to be carefully mitigated as they move towards creating and participating in a socially networked business ecosystem. From the temptation to ignore traditional benchmarks in favor of new metrics, to fighting basic human behavior, to relying on social software that claims to do all the magic, the promise of true business transformation will remain a pipe dream in the absence of well thought out execution components.

Some important considerations to help you avoid Enterprise 2.0 failure:

Read the rest of this entry »

July 25th, 2008

Did Levi's use failed IT as a 'convenient scapegoat'?

Posted by Michael Krigsman @ 6:16 am

Categories: CIO issues, Financial impact, IT issues, Implementation, Project failures, SAP

Tags: Financial, Implementation, Information Technology, ERP, Levi Strauss, Software Deployment, Francine, Enterprise Resource Planning (ERP), Strategy, Enterprise Software

Levi Strauss recently blamed a substantial drop in quarterly net income on problems related to its ongoing ERP implementation. Following that report, several observers suggested the company used IT failure as an excuse to deflect attention away from deeper and more significant financial challenges.

Last week I wrote:

SAP implementation problems prevented Levi Strauss from fulfilling orders for a week during the second quarter of this year.

These shipping problems, combined with other economic issues, caused the company’s net income to drop 98% relative to the same quarter in 2007. Levi’s most recent 10-Q SEC filing states that negative effects arising from the implementation “constitute a substantial portion of the decrease in the region’s net sales in the second quarter as compared to the prior year.”

Retail industry analyst, Paula Rosenblum, raised general questions about Levi’s financial reporting in a blog comment:

Companies have been blaming poor results on ERP implementations for 20 years. In my years as a CIO, I always found this notion to be a convenient scapegoat for other, deeper corporate issues. My years as an analyst have only deepened that conviction.

Considering this issue in her customer newsletter, Paula added:

How else do we explain how ten apparel manufacturers successfully implement a package, and an eleventh fails to implement the same package, blaming revenue shortfalls on a poor implementation? Perhaps the IT department didn’t gel well with the systems integrators hired to do the implementation. Perhaps the users didn’t document exactly what they did “in the old system.” And maybe even worse, perhaps standard operating procedures had fallen so much into folklore that no one even really knew who did a particular task, and why it was critical to the running of the enterprise. What if all of the above was true? Most likely there were mixed emotions about implementing a new infrastructure anyway.

Having similar suspicions, ZDNet colleague, Dennis Howlett, discussed more specific concerns with me privately and on Accman, his personal blog:

I suspect there is more to this than meets the eye. Levi anticipated ERP issues to the tune of $18 million so you can’t realistically count that because they took sales credit for those advanced shipments - at least that’s my reading of the Q1 10-Q filing. The company was anticipating a decline in revenues anyway from a variety of other factors, including a substantially weakened economy (in its opinion).

I have no doubt there were issues related to the ERP. But assigning so much emphasis when the company had already anticipated an issue is stretching credulity.

Former auditor, Francine McKenna, whom I quoted in the original piece, focused on possible financial controls issues at Levi’s:

Multinationals have long struggled with getting an ERP implementation right in one country on the first go around. When they implement multiple instances in quick succession, they accept the challenge of automating manual processes, adding automated controls to those new processes, and making these new and improved processes conform to the software capabilities and their business objectives. That’s almost impossible to get right the first time.

THE PROJECT FAILURES ANALYSIS

Given the frequency of failed projects, it’s not surprising some companies blame business or financial issues on IT. Large software deployments are complex by their nature, especially when an organization uses the implementation to change and improve business processes while integrating legacy systems. This complexity leads to high project failure rates and creates the opportunity for scapegoating and misdirected blame.

For private companies, the IT blame game is a political maneuver used by an individual or group to push culpability onto others. Public companies may sometimes use IT scapegoating to shift investor attention away from strategic management or financial challenges toward narrow technical issues.

Francine believes companies can mitigate the problem by improving auditor oversight on their large IT deployments:

[C]ompanies constantly make the mistake of thinking that if the consulting firm in charge of the implementation doesn’t consider internal controls as an important part of their implementation, then maybe they don’t have to focus on them to the extent that they should be focused to get them right.

In an interview, I asked Paula how organizations can prevent scapegoating. She believes compensation is the key to ensuring successful IT projects. Her newsletter elaborates:

There’s only one choice. And that’s to tie every single involved party’s compensation to the success of a new implementation. Start with systems selection and drive all the way through to post-implementation support. The business executives, the actual line staff, and the IT group should all have skin in the game. Of course, this requires executive level support. The correct word is “mandate.” But it also requires a coalition on the ground. It requires teamwork and willingness. Willingness doesn’t mean “happiness.” As I said, no one really likes to change.

So what really happened at Levi’s? Although perhaps we’ll never know for sure, Dennis summed up the entire matter nicely: “It is always easier to blame the ERP implementation.”

[Image via crosschurch.org]

July 8th, 2007

INTERVIEW: Don Dodge (Microsoft) on Avoiding Project Failure

Posted by Michael Krigsman @ 3:16 pm

Categories: Interview, Red Herring East 2007

Tags: Software, Project, Microsoft Corp., Don Dodge, Software Project, Michael Krigsman

Don Dodge has been around the software industry for a long time. Currently Director of Business Development, Emerging Business Team, at Microsoft, Don works closely with startups and venture capitalists. I’m an avid reader of Don’s blog (called the Next Big Thing), so it was with pleasure that I ran into him at the recent Red Herring East 2007 conference in Boston.

I asked Don a few questions about avoiding project failures, based on his experience working with many IT companies and products. If you want to understand the dynamics of project failure and success, I urge you to read Don’s comments carefully; He’s distilled lots of wisdom into a few short answers.

Don, when we met at the Red Herring conference, you said (and I’m paraphrasing here) that one of the major causes of failure is ‘unrealistic customers who expect a lot but are only willing to pay a little.’ Is it really that dangerous to be a tough negotiator?

Not unrealistic customers…unrealistic or vague project requirements.

In my experience, many software projects fail because the requirements were unclear right from the start, and buy-in was not achieved among all the various stakeholders who should have been involved. I’ve never seen a project get smaller…they always expand and get bigger. Second, most software projects are not “rip and replace”; they need to integrate with many other existing systems, which are often not managed or controlled by the project sponsor. Integrating with those other systems causes lots of delays and potentially huge architecture issues. Third, I think the biggest mistake in software projects is not doing regular progress checks and demos of code early and often. I worked at one company that used the “Extreme Programming” model, sometimes referred to as “Agile Process”. The great thing about Extreme Programming is that you must demo your work to the customer every three weeks. You can’t get too far off track if you are demoing to the customer every three weeks and getting them to approve the work.

Regarding your second question, I wouldn’t call it tough negotiating…just clear negotiating. Be very clear about the project specs, schedule, and success criteria. Then regularly check progress throughout the project.

You work with many startups and small companies in your role at Microsoft, and they’re often in an extremely weak negotiating position when dealing with enterprise buyers. Is there a way for these companies to command a price that lets them do a good job for demanding clients?

Startups are not in a weak negotiating position. They can move faster, have lower overhead, and offer a more personal approach than big companies. In fact, startups can charge lower prices and still make lots of money because they don’t have the huge overhead expense. The problem is that startups often feel like they’re in a weak position and therefore under-price themselves. In fact, however, they are not in a weak position.

At the same time, some projects are just not worth taking. If the requirements aren’t clear, if the schedule is unrealistic, or the price is too low…don’t take it. Life is too short.

Any time there’s a bidding war among vendors, common sense suggests that the buyer better have a clear idea of key project requirements — must-have features and critical performance criteria vs. less-essential stuff. Do you see this happening in actual practice?

Bidding wars often result in the “winner” losing money in the end.

If a customer bases his or her decision strictly on price, there are sure to be bad feelings somewhere down the line. Most people are honest and try to do a good job. However, mistakes happen when people move too quickly, without clearly documented requirements, without taking the time to map out a realistic schedule, and so on. A quick deadline for proposals or vendor selection can cause the customer to make mistakes.

What about the role of consulting partners in an under-funded project? How can the consultants manage customer expectations so the project doesn’t fail?

Big projects can get very complex…too complex for any one person to fully understand. Customers and project managers rationalize away issues, hoping to make up the shortfall downstream, perhaps cutting features or requirements in the desire to make it all fit together and work. That’s a recipe for disaster.

Projects that are “under-funded” or where customer expectations are not clear are in deep trouble. It gets back to the basic points I made in the first question:

• Be clear about requirements and get ALL customer stakeholders to agree
• Get the integration plan and architecture clear up front
• Demo your work early and often and get the customer to approve

Is there a special Microsoft methodology that helps avoid doomed projects? Or are you guys in the same boat as everyone else?

Microsoft has been building massive software projects for over 30 years. Microsoft projects rarely fail, but Windows Vista is a recent example of a major project schedule slip. The project was successful, but significantly behind schedule.

We spend lots of time getting requirements clearly documented, and bringing all the participant groups together, so everyone knows what they need to do and when. Successful software projects always have a strong leadership team that communicates clearly.

The mechanics of a successful project are pretty basic…but often overlooked.

June 25th, 2007

Four Questions for Selecting Mission-Critical Software

Posted by Michael Krigsman @ 2:15 am

Categories: Implementation, Project strategy, Vendor relationships

Tags: Michael Krigsman

The Evolving Excellence blog has a strongly-worded article against implementing SAP at a particular company with $5M in annual revenue. The argument basically says that a simpler, less expensive, system would work just as well for a business of that relatively small size. While the truth of this perspective is debatable, the post got me thinking about four questions software buyers should ask when evaluating a mission-critical enterprise system:

• How good is the “fit”? Does the intended solution address the problem. It’s amazing how often companies buy technology that will not actually solve their pain. Don’t ask me how this happens, but it does.
• Does the scale make sense? Don’t use a nuclear bomb when a fly swatter will work. Logic and reason tell us that small companies need smaller solutions, while bigger enterprises need larger, more robust systems.
• What’s the fully loaded cost? When buying software, the license fee just gets you in the door. There will be training expenses, downtime, implementation costs, and so on. Count on those additional expenses being part of your post-purchase life.
• Do you like the vendors and can you trust them? Implementing enterprise software is like a marriage with your consulting partner and software vendor. Be sure you are ready to tie the knot with those folks.

Buying any mission-critical system is complex, time-consuming, and expensive. When deciding what to buy, don’t rely on simple feature lists supplied by a software vendor as the primary decision criteria. Recognize you are going down a long path, and plan accordingly.

As I have written here and here and here, the selection process represents the first step on the road to project success or failure. Wise software buyers should tread very carefully on that road.

[Thanks to Dennis Howlett for bringing the Evolving Excellence post to my attention.]

—–

June 14th, 2007

7 Failures from Bad RFPs

Posted by Michael Krigsman @ 10:04 pm

Categories: Vendor relationships

Tags: Michael Krigsman

In my experience, many project failures can be traced back to poorly written requests for proposals (RFPs). When you buy the wrong thing, you get the wrong result.

Bart Perkins from Leverage Partners has written about this at InterGovWorld.com. Some points from his article:

RFPs that are unclear generally result in poorly defined service requirements and produce suboptimal results. They increase costs unnecessarily and contribute to disasters down the road. RFPs that are unclear typically cause one or more of the following problems:

1. Low bids: Unclear requirements may cause some bidders to submit low-priced minimal bids. These providers accept very low margins on the initial requirements but plan to make profits on the inevitable change orders.
2. High bids: In contrast, unclear specifications cause some bidders (often good ones) to bid extremely high to cover their risk. When part of the RFP is unclear, these providers usually assume that the actual project will require the most expensive options and bid accordingly. If the client later uses less-complex services, has lower volumes or needs less-rigorous service levels, these bidders pocket the difference.
3. No bids: Fuzzy RFPs force bidders to make numerous assumptions, which increase their risk. This raises concerns about their ability to make a profit, particularly with fixed-price bids. When this happens, even strong suppliers frequently decide not to bid. The result of less competition is that you may incur higher costs or be forced to select a second-class supplier.
4. Incompatible bids: Not all bidders will make the same assumptions when presented with an unclear RFP. As a result, the final bids may not provide apples-to-apples comparisons.
5. Requirements mismatch: Fuzzy specifications may result in a supplier bidding on what it thinks you specified, not what you actually intended or needed. Unless the bidder realizes that there is a disconnect between the RFP and the intended requirements, it will bid based on its interpretation of your requirements. When the disconnect is discovered, it may be too late to change the bidder’s proposal and still meet your submission deadlines. Even worse, the realization may come after the contract is signed, adversely affecting not only the supplier’s ability to deliver, but also your project deadlines.
6. Inability to deliver: Large, complex RFPs may require more services than a particular supplier can deliver. Some suppliers will bid on the RFP anyway, hoping these holes in their delivery capability will go unnoticed. They assume that if they win the contract, they will figure out how to deliver those pieces later. Unclear RFPs make it harder for your due diligence team to ask questions that will uncover the supplier’s delivery problems. If the bidder’s weaknesses aren’t discovered during due diligence, you may not learn about them until it’s too late - and far more expensive to fix. Clear RFPs help weed out those suppliers that knowingly promise more than they are capable of delivering.
7. Rigid contract compliance: When projects and supplier relationships go south, you can get into “letter of the law” situations and even litigation. In these cases, clarity in the RFP and other project documents can give you important leverage.

I’m always amazed when an ambiguously-written RFP crosses my desk. There are times we simply refuse to bid on a project, knowing that it will end in failure, given the approach demanded in the RFP. As I’ve discussed before, the technology selection and purchase process is important if you want your project to be successful.

[Thanks to the always-amazing Jeff Tarter for this reference.]

December 21st, 2006

Failing Before Starting

Posted by Michael Krigsman @ 5:06 pm

Categories: CIO issues, Vendor relationships

Tags: Michael Krigsman

Problems on many IT project failures can be traced back before the project even started. For example, we’ve all seen poorly-designed projects, that should never have seen the light of day. Whether for political reasons, short-sighted management, or plain old hubris, some IT projects are simply stupid to undertake. They will never, ever, ever achieve their goals and their failure can be predicted far in advance.

With this in mind, take a look at a Forrester Research report on vendor selection. From the report:

Project success hinges on appropriate vendor selection. A thorough selection process minimizes risk and lays the foundation for a winning project…. Just as important as the selection process is what happens the day after the contract is signed — governing the engagement and the relationship with the provider.

I do agree with Forrester that vendor selection is critically important. However, the cynical me sometimes gets the sense that Forrester wants their clients to hire outside experts (which is to say, hire Forrester), so their clients can avoid responsibility for developing in-house competence. Without casting any doubt on Forrester’s skill and experience, I would suggest this is not always such a great idea.

Sure, hire the experts and let them guide you. However, in my experience, failures tend to magnify precisely when in-house expertise is most lacking. Few consulting companies will look after your interests to the same degree your in-house folks will. In addition, once a project starts down the failure progression, the results will often be far worse if you have not developed in-house skills. Crisis situations can deteriorate rapidly when a company is dependant on a vendor that is no longer deemed trustworthy. And this happens all the time.

So sure, Mr. Forrester, vendor selection is important. But it’s only one piece of a larger puzzle. Even the best vendor may not be able to overcome a flawed project design. In fact, the best vendors will avoid flawed projects like the plague.

—–

October 23rd, 2006

Airbus Crashes from Incompatible Software

Posted by Michael Krigsman @ 3:49 pm

Categories: Project failures

Tags: Michael Krigsman

Buying the wrong software can significantly affect the health of even the largest company.

If you don’t believe me, just ask Christian Streiff, former CEO of Airbus. He was recently replaced due to delays on the company’s new flagship plane, stemming from a wrong software selection.

Carol Matlack describes this hard-to-believe situation in BusinessWeek:

It sounds too simple to be true. Airbus’ A380 megajet is now a full two years behind schedule—and the reason, CEO Christian Streiff admitted on Oct. 3, is that design software used at different Airbus factories wasn’t compatible. [Ed. note: on Oct. 10, Airbus announced that Louis Gallois is replacing Streiff as CEO.]

Early this year, when pre-assembled bundles containing hundreds of miles of cabin wiring were delivered from a German factory to the assembly line in France, workers discovered that the bundles, called harnesses, didn’t fit properly into the plane. Assembly slowed to a near-standstill, as workers tried to pull the bundles apart and re-thread them through the fuselage. Now Airbus will have to go back to the drawing board and redesign the wiring system.

It’s shaping up to be one of the costliest blunders in the history of commercial aerospace.

———————————- 

Airbus said, “The root cause of the problem is that the 3D digital mockup, which facilitates the design of the electrical harnesses’ installation, was implemented late and that the people working on it were in their learning curve.

Don’t kid yourself: this happened at Airbus and it can happen to you. Big IT crashes don’t just fall from the sky — they result when a chain of smaller causes come together and cascade into something larger. Moral: be careful at every step of the way. Yes, it sounds too simple, but the cause of this enormous IT project failure also sounds too simple.

 

[via Shayne Nelson]

—–

August 15th, 2006

"7 Ways to Fail in an ERP Selection"

Posted by Michael Krigsman @ 4:34 pm

Categories: IT issues, Vendor relationships

Tags: Michael Krigsman

In the ERP and More blog, Chris Shaul describes “7 Ways to Fail in an ERP Selection.” Here is his list:

1. Choose ERP software without understanding your requirements.

2. Select ERP software without paying attention to business processes.

3. Choose ERP software because your Friend/Neighbor/Relative is using it successfully at their firm.

4. Not having the ERP vendor prove that it will support your business processes.

5. Choosing ERP software because it looks cool.

6. Let the ERP vendor tell you what you need to be doing.

7. Take the ERP vendor’s first offer without negotiating.

I think the takeaway message here is to look beneath the surface. Project success depends on really understanding the landscape: the organizational environment, the technology, and the business. Most project failures arise from incomplete action / understanding in one of these domains.