CTS – Your Technology Partner

Seeing Around Corners

Written by Jonathan Cortis on October 5, 2015

Alarm in retro design

When I was growing up and in grade school, there was nothing I liked more than a fire drill.  It was always a chance to experience loud sounds and flashing lights, get some fresh air, watch your teacher generally annoyed and slightly disheveled (without the natural progression of a trip to the principal’s office), and revel in the unplanned chaos.  Do you know who didn’t like fire drills?  Adults who were trying to get stuff done, because a fire drill is the opposite of getting stuff done.

Now that I am an adult, I don’t care for fire drills in my professional life either.  By “fire drill” I don’t mean the loud siren where we all get up and go outside (those are still awesome).  I mean a “fire drill” in the middle of a software project.  Here is how I define a software “fire drill.”  The project is going along smoothly, code is appearing , testers are testing, statuses are green, users are only weeks away.  Then the project isn’t going smoothly anymore.  The alarm has been raised.  People scramble.  Weekends are worked.  What on earth happened, and (more importantly) how can we stop it from happening again?

The biggest misconception about building software is that it is all about the code.  Yes, coding is extremely important.  Having a talented team of developers can mean the difference between having an on-time, clean product or a late, buggy monstrosity.  A project manager who is attentive to the SCRUM board or project plan can see when any particular coding deliverable may be causing an issue.  In my experience however, most projects that are doomed to spark a fire drill don’t do so during the coding phase. Frequently the fire drills happen much farther down the road and even more frequently for reasons not related to coding at all.

There are so many reasons that a project can end up as a four alarm dumpster fire that choosing just one is a futile effort for a blog post.  The project team can get blind-sided at any point within the project lifecycle with a variety of issues;  bad estimates, incomplete requirements, bad expectations, complex environments, data access issues, performance problems, security issues, unexpectedly hard features to code, expectations around legacy systems, integration issues, forgotten data conversions, regulatory issues, or deployment challenges.  Each one of these reasons could be its very own blog post.

What I would like to explore is whether or not there is a common thread among these issues.  As a technical lead or a project manager, is there any single strategy that you can deploy to prevent being caught off-guard?  I would like to argue that there is.  If you are technical lead or project manager who used to write code, think of approaching your project in much the same way you would tackle coding a particularly  hairy set of business rules.  Think about different areas of the project to their logical conclusions, consider the edge cases, whiteboard the possibilities, and put measures in place to manage those occurrences.

Are you replacing an existing system?  You should make sure you have checked with the business to see what scale of data conversion they need.  (Oh, and that old system?  That’s not a requirements document.  More on that in another post though.)

Does your application rely on data from an external system (or three?)  Make sure you start the conversation with the owners of those systems in the planning phase, not when you are ready to kick off deployment.  Also make sure that your design allows you to integrate more systems without a complete rewrite.

Does your project plan show your end date in December?  Make sure you check vacation schedules, environment freezes, or any other end-of-the-year delays.  Factor those into your planning.

Does your website need to support 3,000 concurrent users?  You should incorporate scale questions along every step of your design.

Are you adding members to the team?  Did you plan for time they need to read up on the project documentation, set up their environments, and work with the team lead to come up to speed?

Every one of these items seem obvious when you read them, but these mistakes continue to happen repeatedly.

Keeping ahead of a software project requires more than just confirming that you are prepared for the requirements that are already written down.  You may have a project plan that is perfectly balanced and on schedule and still walk into a crisis.  In order to avert a crisis, you will need to look all the way down to the end of the road and then ask yourself what may be around the corner waiting to jump at you from the other side.  While we cannot always see everything that may be looming behind every corner, we can make a pretty good guess as to what MIGHT be, so we don’t have to push that shiny, red button that sounds the alarm.

Comments

comments