October 27th, 2008

Agile: Anatomy of a failed project

Posted by Michael Krigsman @ 12:57 pm

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

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 »

July 23rd, 2008

Delivering nada. Zip. Zilch. Zero.

Posted by Michael Krigsman @ 6:11 am

Categories: Project management, IT issues, CIO issues

Tags: Team, Performance, Problem, Bruce Webster, FUBAR, Team Management, Organizational Structure, Management, Human Resources, Michael Krigsman

The aftermath of large-scale failure is never pretty, but sometimes looking back reveals problems so obvious and severe they take your breath away.

Bruce Webster’s blog describes a large project where a major consulting company failed to deliver anything:

The project in question was a major IT re-engineering effort for a mission-critical system; at the time I did this review, the project had been going on for several years and had cost millions of dollars; it would eventually be canceled and the work products abandoned.

Here’s an excerpt from Bruce’s outstanding post-mortem (he redacted the names):

Quality of work and effort: Several consultants said — and the rest pretty much agreed — that far too many of the deliverables, artifacts, and activities (e.g., algorithms, source code, system configuration, design/architecture documents, testing, defect tracking, scheduling etc.) are substantially below any acceptable professional standards and represent a profound threat to FUBAR ever going into production.

Project planning and execution: Project planning and execution is all to often poor or missing completely. Milestone dates, usually unrealistic if not impossible, are based on political considerations or wishful thinking, not bottom-up grounding.

Quality assurance and process: Quality assurance appears to be low-priority concept within the FUBAR project. In the opinion of several consultants, the current person in charge of it is not particularly strong or competent. There appears to be a systemic inability to establish good testing criteria and methods to gauge FUBAR’s progress toward production.

Architecture: FUBAR doesn’t have a viable, consistent architecture. The irony is that FUBAR itself is not a big, complex problem; it is a relatively straightforward problem that has been made big, complex, and possibly unsolvable in the current implementation.

Application performance: FUBAR was never properly architected and designed for the performance required. There is a current effort to increase performance after the fact, but the implementation makes that impossible.

Staffing: Many of the people involved in FUBAR — developers, testers, team leads, managers — lack the qualifications, insight, or experience to make FUBAR a success. The project is overstaffed for the actual complexity of FUBAR, possibly for political reasons (i.e., promotion/stature based on the number of people supervised).

[BrandName team management approach] principles: Mid-level management tells the developers that mood, sincerity, and commitment are everything, and that with them “we can accomplish anything.” At the same time, the principle of granting sincerity appears to be used to justify a lack of accountability and consequences.

Intellectual honesty: Managers reject or explain away bad news and real problems, looking instead for people who will tell them what they want to hear.

Closing remarks: [T]here are some profound problems and flaws with the FUBAR project that will not go away until the project team acknowledges and addresses them. Indeed, it will be hard enough to make them go away even then.

Draw your own conclusions, but I don’t think these problems are uncommon. Sure, this case is more severe than most, but the basics happen all the time.

Combining organizational hubris and over-reaching personal ambition with vendor incompetance is a definite prescription for failure.

[Image via FreeFoto.com]

June 19th, 2008

IT catfight in Portland, OR

Posted by Michael Krigsman @ 5:39 am

Categories: Vendor relationships, Project failures, Government projects, Project management, Implementation, IT issues, Project strategy, CIO issues, Consulting, SAP

Tags: City, Financial, Information Technology, Portland, SAP AG, Financial Accounting, Finance, Michael Krigsman

Portland, Oregon’s late and over-budget ERP implementation has become a battleground between city officials and system integrator Ariston Consulting & Technologies. As the failing project’s budget ballooned from $31 million to $49.45 million, finger-pointing and mutual blame have obscured faults on both sides.

Background. According to a February, 2004 report by Portland’s Financial Reporting and Compliance Project, the city faced numerous system-related challenges:

[T]the City has developed a number of separate, and in some cases duplicative, systems that limit the free flow of financial data and information and the ability to share knowledge and training opportunities among accounting staff across bureau lines. In the absence of a more robust or fully featured centralized financial information system this approach, while serving individual bureau needs, limits the ability to achieve higher levels of productivity and efficiency citywide. In order to improve services and reduce costs, this approach to technology tools and investment will need to change.

