————–

After 131 years great American photographic icon, Eastman Kodak, filed for bankruptcy. Some might say that Kodak never made a successful transition from traditional film to digital cameras, but that’s not exactly correct, because American inventor, Steven Sasson, created the first digital camera for Kodak. I think the Economist put it more accurately, explaining that Kodak had become a “complacent monopolist,” enjoying its profitable film franchise and not keeping up with changing market trends. While Kodak invested in marketing, Japanese competitor FujiFilm created even better films, diversified through acquisition, and changed its business model to attack digital photography directly and with strength.

Photo credit: "Pipe Dream Swirls" by Michael Krigsman

As Kodak struggles for survival, FujiFilm is enjoying a renaissance period of innovation. For Nikon and Canon, FujiFilm’s innovation with sensors, the heart of any digital camera, poses a genuine threat. Only the future will reveal whether FujiFilm can make serious inroads against established competitors, but there is no question the company will push Nikon, Canon, and every other digital camera manufacturer to make fiercely better products. As a photographer myself, I think it’s great.

In 2011, FujiFilm released the X100, a small, lightweight camera with outstanding image quality. Despite usability quirks and missing features, the camera became an instant and viral hit among photographers.

For those accustomed digital single-lens reflex (DSLR) cameras from Nikon and Canon, the X100 is a breath of fresh air - it just feels natural to use. One photographer called the X100, “the greatest digital camera ever made and may just be the greatest camera I have ever owned.” Another said, “The images I get from my Fuji X100 are nothing short of amazing.”

Photo credit: "Tourists on the Water in Boston" by Michael Krigsman

I purchased an X100 and absolutely loved it until last week, when I unceremoniously dumped this small camera wonder. Why, you ask, did I get rid of the beloved camera? Because FujiFilm just announced a replacement, called the X-Pro-1. This new machine promises even better image quality than its predecessor, while retaining small size and adding the flexibility of interchangeable and high quality lenses. It’s a winner and I’m in line to buy one immediately on release.

As Kodak fades, FujiFilm embodies a new generation of photographic technology driven by genuine innovation rather than strict adherence to marketing formulas. A powerful lesson is hidden in this story.

Photo credit: "Conversations in Silos" by Michael Krigsman

Update 1/20/12: Thanks to Carlos Francavilla for translating this post into Spanish!!

This post summarizes my remarks to a group of senior government leaders embarking on an innovative and ambitious plan to improve health care delivery in their state. A key issue is fostering communication and collaboration between business stakeholders and IT.

Statistics tell us that almost 70 percent of IT projects are late, over-budget, or fail to deliver expected value (the worst fate of all). Numbers like these make clear there is a pervasive issue in the world of IT delivery.

Despite the glaring statistics, virtually all projects start with good intentions; after all, no sane team intends to fail. Although politics and self-interest sometimes push individuals to undermine team goals, most organizations that invest in technology expect positive results. Despite these good intentions, failures occur with striking regularity and few organizations take steps needed to prevent failures from arising.

For example, no one expected a meltdown when the state of Maine went live with a new Medicaid claims processing system that allowed medical providers to submit claims over the Internet. But meltdown is precisely what happened when unanticipated errors caused the system to handle claims incorrectly. Original project cost: $25 million. Additional work required to fix errors after going live: $30 million. Hassle caused to medical providers and lost credibility to state of Maine health administrators: priceless.

Similarly, everyone surely expected success when Minnesota’s Department of Human Services (DHS) started developing its HealthMatch program, “an automated system designed to match Minnesota residents with appropriate state-run health programs, based on eligibility.” Nonetheless, the state eventually spent $41 million and settled a lawsuit with the software developer before deciding to shut down the failed program. Despite HealthMatch being a total loss, one enterprising Minnesota lawmaker subsequently introduced a bill directing the Department of Human Services to start over with a new external contractor.

As these examples demonstrate, good intentions and an honest soul are not sufficient to create successful IT projects. Many organizations simply lack the skills needed to navigate complex relationships between technology and business holders in an organization.

To avoid these problems, every CIO, project owner, and business leader should understand three basic principles:

1. Put strategy before technology

