May 14th, 2008
UK gov’t releases transparent post-failure analysis
The UK Identity & Passport Service (IPS) has released an excellent post-implementation assessment report describing lessons learned from five key 2007 projects. In an unusually transparent move for any government agency, the report candidly examines each project’s objectives, deliverables, and areas for improvement.
The report analyzes the following IPS projects conducted during 2007:
- Authentication by Interview (ABI) – our largest project and an important counter fraud initiative which provides the capability for IPS to conduct passport applicant interviews
- Reserve Facility – the provision of a reserve site for IPS’s main passport production facility ensuring business continuity in the event of catastrophic failure
- ePassport Public Reader Project – the provision of a self service facility at passport regional offices to allow the public to view the data on the chip in the ePassport
- Eclipse – a project to introduce a web based on line procurement system to improve efficiency of the procurement process, and comply with the eGovernment agenda.
- PASS 7.2 – development of IPS’s core application processing system to enhance database technology, and implement policy changes and process improvements.
It presents over 20 specific recommendations for improvement, organized according to the following categories:
- Benefits Realisation
- Business Involvement
- Communication
- Contract Management
- Culture
- Governance
- Implementation Roles and Responsibilities
- Issues management
- Management of External Communications
- Off-system Customer Experience Testing (CET)
- Phased Implementation and Transition Plan
- Process
- Project Approach
- Project Resourcing
- Release Authority Board (RAB)
- Release Authority and Business Readiness Meetings
- Security Accreditation
- Staff Recruitment
- Stakeholder Management
- Testing Environment
- Testing Methodology
- Testing and Piloting
This list is outstanding precisely because it covers many common points of program management failure. Despite the importance of post-implementation analysis in preventing future failures, many organizations don’t perform serious post-mortems, fearing that embarrassment or conflict will result.
That’s why the objectivity and candor presented in the IPS analysis is so refreshing. In addition to being even-handed, pointing out both flaws and successes, the results are open and available for anyone to see. That’s a sign of a healthy, confident organization trying to learn from past experience.
Good work, IPS! You’ve set a great example for both government and the private sector.
May 11th, 2008
Hosted software development: an emerging market [includes podcast]
Note: Click the player above to hear my podcast interview on hosted development with Jeffrey Walker and Jeff Leyser from Atlassian Software.
Hosted software as a service (SaaS) development solutions have become an important option for mainstream programmers. These products range from straightforward offsite storage, such as Amazon’s S3 service, to fully outsourced platform as a service (PaaS) application environments, like that which Salesforce.com provides in Force.com.
To learn about hosted software development, I asked two folks from Atlassian Software, which provides hosted group collaboration and software development tools, for an interview. Jeffrey Walker, the company’s President, and Jeff Leyser, Product Marketing Manager, briefed me on issues related to hosted software development.
What is hosted development?
Development systems consist of an integrated development environment (IDE), where programmers directly write and compile their code, along with other supporting tools. Two critical components sitting outside the IDE are the repository, where code is stored and its history maintained over time, and the defect tracking system, where developers track and manage bugs.
Hosted development solutions, such as Atlassian’s Jira Studio, provide these non-IDE components, along with other software development and collaboration tools, over the Internet.
In contrast, full PaaS systems, like Force.com, allow applications actually to run on their system. In other words, platforms include the IDE, supporting tools, have their own development language, and incorporate a run-time system.
What are advantages and disadvantages of hosted vs. local software development?
With hosted development, the hosting provider maintains the development infrastructure, relieving developers of this burden. This yields stable and predictable costs, as with other types of SaaS offerings. Ideally, hosted environments should also embody development best practices, such as incorporating tools to make code reviews easier and faster.
Disadvantages of hosted development include perceived concerns around the safety of intellectual property. Although this issue exists in any remotely hosted SaaS environment, software companies may be reluctant to entrust their key intellectual assets to a remote service provider. Another issue is customization, because SaaS development tools are generally less configurable than locally managed, on-site systems. Similarly, it is easier to integrate internal systems, such as LDAP directories, with local tools than with hosted systems.
When is hosted development most appropriate?
Geographically distributed teams are an obvious candidate, particularly where organizations combine offshore development with an onshore team. Hosted development gives both local and remote groups straightforward access to code and a standardized set of tools anywhere the Internet is available. Hosted solutions also simplify implementing common workflow processes across a distributed team.
How is the workflow and process different with hosted development?
The initial setup and infrastructure planning are quite different with hosted development. However, the daily programming workflow is the same in both local and hosted development environments. Features and functions of the tools drive workflow, regardless whether the tools are behind the firewall or installed locally.
Any comments on Salesforce.com’s hosted development platform?
Answered via email: It will be a cold day in Hell before someone builds a serious piece of software totally unaffiliated with SFDC on Force.com. I am sure SFDC can name examples but I would just point to the failure of the AppExchange after huge promotion and investment….Be careful in comparing a hosted development environment that allows for a myriad of types of projects, like ours aspires to be, with ones that promote a self-serving agenda or proprietary infrastructure.
May 7th, 2008
Government IT failures: “Room for improvement” [interview and podcast]
![Government IT failures: “Room for improvement” [interview and podcast]](http://blogs.zdnet.com/projectfailures/images/government-it-failures-room-for-improvement-interview-and-podcast.jpg)
Given the size, scope and frequency of government IT failures, it’s important to understand the dynamics underlying these projects. To learn more about federal IT, I interviewed two federal systems experts from CA, developer of the Clarity project portfolio management (PPM) solution.
Gil Digioia is Vice President of Federal Project Portfolio Management Sales for CA Clarity, and possesses over 15 years working delivering software solutions tailored to the specific needs of federal agencies and solution integrators. Jose Mora is Sr. Director for Product Marketing for CA Clarity Project and Portfolio Management solution, where he is responsible for all IT governance and public sector-related marketing activities including product strategy and positioning.
The OMB publishes a quarterly list of high-risk IT projects as part of its investment oversight function. Why is this list important?
It’s an extremely important means for the Office of Management and Budget (OMB) to provide visibility and transparency regarding IT projects to the agencies. In addition, citizens want to know how agencies allocate and invest funds, and whether they are achieving their deliverables. Having a list of projects in the red zone is also critical to making decisions.
Do government agencies pay attention to the list?
Absolutely. The most important thing about this list is bringing attention, and drawing focus, to where agencies will direct their spend and plans over the year. A lot of attention is placed on bringing these high-risk projects into the green.
In addition, when an agency has a change, such as new CIO or director wanting to make an impact, the list is often used to bring about quick success.
Why do so many government projects fail?
There is room for execution improvement regarding the triple constraints of scope, time, and budget. The big reason is lack of “critical corrective action” from high-level decision makers within the organization. This can result from either lack of decision-making or leaders who don’t have the proper information to make decisions that ultimately impact the project.
Requirements also tend to change after projects have been awarded, and are often different at project conclusion from what was specified in the original proposal. These changes tend to disrupt project workflow and collaboration. Such challenges pose particular difficulties for organizations that don’t have a repeatable governance process in place or lack the proper technology to react easily to those changes.
Problems can arise at the project management level, the executive decision-making level, and with technology. For example, problems are sometimes caused by legacy systems that can’t adapt to the rapid changes in information these organizations face.
Are there differences between public sector and private sector projects?
The biggest difference is profitability on the finance side. In the private sector, cost reduction is important but they’re also looking to drive profitability.
From the perspective of project management and program management behavior, however, the federal government is definitely ahead of the private sector. Various mandates on government projects, such as OMB and enterprise architecture requirements, are much further ahead than what is typical in the private sector. For example, “earned value” is still a novelty in the private sector but it’s important in the government.
How can federal organizations evaluate IT projects to prevent failure?
Earned value management, which the OMB mandates, is a solid and rigorous project management technique. It captures the fundamentals for evaluating a portfolio, including analysis of baseline costs, performance data, schedules, resources and skill sets, outcome measurement, and examining reporting requirements. All these provide a solid foundation for evaluating one project versus another.
Aside from systematic upfront evaluation, what steps can federal managers take to ensure successful projects?
Selecting the right governance structure is important, which means examining how an agency makes decisions on its program portfolio and ensuring this process is repeatable and established throughout the organization. This process component is fundamental.
It’s also important to define comprehensive criteria for evaluating projects and to ensure that criteria includes all critical areas or details that could impact earned value reporting back to the OMB. The earned value requirement established by the OMB is a step in the right direction.
Accurately capturing and reporting project data is another key area. Although this sounds simple, we often see complicated, homegrown legacy applications for project management, resource management, and tracking time or cost. All these disparate systems create confusion and complexity, making it difficult to track accurate data.
Project improvements also mean mobilizing and empowering the proper infrastructure of people needed to make and communicate decisions throughout the organization. Leadership is required to make difficult decisions such as killing a project, delaying a project, or simply not funding a project.
To be successful, start with sound processes, as opposed to throwing a tool or solution at the problem. Get your processes in place, understand your risks, and then create a platform where you can organize the people who need to execute, in a manner that’s repeatable, process-driven, and has visibility from executive management. Take on smaller wins that deliver value quickly instead of attempting a big bang.
[Thanks to Joan Levy from Blanc & Otus Public Relations for arranging this interview.]
April 30th, 2008
CNBC: SAP America’s president should offer media training
During an interview on CNBC, SAP’s CEO Bill McDermott, said customers buy his software to accomplish three goals:
- Making money
- Cost reductions
- Maintaining compliance
In a moment of what some might consider to be irrational exuberance, McDermott described SAP as the only software company able to offer these things to customers. I suspect some SAP competitors might take issue with his comment.
One interviewer jokingly asked McDermott whether he offered media training, since he turned all the negatives into positive comments. Fellow Enterprise Irregular, Charlie Wood, was also impressed. His post includes the full clip.
On a more serious note, SAP announced that Business byDesign, their software as a service (SaaS) offering, would be delayed 12-18 months. Larry Dignan and Dennis Howlett covered that story.
Business by Design represents a strategic shift for SAP in the years to come, so I think the delay is only a temporary setback. As Vishal Sikka, SAP’s chief technology officer, told me:
“[Business byDesign represents] a profound shift we are trying initially in the mid-market; we are being cautious, we are being conservative, we can afford to, and we are going to get this right.”
See also: Exclusive interview / podcast with Vishal Sikka, SAP’s chief technology officer
SAP has been touting the product to its ecosystem, and partners building their business around this new initiative will be disappointed with the delay.
April 28th, 2008
SAP’s CTO: Business knows ‘what’, IT knows ‘how’
The Naked IT interview series talks with innovators about the evolving relationship between IT and business. Please listen to the audio podcast and enjoy the brief excerpts below.
Vishal Sikka is SAP’s Chief Technology Officer. Reporting directly to CEO Henning Kagermann, Vishal is responsible for driving technology and architecture strategy across SAP’s product portfolio. As CTO, Vishal also leads the company’s forward-thinking efforts around emerging technologies and is responsible for mapping SAP’s next-generation architecture. He holds a Ph.D. degree in computer science from Stanford University and his experience includes research in automatic programming, information and application integration, and artificial intelligence at Stanford, Xerox Palo Alto Labs and two startups.
Vishal and I spoke about a broad range of enterprise software issues, including his role as CTO of SAP, service-oriented architecture (SOA), relationships between business and technical organizations in the enterprise, IT project failures, SAP’s acquisition of Business Objects, and Business byDesign.
If you’re interested in CIO or CTO issues, give the podcast a careful listen; it’s well worth your time and attention!
On being CTO:
My primary job is to define and articulate the roadmap for our products and technology, bringing coherence and uniformity to the way we govern our architecture and over-arching product design.
On packaged applications:
The basic idea of a packaged application is one size fits all, serving a wide variety of customers. You get economies of scale from packaging that application, functionality, and so forth….Having a packaged application suite that simultaneously fills the need across that broad diversity of industry, country, nature of business…is a very, very difficult problem. There have been generations of companies that have tried to do this and failed. Simultaneously reaching for breadth, depth, and ease of use killed these other companies.
On IT / business alignment:
Lines of business know the what and IT knows the how. Companies in which this “what / how” distinction is broken tend to have difficulties. You have to empower the lines of business and the IT guys….trusting the IT guys know the how and lines of business can articulate the what….The business [should] tell IT the nature of the problem to solve; IT [should] then bring in tools and platforms to [address them].
You [develop] strategic IT by bringing the line of business and the IT guys together to the table [with] mutual respect and empowerment.
On IT extinction:
That is just nonsense.
On reducing IT failures with enterprise SOA:
[SAP combines] IT simplification (technical visibility) with business transformation. Implementation maps [along with] the enterprise services repository and its process capabilities…help get solutions get adopted very quickly [and with lower risk]. The services repository gives [stakeholders] a very public and visible way of seeing how their business relates to the software.
[Stakeholders] can also [share] with other business process experts to get a sense of what others are doing, which Hasso [Plattner], our founder, refers to as “doing business with an open window.” Seeing what other people have done, sharing experiences, [provides] extra visibility into [how the software relates] to the business, making the entire process much more seamless, and reducing project failure.
On the Business Objects acquisition:
We closed the strategy to execution loop, which CEOs , CFOs, CIOs, and heads of operations are badly missing….Closing that loop between strategy and execution is something that Business Objects really enables us to do.
The user-centric and the information-centric aspects are fundamental….We want to be in activities that business users [perform]; that are not directly operational, but informational, in nature. We are going to get there faster than any of the other guys.
On innovation in enterprise software:
If you have applications that serve core business processes and live for ten or fifteen years, how do you bring innovation that is non-disruptive to customers? We deliver innovation in consumable packages twice a year in enhancement packs, which also include technology improvements; this is a non-disruptive roadmap for [customers] to continuously innovate. [It’s] a mechanism for delivering innovation while preserving stability; of delivering insight while preserving execution.
On Business byDesign:
Salesforce.com talks about adapting and so forth, but doesn’t cover even a tiny fraction of the breadth of [SAP’s product suite]. On-demand to us is an interesting delivery mechanism…. [However, Business byDesign represents] a more profound shift….
A few years ago we launched an effort to rethink how we build the core software;…it was our generational look at what has to happen inside the core processes. Business byDesign is our mid-market delivery of that vision…It represents a fundamentally modular way of building software that no one in the industry has ever dreamed of building. It is designed for the mid-market but has implications beyond that.
April 23rd, 2008
Salesforce.com’s bold development platform vision [includes executive podcast]
Note: Click the player to listen to my podcast interview with Steve Cakebread, President and Chief Strategy Officer of Salesforce.com. Steve comments on his company’s strategy, discusses on-premises software, and presents Salesforce.com’s vision for mobile devices.
Salesforce.com’s Tour de Force roadshow is traveling around the world to present the company’s platform as a service (PaaS) strategy, which it calls Force.com. According to Marc Benioff, Salesforce.com’s ebullient CEO, the company’s long-term vision for PaaS represents nothing less a sea change for software development.
Salesforce.com wants to be, “The world’s first multi-application, multi-category SaaS company.” To achieve this goal, Salesforce has built a rich set of programming, user interface, and rapid development tools to attract developers and ease their transition to the Force.com platform.
The strategy is based on the notion of utility computing, where developers offload certain functions, such as database hosting and administration, onto Force.com, which becomes, in effect, a low-cost, commodity infrastructure service provider. With this strategy, Salesforce hopes to reduce its customers’ development cost, lower complexity and risk, and shorten development cycle times
This paradigm extends the company’s core SaaS application-delivery model, based on a multi-tenant technical architecture, to a full range of backend web services. The following slide shows the development activities and infrastructure that Salesforce is attempting to centralize and commoditize with economies of scale:
According to Salesforce, the Force.com platform consists of services that address key components in the development workflow, so programmers can focus on high-value activities such as core application functionality. Here’s a high-level architectural diagram of Force.com:
THE PROJECT FAILURES ANALYSIS
Salesforce.com has divided the software development lifecycle into high- and low-value activities to drive commodity traffic to its platform. Although it’s an impressive and sweeping vision, to achieve market-leading traction Salesforce must overcome certain obstacles.
Change management. While developers can split off and outsource certain activities, organizational and cultural issues around software development and deployment still remain. Training and change management, for example, remain important determinants of project success in both the on-premises and outsourced paradigms.
In addition, outsourcing requires developers, users, and management to adopt a new set of expectations around development timeframes and workflows. For example, Analog Devices’ Worldwide CRM Strategy Manager, Cheryl O’Conner, a satisfied Force.com customer, said the rapid release cycles made possible with outsourcing can wreak havoc on user education, because training materials can remain perpetually out of date.
These concerns will diminish over time, as the market adapts to outsourced development, but they are real issues today.
Process maturity and application heterogeneity. I believe Salesforce eventually plans to offer a “virtual software suite” to encourage it’s customers to dispense with the likes of SAP, Oracle, and other on-premises enterprise solutions. Several substantial obstacles militate against Salesforce realizing this vision anytime soon.
Large enterprise vendors typically offer industry-specific best practices, in the form of well-established processes and workflows, embedded in their software suites. These proven practices, often created over the course of many years, frequently drive the business transformation efforts that lie behind successful software implementations.
While software development under Force.com may be faster than using traditional methods, process maturity across multiple industries and business functions is independent of development speed. Salesforce must address this issue to compete successfully against larger, more established, packaged application vendors.
Additional considerations for customers seeking to purchase a virtual product suite from components offered on Force.com include the lack of coordinated, single-vendor responsibility over application functionality, master data management, user interface, and so on. Since Force.com is a platform, who will be designated as controlling authority over integration among the components? This will be a strategically challenging issue for Salesforce.com.
Without centralized control, Force.com could become like Windows–disorganized, bloated, internally inconsistent–rather than sleek, clean, and friendly like the Macintosh.
On-premises is sometimes necessary. Both outsourced and traditional on-premises software have a legitimate place in the world. For example, hosted outsourcing is not acceptable in certain environments, such as financial services, where security concerns are paramount. Even CODA’s CEO, Jeremy Roche, another enthusiastic Force.com customer, acknowledged that his on-premises product line is here to stay.
The big question: will developers buy it? The development tools landscape is littered with companies who once offered innovative languages, rapid development frameworks, and integrated programming environments. Symantec and Borland, to name two examples among many, were forced to exit the development tools business years ago.
Developers don’t make the platform decision lightly or quickly, so winning their hearts and minds is a time-consuming and highly risky proposition. Nonetheless, the new paradigm is compelling, interesting, and undeniably cool; the concept, platform, and strategy also make intuitive sense. Clearly, this battle is worthy of careful observation.
March 17th, 2008
IT failures and social media
Shel Israel, co-author (with Robert Scoble) of the influential book on blogging, Naked Conversations, recently interviewed me regarding social media and IT failures. I used the interview to consolidate my views on several IT failure-related issues.
Here’s a summary of the interview; the topics are Shel’s, but the answers are mine. For more detail, read the full interview.
Causes of IT failure
IT failures are generally caused by management errors in human, rather than technical systems. Poor judgment, dysfunctional organizational politics, and bad planning are far more likely to cause a major project failure than a database failure, for example. The high profile failures that hit the newspapers, or that I blog about, generally arise as the culmination of many bad decisions strung together over time.
Large software implementations typically involve three parties: the customer, the software vendor, and the consulting services supplier. Considering this complexity, and the sometimes-conflicting agendas that result, the high rate of IT project failures becomes less surprising.
Social media and IT failure
To the extent social media improves an organization’s communication and decision-making abilities, it will also improve project success rates. Social media is not a magic bullet, but represents an organization’s commitment to streamline communication, share knowledge, and work more effectively as a team. These are characteristics of both healthy organizations and successful IT projects.
Shelfware and social media
[M]erely making software available does not mean users will actually adopt it.
More significantly, an organization must define “rules of engagement” that encourage users to embed social media in their day-to-day work. From this perspective, planning the diffusion of social media through an organization is little different from planning a traditional enterprise software implementation. Without proper change management, training, documentation and so on, social media becomes yet another under-utilized tool sitting on a server. The annals of IT failures are filled with cases of software that was purchased, deployed, and never fully used. Social media is not immune.
Coordinated deployments of social media across a large enterprise look and behave like any other enterprise software implementation. In both cases, IT and the business are essential partners in making the deployment successful. As with IT failures in general, the success of social media deployments depend more on human, rather than technical, systems and planning.
Social media and centralized IT power
Social media puts power into the hands of individuals and that power ultimately comes at the expense of centralized IT departments.
Strategic business computing decisions, including social media issues, should reflect the involvement of three groups: end-users, business management, and technical management.
To the extent that social media programs are business-based, meaning their core function is providing non-technical benefits to users, then sponsorship should lie in the business domain. In this respect, social media is a business initiative like any other, and should be treated as such.
On the other hand, if IT tries to interfere with new methods of communication between enterprise groups, then it will be doomed to fail. There’s virtue in going with the flow, especially when the flow is inevitable. It should be a partner in helping the enterprise adopt improved tools and work processes. For IT to succeed, it must engage users in dialog and support their desire to improve communications and information sharing.
IT / Business alignment
It’s time for IT to leave the ivory tower and become part of the decision-making culture of the business. The entire notion of IT as being somehow separate, or having independent goals from, the non-technical parts of an enterprise is absolutely ridiculous.
I don’t want to paint this as being entirely the fault of IT – many senior business executives don’t fully understand how IT processes function, nor do they completely grasp the ramifications that technical decisions can have on non-technical business strategies.
March 6th, 2008
Can project portfolio management prevent IT train wrecks?
Project portfolio management (PPM) vendors promise to help customers juggle competing investment priorities, reduce IT failures, and improve alignment between technology and their business. Given these impressive benefits, it’s worth examining what’s required to successfully implement PPM. To learn more about the issues, I attended a PPM briefing by HP.
Dennis Gaughan, Research Director at AMR and one of the HP presenters, is an expert on the PPM market. In an interview, he described PPM success factors:
PPM deployments are no different from any other transformational exercise which is driven from the top down. The CIO must be the executive champion for these deployments. It’s also important to establish a PMO, so you have a centralized point for aggregation of data and control.
When implementing PPM, start with the question, “How good are you at delivering today?” To gain business support, IT must demonstrate it is capable of delivering and executing IT project successfully. Credibility with the business is a key issue. If you haven’t had a good track record delivering from an IT perspective, it will be hard to get the level of business commitment required to be successful with PPM.
Dennis offered advice for making PPM implementations successful:
- Conduct a project inventory, to establish a baseline right from the start
- Work with internal business customers, to define the criteria used for evaluating project investments
- Ensure that basic IT execution skills, such as project management, are in place
- Involve finance, since IT must learn to translate business requirements, measures of return, and value into technology projects
- Measure benefits, after projects have been completed
As Dennis told me, many organizations overlook the importance of measuring benefits on a post-mortem basis:
PPM involves upfront standardization of criteria used for building business cases and metrics. However, people don’t always go back to evaluate and measure, after the fact, whether they realized those results. When used this way, PPM can measure overall IT effectiveness, in effect answering the question, “How good are we at delivering value from technology?” Instituting this discipline is the challenge.
I asked Jon Collins, Service Director at Freeform Dynamics, a UK-based analyst firm, and co-author of “The Technology Garden,” to comment on the intersection of IT and business with respect to PPM, especially from a project failures perspective:
Project portfolio management involves a number of activities, the most basic of which is “to get everything into one place.” That helicopter view onto a number of projects is a major step forward for a program manager, IT exec or CIO, as it is often the dependencies between projects that cause failure; equally – and we have all seen this happen – projects may continue long after the initial requirement has changed, or even gone away.
To be successful, PPM requires someone who is actually capable of collating the right information and interpreting it in a way that enables a good steer through pitfalls of project implementation. Good program managers are hard to come by, but in my experience a high quality person at the helm can overcome poor organizational processes, whereas the best processes can fail if the person in charge doesn’t know how to steer the ship. One can become a slave to project metrics.
Here’s a relevant quote, included in our book, from Darin Brumby, CIO at First Group: “In my portfolio I have 220 projects . . . Sure, I’d like Utopian projects which all finish on time and to budget, all highly successful deployments with great post-implementation reviews. In reality I would be happy if just 80% of those just moved along, and were completed. Even if they were just 80% right, I would be happy because the amount of distance that would move this company forward against its competitors in this sector would be enormous.”
THE PROJECT FAILURES ANALYSIS
Despite PPM’s clear benefits, it’s neither a panacea nor is it appropriate for every organization. Before implementing any PPM system, ask yourself three questions (and be honest when you answer):
- Is my organization committed to treating IT as a true business function (as opposed to a purely technical operation)?
- Are the technology and business folks ready, willing, and able to engage in serious, respectful dialog?
- Is IT willing to subject itself to the same measurement scrutiny that other parts of the organization routinely face?
If you answered “yes” to these questions, PPM may be a great vehicle for building real partnership between the technology and business sides of your enterprise. If you answered “no,” then perhaps it’s time for your organization to take a look in its collective mirror and make some changes.
February 13th, 2008
NakedIT: JP Rangaswami says, ‘Don’t call them IT projects’
The Naked IT interview series talks with innovators about the evolving relationship between IT and business. Please listen to the audio podcast and enjoy the brief excerpts below.
JP Rangaswami is Managing Director of Service Design at BT Design, which has total responsibility for designing, building and implementing the IT and business processes, systems, networks (non-Openreach) and technologies for BT, the huge British telecom. A Fellow of both the Royal Society of the Arts and the British Computer Society, JP’s career has spanned thirty years. Dan Farber, ZDNet’s editor in chief, has called him “one of the smartest people in IT.” He’s a prolific blogger and is active on various social networks, including Twitter, where we met.
In this interview, JP describes the challenges and opportunities associated with transforming BT from a traditional telco into a modern, customer service-oriented organization. The podcast offers a fascinating glimpse inside the mind of an innovative and experienced CIO, so please listen, learn, and enjoy.
On transforming BT into a customer-centric organization:
The first transformation was understanding we were not going to be able to survive in the traditional telco model….[W]e understood that the only way to deliver transformation to the customer was to focus on metrics that were only about the customer and nothing else….[N]obody associates telco with the phrase “customer service.”
Then came the challenge of breaking 100 years of history and bringing these departments together….[T]he building we were in used to house Marconi in 1905.
[I]n order to change our world, we had to change ourselves. [T]his kind of large-scale change has never been tried by any other comparable firm….Management recognized [there were entrenched systems] and was prepared to act. [T]he competition [was] watching us, because they knew we would be different if we could manage to pull it off.
We realized the silos, the tribalism, and the warring were actually systematic, because they reflected historical structures and realities. Changing [all this], and the way it was embedded in our culture, is not trivial.
We took the people in IT, networks, products, and processes, put them into one big pool, and threw away all our titles. The intention was to also throw away our old prejudices….so that when somebody called BT, they no longer had a buck to pass because there was no one to pass it to.
On BT as a business services provider:
[H]alf our revenues, nearly $20 billion, comes from services. We’re one of the world’s largest services companies, but it’s almost a secret….We are in the business of doing the things the customer needs done, but doesn’t want to do.
On the IT / business divide:
[Projects] will fail unless all dimensions of the project — the human elements, the commercial elements, the business elements, the architectural elements — are resolved. Crudely, one could say, IT projects fail initially on nomenclature because they’re called IT projects. To me, it’s as ludicrous as saying male childbirth. A project exists in order to create some transformation, some business outcome, and if there isn’t a business component to the project it should be strangled at birth.
The idea that you could take a critical function within an enterprise and state that it is “not business” is insane….[E]verybody and everything should be about creating new business value on behalf of the customer.
[W]e have conned ourselves into believing there are separations to justify organization charts where people build empires, when actually you [should] have a bunch of people taking accountability for different facets of the business.
[W]e have to get to the idea that we’re all in this together, because we are in business together, and we are in the business of delivering value to our customers.
On IT project failures:
First and foremost, we have to manage better communication….Project failure and success seem to depend on saying, “Are you able to accurately articulate and collect what the requirements are?” and “Are you able to express the right estimates?”…. Too many times, the collection process is weak, because the customer is not easily able to articulate [his needs] in language the people [on the project] understand. [S]oftware estimation is not a trivial exercise; it is still an art rather than a science.
[F]ailure is usually a characteristic of unwillingness to recognize change and to cover up….It’s like a salesman putting forth a forecast to management…without ever talking to the customer. Management [is] blissfully unaware of the fact that the information is false.
February 11th, 2008
Customer blames bankruptcy on IBM IT failure
American LaFrance (ALF), the “leading brand of custom-made fire fighting, fire rescue vehicles, ambulances, and heavy-duty work refuse vehicles,” has declared bankruptcy, blaming IBM and a failed ERP implementation.
According to filings in the District of Delaware bankruptcy court (PACER case no. 08-10178), problems occurred when ALF was spun out as an independent company from Freightliner, the previous owner. During the transition, ALF outsourced “accounting, inventory, payroll, and manufacturing process services” to Freightliner. As part of the transition, ALF developed a “standalone” ERP system designed to support the firm after the Freightliner separation was completed.
The bankruptcy filings describe the painful cutover from Freightliner:
Almost immediately upon the changeover to the ERP System, ALF recognized serious deficiencies with the system that had a crippling impact on ALF’s operations. Some of the problems that ALF encountered in implementing the ERP System included, among others: (i) inability to reconcile data between the Freightliner system and the ERP System; (ii) incorrect or incomplete inventory, purchasing and customer data due to either problems with the Freightliner system or the conversion of the data to the ERP System; (iii) inaccurate or incomplete vehicle configurations loaded in the ERP System; (iv) insufficient training on the ERP System; and (v) missing financial information including accounts payable detail, incomplete or inaccurate accounts receivable data, and inaccurate beginning general ledger balances.
For the next several months following the changeover, ALF attempted to solve the plethora of problems with the ERP system. Despite such efforts, as a direct result of the problems with the ERP System, ALF became unable to complete the manufacture of many pre-ordered vehicles.
The manufacture of highly-customized Emergency Vehicles requires the availability of a large number of inventory SKUs at key points in the production process. The conversion from the Freightliner system to the ERP System resulted in the inability to account for inventory on a reliable basis. This, in turn, severely limited ALF’s ability to deliver completed products to its customers. Consequently, ALF’s inability to deliver vehicles had an immediate impact on ALF’s cash flow and created a liquidity crisis.
ALF claims that IBM is responsible for the IT problems that precipitated the bankruptcy:
ALF is currently analyzing potential causes of action against IBM based upon services provided by IBM in connection with the problem-riddled transition to the ERP System.
The documents describe IBM Corp. (for the “customer agreement”) and IBM Global Services (for “systems applications project assistance”) as having open contracts with ALF. IBM is listed as a $5.5 million creditor, although ALF disputes the invoices:
THE PROJECT FAILURES ANALYSIS
In my reading of the documents, which only present ALF’s side of the story, it could be said that both ALF and IBM dropped the ball during the transition from Freightliner. Here are my conclusions:
- IBM did not manage the project properly. Given ALF’s dependence on Freightliner, “serious deficiencies” in production software should have been identified prior to the cutover, for example by testing and running the systems in parallel. IBM managed development, which typically includes extensive testing before deployment.
- ALF did not manage the project properly. IBM’s role does not minimize ALF’s ultimate responsibility for managing this mission-critical IT project. ALF’s management was probably distracted by the deteriorating Freightliner relationship, by a major facilities relocation that didn’t go well, and by generally poor market conditions.
- The ERP problems were managerial, not technical, in nature. The list of ERP and data problems cited in the filings suggest poor project management, rather than technical issues, were at the root of the difficulties. Since the division of labor between ALF and IBM is not made clear in the filings, it’s impossible to discern where responsibility lies.
- General market conditions made things worse. While all this was happening, the market for ALF’s products tanked:
[T]he Emergency Vehicle industry is currently depressed. Many competitive manufacturers are experiencing financial difficulties and several have ceased operations.
- All these issues created customer service problems, multiplying the negative effects of the market downturn. For example, the Bellingham Herald reported:
The city is trying to get a refund of the more than $362,000 it spent on an American LaFrance pumper that has had electrical problems 10 times [since 2005].
- In addition, FireRescue1, an industry news source, states:
Several departments that have ordered apparatus have suffered lengthy delays in delivery.
“I think one of their problems may have been that they underestimated the problems with moving a plant and production and actively pursuing business for new apparatus,” [Bill Peters, who runs New Jersey-based Fire Apparatus Consulting Services] said.
“Perhaps they bit off more than they could chew, especially with the building of a new factory. It might have been wise not to take as many orders and not to have backed themselves up so much.”
This risky, high stakes project was primarily business in nature, despite the heavily technical components. Project failures often arise when non-technical senior management don’t fully understand the business ramifications of technical decisions made by IT. Poor communication and lack of understanding between IT and business management remains a serious problem contributing to many IT failures. My ongoing interview series, NakedIT: Conversations with Innovators, explores this issue in depth.
The combination of so many negative conditions ultimately created a situation where the company could not recover, leading to the bankruptcy. ALF was founded in 1832, so it’s a shame to see this happen. Unfortunately, many of ALF’s vendors will probably suffer as the company goes through bankruptcy.
(To research this post, I studied the bankruptcy documents, left messages for ALF’s proposed Chief Restructuring Officer and its IT manager, spoke with two attorneys connected with the case, and got unpleasantly barked at by a third. All facts, conclusions, and interpretations in this post are based on information obtained from publicly-available filings.)
Update 2/22/08: IBM ignored a request for comment on the story. Larry Dignan wrote a great follow-on post.
Michael Krigsman is CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures. See his full profile and disclosure of his industry affiliations.
Recent Entries
- Let’s meet in Berlin
- 10 attributes of bad CIOs (self test)
- UK gov’t releases transparent post-failure analysis
- Feedburner is down
- EDS’ troubled legacy of failed IT projects
Most Popular Posts
- 10 reasons for IT failure
- IT politics killed White House email project
- CNBC: SAP America's president should offer media training
- Government IT failures: "Room for improvement" [interview and podcast]
- Volvo recall due to airbag software problems
- SAP's CTO: Business knows 'what', IT knows 'how'
Top Rated
- FBI: Counterfeit Cisco routers risk "IT subversion"+26 votes
- 10 reasons for IT failure+14 votes
- 8 tips to avoid being an IT scapegoat+6 votes
- EDS' troubled legacy of failed IT projects+5 votes
- Social media and enterprise power relationships+4 votes
- Hosted software development: an emerging market [includes podcast]+4 votes
- 10 attributes of bad CIOs (self test)+3 votes
- Salesforce.com's bold development platform vision [includes executive podcast]+3 votes