In plain English, the old financial systems were so bad that employees across the city developed their own ad hoc tools on a workaround basis. Computerworld interviewed Mark Greinke, Portland’s chief technology officer:

Because it was hard to add new components to that application, “shadow systems” were created by various city departments to add needed features that weren’t tied directly into the main legacy application. What that created, he said, was a diverse IT system made up of single Microsoft Access database files, single Microsoft Excel spreadsheet files and more that weren’t connected in a useful way. The new IT infrastructure is being created to tie all of that data together in a unified system, he said.

Proposed solution. To solve these problems and create an integrated city-wide financial reporting tool, Portland decided to replace it’s old IBM mainframe with a web-based ERP solution from SAP. It appears the city purchased the software from SAP but engaged Ariston to provide implementation services. (Neither SAP nor Ariston responded to requests for comment on this post.)

Problem description. Last December, a third-party reviewer found Ariston’s project plan lacking. From The Oregonian:

[A] consultant hired to do regular quality control updates told city managers that Ariston was working too slowly and that the city and the contractor lacked the kind of detailed plan necessary to get the new system working on time.

A payroll system test last December produced unexpected and incorrect results, causing the city to terminate Ariston and hire SAP to provide consulting services needed to complete the project.

THE PROJECT FAILURES ANALYSIS

This case highlights the oft-repeated assertion that projects live or die based on management and planning rather than technology. The SAP Watch blog explicitly gives a clean bill of health to the technology:

It isn’t clear who’s to blame for the cost overrun and project delay, but Portland and Ariston will no doubt implicate each other in time. The soundness of the underlying SAP software itself has not been questioned by either party.

Mutual blame game. In my view, both Ariston and Portland underestimated the project’s complexity from the start. In a rather naive approach toward public relations, each side has publicly blamed the other.

Portland’s chief administrative officer, Ken Rust, blasted Ariston (emphasis added below):

Ariston, a 30-person firm, did not show the kind of guidance city leaders needed.

“No one in city government had ever installed a system like this before,” Rust said. “We hired a consulting firm to lead us through the process. Instead, we saw a complete lack of leadership.”

Rust said there’s little city administrators could have done differently. Ariston had good references and a successful track record. The only red flag city leaders might have noticed, he said, is that Ariston had never led a project this large and complicated.

These comments demonstrate the city’s inexperience and lack of insight. I find it disingenuous for Rust to claim the city had no responsibility, despite selecting a vendor that clearly didn’t possess the requisite experience.

Ariston responded in kind:

Ariston’s president referred questions to Stoll, the Portland lawyer, who noted that Ariston has handled several large government contracts. He suggested that Portland administrators did not realize how complicated the job was.

“Frankly, there are a lot of silos within the city,” he said. “When you try to go from the silo system to one overall system, and nobody has looked at how they integrate and whether they even can integrate and what it’s going to cost to integrate them, it’s very difficult for a consultant to come in and be successful.”

Ariston continued (emphasis added below):

From Ariston’s point of view, [Stoll] said, city officials who prepared the project requirements and put it out for bid weren’t familiar enough with their overall IT systems and needs, making the goal for the work an impossible target to hit. “It’s sort of garbage in, garbage out, if you know what I mean. I certainly don’t think that Ariston made any mistakes.“

Portland’s systems are genuinely complex. For example, the city must consider 16 different labor contracts when calculating payroll. This complexity was not clear to either Ariston or city officials during the project planning phases. As a result, both parties entered an agreement ultimately doomed to fail.

My take. The city didn’t provide sufficient direction to Ariston regarding project goals and requirements, and Ariston accepted a poorly defined contract that went beyond the company’s capacity to execute.

This project was doomed from the start and affirms my belief that many IT failures arise at the intersection of greed, arrogance, and inexperience.

June 18th, 2008

15 non-technical reasons IT projects fail

Posted by Michael Krigsman @ 7:28 am

Categories: Project management, IT issues, CIO issues, Research and statistics

Tags: Information Technology, Strategy, Management, Michael Krigsman

A study of IT “abandonment” reported by the British Computer Society (BCS) reinforces the notion that IT projects fail primarily for non-technical causes. Such quantitative research is important in helping managers understand the business, organizational, political, and cultural dimensions behind failed projects.

Here’s the BCS list of “key reasons why projects get canceled:”