It may sound obvious but many organizations do not fully consider business strategy before deploying technology.

A prevailing view assumes that IT’s primary role is managing technology. However, this limited perspective obscures a more profound truth: technology’s highest value is helping the business achieve benefits such as driving innovation and competitive advantage, lowering costs, increasing market share, and so on. For those who love jargon, call this “IT enabling the business.”

Projects fail when organizations perceive IT as folks who “keep the lights on.” When business process owners and stakeholders do not involve IT with planning and strategy, they create mutual co-dependence with their IT counterparts. Eventually, IT itself completes this unhealthy relationship cycle by not taking sufficient time to understand and engage lines of business in a meaningful way. For those who love jargon, call this pattern “mutually assured self-destruction.”

The technology must work or you’re screwed »»

Just for fun, here’s a video clip of a news interview I recorded, talking about the latest cool technology and even discussing whether Microsoft is relevant in today’s world:

Cotton candy photo by Michael Krigsman

While browsing the instruction manual for a professional cotton candy (PDF download) machine, the following phrase jumped off the page (emphasis added):

Many experienced operators prefer to lift the ring out of the pan and, with a flick of the wrist, turn the ring into a figure eight and whip it around the cone. This leaves giant air pockets and makes it appear that you are serving a larger portion.

Of course, sales people want to minimize weaknesses in their product or service offerings, so this kind of presentation happens all the time in every sphere of life.

In the enterprise, where products and their organizational impact are intensely complex, the situation is magnified a zillion-fold. The many lawsuits over IT failures testify to the significance of mismatched expectations between vendor claims and buyer understanding.

At what point does beneficial “product presentation” become outright deception and is there a solution for the enterprise? Please share your thoughts.

IT failures arise from a confluence of factors such as misunderstanding technology, poor judgment, lousy project management, politics, conflicts of interest among the Devil’s Triangle, to name just a few. Enterprise projects are hard precisely because they extend across organizational and functional boundaries; solving the problem requires a holistic view that encompasses multiple stakeholders and project participants, inside and outside the company.

As we enter 2012, three trends will drive renewed interest in improving IT success rates:

1. A difficult economic climate that is less forgiving of financial waste and lost productivity
2. Software as a service (SaaS), which holds the potential to simplify implementations and reduce risk, cost, and time
3. Consumerization of IT, including rise of the CFO (and lines of business) as a powerful force in IT investment

These trends have placed pressure on enterprise software vendors, system integrators, and customers to improve implementations and reduce the waste associated with enterprise projects.

As we enter 2012, there is evidence of enterprise software vendors taking steps to help customers run more successful projects. This post takes a look at the rapid implementation work of three vendors: Syspro USA, SAP, and Oracle.

Syspro USA and the Quantum Architecture »»

In this video interview, Aneel Bhusri, co-CEO of Workday, offers insight into his view of enterprise cloud software and the consumer Internet. Workday’s vision is to sell ERP software that competes directly with Oracle and SAP. During the interview, Bhusri characterizes Workday as an “ERP replacement” company, further highlighting the intensity of his competition with the established players.

It’s interesting to hear Aneel discuss lessons learned from his experience in the industry. At one point, the interviewer asks about a potential future acquisition from Oracle:

Interviewer: Once you are a public company, what is to stop Larry Ellison from coming around and knocking on the door [as he did in the past, acquiring PeopleSoft]?

Bhusri: He can knock on the door, but it will be locked. Between Dave [Duffield] and I we will control well more than fifty percent of the company.

As a cloud-based ERP vendor selling to the largest companies, Workday combines the enterprise with a strong nod toward consumer Internet sensibilities. The conversation is thoughtful and engaging, making this interview highly worthwhile for anyone interested in enterprise software and the cloud.

This week, SAP announced plans to delay releasing its new community software by a few months, igniting a contentious mix of opinions. While most observers believe the delay is a reasonable response to technical issues and the need for continued testing, others state the company risks “permanently blowing up” its credibility.

To learn more, I spoke with Mark Yolton, SAP’s Senior Vice President responsible for SCN. Mark explained he based the decision to delay on several factors, which he subsequently summarized in a blog post:

