On TechRepublic: 19 words you don't want in your resume
BNET Business Network:
BNET
TechRepublic
ZDNet

July 4th, 2008

Runescape graphic glitches

Posted by Michael Krigsman @ 3:47 pm

Categories: End-user impact

Tags: Graphics, Michael Krigsman

Spending the American July 4th holiday with friends and family is a wonderful break from the daily routine. Imagine my surprise when a lively 12-year old proudly showed me the graphics problems he discovered in Runescape, an online game.

According to this young bug-hunter:

It all started recently when they rolled out a graphical update. Everything was fine before that.

A couple of screen captures illustrate. On the left: the light green tunic is actually a cape the character wears on his back; it should be invisible, hidden behind the body. On the right: although the character is wearing an armored headdress, his face and head are missing:

Runscape graphic glitches

More interesting than these minor graphics problems was the young player’s attitude. At 12 years old he’s already completely accustomed to the notion that software doesn’t always work as expected. Finding obvious bugs has become a form of entertainment.

Hoping your July 4th holiday is enjoyable, have a Runetastic day!

July 3rd, 2008

5 more reasons IT projects fail

Posted by Michael Krigsman @ 9:19 am

Categories: IT issues, CIO issues

Tags: Project, Information Technology, Project Management, Strategy, Change Management, Tools & Techniques, It Operations, It service Management, Management, Michael Krigsman

5 more reasons projects fail

How doth my project fail? Let me count the ways.

With apologies to the poet Elizabeth Barrett Browning, there are myriad ways that IT projects fail. The Project Management Hut blog offers five:

  1. Executive Level Non-Support. All executives must stand behind the project plan if it can have any chance for success.
  2. Improper Staffing. I have never seen a project succeed when overtime is pre-scheduled into the plan. Outside resources or consultants are the best alternative when in-house staff resources are inadequate.
  3. Poor Project Management. Very few skilled managers ever get the opportunity to manage a project from inception to completion. As a result, most assigned project managers lack the experience in handling the broad range of problems that arise during the course of a project.
  4. Unreasonable Completion Dates. [M]anagement in its wisdom will declare target completion dates, or worse…deadlines, even before a project plan is constructed.
  5. Poor Project Planning. While many tools exist to assist in this process, it is the analysis of an experienced project manager that is needed to develop the plan and smooth out its deficiencies.

The list is a good start, but a broader set of drivers should include issues related to business case, change management, and vendor relationships just to mention a few.

Given the diversity of IT projects, it’s hard to create an exhaustive list of conditions that cause projects to fail. Still, we can definitely say most projects crash due to business, organizational, and political reasons, rather than for technology reasons. Despite being an easy target, technology is rarely the real, underlying culprit causing projects to fail.

July 3rd, 2008

Computer ‘mystery outages’ plague Australian Emergency Services

Posted by Michael Krigsman @ 4:50 am

Categories: Project failures, Government projects, Project management, IT issues, CIO issues

Tags: TriTech Software Systems, Outage, Computer, Manufacturing, Quality, Business Operations, Michael Krigsman

Fire truck

A series of four “mystery outages” have forced the Department of Emergency Services in Queensland, Australia to suspend rolling out a new, $6 million computer-aided dispatch system based on TriTech Software Systems’ VisiCAD product.

During the most recent downtime, which lasted two hours, ambulance and fire personnel resorted to a manual tracking system, writing incoming jobs on a “big whiteboard.” Queensland Emergency Services Minister Neil Roberts commented:

The one just yesterday is unexplained at this stage, however we’re confident we’re going to be able to find out the reason for that.

We’re seeking advice from the United States suppliers and until we get a clear indication of what the actual issue was, I’ve instructed the Department to put on hold the further roll-out of this system….

After another outage last June, a Department press release cut the system some slack. It’s not clear what’s the difference between “system” and “maintenance” issues:

Late yesterday the system experienced an outage for approximately 90 minutes where it was necessary for operators to resort back to a manual system. The cause of this outage was related to a maintenance issue, not the system.

