By: Craig Lamb

Publish Date: //

I have had the privilege of working on hundreds of software projects over the last 20 years. Throughout my experiences, I have been the developer, the architect, the project manager, and an executive sponsor. I have seen a lot and held many changes in perspective. Further, some of the projects have been considered ‘failures’. It sucks, but it has happened.
I have read a ton on “Why Projects Fail” and they list the standard stuff, like ‘scope creep’, budget constraints, missed deadlines, bad clients, bad development team; the list of standard reasons are quick candidates for the defeated. I have to tell you, from where I sit, these reasons are symptoms of a solitary issue that feeds failure. Failure comes with a failed process – simple. Failure, in anything – not just software development, is a series of missteps, not a singular event.

Failure is not a singular event but a series of missteps.

Isn’t that truth a bit harder to swallow? That means that a project failed over time and, if you’re the project manager or sponsor on either side of the equation, you hold the responsibility.  But there is good news. Just as failure does not fall in your lap as a single event, nor does success. Trajectories can be changed, fates altered, jeers to cheers.
How, you ask? A repeatable, agile, and simple process.
Allow me to digress for a second, and point out an interesting observation that supports my assertion.  If I had a nickel for the number of times that I met a client’s project manager and, when asked how they were assigned to the project their response was something like, “Well, I am kinda the most versed in the web in my department” or some other “technical champion” duress has been applied in the assignment, I’d have a bag of nickels. I have always found this curious.

If a project process is clearly mapped, defined and followed, why would the client PM need technical aptitudes too?  It’s like bringing your friend to your doctor’s visit because your friends uncle married a doctor, and they can keep them honest. Weird, right? If you needed to do that most people would think you should choose a better doctor. If you chose a technical firm to work on your project based on trust in their skills and process, why would you need to have technical expertise as well?
Ok, so, failure is a series of missteps; scope creep, budget inflation, extended timelines, and others. We get it. How are these land mines averted? Well, each firm has their own method but I’ll crow about our process steps, as it is the hard work of a bunch of super smart people. Even Envative didn’t start out being awesome, it has definitely been an evolution.
  • Translate requirements to interactive wireframes prior to coding
    • It takes the words off the page and offers a visual catalyst for consideration and critique
    • Money spent on interactive wireframes has saved thousands in development costs
  • Set expectations for project review and keep them
    • We employ 2-week sprints, stealing the best practices from the Agile development methodology but ignore the ‘project never ends’ stuff.
    • Reviews allow for budget and requirement auditing, it keeps the players engaged and abreast of efforts
  • Establish “rolling” release schedules
    • Everyone has a ‘must go live date’ but rarely does it include the entirety of an application or system. Establishing the hot buttons and making sure they are ready keep the teams organized and harmonious.
  • Hold “Failure” Meetings
    • Collectively, it is a great exercise to ask the teams, “What can cause us to fail, at this point?” This is not negative, it allows for people to voice their concerns with ample time to proactively address potential issues.
  • Define Phase 2 – First
    • Software is never ‘done’. Never. There are code freezes, versions, and editions, but it is never done. Technologies evolve, processes evolve, management changes. It is important to identify what’s next, if for no other reason than to aid in smart development.
  • Communicate – A lot
    • Even reporting that there are no issues to report is invaluable to the tenor and cadence of a project and, don’t kid yourself, momentum has great value. Things that matter are measured and things that are measured are reported. You can’t go wrong in constant communication.
Can you see how each area supporting success is a series of events, just like failure? So, was there ‘scope creep’ or did you fail to illustrate requirements or properly identify the appropriate phase? Did you run out of money or not audit the budget frequently enough?  Did you silently worry about an issue or share with the team?
No one likes to fail. Next time you’re looking to work with someone on a software project, be sure to ask about the process after you’ve determined they are technically qualified. It will insure success and your coworkers will speak your name in reverence for evermore. Trust me. I have a friend whose father is a doctor.