Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Software Development

It’s been nearly 20 years since I first taught myself to program with GW (Gee-Whiz) Basic. Since that humble beginning and many programming languages and jobs later, I’ve experienced both the euphoria of project success and the agony of project defeat. Unfortunately, I’ve observed that it’s the doomed projects, not the success stories, that make the biggest impact on an IT career. In their sad aftermath, we attend project postmortems (aptly named) and write lessons learned (not-so-aptly named) so that it never happens again. But even before the ink is dry, that lessons-learned document becomes shelfware, and the mistakes that led to a project’s demise are soon repeated.

I’ve never understood why we can so easily recount the excruciating details of the latest project disaster but are loath to share the reasons for a project’s success with equal clarity or fervor. Successful projects ought to make you want to shout with joy, and that’s what I’m doing here: sharing a success story, complete with a happy ending and a moral.

The Renter’s Insurance Project

Thousands of renter’s insurance policies have been sold over the Internet, generating hundreds of thousands of dollars in revenue since my company’s Renter’s Insurance on the Internet application went to production. The project paid for itself in less than four months—quite a tidy return on investment! How was it accomplished? Why was it so successful?

The Mother of All Projects

Our schedule called for a one-week requirements phase. Meetings facilitated by our business project manager were conducted each morning. Participants included representatives from key business and technical organizations: property and casualty, underwriting, product management, Web programmers, Web designers and, of course, project management. I served as the lead systems analyst. For four hours a day, five days in a row, we hammered out what became an outstanding set of requirements. This success depended on three elements:

• Our commitment was solid: The group was committed to completing the task in a week. Our business project manager negotiated tirelessly with management to free up the necessary resources. No one complained about the lack of time or expressed doubt that it could be done.
• “80/20” and “KISS” (Keep It Simple, Scott) were our mottos. Well-seasoned in the task of eliciting software requirements, we concentrated on the system’s critical features, avoiding getting “wrapped around the axle” on any one issue. Less common or unusual business scenarios and exception processes (the 20 percent) were scoped out.
• Everyone participated and contributed to the discussion—and was mindful of the time constraints. Decisions were made on the spot whenever possible. Issues requiring research or management escalation were resolved within 24 hours.

Before the project, I had only a rudimentary knowledge of renter’s insurance, but in the course of a single week, I learned everything I needed to know to start developing a software application to provide renter’s insurance quotes and allow our customers to apply and acquire renter’s insurance online. Our business partners’ willingness to share their knowledge during the requirements marathon and throughout the project made all the difference.

Each morning of our marathon, I participated in a requirements gathering meeting. Each afternoon I feverishly created and updated use cases, which were reviewed by the team on each successive day. Use case analysis let me quickly interpret the requirements and helped identify conflicts, duplicates and missing information. During this time, our Web designer created an outline of the Web pages that would comprise the application’s user interface. At the end of the week, we reconciled our two perspectives to produce a unified model.

With an initial set of requirements completed, the next set of challenges was upon us. The Web designer needed to develop a content model, perform usability testing and coordinate the design through the management maze—in just three weeks. My challenge was to design an application database, create technical specifications for 15 new Web pages and provide coding estimates during those same three weeks. The database had to be available to the developers no later than day one of the construction phase. Finally, I needed to assist our test organization in identifying test cases, as well as prepare for and conduct a design review.

Don’t Try This at Home!

Our team produced a great set of use cases, and I modeled them with activity diagrams. Project issues and risks were well documented, but everything needed to be reviewed before the project could proceed. To expedite the review process, I met with our resident application architect, who called two of his architect pals. We gathered at my desk for an impromptu peer review. I communicated the project details, reviewed the content model, proposed my design ideas and answered questions until they were completely satisfied with my answers and convinced that I had thought of everything. This casual gathering was no less thorough than our traditional review meetings, and proved invaluable to the project’s overall success. Without the skill and trust of my helpful architect friends, I would have started a three-week analysis and design phase one week behind.

Analysis and Design

Next, I scheduled a series of joint application design meetings. I believed it imperative to lead the team through the problem-solving stages together, to develop the application design collectively. Each meeting was scheduled several days in advance, always had an agenda, and never lasted longer than two hours. Participants included the application developers, database analysts and our testing lead. The technical project manager and application architect were also invited as optional attendees, and came to most sessions. Our Web designer was just a phone call away and made several appearances to assist us, often interrupting his own work. However, no more than seven people were present at any meeting at any time, and I invited only those people who could contribute directly to the discussion or make a command decision—I had no time for spectators.

The meetings were lively and productive, and we collaborated like crazy! The database analysts pored over the use cases with a fine-tooth comb, communicating their perspective and contributing to our overall understanding of the business problem. The application programmers were instrumental in the development of a solid database design, and our testing lead asked pointed questions as our design took form, in essence testing our assumptions, analysis and design while it was happening. Our complementary technical skills were fully utilized in these discussions—as was our interactive ability. We listened to each other, communicating openly and continually building upon each other’s ideas. It was quite liberating, playing in each other’s sandbox without reprisal, meshing as a team, all in the pursuit of excellence—and it worked.

