January 7th, 2010

Tim Bray's Enterprise 2.0 conundrum

Posted by Michael Krigsman @ 7:53 am

Categories: CIO issues, Cultural issues, Enterprise 2.0, Failure 2.0, IT issues, Politics

Tags: Information Technology, SOA, Enterprise 2.0, Tim Bray, Tim, Erik Engbrecht, Service-Oriented Architecture (SOA), Strategy, Web Services, Enterprise Software

Yesterday, I reprinted an excellent and thought-provoking blog post by Tim Bray, one of the inventors of XML.

Tim’s post represents a reality check for traditional enterprise software, suggesting we could avoid massive IT failures by following a more web-oriented approach to IT and software development.

• Related: Enterprise systems: “Time to stop the madness”

Tim summarizes his point this way:

The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise.

He goes on to compare the culture of web development (”starting small, gathering user experience before it seems reasonable”) to that of traditional enterprise IT, where he says failure rates “remain distressing.”

Tim then argues against building large-scale custom software unless absolutely necessary (a premise I wholeheartedly support) and finally concludes that “we need to do it better.” In this case, improvement means philosophically adopting an end user, consumer-oriented approach to software creation.

In Tim’s words:

Suppose you asked one of the blue-suit solution providers to quote you on building Ravelry or Twitter or Basecamp. What would the costs be like? And how much confidence would you have in a good result?…

Read the rest of this entry »

June 22nd, 2009

HP connects IT investment, value, and transparency

Posted by Michael Krigsman @ 3:39 pm

Categories: CIO issues, Governance, Hewlett Packard, IT issues, Project portfolio management

Tags: Hewlett-Packard Co., Information Technology, IT Investment, Project Portfolio Management, ROI Analysis, Brian, Project Management, Tools & Techniques, It Operations, It service Management

Last week, I attended HP’s Software Universe 2009 conference to participate on a panel discussion around success strategies for deploying project portfolio management (PPM). I used the opportunity to speak with HP executives about their vision for the future of PPM and its relationship to enterprise value creation.

To understand the company’s PPM product direction, I spoke with four folks representing HP’s views on features, strategy, and customer implementation:

• Paul Muller, VP for Strategic Marketing
• Ken Cheney, Director of Products, IT Financial Management
• Bruce Randall, Manager of Product Marketing, PPM
• John Wills, Practice Principal for HP’s Business Intelligence Solutions group

HP’s primary strategic message about the future direction of PPM involves helping IT departments improve their ability to quantify project costs, benefits, and derived value, which Paul described this way:

We automate the spreadsheet Kung Fu that IT often uses to analyze financial data. Our goal is reducing decision-making cycle times and creating transparency that quantifies the business value of IT operations.

Ken Cheney elaborated on this message:

Many organizations find it difficult to get an accurate handle on IT costs. We link IT with the business services it delivers and assign value to help IT appropriately price these services. The future of PPM is helping organizations clearly see the total cost of ownership of all IT services.

HP’s strategy positions PPM as a building block in a broader IT financial management offering, as the following diagram illustrates:

Read the rest of this entry »

January 27th, 2009

5 tips to reduce outsourcing risk

Posted by Michael Krigsman @ 6:22 am

Categories: CIO issues, Consulting, Devil's Triangle, IT issues, Interview, Project strategy, Vendor relationships

Tags: Project, Risk, Managed Hosting, Outsourcing, It Operations, Business Operations, Outsourcing & Subcontracting, Michael Krigsman

Service providers present a special challenge to organizations involved with complex IT projects. Although consultants are integral to many projects, dysfunctional service provider relationships can increase the customer’s risk of failure.

To explore this issue, I spoke at length with Alec Miloslavsky, CEO of Exigen Services, an outsourcing supplier that specializes in Agile development. I asked him why traditional relationships with system integrators sometimes cause a gap between customer goals and consultant interests:

Traditional consulting companies base their relationship model on labor arbitrage, where the services provider gains financial benefit primarily from differences in labor costs. As a result, the consulting firm neglects key issues in IT project delivery, increasing the customer’s risk.

Alec added that projects generally face three types of risk:

• Financial risk, where project cost rises above expectations
• Time to market risk, where the project is late
• Delivery risk, where the project doesn’t achieve planned objectives

