IT Projects: Expert Witness, CIO, In-House Counsel & Litigation Forum

SAP Makes A Dramatic Move:

We need a score card nowadays to keep track of the re-organizing of Tech biz companies - and the moves being made by top executives - its like a very intense game of  musical chairs, and the prizes for the winners are stupendous.  Right now the tech world's big businesses could be the new template for the classic Abbot and Costello routine - but what could we call it... "Who's On Google, What's On Apple, and Nobody's on Yahoo?             Marlene

Ex-Oracle Exec John Wookey To Head Up SAP’s New On-Demand Market Effort

http://blogs.zdnet.com/Greenbaum/?p=189

Previously appeared on November 11, 2008 posted by Joshua Greenbaum

It’s hard to know which was more significant, the announcement that SAP is going to tackle on demand at the top of its market, or the name of the person – former Oracle apps exec John Wookey – who was picked to lead the effort. Off the top of my head, I’d say it’s a draw: an almost amazing segue into a new, and very challenging market, and an amazing pick to head up the effort.

John won’t lack for challenges in his new job, the title of which is executive vice president for large enterprise on-demand. Having lead Oracle’s efforts to rationalize its ever-growing, and increasingly heterogeneous acquisitions until he abruptly left last year, John has some experience in accomplishing what looks almost impossible to do.

10 tech leaders who could become Obama’s CTO

Previously appeared on November 10th, 2008 posted by Jason Hiner http://blogs.techrepublic.com.com/hiner/?p=850&tag=nl.e019

As a presidential candidate, part of Barack Obama’s technology policy platform included hiring the U.S. government’s first chief technology officer (CTO). If Obama follows through on this, who is likely to get the job? Here are 10 top candidates.

During his presidential campaign, Barack Obama used technology to organize, communicate, and raise funds in innovative ways that gave him an advantage over opponents in both the primaries and the general election. It’s clear that Obama views tech as a powerful catalyst, and with the U.S. facing an unprecedented array of economic challenges, Obama will need to use technology to drive efficiency and institutional transformation.

A part of his policy platform, Obama has stated that he plans to hire the nation’s first chief technology officer (CTO) to play quarterback in driving these changes. A CTO is typically an organization’s top engineer and focuses on outward-facing technologies (see What’s the difference between CIO and CTO) but based on Obama’s policy statements he wants to use the national CTO position to:

• Build a 21st centrury technology infrastructure

• Unite and lead the CIOs and CTOs of various federal agencies

• Architect innovative tech solutions to help solve big problems.  

As a result, Obama is going to need a visionary tech leader who can rally both technologists and standard Washngton bureacrats around a common purpose. It also wouldn’t hurt to bring in a big name — someone who already has a strong reputation that will translate into political capital.

Here are top 10 candidates.

10. Shai Agassi

This former technology head of SAP has the business experience and the interest in larger societal issues to do well as America ’s CTO. However, he’s recently founded his own company,Better Place, to create an entirely new business model and power system to run the electric cars of the future. Because of his passion for that project, it’s doubtful he would want the U.S. CTO gig.

Former IBM exec blocked from running iPod, iPhone engineering teams

Previously appeared on Nov 9, 2008
Posted by Gregg Keizer

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9119643&intsrc=hm_list

November 9, 2008 (Computerworld) A federal judge on Friday ordered a former IBM executive who was recently hired by Apple, Inc. to stop working for the company, court documents showed. U.S. District Court Judge Kenneth Karas ruled that Mark Papermaster, who was announced as Apple's new vice president of devices hardware engineering only last Tuesday, must "immediately cease his employment with Apple Inc. until further order of this court."

Karas did not explain his reasons for the order, saying only that he would issue an opinion at a later date. Friday's move was the result of an IBM motion for a preliminary injunction designed to block Papermaster's move to Apple. On Oct. 22, IBM sued Papermaster, claiming that a noncompetition agreement he signed in 2006 bars him from working for competitors for a year after leaving the company.

According to IBM, Papermaster had information of "highly confidential IBM trade secrets" that would "irreparably harm" the company if he's allowed to work for Apple. Apple hired Papermaster to run its iPod and iPhone engineering group. The same day that Apple announced Papermaster's hire, it also said that Tony Fadell, who has been credited with jump-starting the company's iPod business, was leaving his position as senior vice president in charge of the player, but would remain as an adviser to Jobs.

New Legal Finding Against SAP: 'Guilty by Reason of Customization