1. Business reasons for project failure
2. Business strategy superseded
3. Business processes change (poor alignment)
4. Poor requirements management
5. Business benefits not clearly communicated or overstated
6. Failure of parent company to deliver
7. Governance issues within the contract
8. Higher cost of capital
9. Inability to provide investment capital
10. Inappropriate disaster recovery
11. Misuse of financial resources
12. Overspends in excess of agreed budgets
13. Poor project board composition
14. Take-over of client firm
15. Too big a project portfolio

This list is all about management, focus, and planning. IT projects also collapse when stakeholders and participants don’t properly manage time, scope, and costs (considered the triple constraints of project management).

Reinforcing this point, the BCS article adds:

Our evidence suggests that the culture within many organisation’s is often such that leadership, stakeholder and risk management issues are not factored into projects early on and in many instances cannot formally be written down for political reasons….

Leadership and cultural issues are hard to measure and quantify, so many organizations simply ignore these most common sources of IT failure. Given this, it’s not surprising the sinking ship of high IT failure rates continues to plague business.

June 5th, 2008

Leaked Pentagon doc slams Lockheed

Posted by Michael Krigsman @ 7:59 am

Categories: Project failures, Government projects, Project management, CIO issues, Project portfolio management, Politics

Tags: Lockheed Martin Corp., Pentagon, Project Management, Tools & Techniques, Performance Management, Strategy, Productivity, Mergers & Acquisitions, It Operations, It service Management

A leaked Pentagon report said Lockheed Martin, the world’s largest defense contractor, failed to “provide the requisite definition and discipline to properly plan and control complex, multi-billion dollar weapon systems acquisition programs.” This allegation casts doubt on Lockheed’s ability to manage large programs, including major IT initiatives, successfully.

The Defense Contract Management Agency found Lockheed “to be non-compliant in 19 of 32 industry guidelines” related to the Earned Value Management System (EVMS), a method for managing government projects. As fellow ZDNet colleague, Richard Koman, reported, the Office of Management and Budget (OMB) has mandated EVM for large IT projects.

From the report:

Significant findings, resulting in lack of planning and control disciplines include:

• Using vague and confusing EVMS documentation;
• Lack of clearly delineated roles and responsibilities; Using management reserve to alter internal and subcontract performance levels and overruns;
• Work authorization and change control processes that do not extend to appropriate levels;
• Cost and schedule integration problems that undermine the validity of data;
• Inappropriate earned value techniques used for the assessment of material, subcontracts, and rework; and
• The inability of LM-Aero CAMs to demonstrate a working level understanding of key EVMS processes including the definition and use of a program critical path, situational awareness of cost and schedule variances for course correction, and the substantiation of completion cost estimates.

The Wall Street Journal added:

The Pentagon’s Defense Contract Management Agency, according to part of a report obtained by watchdog group Project On Government Oversight, found problems with how Lockheed used software to manage supplier costs on its fighter contracts, which hurt the ability to foresee overruns. “We have worked closely with the DCMA team since November, resulting in an approved corrective action plan,” Lockheed said in a statement.

In an email exchange with the Journal’s reporter, August Cole, he clarified the article: “the report describes problems with how the EVMS was used, not implementation or technical issues.”

THE PROJECT FAILURES ANALYSIS

Earned Value Management is an important tool for controlling costs and managing work on large projects. I asked Gil Digioia and Jose Mora, project portfolio management (PPM) folks from CA, about the importance of the EVMS in federal IT:

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.

It’s inexcusable for a large contractor such as Lockheed to fail on so many dimensions of program management. Nick Schwellenbach, national security investigator for the Project on Government Oversight, which obtained the document, remarked:

We can’t continue to trust Lockheed with billions of taxpayer dollars or we’ll end up with less bang for more bucks. Affecting Lockheed’s bottom-line is the only thing that can cause them to clean up their act.

This sentiment absolutely has the ring of truth. With vast resources at its disposal, Lockheed should be the poster child for careful project management rather than a symbol of incompetence, greed, and waste. It’s time for a government inquiry to uncover the truth.

May 28th, 2008

Research: 25 percent of web projects fail

Posted by Michael Krigsman @ 6:50 am

Categories: Project management, Project strategy, Research and statistics

Tags: Web, Web Development, Web Project, Channel Management, Marketing, Michael Krigsman