Pure labor arbitrage contributes to all these problems, especially in environments where there is insufficient governance to control results.

I asked Alec for five tips to help services customers get the most from their relationship with external consultants. Here is his list:

Read the rest of this entry »

November 18th, 2008

Texas gov. intercedes in failing IBM project

Posted by Michael Krigsman @ 7:19 am

Categories: CIO issues, Cultural issues, Devil's Triangle, Financial impact, Government projects, IT issues, Implementation, Politics, Project failures, Project strategy, Vendor relationships

Tags: Texas, IBM Corp., Advertising & Promotion, Marketing, Michael Krigsman, Agency, State, Backups, Outsourcing, It Operations

Texas Governor, Rick Perry, ordered state agencies to stop transferring data to IBM to prevent data loss on a failing project. Texas also fined IBM $900,000 for failing to meet data backup requirements specified in the state’s $863M outsourcing contract.

This backup situation represents only tip of the iceberg with lots more failure to come. Be forewarned: as they say, “You ain’t seen nothin’ yet.”

The Dallas Morning News reported:

Read the rest of this entry »

October 27th, 2008

Agile: Anatomy of a failed project

Posted by Michael Krigsman @ 12:57 pm

Categories: CIO issues, Consulting, Cultural issues, IT issues, Project failures, Project management, Project strategy, Vendor relationships

Tags: Project, Michael Krigsman, Customer, Agile, Mitch Lacey, Corporate Communications, Team Management, Marketing, Management

A finite set of problems causes almost all IT failures: including lousy requirements planning and mismatched expectations among key stakeholder groups. Agile practitioner and trainer, Mitch Lacey, dissects these issues in a valuable video presentation titled, “When Working Software Is Not Enough: A Story of Project Failure.”

Mitch describes the project background, details initial warning signs, walks the audience through progressive steps of failure, and suggests post-mortem lessons learned. Mitch explains how Agile development could not overcome basic misunderstandings that ultimately led to catastrophic failure.

Several key warning signs early in the project suggested downstream failure. Most significantly, in my view, the customer stated a $500,000 budget, while Mitch’s team assessed the cost at $1 million. To meet this budget, the developers pushed critical work back to the customer, as described in the following slide:

Read the rest of this entry »

December 4th, 2007

SAP Influencer Summit: SOA grows up

Posted by Michael Krigsman @ 8:31 pm

Categories: CIO issues, IT issues, SAP, SaaS, PaaS, and SOA, Vendor relationships

Tags: SAP AG, SOA, Service-Oriented Architecture (SOA), Product Development, Business Structures, Tools & Techniques, Web Services, Strategy, Enterprise Software, Middleware

I’m spending a couple of days at the SAP Influencer Summit, an invitation-only event for approximately 500 key SAP partners, bloggers, analysts, user group leaders, academics, and the press. According to Mike Prosceno, Vice President for Marketplace Communications, the Influencer Summit is intended to facilitate “networking and relationship building, and is the last formal opportunity of the year for SAP to address its ecosystem of SAP watchers.”

Through a carefully-orchestrated set of presentations, SAP offered attendees a glimpse at important accomplishments and future plans. Here are some thoughts and impressions from the first day of this event:

Overall, I’m impressed. SAP’s product vision is forward-thinking and comprehensive. Years of SOA-based product development effort have finally started paying off with Business byDesign and the revamped ERP Suite, both based on the NetWeaver platform. Business byDesign, an ERP suite for small enterprises, was created from the ground up, using modern development tools, methods, and a globally distributed development environment. Call me a geek, but I buy into the platform’s underlying depth and elegance.

In the long run, products such as Business byDesign will make implementations shorter and more successful, reducing the size, scope and impact of potential project failures. Obviously, that’s a good thing.

Simplifying complexity is an important theme which arose during presentations, as well as in private blogger meetings with SAP executives, such as CEO Henning Kagerman and Executive Board member Peter Zencke.

Customizing is out; extending is in. Continuing a mantra stated during dialog at Sapphire in Vienna last spring, custom code is history at SAP. In response to my question, Peter Zencke described three types of customization:

1. Setting configuration “switches,” which continues to be an accepted and approved method to make packaged SAP software work in varied customer environments.
2. Directly modifying code, “which SAP will not support, so customers can maintain the ability to perform in-flight maintenance.”
3. Extending the software, using a “composition layer” that gives access to SAP’s SOA services, has become the approved way for adapting SAP software to meet specific requirements, such as those posed by “micro-verticals”.

In plain English, SAP now provides a foundation, on top of which third-parties (customers and partners) can write new applications and which prevents the core SAP code from being changed. This approach ensures a clean, future upgrade path without the downstream costs traditionally associated with custom code. Customer adaptations integrate directly with the core SAP software to extend it’s functionality, but again, the core remains protected.

In subsequent conversation, Jim Hagemann Snabe, who is responsible for SAP’s Business Suite product line, reaffirmed the importance of avoiding custom code.

Some observers remain skeptical. Analyst and blogger Judith Hurwitz, who also attended the Summit, registered concerns during a late-afternoon conversation:

It all works, if you assume you live in SAP-only world. But the reality is many customers have complicated, multi-vendor environments that include many parts. Unless you make the SAP world your context it wont work. In fairness, you can say that about any enterprise software world. Each vendor wants you to view their offerings as the center of the world.

Judith discussed the same issue on her blog:

So, why does this bother me? I think that because that the strategy and platform assumes that customers will be willing to adopt a single vendor platform that everything in their enterprise will flow through. To its credit, SAP does expect that third party applications and environments can be integrated through well defined interfaces. These outside resources would be integrated through the repository. However, will a customer want to give a single vendor that much power? Perhaps? Will most customers overcome the internal political issues to have everyone agree on a single platform across departments, subsidiaries, and even partners? I would say that I am skeptical.

Fellow Enterprise Irregular, Prashanth Rai, offered another note of concern during a conversation. He’s impressed by the technology, but wants to see businesses adopt the new software before he fully buys-in. From Prashanth’s perspective, without more customers, the vision remains unproven:

SAP has delivered and continues to deliver on the technical aspects of “business network transformation,” but the realization of this, from a business/customer point of view, remains to be seen in 2008.

When a large company such as SAP offers a view across its many initiatives, it’s not possible to comment on everything at once. This post summarizes first impressions, based on a long day spent trying to absorb buckets of information very quickly. Others may disagree with these assessments and opinions, but that’s my broad comment for today.

October 13th, 2006

Reducing Consulting Costs with Productized Content

Posted by Michael Krigsman @ 10:03 pm

Categories: Implementation, Packaged Services

Tags: Michael Krigsman

High-priced, open-ended consulting deals often fuel enterprise software implementation failures.

As a result, a trend has developed among consulting companies and software vendors to package services into pre-defined, discrete units, decreasing risk and lowering costs for the customer. As examples, see here (pre-configured content shipping with software), here (packaged services), and here (more packaged services).

Pertinent to this subject, Jason Busch at SpendMatters writes, “In the consulting and software worlds, the lure of the billable hour or high margin application deals has traditionally trumped a content- or information-based sale. But perhaps things are changing.” Jason goes on to describe a newly-announced partnership between software company Procuri and consulting company AT Kearney Procurement Solutions.

Procuri will include AT Kearney’s Market Solutions tool content as part of it’s software product offering. The Solutions tool includes “templates and guides for RFPs and auctions, and supply market reports and insights for a broad range of sourceable goods and services.” In other words, AT Kearney has packaged its knowledge into productized form, which can then be leveraged and reused across multiple client engagements.

Of course, there is a place for open-ended consulting arrangements, especially on complex and strategic projects taking place in a changing, dynamic environment. However, open billing arrangements potentially create an incentive for the vendor to rack up hours beyond what is required to get the job done. In contrast, fixed-fee engagements tend to shift project risk away from the customer to the consultant. In many cases, this risk shifting forces the vendor to be more efficient.

For customers, the allure is obvious: lower project risk combined with lower consulting costs.

October 10th, 2006

Productized Services - AT Kearny

Posted by Michael Krigsman @ 1:55 pm

Categories: Consulting, Packaged Services

Tags: Michael Krigsman

Jason Busch at the SpendMatters blog has a great post describing AT Kearny’s procurement-related consulting offerings. His description of AT Kearny’s services is instructive for anyone interested in packaged services:

Procurement Solutions is focused on creating repeatable, expert solutions to Spend Management versus a more traditional management consulting approach which looks at each new procurement and supply chain opportunity from a generalist, one-off analytical lens.

[M]ore sophisticated organizations are most likely to use their services to augment their own capabilities where there is a specific need. In contrast, the management consulting organization is typically a better fit from a sourcing and category basis with clients who are less mature and need greater process help and all around Spend Management expertise and guidance.

The exception to this are more sophisticated companies looking to solve abstract problems or those that demand industry specific expertise — these situations are also a better fit with AT Kearney’s more traditional management consulting services arm. But quite often, the two organizations cross pollinate on projects, joining forces to help clients. Management consulting type-engagements, however, such as a complex make / buy manufacturing analyses, which are large and transformational in nature, are more likely to be led by generalist firm resources than specialized Procurement Solutions ones.

Jason makes a couple of key points to which I want to call attention. First, he emphasizes repeatable vs. one-off solutions: productized services are all about defining repeatable activities, documenting them, and delivering them more efficiently. Second, he correctly notes that the packaged approach is not always a good fit; for example, on large strategic projects where the dynamics are unique and complex.

Packaged, productized services can substantially reduce software implementation time and cost, lowering the risk of project failure. If you are a consulting company or services group inside a software vendor, get on this train, as I have recommended here and here and here.

—–

October 2nd, 2006

Reducing Services Costs

Posted by Michael Krigsman @ 2:47 pm

Categories: Implementation, Packaged Services

Tags: Michael Krigsman

Vinnie Mirchandani posts on IBM’s strategy to productize services.

Almost a year ago, Vinnie posed this challenge: “IBM’s SI/outsourcing groups do not think like its software group. They want to sell more bodies, not automation. If they allowed the same software team which is working on self-healing systems management to work on SI automation, I would be willing to bet they could develop significant labor saving tools.”

When I saw this quote, I had to respond.

First, Vinnie absolutely right in asserting the tension between the stated goal of reducing services costs and the way consultants are incentivized. This is a big deal, and productized services can only work in the context of a more fundamental shift in service delivery strategy, which includes adjusting the consultant compensation model.

Second, Vinnie mentions consulting automation tools. I say YES YES YES to that! Recently, I gave a presentation on exactly this subject; here are several approaches to consulting automation from that talk:

1. Implementation toolkits. Document the process, including roles and activities, and package it into a sharable tool. (Blatant self-promotion note: Cambridge Publications has worked with SAP, IBM, and others to create such toolkits. There is no one in the world better at it than we are.)

2. Reusable content. For example, developing pre-configured systems, along the lines of what SAP and Oracle have done.

3. Automation tools. Well-designed tools reduce hours spent on routine consulting tasks. For example (another blatant self-promotion note follows), Asuret has created a consulting tool to perform rapid pre-implementation risk assessments. We quickly gather data and then automate the reporting. There are also a variety of tools on the market to automate such things as data conversion and system configuration.

Consulting organizations that develop such tools will reduce their cost to customers, thereby improving their competitive position in the market. However, as a developer of such tools, I can say with certainty that consulting automation requires an investment that many services organizations will be reluctant to make.

If you are a services group, either standalone or part of a software company, then beware: now is the time to start thinking about automating your routine activities. Rest assured, your smartest competitors have already begun this process for themselves.

—–

September 26th, 2006

Reducing Implementation Costs

Posted by Michael Krigsman @ 10:40 pm

Categories: Implementation

Tags: Software, Software Company, Michael Krigsman

Vinnie Mirchandani posted an insightful comment on this blog related to software implementation time and cost. He correctly points out that even so-called “successful” implementations often run substantially over-budget. In most fields, a project that has run 2-3 times over-budget would be considered a failure, but the expectations around software seem to be different. Why do otherwise rational, sane people find huge cost overruns acceptable on software-related projects?

I recently spent an afternoon consulting to a group of senior executives from an important enterprise software vendor. Their challenge: reducing implementation time as a means to increase customer satisfaction. This is easier said than done, given complexity around both the software and the customer environment. To some degree, definitively solving the implementation problem requires that software products and related services be designed with implementation in mind. This is not easily accomplished, but in the long run lowering implementation costs almost always helps a software company sell more product.

Hey software vendors, this is a simple concept: make your products easier to deploy and you will sell more!

—–