• Technology problems, including important bugs that remain to be fixed
• Impact of end of year holidays on the project team and availability of resources to fix unexpected problems after release
• Opportunity to gain pre-release feedback from influential and active members of the community

Most important, Mark told me, he wants to ensure a positive experience for users when the new site goes live.

STRATEGIC ANALYSIS

The decision to delay a project is always difficult and involves consideration of multiple risks, impacts, and benefits. In this case, SAP made an intelligent decision for three reasons:

1. The delay causes little or no impact on users or stakeholders because the existing site continues to function without interruption.
2. The original date was driven by desire to improve community experience rather than a specific external deadline.
3. Premature release could cause unexpected problems, such as bugs or performance glitches, for the two million members of SCN.

While it is easy and dramatic to call this situation a failure, I take the opposite position and offer SAP kudos for reducing risk, maintaining clear focus on long-term user satisfaction, and being transparent.

We can find many examples where a business suffered substantial ill effects because management pressured a project team to release a customer-facing platform prematurely. For example, retailer J. Crew suffered poor earnings after deploying a CRM and web system without sufficient testing.

In this case, SAP’s decision to delay helps ensure that users receive high quality, uninterrupted service. Since the original deadline was arbitrary and self-imposed, SAP made the right decision. Moreover, according to Marc Yolton, it is unlikely the delay will be significant relative to the project duration as a whole.

I asked respected community member, Jon Reed, for his thoughts. Jon’s view reflects a nuanced view in accord with those expressed in this post:

In this case, a late launch done the right way is far better than a premature, buggy go-live. But, SAP will take a PR hit for these delays. It puts the pressure squarely on SAP to deliver something excellent out of the gate in 2012. How the community receives this go-live will tell us a lot about whether SAP was inclusive enough in their implementation to anticipate snafus they can’t afford to have in January.

My take. This situation is meaningful because SAP’s large community draws significant attention. From a project failure perspective, this case offers a great lesson — don’t take unnecessary risks, especially when your only deadline is self-imposed. In the end, good judgment trumps slavish adherence to schedule, budget, or the desire to drive short-term public relations.

Photo credit: Cloud watching by Michael Krigsman

TechCrunch trumpeted an odd lack of interest in SAP’s acquisition of human capital management vendor, SuccessFactors, for $3.4 billion. The popular technology startup blog offered these choice comments:

In what is perhaps the most boring piece of tech news to come out of this week, German software giant SAP has today announced that it will buy the US-based SuccessFactors….

I think this means that it provides enterprise software for human resources, but you can never be too sure with these incredibly dull companies. I am too bored to Google it.

If you are actually interested in finding out more, or having trouble sleeping and need something to push you over the edge, SAP will be holding a conference call….

Even the carefully chosen web address for the TechCrunch article speaks volumes:

http://techcrunch.com/2011/12/03/zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/

Now, I totally get that enterprise software is not exciting. But let’s remember two facts:

• This deal is worth billions and is about the cloud. Regardless of your opinion good or bad, it’s important.
• According to SAP, 63 percent of the “world’s transaction revenue” touches an SAP system

The SAP acquisition demonstrates the mainstream importance of cloud computing; it’s good for everyone involved in the cloud ecosystem. From startups, which are TechCrunch’s usual fare, to the largest players in the world this acquisition says: CLOUD HAS ARRIVED.

One startup CEO, Aaron Levie from Box.net, which sits at the junction of consumer and enterprise, tweeted his recognition that this acquisition matters:

A a million dollars isn’t cool. You know what’s cool? $3.4B cloud acquisitions. Take that consumer internet!

As of this writing, here are the best pieces I have seen discussing the SuccessFactors acquisition:

SAP Press Release: SAP To Accelerate Cloud Strategy with Acquisition of SuccessFactors

ZDNet: SAP acquires SuccessFactors for $3.4 billion: Cloud consolidation accelerates

Jon Reed: Some quick thoughts on SAP’s acquisition of SuccessFactors

John Appleby: SAP acquires SuccessFactors – is it all hot air in the cloud?