"If it walks like a duck and quacks like a duck..."
The Wisconsin Supreme Court ruling of July 11, 2008 discussed here in Byron's blog brought this old adage to mind.  My analogy to the packaged software issue  being something like the fabled ugly duckling that turned into the beautiful swan.  The swan's beauty and appeal required time for the "add ons" of its growth and maturity, while from the get-go, a duck is a functioning package, including flying as well as swimming, albeit not offering the aesthetics of a swan.  What, if any, import could this ruling have in litigation involving  failed software projects?  Any  thoughts?
Marlene Palmer, Consultant, WSR Consulting Group LLC

http://www.itbusinessedge.com/blogs/den/?p=132
Posted by  Dennis Byron on August 4, 2008

In the dog days of August here on Cape Cod, it’s harder to find something to write about regarding enterprise software on a daily basis than it is to actually write it. It’s summertime and the living is easy, blah blah blah. But not for bloggers.

My choices looked pretty bleak this morning as I scoured the Web for news over the last few weeks while I was on vacation. Let’s see: Write my umpteenth post about enterprise software being too expensive? Is enterprise software good or bad for open source? Or I could write that enterprise software is doomed by software as a service!

And then this story from Wisconsin popped up and hit me across the forehead with all the subtlety of a two-by-four at a stick-ball game.

IT careers in the 'cloud'

 

Time to retool again!  In today's ever changing IT world new skills are critical.  But where should you spend your time and hard-earned dollars?  In the 'Cloud'? Boning up on the hosted ERP services of the largest vendors?   How to write new algorithms for 'targeted internet ad marketing'?  How to improve your testing results?  How to make your software more successful?   Why don't you drop us a line with your experience and  recommendations as to where, and why, you will focus your on-going IT learning and education efforts.  Warren
 

By Thomas Hoffman, Aug 4, 2008 This article appeared in Computerworld's print edition. http://www.computerworld.com/action/article.do?
command=viewArticleBasic&articleId=322132&source=NLT_CAR&nlid=5

IT organizations that shift a good part of their IT infrastructure activities to hosted service providers over the next decade (see "Is Google your next data center?") will likely see profound changes in the makeup and skills of their remaining IT staffers.

"There's a limited number of resources in IT," notes John Dutra, CTO of Sun IT, a division of Sun Microsystems. "Wouldn't I want to focus them on the most strategic areas possible?"

101 Ways To Know Your Software Project Is Doomed

I thought this was a pretty good list.  I picked my favorite ten, presented below from the full list -- and that was harder to do than I first envisioned.

1. Management has renamed its Waterfall process to Agile Waterfall
2. Allocated QA time is for Q and A why your crap is broken
3. All of your requirements are written on a used cocktail napkin
4. Progress is now measured by the number of fixed bugs and not completed features
5. Every bug is prioritized as Critical (or Every Bug Is Trivial)
6. Your spouse only gets to see you on a webcam
7. The sales team decreased your estimates because they believe you can work faster
8. Budget for testing exists as “if we have time”
9. The client will only talk about the requirements after they receive a fixed estimation
10. Broken unit tests are deleted because they are obviously out of date

Taken from http://www.codesqueeze.com/101-ways-to-know-your-software-project-is-doomed/

Your part:  What favorites do you have that are not on this list or which ones on the lsit do you disagree with?   Warren (Note: Click below to see the full list.)

Sharing Information and Ourselves: Facebook Founder and CEO Mark Zuckerberg and COO Sheryl Sandberg

Here's another fun interview (highlights) from the 2008 D6 conference. Enjoy!  Warren

Wednesday, May 28, 2008 by John Paczkowski. See John's original post at:   http://d6.allthingsd.com/20080528/zuckerberg_sandberg/#more-64

Because Mark Zuckerberg is barely in his mid-20s, his résumé is a bit thinner than others here. Well, except for his first job as founder and CEO of Facebook, perhaps the most explosively popular social-networking company ever and the most high-profile Web 2.0 start-up. Mr. Zuckerberg created Facebook in 2004, while still an undergraduate at Harvard University, where he studied computer science. He brought the company to Silicon Valley before he had a chance to graduate from college, but managed to get a $15 billion valuation for the company anyway. 

Video: Bill Gates and Steve Ballmer Highlight Reel, Part Two

Even if you saw this in print in the Wall Street Journal, you'll want to share the fun with "Bill & Steve" in this video! Also see Part One of this interview on this blog.  Warren

Tuesday, May 27, 2008 originally posted at:  http://d6.allthingsd.com/category/bill-gates/

Here are a few video highlights from the second half of the D6 interview of Microsoft (MSFT) Chairman Bill Gates and CEO Steve Ballmer, conducted by conference co-hosts Kara Swisher and Walt Mossberg. (Click here for highlights from the first half of the interview.)