According to Tritech, VisiCAD integrates dispatch information, such as incident location, with mapping data. Here are two screen captures:

[7/3/08, 3:40PM EDT: Screen captures were removed per request of TriTech Software Systems.]

THE PROJECT FAILURES ANALYSIS

This case offers a classic example of poor alignment between IT system implementers and end-users. Emergency response personnel, who are the users in this case, are extremely dissatisfied, as shown by this quote in AustralianIT:

Fire officers have been highly critical of the new system, which they say has only been “half implemented” by the department making it ineffective.

“The system is meant to locate the closest vehicle to an incident and dispatch that vehicle. But they’re yet to install the automatic vehicle locaters in our trucks so it can do this,” an officer said.

There appear to be several core issues:

  • Technical deficiencies related to the software, configuration, hardware, network, or related infrastructure
  • Implementation or project management problems
  • Testing and system integration quality control oversight
  • Insufficient end-user training, communication, and change management

Fortunately, manual dispatch methods have proven workable to date. Nonetheless, given the mission critical nature of emergency services, the Department and TriTech should organize better planning and testing before restarting the project.

July 2nd, 2008

Stop the madness: 10 steps to kill failures

Posted by Michael Krigsman @ 7:30 am

Categories: IT issues, Project strategy, CIO issues

Tags: Project, Information Technology, Failure, Corporate Governance, C/C++, Strategy, Business Operations, Corporate Law, Programming Languages, Software Development

10 steps to kill IT failures

Are you too pussy-footed to pull the plug on projects that will inevitably fail? If so, you’re not alone. Whether through fear, denial, or ignorance, many organizations don’t kill their doomed projects fast enough. It’s a darn shame because these lousy things can drive everyone crazy while burning scarce resources.

Baseline has assembled a set of ten solid steps to help you kill IT failures mid-stream:

  1. Build in Ways to Cheaply Pull the Plug. Canceling bad projects is much easier when there’s already an evaluation and chartering process in place.
  2. Set Risk Tolerance in Advance. If the tolerance level has been breached, the project gets canned.
  3. Don’t Delay the Inevitable. CIOs should try to pull the plug as soon as possible after imminent failure makes itself apparent.
  4. Hone the Business Case for Cancellation. [T]ry to collect hard figures on costs and benefits to make your case.
  5. Get Your Resume Together. [T]hese situations can get ugly.
  6. Get Senior Management On Board. [K]illing a project is as critical as [convincing the board] to release project funds in the first place.
  7. Articulate Reasons for Cancellation to Project Team Members. [A]void finger pointing when breaking the news to a project team….
  8. Tie Up Loose Ends. [C]lean up documentation before reassignment….
  9. Look for Salvageable Intellectual Property. [A]nalyze everything to see if components can be made useful.
  10. Do a Post-Mortem. [H]ire an independent third party to conduct confidential interviews and present their findings.

Don’t be a victim: kill the failures before they kill you.

July 1st, 2008

Scathing report slams UK gov’t data loss

Posted by Michael Krigsman @ 7:33 am

Categories: Project failures, Government projects, IT issues, CIO issues, Politics

Tags: Information Security, Data Loss, Accountability, HMRC, Security, Michael Krigsman

UK gov’t data loss: Detailed explanation

The UK government has released a scathing report, called the Poynter Review, criticizing Her Majesty’s Revenue and Customs (HMRC), following the loss of confidential data belonging to 25 million UK citizens. The report concludes “the loss was entirely avoidable and the fact that it could happen points to serious institutional deficiencies at HMRC.”

The report describes organizational insensitivity around security issues:

Operational concerns placed ahead of security risks

These concerns [about releasing large amounts of data] were not escalated to a suitably senior level within HMRC and the suggestion to remove sensitive information from the scan was thwarted by concerns over cost and resources.

[It] would appear that, as a general rule, staff below the Senior Civil Service level, prioritise operational delivery over information security in the execution of their day-to-day roles. This finding is consistent with previously-mentioned lack of awareness amongst staff of the existence of security policies.

Insecure methods of data storage and transfer

