SDLC Is Not the End

April 8, 2013 • Management Practice

Many years ago I was privileged to represent my country at commemorative ceremonies in Egypt for the 50th anniversary of the battle of El Alamein. Churchill famously said of the outcome of that battle “Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.” In the IT world, the major projects are our wars; so – if you’ll grant the metaphor – you know what it is to feel victory around the corner, only to find yourself months later still in the trenches and no end in sight.

Successful navigation of the SDLC is one major battle in any software project which all too often is confused for the whole war. Software projects include the system itself but also a host of associated deliverables plus necessary adjustments made to displaced or amended systems and processes. Training and training materials are obvious ancillary deliverables often overlooked; others are the instructions for help desk personnel, the sun-setting of existing systems, the establishment of communities of practice, and so on. It can be thrilling when software is delivered, and even the users may get excited as promises of the new and powerful capabilities start to come true. Churchill’s words were meant to caution against overconfidence at a similar point of exhilaration.

Here is an incomplete checklist of things which may slip through the SDLC that a project manager should consider in order to win the war.

Requirements: This is well inside the SDLC tent but is still very often skipped over too lightly. We in IT tend to believe we know what the users want. I was once the project manager on a project that included a component to automate account opening tasks that had previously been handled by back-office staff using green screen terminal emulators. The advantages of the Windows system were obvious to us; but not to the users. All that clicking and tabbing around the screen took more time than simply typing the two-character command line codes that flowed out of their fingertips without a thought. A little more time spent on requirements would have helped there.

What did the users ask for? What do they want? What do they need? These are probably three quite different things. Managers need to be sure they recognize the differences, have made intelligent decisions about how to reconcile the discrepancies, and are prepared to deal with the users when the distinctions become manifest upon roll-out.

Change Management: the crux of a successful system implementation is the cut-over. Whether it’s an overnight roll-out or the old and new systems are run in parallel for two quarters, the ground must be carefully prepared. Make sure training is adequate and timed appropriately. It should happen as close to the moment when the users will start using the new system as possible. Reference materials often seem like a waste of time. Did anyone ever look at those massive binders they used to carry back from the training room? Now we put even more information online; yet it’s still usually easier to google the question than it is to hunt the answer down through the data dictionary and object model arcana of the online manuals. But it’s not the frequency of reference to this material that determines its utility. If the user can look something up and eliminate a frustration or roadblock just once – when they really need it – the efficiency and likely adoption success is much enhanced.

Ongoing Support: probably the most often neglected. A runway is needed for new users as staff change and the organization grows. Instructions, training and mentorship will be needed long after the project launch coffee mug is thrown out. The help desk needs to know how to handle or redirect problems. Consider establishing and supporting a community of practice. This is a network of users across the organization tied in to the IT department experts that shares tips, sources and lessons learned. Managers and the corporate culture need to support this semi-formal structure. This can be done by recognizing those who contribute and even sending people to conferences associated with the new system. It may also be worthwhile to provide collaboration tools, like a SharePoint site.

Retirement: don’t neglect other stakeholders by forgetting to decommission the old system. Servers can be turned to other uses, service contracts can be expired, licenses non-renewed. Large organizations have been known to continue to pay for upgrades on software they no longer use. Scour the landscape for processes that can be eliminated with the new system. Look at help desk instructions and backup routines, for example. Every kind of win improves the organization’s perception of the system’s success.

Hope for the Future: no significant system is ever complete upon initial delivery. Gather enhancement suggestions from the user community, let them know when upgrades can be expected, and deliver them. Those features that didn’t make it into the current release can become the sand in the works that kills user satisfaction and discourages adoption. Once people hit the steep part of the learning curve it doesn’t take much. New features on the horizon are both carrot and stick: users are encouraged to work with the new system, knowing it will get better; and they’re reminded that the system is part of the permanent landscape so they better get used to it.

Good strategy is supposed to prevent one from losing the war despite having won the key battle. The military metaphor is risky: there should be no violence in a software project and users are not the enemy. But projects are lengthy campaigns that require detailed planning, good intelligence and careful execution. The key is to focus on the next battle and not past victory.