Nothing can make or break your project’s success or perceived success like release management and deployments. Miss a release or deployment date, and not only will you incur additional costs but your lack of planning and success can endanger your company’s very existence. So, this begs the question: Why do we wait to discuss releases and deployments until the last minute? Is this a result of our lack of planning and knowledge, or is there a deeper reason why we fail to plan properly? Keep reading while I dig deeper into this portion of the software development lifecycle (SDLC).
Why Do We Fail to Plan Releases and Deployments Correctly?
The reason for failing to plan releases and deployments correctly has nothing to do with deployments and releases at all. It simply boils down to our inability to estimate our workload. By no means is estimating a science; it is a mix of number crunching, educated guesses, and, sometimes, stabs in the dark. Estimating should take place at the beginning of the SDLC. But schedules can slip and dates can be missed if there is even one failure in the estimating process. You can miss dates and lose face internally or externally if you underestimate or overestimate. Unfortunately, there is no silver bullet for estimating the time necessary to fully complete development and testing. This does not mean that we can’t become better at it—we can just never be perfect.
We should be continually estimating and changing timelines rather than sticking to hard dates that can never be met; however, this may be impossible if the change is mandated by a governmental body. Because technology is constantly changing, we should be continually estimating. I find it hard to believe that anyone knows precisely where we will be in two or even five years. For example, cloud computing is one of today’s hot topics. However, cloud computing could come crashing down if a flaw in security is found resulting in a major breach of data. How much would that change the game in a five-year project? Although there are many other reasons why continually estimating and refining releases are necessary, the fact that things are constantly changing is the main idea to come away with from reading this article.
Release and Deployments as a Competitive Advantage
Two cases come to my mind as the best examples of using release and deployments to your advantage and, sometimes, disadvantage, the first being the Microsoft XBox 360 gaming and entertainment system. Microsoft released this product before competitors at Sony and Nintendo had their next-generation systems ready. Initially, it looked like this advantage would spell major success for Microsoft, but, in the end, Nintendo’s Wii gaming system won this battle by making its system family-friendly rather than making a system designed with the individual gamer in mind. This is one case where launching a product early to market didn’t work out as well as the business hoped.
The second case involves the 2005 redesign of the Ford Mustang, when an early market release sent other companies into a tailspin trying to catch up and release their products in hopes of cashing in on a trend. It took Chrysler three years and GM five years to release retro versions of their vehicles from the muscle car era. Ford took full advantage of its three- and five-year head start. No doubt the company had this release planned for several years, and knew of the advantage it had on its competitors. While this may not be an information technology example, it does show how important it is to plan your releases and deployments.
How Do We Plan Releases and Deployments Better?
While I alluded to the benefits of better estimating earlier in this article, there is more to this story than just estimating well. However, that is not discounting estimating—all areas of the SDLC must be improved: from the vision to project approval to the project plan being written to project charters, SLAs, CM plans, etc. So, we have to begin with a vision that is doable. IT can’t solve every problem until business and IT align in purpose, drive, and execution. Project plans must include not only the vision’s layout and direction but also the various risks that may occur given the agreed-upon direction: Risk must be managed. Most groups simply list the risks involved while never updating or considering that other risks occur as the project goes through its lifecycle. The project plan must be a living document to be changed as needed as the project progresses. However, it’s typical that the initial documents are written and never revisited unless a conflict arises, in which case the players find out this was never anticipated or that the document doesn’t reflect the current reality.
Additionally, most groups become reactionary rather than proactive once the project slips on a date or an unexpected risk arises, which causes projects to fall apart. Dates get pushed back or left alone, and the project becomes unsalvageable as the failures mount. On the flip side, not all arising risks will cause failure, and slipped dates may not be the end of the project’s success. How we react to those failures and missed dates can be the difference. Getting out in front of issues will always be better than simply ignoring them.
How Does This Tie Together and How Can We be Successful?
We need to be willing to talk about release and deployment not only at every step in the SDLC but also at every meeting, in every email, and during every project discussion about the effect on our release and deployment dates. All too often, we build silos in development, testing, operations, and project management that do not allow us to see beyond the current situation or put out the potential fires threatening us in the moment. We get so lost in the details that we ignore or blatantly disregard the bigger picture. So, what we end up with is a project that is out of scope, out of budget, and out of time. The finger pointing begins and blame is assigned.
Open communication between all groups involved is the one thing that can help tear down these silos of inefficiency. We have to be honest with one another and not fear that if one failure is noticed and brought to everyone’s attention that the person or group will be afraid of the consequences. Sweeping issues under the rug compounds the severity of the problem and the length of time it takes to fix the mess made by the cascading failures that occur afterward. If we continually update and change the plans and estimates that we create and openly communicate with each other, successful releases and deployments should be the order of the day.