Over 30 percent of web development teams deliver projects late or over-budget, according to a survey commissioned by Ruby development shop, New Bamboo. These findings are consistent with studies of larger IT initiatives showing failure rates of 30%-70%.

According to the report:

• Nearly a quarter of website projects fail to be delivered within budget (24%) and 5% were unable to confirm the final cost of their web development project
• 21% fail to meet stakeholder requirements
• Nearly a third of web based projects (31%) were not delivered within the agreed timescales
• Three elements that cause web project failures First there are too many changing requirements (55%) Too many stake holders to please (48%) Not enough budget or time to deliver (31%)
• Nearly half of basic web based projects continue to be built
  in-house; with 28% are outsourced to third parties

The study describes three reasons for this high failure rate:

1. Changing requirements
2. Inconsistent stakeholder demands
3. Insufficient time or budget

THE PROJECT FAILURES ANALYSIS

It’s unusual to see a survey covering web projects rather than enterprise software deployments. Although there are substantial differences between web projects and large software rollouts, the underlying drivers of failure are similar in both cases.

Multiple project stakeholders and organizational objectives often guarantee project environments that include changing demands and inconsistent agendas. Failure is almost inevitable when management allows ambiguous objectives to persist after a project starts. Unfortunately, many organizations allow their web projects to become complicated by unclear focus, a dubious business case, and inconsistent goals.

To resolve these issues, Damien Tanner, co-founder of New Bamboo, suggests:

Taking a collaborative and iterative approach to web project development, with all stakeholders sharing ownership of the project, and ensuring that the expectations of the business and the final product are aligned. This approach involves regular meetings with all stakeholders where working software is tested and a certain amount of QA is carried out, which not only keeps the project on course for success but also ensures that mistakes are rectified early on.

I encourage other vendors and interested parties to conduct additional web development studies, emphasizing the dynamics of failure within smaller teams.

May 2nd, 2008

Sleazy sales and the Rockwell Retro Encabulator

Posted by Michael Krigsman @ 1:32 pm

Categories: Vendor relationships, IT issues, CIO issues

Tags: Rockwell, Sales Strategy, Sales Force Management, Corporate Communications, Sales, Marketing, Michael Krigsman

Many project failures can be traced to a vendor making outlandish claims which the customer accepts hook, line, and sinker. In these situations hope, greed, fear, inexperience, and denial come together as ingredients for a spectacular flame-out.

With that mind, take a look at this sales pitch for the Rockwell Retro Encabulator. Now tell the truth, did you believe the pitchman in the video? It’s amazing how even the most unvarnished nonsense can be delivered with such conviction.

April 12th, 2008

Absolutely amazing: Integrator completes ERP project on-time

Posted by Michael Krigsman @ 5:17 pm

Categories: Vendor relationships, Project management, Implementation, IT issues, CIO issues, Consulting, Project success, SAP

Tags: ERP, Consulting, Outsourcing, It Operations, Business Operations, Outsourcing & Subcontracting, Michael Krigsman

CIBER (NYSE: CBR), a system integrator, completed an SAP implementation on-time and within budget. This amazing accomplishment must be extraordinary news because the company released a press release specifically to alert the media.

I interpret the press release as an indictment of CIBER and the entire implementation consulting industry. This business is so failure-centric that success seems an aberration worthy of media attention.

THE PROJECT FAILURES ANALYSIS

The solution to late and over-budget projects is harshly aligning consulting compensation and incentives directly with the interests of the customer. I recommend that enterprise software customers create vendor penalties that kick in when projects are not completed on-time or within budget.

Consulting companies may claim that’s not fair because so many variables lie on the customer and software vendor sides. My response: deal with it by planning more carefully. If you can’t plan a project successfully then get out of the business.

At the same time, IT services customers must learn to be responsible and intelligent consumers. Get multiple bids and don’t rely only on low cost as your selection criteria; as a wise man once said, “buy cheap, get cheap.” Most important to ensuring IT project success is binding services vendors into the agreed-upon schedule and budget; that’s called skin in the game.

For more information on fake promises of trust and consulting compensation, see: Consulting’s dirty little secret.

These are complicated issues, so please leave comments with your views on managing vendor / client technology services relationships.

March 9th, 2008