HMRC specified the medium for this download, its format and the use of a certain version of proprietary software with limited alphanumeric password protection. Given the amount of sensitive customer data on the discs and the portability of such a medium, this level of encryption was clearly insufficient to protect the information in the event that the discs were lost.

HMRC’s information security and governance policies were also lacking:

Information security policy and procedure could have been stronger and better communicated

HMRC has detailed policies and guidance around information security and the release of data to third parties….If these policies had been adhered to, it is likely that the data loss could have been prevented.

Lack of clarity governance, accountability and communication in respect of data guardianship

One of the problems faced by the HMRC staff involved was that there was no clearly assigned data owner or guardian
from which to seek this authorisation….The fact that no senior HMRC official was involved in the events leading to the data loss raises serious questions of governance and accountability….

[I]t is highly unlikely that the discs would have been permitted to leave HMRC premises in March without the authority of the data guardian, nor would a properly trained data guardian have permitted the use of internal post for the October transfer….

Authority requirements and accountability for decisions relating to data transfer are neither well defined nor understood within HMRC. Staff neither sought nor believed they should have sought authority for the removal or removal method of large amounts of sensitive data from HMRC.

Finally, the report discusses how the data loss was “symptomatic of a wider problem” in the organization:

  • Information security, at the time of the incident, simply wasn’t a management priority;
  • Even had it been a priority, HMRC’s organisational design and the governance and accountabilities underpinning it would have made it extremely difficult for it to be felt as such;
  • Even with a more suitable organisational structure, the fragmentation and complexity that has accompanied the changes that HMRC has had to absorb makes information security difficult to control;
  • HMRC’s information security policies were inadequate and those that they had were unduly complex and not adequately translated into guidance or training for the junior officials who needed them; HMRC continues to operate processes that hark back to a paper-based, rather than a digital, world; and
  • Morale is low in HMRC and management needs to continue to focus on engaging with staff as the department embarks on a period of further change.

My take. The report’s conclusions are not surprising, given the HMRC’s terrible record on IT-related security, procurement, and systems issues; HMRC is the poster child for organizational failures driving IT disaster.

The Poynter report is required reading for anyone interested in how organizational, cultural, and management conditions give rise to IT failures.

June 30th, 2008

Has Google demoted FeedBurner?

Posted by Michael Krigsman @ 6:25 am

Categories: SaaS, PaaS, and SOA, Enterprise 2.0, Availability and reliability, Failure 2.0, End-user impact

Tags: Google Inc., Feedburner, Blog, Blogging, Web Site Development, Web Technology, Internet, Michael Krigsman

Update 6/30/08 6:00pm: FeedBurner is working correctly.

FeedBurner blog site statistics have been down for over two days with no word from Google despite numerous complaints from users. Does Google’s lack of response suggest something we don’t know?

One unhappy user sent me the following screen capture, showing zero visitors on a well-trafficked blog:

Google FeedBurner stats down

FeedBurner’s user forum reports numerous instances of this problem:

FeedBurner user forum

Google has ignored all of these complaints. The last entry on their known issues list is June 28:

28-JUN 2008 From the it’s-not-you-it’s-us dept.: If you use our Site Stats for website traffic statistics, you may notice unusually low numbers for 28-Jun so far. We are restoring tracking services that have temporarily been suspended and expect to be reporting more recent site stats again shortly. Apologies for the temporary inconvenience!

In my view, Google’s cavalier attitude toward FeedBurner suggests that perhaps the service has been demoted to second-tier status despite the fact some FeedBurner services remain working. If so, that’s bad news for users. Google, any comment on this?

June 29th, 2008

Bad leadership causes failed IT

Posted by Michael Krigsman @ 3:53 pm

Categories: IT issues, SaaS, PaaS, and SOA, CIO issues

Tags: Information Technology, Leader, Failure, Blogger, Mike, Leadership, Strategy, Service-Oriented Architecture (SOA), Management, Web Services

Bad leadership causes failed IT

This post was written by guest blogger, Mike Kavis, a senior enterprise architect. Mike describes how the roots of failed IT projects lie in management and leadership rather than in technology.