Video: Bill Gates and Steve Ballmer Highlight Reel, Part One

Even if you saw this in print in today's Wall Street Journal, watch this video. What sense do you get seeing them visually?   Warren

Here are a few video highlights from the first half of the D6 interview of Microsoft (MSFT) Chairman Bill Gates and CEO Steve Ballmer, conducted by conference co-hosts Kara Swisher and Walt Mossberg. (Click here for highlights from the second half of the interview.)

Posted at 11:22 PM PT;   Original story and video can be seen at:http://d6.allthingsd.com/category/bill-gates/

Be Mindful Of IT Workers' Age Groups

In most companies, the policies and practices used to motivate the workforce were established with older generations, the traditionalists and baby boomers, in mind. However, the mind-sets of the younger generations, Generation Xers and millennials, are markedly different. IT leaders need to craft the cultures of their organizations to ensure that all technology workers have the highest motivation levels.

Traditionalists, born between 1900 and 1945, are comfortable with a command-and-control managerial style primarily because they believe it was effective in World War II.

Integration can kill otherwise kill successful ERP implementations

Over half of silicon.com's CIO Jury panel believes integration issues are increasingly becoming a major obstacle to the successful implementation of complex ERP systems.

This comes after furniture chain MFI issued a profits warning after the botched rollout of an SAP-based supply chain system that led to customer orders being sent out incomplete; the problem will now cost £30m to correct.

Integration issues appear to have been the key to the problems, with SAP claiming there have been no issues with its software. We asked our CIO Jury if the complexity of integrating ERP systems is getting worse and hampering projects.

Seven Key Lessons to Keep in Mind When Communicating an IT Failure

Posted March 4th, 2008 by Jonah Paransky
ttp://www.stacksafe.com/blog/2008/03/04/seven-key-lessons-to-keep-in-mind-when-communicating-an-it-failure/

IT Failures Happen.

While business and customers often expect 100% uptime, they don’t always receive it.

When failures happen, often the quality of the communication process does not match the technical resources brought to bear to solve the problem.

Here are seven key lessons to keep in mind when communicating an IT failure.

1. Have a communication plan in place and ready to go

All IT service delivery teams should maintain an active business continuity or disaster recovery plan. The time to develop your communications plan is not during the outage or service failure when the entire organization if focused on dealing with the problem at hand. Any credible continuity planning process should include the development of canned messages and a communications playbook that can be used during the failure. Does yours? If not, start the process of updating it as soon as possible.

2. Direct Communication with your customers is the number one concern

Customers would much rather hear about a problem directly from you, rather than from the media or discovering the problem themselves. If you are experiencing a major service failure, let your customer base know ASAP.

IT failure at Heathrow T5: What really happened

April 7, 2008, by Michael Krigsman @ 7:48pm, See http://blogs.zdnet.com/projectfailures/?p=681

Anyone having the misfortune to pass recently through Heathrow’s new Terminal 5 knows the huge project debuted as a case study in full-blown systems failure. Most reports have focused on stranded customers, a crazed supermodel, and Queen Elizabeth’s grand opening speech, which called the terminal “a 21st Century gateway to Britain.”

Here’s my rundown of the major failures and why this debacle happened.

Just One More Time, "Why Do Systems & Software Projects Fail?”

In this new millennium, it is still true that approximately 29% of all large-scale systems projects are successful, 53% are challenged (with average overruns of 84% in time, 56% in dollars and only providing 67% of the required functionality), and 18% are scrapped and written off altogether. Although these stats show a small improvement over the statistics from a decade ago, and even with all the reported advances in technology, methodology, and software development and implementation, this is a poor showing for the Information Technology Industry [Source: Standish Group “Chaos Reports”].

For the past 36 years I have been a computer systems consultant and computer crisis consultant, including 20 years as a large-scale systems project turnaround specialist and an expert witness in large-scale software and systems implementation failures in the United States, Canada, the Caribbean, Europe and Asia. If I have learned anything, it is the following:

1. Virtually all systems failures stem from the same handful of root causes and lack of “-abilities” (e.g., cap-ability, respons-ibility, suit-ability, etc.). And this is true everywhere in the world!
2. All parties in a large scale systems or software project failure or dispute typically share some of the blame, but with some bearing much more blame than others for causing the failure(s) to happen, allowing them to happen, or being unaware that they are happening – with each party contributing anywhere from 0%-100% in each failure category.
3. Many, if not most, of the problems (sand their causes) could have been avoided, mitigated, or managed if the parties followed a few simple, but not easy, rules.
4. Putting in proper project policies, procedures, resources, monitoring metrics, tools, and project team communications to address these root cause areas could have either: (1) allowed the project to be successful in the first place if they were implemented and used from the outset of the project, (2) been used to turn around a runaway project midway if not originally implemented.
   
   Alternatively, determining how and how much each party contributed to these root causes is extremely powerful in helping judges, juries, and arbitrators assess the comparative guilt of the parties in litigation or dispute resolution for failed systems.

I developed the chart below to summarize my findings regarding why systems and software projects fail. This chart has been published in several peer-reviewed scholarly journals with relatively few changes over the years because of the persistent applicability and relevance of these root cause failings through today.

Please send me your experiences and insights on Why Systems Fail -- and What to Do About it?

More Software Bugs: 2003 - 2005

Trading on a major Asian stock exchange brought to a halt in Nov. 2005, reportedly due to an error in a system software upgrade. The problem was rectified and trading resumed later the same day.

May 2005 newspaper article reported that a major hybrid car manufacturer had to install a software fix on 20,000 vehicles due to problems with invalid engine warning lights & occasional stalling. In the article, an automotive software specialist indicated that the automobile industry spends $2 billion to $3 billion per year fixing software problems.

Media reports in Jan. 2005 detailed severe problems with a $170 million high-profile U.S. government IT systems project. Software testing was one of the five major problem areas according to a report of the commission reviewing the project. In March 2005 it was decided to scrap the entire project.

July 2004 newspapers reported that a new government welfare management system in Canada costing several hundred million dollars was unable to handle a simple benefits rate increase after being put into live operation. Reportedly the original contract allowed for only 6 weeks of acceptance testing and the system was never tested for its ability to handle a rate increase.

Millions of bank accounts were impacted by errors due to installation of inadequately tested software code in the transaction processing system of a major North American bank, according to mid-2004 news reports. Articles about the incident stated that it took two weeks to fix all the resulting errors, that additional problems resulted when the incident drew a large number of e-mail phishing attacks against the bank's customers, and that the total cost of the incident could exceed $100 million.

Software Bugs Continue to Plague Systems (2006 & 2007)

Source:  A very good website:  http://www.softwareqatest.com/qatfaq1.html

"What are some recent major computer system failures caused by software bugs?

• News reports in December of 2007 indicated that significant software problems were continuing to occur in a new ERP payroll system for a large urban school system. It was believed that more than 1/3 of employees received incorrect paychecks at various times since the new system went live in January of that year, resulting in overpayments of $53 million, as well as underpayments. An employees' union brought a lawsuit against the school system, the cost of the ERP system was expected to rise by 40%, and the non-payroll part of the ERP system was delayed. Inadequate testing reportedly contributed to the problems.
• In November of 2007 a regional government reportedly brought a multi-million dollar lawsuit against a software services vendor, claiming that the vendor 'minimized quality' in delivering software for a large criminal justice information system & the system did not meet requirements. The vendor also sued its subcontractor...
• In June of 2007 news reports claimed that software flaws in a popular online stock-picking contest could be used to gain an unfair advantage in pursuit of the game's large cash prizes. Outside investigators were called in and in July the contest winner was announced. Reportedly the winner had previously been in 6th place, indicating that the top 5 contestants may have been disqualified.

New Millennium: New Lawsuits

Japanese bank sues IBM over ‘difficult’ computer system

March 6th, 2008 by Beth Pariseau

... I got a chuckle out of this story from Reuters UK today about a lawsuit filed against IBM:

A small Japanese bank has slapped International Business Machines Corp with a $107 million lawsuit, saying the technology giant failed to properly deliver on a computer deal.

Suruga Bank, based in Shizuoka Prefecture west of Tokyo, hired IBM in 2004 to help overhaul its computer system, but later baulked [sic] at the proposed changes.

“We are suing because we decided it would be difficult to implement the system they suggested,” a spokesman for the bank said.

Kind of a dangerous precedent ... if this suit is successful, don’t you think?
***************************

Well?  What do you think?

Chasing a Moving Target Wastes Energy by Lubomyr Chabursky

Every good hunter knows that chasing after a moving target takes a lot of energy, effort and skill. For hunters, that’s the enjoyment of their enterprise. For computer projects, that’s squandered energy and effort.

Getting to market first or bringing a new system on-line is a huge force to be reckoned with. A company’s reputation among its investors and customers is often put at stake based on promises made by the company’s visionaries, sales staff and marketing divisions, who know much about spinning a good story, and less about the realities of computer projects The imperative of diving into a project as soon as possible appears to make good business sense initially for both the company and computer systems provider, but a proper assessment of doing so can only be made if the both the company and provider understand the risks and potential consequences.