Sleazy analysts and corporate weasels

Posted by Michael Krigsman @ 10:02 pm

Categories: Vendor relationships, CIO issues, Consulting

Tags: Analyst, Blog, Business Ethics, Blogging, Leadership, Management, Internet, Michael Krigsman

IT buyers look to industry analysts for wisdom in understanding the past, counsel in handling the present, and advice when future plans go awry. Unfortunately, this symbiotic relationship between analysts and their corporate masters can include a complicated mix of mutual respect and fear, punctuated by greed and need on both sides.

The Institute of Industry Analyst Relations recently blogged about analyst ethics:

Any analyst firm which values its long-term reputation in the market has to ensure that its research is independent….

However we do need to be realistic about the economics of the analyst business. Most analyst firms couldn’t exist without vendor cash - be it via sponsored research, consulting projects or speaking engagements.

And so long as analyst firms clearly communicate who is sponsoring their work, I’m fine with that.

The blog raises questionable analyst practices such as the following:

• the analyst that writes blog posts promoting a project that his consultancy is involved in - without disclosing his connection
• the division of a large group that prioritizes briefings based on the likelihood of selling reprints of the resulting company profile
• the analysts that use a briefing as an opportunity to pitch their own services

THE PROJECT FAILURES ANALYSIS

Analysts can achieve transparency, and neutralize many ethics violations and conflicts of interest, by fully and completely disclosing their affiliations. Unfortunately, such disclosure is not always forthcoming, and some analysts use lack of transparency as a tool to mislead clients and the unsuspecting public with so-called “objective” research that has in fact been compromised.

Ethical lapses also occur among the corporations that engage analysts, some of whom use their buying power as a lever to manipulate undue influence over research and reports. Using the promise of large fees and ongoing retainers, these corporate weasels subtly encourage analysts to bias their recommendations to the sponsor’s advantage. Again, unsuspecting readers are wrongly led to believe the analyst’s report and conclusions are unbiased.

The best analysts skillfully manage these conflicts and tensions without compromising either their integrity or their work. For example, Jon Collins, of Freeform Dynamics, told me that analysts who pitch their own services at briefings are “unsavory and unproductive.” He wrote that’s it’s “difficult to be both transparent and unethical.” Similarly, James Governor, of Redmonk, blogged “You Can Buy Our Thinking But You Can’t Buy Our Opinion.”

The bottom line: When talking with analysts, remain alert to potential conflicts of interest and ethical gaps. Ask about their affiliations, demand full disclosure, and walk away if you don’t get satisfactory answers. The best analysts will welcome your questions and withstand your scrutiny; the others aren’t worth your time or money.

Update 3/10/08: Changed the title to better reflect the content.

January 20th, 2008

Update: Philadelphia’s water project actually finished

Posted by Michael Krigsman @ 3:50 pm

Categories: Vendor relationships, Project failures, Government projects, IT issues, CIO issues, Project success, Oracle

Tags: Philadelphia, Oracle Corp., Corporate Governance, Sales Channel, Customer Relationship Management (CRM), Leadership, Business Operations, Corporate Law, Sales, Enterprise Software

Philadelphia has finally finished it’s ill-fated water utility billing system, called Project Ocean. Following a series of high-profile failures, with costs that approaching $47 million, the final phase was complete on-time and under-budget.

To complete the project, Philadelphia dumped most of its planned Oracle applications, and went with off the shelf software from Prophecy International PTY in Adelaide, Australia. According to Computerworld:

Project Ocean started in 2002 with Oracle on board, but work was stopped in October 2005 after the city spent $18.9 million, twice what it expected to spend. The city signed an amendment to Oracle’s contract in which Oracle agreed to pay or forgive $6.9 million of those costs to fund the revived Project Ocean.

Philadelphia’ CIO, Terry Phillis, said he learned that:

“[T]echnology is not the prime concern in being successful in a project of this size.” Instead, he said, success is a matter of “process, collaboration and leadership,” although he said it is obvious that “the technology has to work and it has to match your skill sets.”

A year ago, he said, “we had to spend a lot of time upfront deciding how to run this and how to collaborate between three departments.”

Huh? The CIO of a major US city, overseeing a budget of millions of dollars, has only now learned that technology isn’t the primary driver of IT success and failure? Shaking my head in disbelief as I write this.