Reader Feedback: Online Education, Vendor Relations, Software Requirments

The Queen’s University MBA

There may be an incorrect assumption in your article [“Oh, the Places They’ll Go,” found exclusively online in the June 15, 2001, section at www.cio.com/printlinks]. You mention, “They [MIT] were the first MBA class anywhere to get their applications off the Web rather than in the mail. They established a community site on the Internet long before they set foot on campus. They Web-enabled student life with a host of online services such as a student photo directory and a calendar of events.”

I am a participant in the Queen’s University MBA program, and we have all of those services and more. Our classes are linked by videoconference and are held in boardrooms across the country. The system has been the focus of much attention by the academic community worldwide.

Queen’s University in Kingston, Ontario, has been running this program since 1996. I believe that MIT’s Sloan School of Management and the Queen’s School of Business have been negotiating a means for Sloan to offer this program to their students. Queen’s also offers a specialized science and technology MBA, the MBAst.

Joe Carrigan

Class of 2002

Queen’s University School of Business

joe@metricksystem.com

The Truth about Vendors

I wholeheartedly agree with the premise of spending time to thoroughly review a vendor’s background prior to entrusting your money, time and?most important?data to a vendor [“Do Diligence,” July 1, 2001]. However, I take issue with one of the writer’s core examples. While I relish the fact that her article besmirches Accenture, a core competitor of mine, I must stand in its defense. Except for the exclusion of an RFP, the process by which it winnowed the ERP package and its short list of vendors was appropriate to that time period and industry. Five years later, we look back to a vendor that has since declared bankruptcy and unequivocally exclaimed that the wrong decision was made. But, I wonder, how many vendors in that original pack of 20 are also no longer viable? If the company had instead chosen one of the remaining large players of today, how much customization would have been required?

The writer’s overall point is valid but could have easily been made using more overt and recent examples. How many companies have selected e-commerce vendors that have never declared a profit? How many companies have selected an ERP package based on a convention speech or hearsay on the golf course? I can think of a slew of companies that have recently dallied on diligence?examples that don’t involve the long-term implications of a changing business landscape.

Karen Hollinger

jokaho@aol.com

Software Guidelines that Work

No software development methodology is perfect [“The Secret to Software Success,” July 1, 2001]. However, comparing the software development process to building a bridge is a fundamentally flawed comparison. That analogy is the worst I have ever heard.

Proponents of this methodology seem pretty quick to draw abstract comparisons of how the other methodologies are bad and theirs is good. Unfortunately, this disregards nearly half a century of software development. True, many software development projects fail. True, they fail for many of the reasons stated in your article. True, even the older tried-and-true methodologies do not fit in the Internet age of application development.

My experience, however, has been that methodology is simply one of many factors that affect the success of a software project. Customer expectations, process analysis, time frame, availability of technologies, management support, project championing and technical expertise all contribute. I think [Agile Alliance Cofounder Martin] Fowler raises some very important, if not obvious, points about why traditional software development does not always work. However, I failed to see in the article any reference to similar methodologies, especially those in other industries, that currently work. Would you believe me if I told you that my own personal software methodology was revolutionary and because of it I never had a project fail?

Bradley S. Behrens

bbehrens@sco.ca.gov

I really enjoyed your article. My company is a software development and consulting company based in northeastern Ohio. Unfortunately, I must admit that I am familiar with many of the problems that you describe. I forwarded the article to several of my peers here, and I would like to give Agile Development a try.

Being a relatively small company (25 developers), we may not be the type of company that you had in mind when you asked, “Would you be willing to give Agile Development methods a try?” However, our answer is yes!

Eric Eckman

Director of Business Development

ETC Computers

eeckman@etccomputers.net

Although I have not been responsible for the development of large software systems until recently, I can say that the guidelines you covered in your article are the principles that have made me successful. I have always demanded a commitment to having the real users of a system be involved in direction, development and testing of the software. I have also found that if you don’t include the real users, then when you meet the stated requirements of a project you will find that no one really needed the software and it won’t get used. Keeping initial requirements realistic and minimal allows for much greater success. Putting out a fully functional and bug-free version of the software that handles only a fraction of desired processes is the best kind of trial by fire. Good software will get used even if it doesn’t do everything. It also prevents you from overdeveloping any particular portion.

Aaron Heady

U.S. Southern Command

Web Administrator

headya@hq.southcom.mil

Just read your article and wanted to say you hit the nail on the head. Thought you’d be interested in the Agile Modeling homepage where we’re developing an Agile methodology for effective software modeling. We’ve got a mailing list going where we actively discuss the methodology, and several of the Agile Alliance folks are participants, including Fowler and [Project Management Consultant] Jim Highsmith. Visit the site at www.agilemodeling.com.

Scott W. Ambler

President

Ronin International

scott.ambler@ronin-intl.com

I enjoyed your article. I’ve been following Fowler and [Project Manager Kent] Beck for the past couple of years, watching their sites on the subject of Extreme and Agile methodologies. Working in a small consultancy, it’s interesting trying to sell a light methodology to big clients, after the sell for so many years has been about heavy methodologies. For example, once a large organization has taken the time and effort to implement a formal development methodology, moving to an agile or lightweight way of doing things can be seen as revolutionary.

Organizations are political places, and the dynamics and motivations of the people inside the organizations often have as much, if not more, to do with project failure than technology or process choice.

Gordon Ross

Partner

OpenRoad Communications

Vancouver, British Columbia

gordonr@openroad.ca

I run a software development company specializing in enterprise client/server systems for midsize businesses. It was particularly gratifying that this article confirmed many of the practices my company has employed since 1983. I started my career in finance for a Fortune 50 where I coordinated the development of software from the user side of the table. The conventional wisdom is that the main problem with the software development process is that the planning is flawed, incomplete or shortsighted.

Because of that, an extraordinary amount of effort went into planning, so much so that projects were often obsolete before they were implemented. My theory is that if the implementation can be accomplished quickly and cheaply, a flawless plan is not only unnecessary but a complete waste of time.

Glenn Lawler

President

Incode Systems

Peoria, Ill.

gblawler@incodesystems.com

Not only was your article on Agile Development right on the mark, but I personally have been managing projects this way for years with great success. What’s more, this methodology works well when applied to any type of project, not just software development. I’m glad to now know the official name; I’ve been calling it Common Sense Development.

Michael P. McGinty

Manager Information Technology

Riviera Finance

Tampa, Fla.

mmcginty@rivierafinance.com