Offering regional and national programs, CIO (and CSO) events bring together some of the most respected names and thought leaders in information technology and security. Presented by CIOs and other senior level executives, these invitation-only programs offer timely topics and strong networking. Learn More »
Webcast: In the Google Apps Cloud: How to Achieve Your Business Objectives
Dec 3rd, '09, 1 - 2 pm US/Eastern (GMT-5)
Join Council member Brent Hoag, Director, Global IT, at JohnsonDiversey, as he discusses the adoption of Google Apps which has helped meet four corporate goals; sustainability, simplification, increased employee productivity and global collaboration.
Webcast: Collaboration Initiatives: Benchmarks & Best Practices
Dec 15th, '09, 4 - 5 pm US/Eastern (GMT-5)
Join Council members Ruth Thorpe, VP & CIO at the U.S. Pharmaceutical Operations of Sanofi-Aventis, and Gary Kuyper, CIO at Bethany Christian Services, as they speak about their collaboration initiatives and experiences in how and why they chose the social networking and collaboration tools they are using and their business goals for collaboration, and facing culture change challenges.
Data Overview: Collaboration Initiatives Field Guide: Benchmarks & Best Practices
This appendix to the Council Field Guide provides an analysis which discusses benchmarks for collaboration IT implementation costs, adoption rates and payoffs. The overview identifies top IT and business goals and satisfaction rates for collaboration initiatives as well as best practices and lessons learned for implementing collaboration IT.
Learn more about the CIO Executive Council »May 24, 2007 — CIO —
Quality in software development projects doesn't happen on its own. It also doesn't occur after a small group of heroes rides in on white horses and waves its shiny swords to vanquish the problems. Quality happens only when careful planning is done, when the entire project team maintains a quality-conscious approach every step of the way, and when problems don't escape from the phase in which they were introduced. A quality product is a team effort. It's planned and predictable. It's without heroes, and it's faster and cheaper than a low-quality effort.
How can this be? Let's look at some sample projects. The first is a normal, low-quality, late project. We'll call it project "Hurry Up" (HU for short).
Project HU got a bit of a late start due to the ongoing maintenance issues of its predecessor project "Just Ship It" (JSI). JSI was handled by a project manager (PM) who felt it was more important to ship on time than to ship a high-quality product. So he did. This PM was rewarded for his ability to "pull it together," "get it out the door" and "meet the schedule." The JSI PM was given a bonus for meeting his schedule and is now vacationing in Tahiti while the team deals with the fallout of the numerous bugs and unhappy customers.
Lesson #1: Don't reward for shipping on schedule. Anyone can ship garbage. Base rewards on quality metrics.
During the last month of the project, the JSI developers worked 80-hour weeks. One heroic fellow was recognized for working 120 hours in one week, stopping only for brief rests. He heroically repaired multiple interfaces between applications. Those interfaces had not been properly specified (there were no design documents), no integration testing was done (no time to do it), and the QA team fought quality issues throughout system test.
Lesson #2: Don't reward heroes for their Herculean effort late in the project to fix problems that could have—and should have—been fixed by the same people much earlier in the lifecycle.
The entire JSI team is down with the flu now due to lack of sleep.
Lesson #3: If you expect to work your people inordinate hours, you might want to consider corporate-sponsored flu shots!
Project HU was supposed to start three weeks ago, but the lingering effects of the flu, the nagging JSI maintenance problems and general team discord delayed the start. The analysts responsible for writing the requirements are in a rush. They got started late, the customer can't make up his mind, and the PM is pressuring for completion. The analysts write what they can in an MS Word document and ask for a review. The PM tells development to start coding and schedules a "quick" requirements review between the analysts and the developers.