How to Deal With Software Development Schedule Pressure

The work is due next month, but you know it won't be done for three months. Now what? A group of programmers and consultants met at a recent software development conference to swap war stories and discuss management and firefighting challenges.

By Matthew Heusser
Tue, April 09, 2013

CIO — My alarm goes off at 5:30 a.m. on a Saturday. I'm driving three hours to Dearborn, Mich., to the Agile and Beyond conference. Jim Benson, author of Personal Kanban, is giving a keynote on management anti-patterns.

I'm not getting up early just for Benson, or the 28 conference sessions, but, instead, for a gathering of the Council of Elders, an informal group of Midwest software development practitioners. We last met at the previous Agile and Beyond. Our purpose this time was to discuss schedule pressure and how to deal with it.

Nayan Hajratwala, principal of Chikli Consulting, was back from last year, along with agile coach and consultant Matt Barcomb, programmer David Hoppe and Michael Drzewiecki, a project manager from South Bend, Ind. The band had two new members: Todd Kaufman, co-founder of Test Double Consulting, and agile coach and consultant Sandi Keller.

Grabbing lunch—the only free time slot, as half the council were conference speakers—we found the speaker room and talked about how to deal with pressure.

Software Development Council of Elders
The "Council of Elders" (from left): David Hoppe, Nayan Hajratwala, Sandi Keller, Kevin Redar, Michael Drzewiecki, Todd Kaufman and Matt Barcomb.

When Deadlines Move Up, You Must Cut Scope

CIO.com: You know the project is going to be late. I know the project is going to be late. Someone else figures out the project is going to be late. The pressure's on. Now what?

Hajratwala: It's hard to give general advice, but I can give you a case study of what I am working on right now. It's a multi-year, multi-million dollar federal government project. It was about halfway through…when I got there, and nothing had been built--just architecture and a proof of concept that did nothing.

CIO.com: How can your proof of concept do nothing?

Hajratwala: The big concern was performance, so the team had built the capability to performance-test the application with massive amounts of client connections in real-time. It just didn't do anything yet. I…suggested the team build some features, and we did. After a few months, I looked at the number of stories, our existing velocity, and predicted it would take about six-and-a-half-years to complete. It really wasn't accurate at all, but it was the best we had—certainly better than wishful thinking.

How-to: 13 Tips for Keeping IT Projects Under Control

CIO.com: What then?

Hajratwala: Management did the right thing—cut scope—and managed to cut a few things. That, combined with a better understanding of our scope and a slightly increased rate of throughput, allowed my simple measurements to show we could be done around May 2014. That's when the email came from management: "How about you deliver it in December 2013 instead?"

Continue Reading

Our Commenting Policies