Sticking the Landing – Driving Success in your Software Project

In the thirty years I have worked within software development I have been part of many software launches. Some have been tremendous successes, some not so much. I’ve been fortunate that the majority of these projects have been successful (for the most part) but there have been one or two near disasters along the way.

Before I start I’d like to stress two things. Firstly I’m not including arguments in favour or against either Agile or Waterfall processes here. Yes, they will be very important to the delivery of any project but they’re somewhat tangential to my focus here.

And secondly, if you were looking for me to air the dirty laundry of the past you’re going to be disappointed. I’m not going to – not even under the false pretence of a “names have been altered to protect the innocent” gambit. ?A quick read through my LinkedIn profile would be enough to tie such examples up with the companies concerned.

What I am going to mention though are a few thoughts around why I think some launches work and some…well, don’t. And I’m going to start at the beginning.

Planning Phase Problems

The most critical part of any project is one that is so obvious you might not think it a potential problem. To stick the landing, you have to know where to land.

Or to put it another way, everyone involved should understand what is being delivered, when and how it is to be delivered, and is in agreement with what success means. It’s a bit like arranging a night out with friends only using the phrase “Let’s all meet up tonight,” but not adding where or when… or what you’ll be doing… or, crucially, whether it’s fancy dress.

And it’s not just the developers need to know what you’re building (and for when). You (the developers) may be creating the thing, but you are far from the only people needed to make this work. Product launches need the ground preparing – and that usually comprises a wide range of non-coding activities.

A typical project will require marketing, customer management, sales pitches, support team preparation (face it, you’re going to get support calls whenever you launch something new), QA/testing, especially performance testing if you’re anticipating high user levels, generation of educational material…I could go on.

Time needs to be allowed for each of these functions to do their part in making the release a successful one. They will all need to be ready ahead of launch day. Coordinating all the actors required is complex. Without having a single cohesive plan before you start it’s next to impossible.

However, it’s worth the effort. When all of these come together (and I’ll mention some thoughts on the “how” of this later) you have a greater chance of technical success on delivery.

But there’s more to getting the landing right than internal consensus. For one thing, does anyone want it? Have you established the appetite in your customer base for what you are looking to deliver?

Whether you are working in an internal development team or for a software provider, your system will have users.

Imagine you work in a software house operating a reasonably successful SaaS model. Internally you have this “great” idea for a new feature you want to add to the platform. Collectively you get your heads together and build the perfect plan, you resource the team as needed and deliver the best software feature your company ever has. Only no one uses it. Why?

Well, simply put, you didn’t take the time to understand the needs of your customers. The best software in the world will fail if no one wants it. If you want some real world examples of technology that failed because the market wasn’t there, go read about the Sinclair C-5, the Laserdisc, Microsoft’s Office Assistant (I still shiver), or New Coke.

Before you start any significantly large commercial project, ensure you’ve established there is an appetite for it, and importantly an appetite for it at the price you will be asking. Talk to your customers, do your market research, build up some early interest, and modify your plans based on what they tell you.

Unfortunately even if you do all of the above well, you’re not home safe. Now you have to build the darn thing.

Development Phase Problems

We’ll assume for the next topics we’ll discuss that during the planning phase you secured the necessary resources to complete the project. We’re not considering the problems arising from attempting a project with insufficient time, people, skills etc. in this piece; another time maybe.

No development phase will ever go to plan. No one will ever foresee every potential hurdle. Not every issue encountered will be obvious to all involved parties. So this is where you need to have coordination. For projects to launch successfully they need to be controlled, you need someone fulfilling the Project Management function.

We are all human. People get sick. You could find yourself suddenly under-resourced. You may uncover Technical Debt that needs to be resolved. First feedback from customers or internal stakeholders might increase the scope of the delivery. Each of these, and any number of other factors, could mean the original timeline is now not going to happen.

So you need to react. Regroup with all needed stakeholders, rationally discuss the problems and offer potential solutions – timeline extensions, increasing the resource in play (although keep Brooks’s Law* in mind if you’re already running late), or redefining what your MVP could be. Any of these approaches could resolve your predicament, pretending it doesn’t exist and just soldiering on is not a wise choice.

Next, when you have a new plan, publish it. Make sure everyone knows the new schedule.

If you don’t, marketing might be sent out with a now unrealistic date, and demo sessions with early adopters could be scheduled before there is anything to show. Having a bunch of very important folks turn up for an eventless event doesn’t bode well. Good luck trying to get them to come again in future when you do have something to show.

Post-Production Phase / Adoption Problems

You have got to the end of the development phase, all testing has passed, the initial feedback from beta testers and early adopters is good, so you think you’re home and dry… Well, no. In some ways you’re now entering the most critical phase, you need to drive adoption.

Some of that heavy lifting will have been done if you did your research right and established this is a useful change for customers, that you’ve designed your system to be very user friendly, and that it is robust and highly performant. But none of that means anyone will use it.

You can’t rely on any marketing material ahead of launch being enough. Most people probably won’t have even read it and those that did are likely to have forgotten by launch day. You need to keep on it, make it front and central on social media, in internal presentations, in conversations with customers – when you speak to someone it’s a simple thing to ask how they are finding the new feature. And if they admit they haven’t used it, offer a quick intro course or to send them the link to a short walkthrough video.

You need to be ready for issues and this is when work scheduling cause problems if not managed well. For all the testing you did, once in production a critical bug or gap might be identified and require immediate remedial action.

But what if the people required to enact the resolution have been reassigned to other work and that work has its own critical timeline? Or are on annual leave? Or additional development work on the codebase means making an urgent release is impractical or impossible?

Important product releases need intensive aftercare. A new feature which fails on release and is not immediately fixed has lost all the positive energy it could have had. You had one chance to make a good first impression and you blew it.

The simple answer is don’t consider the go live date the end of the project. Factor in additional resource requirement for the immediate post-live period.

If nothing serious happens you can always use the time reduce your Bugs Backlog… Don’t try to pretend to me your product doesn’t have in production bugs. We all have low priority niggles. If you have some slack, resolve a few – some of your customers will thank you for such low level fixes so the time will not be wasted.

Reality Check

Will your project be perfect, even if you follow the above? Likely as not, it will not be. That’s the nature of the beast. So look back over what you did when the dust has settled. Praise what worked, analyse what didn’t and look to stick the next landing better.

Footnote

* Brooks’s Law is an observation of software project management, where increasing the number of people on a project that is already behind schedule often results in further delays.

The complexity of the project increases with more moving parts and the ramping up process to integrate new team members often requires existing team to take time away from their scheduled work.