IT failures continue to plague organizations across virtually every industry. Poor business leaders who don’t possess the skills needed to manage change effectively have created this mess.

There are countless articles about failed IT projects, ranging from outsourcing failures, SOA failures, technical architecture failures, and customer service failures. I outlined 10 reasons why large IT initiatives fail in a previous post:

  1. Poor Communication
  2. Underestimating or ignoring impact of change
  3. Lack of Leadership
  4. Lack of strong executive sponsorship
  5. Poor project management
  6. Poor Planning
  7. Trying to do it cheap
  8. Lack of technical knowledge
  9. Lack of sound business case
  10. Poor vendor management

This list boils down to three categories: technology, business, and people. You can probably count on one hand the number of folks that you’ve come across who excel in all three areas.

Most large business transformation projects fail because IT leaders don’t acknowledge, or at least underestimate, the impact of change on the workforce. These managers focus entirely on technical issues while failing to address the human side of change.

Driving change successfully requires creating a sense of urgency, communicating a clear vision, and addressing WIIFM (what’s in it for me) at all levels. Leaders must identify change agents throughout the company to battle resistance, while remembering success is about the people and not the technology.

Leaders often make a lethal mistake by not aligning technology projects with key business drivers, which is precisely why so many Service-Oriented Architecture and Enterprise Architecture initiatives fail. Both SOA and EA are long term strategic initiatives requiring many resources and a great deal of funding, which only worsens alignment issues.

When IT is not aligned with business drivers, IT makes poor architectural decisions that nobody on the business side will want or understand. Consequently, the business won’t invest in these initiatives because they see no apparent benefit. This is where IT leaders must learn to speak in financial terms that the business will understand and appreciate.

Most IT failures are due to a team’s inability to embrace changes needed to implement new technology. Nonetheless, leadership frequently points the harsh finger of failure to technology, which is simply the wrong place to look for solutions. No wonder IT failure rates remain so high!

The next time you see a major project fall apart, remember it’s not the technology that failed but leadership that didn’t measure up.

June 29th, 2008

SlideShare: user communication failure

Posted by Michael Krigsman @ 9:20 am

Categories: Enterprise 2.0, Availability and reliability, Failure 2.0, End-user impact

Tags: Object-oriented Programming, File, SlideShare, Ooa/Ood/Oop, Software Development, Software/Web Development, Michael Krigsman

While Enterprise 2.0 applications can be useful, hassles sometimes abound. In this case, I innocently tried to upload a simple file to SlideShare, only to learn things aren’t always straightforward.After attempting to upload the file, I received an error message stating in part:

There’s a big chance this is just a temporary/random glitch with our servers; just retry after 5 minutes and see if it works.

Here’s a screen capture, highlighting the relevant message:

SlideShare error message

The troubleshooting FAQ offers a bit more information:

I am getting a file conversion error while uploading my file. It gives me an “OOPs”. What is this?

This means your file could not be converted to our format. Reasons could be varied
- it’s possible our converter is temporarily down, try uploading once again
- if your file is password protected or contains macros, you might get an OOPs; remove them and upload again
- sometimes uploading the pdf version instead of the original ppt/odp file (or vice-versa) helps to overcome the OOPs

If none of the above helped, this could be due to some incompatibility between our converter & your file.

While every application suffers bugs and errors, I don’t understand why SlideShare doesn’t state whether or not their converter is down. As the screen capture shows, I spent 41 minutes screwing around — converting the file, uploading, re-converting, and so on. SlideShare, if your converter isn’t working, please speak up so I don’t waste my time.

Although I generally like SlideShare, communicating errors and problems clearly to users is obviously not a strong point. It’s time the company learned this important skill.

Update 6/30/08, 8:30am EDT: The SlideShare blog reports the upload problem has been resolved. Amit Ranja, one of SlideShare’s founders, sent the following comment by email:

Regarding your suggestion to add intelligence to upload error messages, it is definitely a good idea. Let me discuss this internally and see if we can incorporate that.

June 27th, 2008