As before, after we met in the morning, I furiously modeled and documented in the afternoon. The design was completed with time to spare. The formal design inspection lasted all of 30 minutes. Our collaboration of analysts, developers, testers, designers and architects created a high-quality product in an impressively short time.

Men (and Women) at Work

The development and testing phase of the project was a non-event until the end. Since the development staff had contributed significantly to the design, they had a strong commitment to following the specifications. And since the testing lead also participated in the design sessions, she, too, proceeded to develop her test plan and test cases without further ado.

We integrated our new application into the test environment on schedule. System and user acceptance testing were conducted concurrently, and everything was going very smoothly. Of course, as with any project, there were a few bumps in the road: Rate tables weren’t finalized until very late in the process, unexpected change requests emerged from user acceptance testing, and several content tweaks were requested by our project sponsor. Just days before our production date, we hit a major pothole, however. An important requirement related to a customer’s eligibility to use the application was missed and initially we couldn’t find a viable solution. For a moment, that pothole threatened to derail the project—but several conference calls and two impromptu stand-in-the-middle-of-the-aisle huddles later, a solution was brokered. Again, our project managers’ ability to focus the team, complemented by a heroic late-hour effort by our developers and testers, ensured that we wouldn’t miss our release date. The show would go on!

Our team assembled en masse on the evening the application was released to production. Technically, we were there to resolve any last-minute glitches—which were notably absent—but we really came to claim victory and eat cheesecake.

Observations in the Afterglow

Early on, we encountered some whining about the aggressive date. OK, I whined about executive management pulling a date out from the dark recesses of their mysterious minds. I even joked about bidding the date down further: First it was 90 days. Then 90 days became 75. “75 days; hey, why not 60?” But in the end, after reviewing the few requirements that were available, the team accepted the date and put a schedule together. Nothing more was said about it. We accepted the challenge and ultimately exceeded customer expectations when we delivered the project in just 69 days, six full days ahead of schedule.

I once overheard a colleague refer to our group as the “A Team,” and perhaps it was an assembly of the more highly regarded analysts, developers and project managers. But putting together a team of highly skilled players offers no guarantee of success. What does significantly raise the chance for success is strong leadership, and our project managers provided this. Sure, they did many of the tasks that typify good project management: They ran meetings, put together a schedule, bought coffee, lined up resources, communicated often and bought more coffee. But more importantly, they sheltered us from distractions: scope creep, management expectations, schedule pressure, revolving resources and so on. They steered the project, rather than trying to control it—and us. Rather than dictating absolute adherence to the project schedule, they made minor course corrections, adjusting tasks, resources and even milestones while preserving the overall schedule. And most importantly, at least for me, was their confidence that our team was up to the task, their trust that we would do the right thing, and their encouragement to innovate, adapt, and improvise whenever necessary to succeed.

The Fun Factor

I also observed a most interesting phenomenon during the project. Without my soliciting their opinion, teammates began telling me that they were having fun. Not just one or two people, but everyone on the project at one time or another felt compelled to tell me personally that they were having fun. This had never happened to me before this project—and it hasn’t happened often since. The camaraderie created by our cooperation and communication made the project an enjoyable activity.

Finally, we all worked some overtime—but it was minimal compared to today’s standards. We knew what had to be done, we believed that we could do it, and we committed ourselves to achieving it. Self-motivation is a powerful force.

The Secret of Our Success

Have you realized the secret of the Renter’s Insurance Project’s success? I’ve been leaving little hints throughout; a trail of bread crumbs that will lead you to the correct conclusion. I hope it doesn’t come as a shock that the secret of our success lay not in the Capability Maturity Model, process initiatives or prolonged sacrifice of home and family. And though I’m an advocate of repeatable processes, incremental, iterative development and believe in the agile movement, our team wasn’t particularly iterative, incremental or agile on this specific endeavor. The secret of our success is something much more sublime: great leadership modeled by our project managers and emulated by everyone else, technical skill and old-fashioned teamwork.

Principle-based leadership defined by bold actions, not words; strong technical skills for which there’s no substitute; and team members who committed to the cause—who chose to make a difference. This recipe for project success can’t be bottled, loaded into a vending machine and dispensed to those with correct change. Rather, it must be cultivated, nurtured and, most of all, reflected in the words and actions of leaders, both technical and management.

RELATED ARTICLES NIST Releases Guide to Bluetooth Security Microsoft Kicks Off Embedded Device Competition Automatic Photo Tagging and Visual Image Search WiFi, Networked Cars, and Personalized Commutes SafeCode Releases Guidelines for Secure Code		TOP 5 ARTICLES No Top Articles.