Ray Wang: News Analysis: SAP Buys SuccessFactors for $3.4B Signals SAP’s Commitment To Cloud, HCM, and Social

Paul Hamerman: SAP’s Acquisition Of SuccessFactors Re-engergizes Its HCM And SaaS Strategy

Sven Denecken: SAP to Accelerate Cloud Strategy with Acquisition of SuccessFactors – will talk more #SAPSummit

Phil Fersht: SAP + SuccessFactors = Great for SAP, but could restrict growth potential for the HR services industry

Photo credit: String Theory by Michael Krigsman

The endless succession of failed projects forces one to question why success is elusive, with an extraordinary number of projects tangling themselves in knots. These projects are like a child’s string game run amok: a large, tangled mess that becomes more convoluted and complex by the minute.

In my view, the core problem lies in mismatched expectations, poor communication, and a host of other non-technical causes.

During the last few years, the practice of “design thinking” has become popular among some enterprise practitioners and observers. Design thinking helps structure team interactions to cultivate greater inclusiveness, foster creativity, and align participants around specific goals and results.

I first learned about design thinking during conversations with people like Chirag Metha, an enterprise software strategist and design thinking expert; Chirag is one of the most thoughtful folks I know and writes a great blog on enterprise software. With these qualifications, of course I asked him to write a guest post explaining how design thinking can help project teams run successful implementations.

Chirag Mehta is an enterprise software generalist with 15 years of experience in strategy, design, architecture, product management, and product development in areas such as ERP, CRM, BI, middleware, and infrastructure. He is a top independent blogger on cloud computing, an adjunct faculty member, and advisor to many entrepreneurs. Chirag is passionate about design thinking and has coached others at Stanford d.school.

Chirag works for SAP driving business development and early adoption of new applications built on SAP’s in-memory computing platform. Previously, he was a strategist with SAP’s office of the CEO (and CTO), where he served as trusted adviser to the company’s CEO, Chairman, CTO, and executive management on topics such as design thinking, cloud computing, SaaS, Web 2.0, BI, in-memory computing, location-based applications, social media, and sustainability.

Thank you to Chirag Mehta for writing this guest post.

——–

IT projects fail all the time. Business blames IT, IT blames the system integrator (SI), who then blames the software vendor. After all this blaming and shaming, everyone goes back to work on another project without examining the project management methods and processes that caused the failure. And, so, they fail again.

There’s no one definition of design thinking. It’s a mindset and set of values that applies both analytical and creative thinking towards solving a specific problem. Design thinking is about how you think and not what you know; it is about the journey and not the destination.

Having followed Michael Krigsman’s analysis of IT project failures, it became evident that design thinking can play an important role in improving enterprise software development and implementation. The design thinking approach offers a means to address the underlying causes of many project failures — poor communication, rigid thinking, propensity toward tunnel vision, and information silos.

I have distilled important lessons from design thinking into six principles that can help stop project failures. Along the way, we will draw comparisons with Agile development, since that distinction is often a source of confusion when discussing design thinking.

Continue reading for the six principles »»

Leaders in many organizations mistakenly think that project managers are solely responsible for implementation success or failure. On the surface, such myopic and shortsighted views may appear true — if lots of tasks are late and over-budget, then of course the overall project will follow suit.

However, looking more closely it becomes clear that project management is only one dimension among many required for implementation success. For example, a solid business case, executive support, success metrics, and even budget are all critical factors over which the project manager may have little control.

An academic thesis, titled ERP Adoption in Small and Medium Sized Enterprises (PDF download), reinforces the view that project management alone offers a limited, and not particularly useful, definition of implementation success. Although focused on ERP, the lessons hold true for any enterprise software deployment:

[M]uch evaluation of ERP success is based on meeting project targets and milestones but little is done to measure the effect on organizational effectiveness. An unsuccessful project, in terms of project targets and milestones, could still be successful in terms of improved business value.

In this statement, we see the weak link that often prevails between project management and organizational value or benefit. Assuming project participants want to do the right thing, which is usually the case, tunnel vision occurs when the team slavishly aims at narrow project metrics without adequately defining outcomes that are meaningful to the business.

Continue reading to see the six lessons »»