Gov’t failures: Engineering brain drain and bad leadership

Posted by Michael Krigsman @ 10:21 am

Categories: Government projects, IT issues, CIO issues, Research and statistics, Politics

Tags: Leadership, Systems Engineering, Computer, CAD, Productivity, Software, Michael Krigsman

Gov’t failures: Engineering brain drain and bad leadership

Many large-scale government technology initiatives are failing due to an exodus of qualified systems engineers away from the public sector to private industry. An in-depth analysis of the problem conducted by the National Research Council reveals the considerable impact of this problem.

The New York Times described the issue:

That brain drain, military experts…say, is a big factor in a breakdown in engineering management that has made huge cost overruns and long delays the maddening norm

[T]he central problem is a breakdown in the most basic element of any big military project: accurately assessing at the outset whether the technological goals are attainable and affordable, then managing the engineering to ensure that hardware and software are properly designed, tested and integrated.

The technical term for the discipline is systems engineering. Without it, projects can turn into chaotic, costly failures.

The detailed analytical report, titled “Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits for Future Air Force Acquisition,” states that government projects are becoming worse over time:

The time required to execute large, government-sponsored systems development programs has more than doubled over the past 30 years, and the cost growth has been at least as great….[T]his trend is particularly puzzling given the enormous productivity advantages conferred by the advent of the Internet and e-mail, the revolution in electronics and computer technology, and advances in knowledge-management and collaboration tools such as computer-aided design (CAD), computer-aided manufacturing (CAM), computer-aided software engineering (CASE), and modeling and simulation.

The following table illustrates this point:

Government systems engineering brain drain

Beyond the brain drain as a primary driver of over-budget and late government projects, the report identifies “six seeds of failure,” as it calls certain management and process contributors to the problem:

[T]he committee examined the myriad factors that may have contributed to serious development issues and identified six factors that are pervasive sources of poor performance and that are addressable through sound systems engineering processes.

The six seeds of failure are summarized in a chart:

six seeds of failure

Failed government technology projects cost taxpayers billions; this report takes a hard-nosed look into the problem and offers concrete suggestions. Care to guess whether the government will actually follow the advice?

June 27th, 2008

Fixing failure: Shatter the technical glass ceiling

Posted by Michael Krigsman @ 4:38 am

Categories: IT issues, CIO issues, Research and statistics

Tags: CIO, Information Technology, ComputerWorld UK, Strategy, Management, Michael Krigsman

Broken glass

Projects fail because IT and business people don’t communicate. This gap between business requirements and IT execution remains alive and well, according to new research.

ComputerWorld UK summarizes the issue:

The survey of CIOs, senior IT managers and department heads across 500 European business found that just 48% of UK CIOs sit on the board.

Instead CIOs are usually brought into the strategic process once decisions about the business have already been made, found the study.

In most cases, 35%, strategies are worked out by the board, and then IT is brought in to deliver. Only 13% of cases business strategies are signed off if IT has committed.

THE PROJECT FAILURES ANALYSIS

Given statistics like this, it’s not surprising that 30% - 70% of IT projects fail.

During a recent interview with distributed computing analyst, Judith Hurwitz, she explained how poor leadership on the business side ultimately causes many failures. According to Judith, projects collapse due to poor alignment between requirements stated by business management and IT’s understanding of those requirements.

The study affirms this view:

Sixty six percent of respondents said business opportunities had been lost due to lack of communication between the business unit and IT.

Failures will persist until IT learns to think strategically and communicate more effectively in the language of business. Likewise, it’s time for business leadership to actively engage IT to shatter the technical glass ceiling.

Note to CEOs: If your CIO doesn’t contribute as a true partner to the business, then find a new CIO. Before taking such drastic steps, however, make sure the problem isn’t your fault. (Hint: you’d be well-advised to look in the mirror before firing the CIO.)

Michael Krigsman is CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures. Click here to discuss this post with him on Twitter.

See his full profile and disclosure of his industry affiliations.

Recent Entries

Most Popular Posts

advertisement

Archives

ZDNet Blogs