Among the more prominent risks is that the scope of the engagement and functionality would not be sufficiently fleshed-out and agreed to before the company and provider sign the dotted line. Too often any changes that happen after that signing are considered in the context “who is going to pay for this?” and invariably each party points at the other. The provider would say, “This is great functionality, but it is new – so the company must pay for it.” The company would say, “That was part of our requirements all along, you told us that you understood our needs – so do it for the agreed price.” Even when a contract price is deliberately characterized as a “preliminary estimate”, customer companies will often come to consider this to be a fixed price. On the other hand, for providers, a fixed price for fixed deliverables is typically always subject to scope and price change through change orders.

IT Project Jargon Mysteries Uncovered

Here's a set of definitions to help you understand what those Checkpoint Reports are really telling you ! [author(s) unknown]

Essentially complete
It's half done.
We predict...
We hope to God!
Risk is high, but within acceptable ranges of risk
100:1 odds, or with 10 times over budget using 10 times the people we said we'd employ.
Potential show stopper.
The team has updated their resumes.
Serious but not insurmountable problems.
It'll take a miracle...
Basic agreement has been reached.
The @##$%%'s won't even talk to us.
Results are being quantified.
We're massaging the numbers so they will agree with our conclusions.
Task force to review.
Seven people who are incompetent at their regular jobs have been loaned to the project
Not well defined at this time.
Nobody's even thought about it.
Still analysing the requirements.
See previous answer.
Not well understood.
Now that we've thought about it, we don't want to think about it anymore.
Requires further analysis and management attention.
Totally out of control!
Results are promising
Turned power on and no smoke detected -- this time...
Elements will be phased in gradually as the software interface matures
It's late!
Unacceptable stretching-out of the time scale
It's late!
Still in the early phase of the learning curve
New
The requirement was changed and the programme concluded
Cancelled
Experiencing transient malfunctions
Going wrong
Conceptually configured in several variations
Modified
A structured interface with the government on an inter-departmental basis
Money!

I hope this helps. Maybe you have some that we should add to the list. Tell us in your comments.

Murphy's Laws of Computing: Share you own "laws" with us!

Every successful industry has them  — Murphy's Laws of Computing (Source Unknown).
Do these resonate with you?  Which new ones would you like to add?

1. When computing, whatever happens, behave as though you meant it to happen.
2. When you get to the point where you really understand your computer, it's probably obsolete.
3. The first place to look for information is in the section of the manual where you least expect to find it.
4. When the going gets tough, upgrade.
5. For every action, there is an equal and opposite malfunction.
6. To err is human... to blame your computer for your mistakes is even more human, it is downright natural.
7. He who laughs last probably made a back-up.
8. If at first you do not succeed, blame your computer.
9. A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.
10. The number one cause of computer problems is computer solutions.
11. A computer program will always do what you tell it to do, but rarely what you want to do.

Do these resonate with you?  Which new ones would you like to add? Send them to me and we will select the best and most original ones and create our own bloglist with  your name ascribed to your winning entry!  

Everything Old is New Again!

The following list is adapted from Bill Swanson's "25 Unwritten Rules of CEO Management." 

1. Learn to say, "I don't know." If used when appropriate, it will be often.
2. It is easier to get into something than it is to get out of it.
3. If you are not criticized, you may not be doing much.
4. Look for what is missing. Many know how to improve what's there, but few can see what isn't.
5. When something appears in power point, assume the world knows it. Deal with it accordingly.
6. Constantly review developments to make sure that the actual benefits are as promised.
7. Persistence or tenacity is the ability to persevere in spite of difficulties, discouragement, or indifference. Don't be known as a good starter but a poor finisher.
8. In completing a project, don't wait for others; go after them, and make sure it gets done.
9. Strive for brevity and clarity in oral and written reports. Be accurate in all your statements.
10. You are working for many stakeholders. Keep them informed. Avoid surprises!
11. Promises, schedules, and estimates are important instruments in a well-ordered business. You must make promises. Don't lean on the often-used phrase, "I can't estimate it because it depends upon many uncertain factors."
12. When making decisions, the pros are much easier to deal with than the cons. Your boss wants to see the cons and the risks also.
13. A person who is nice to you but rude to the waiter is not a nice person. (This rule never fails.)

How relevant and applicable do you believe they CEO management rules are for today's CIO's, CTO's and Large Scale Systems Project Managers?