“We don’t release software. It escapes!” (Carl, my former boss and a VP of Development)
My former boss, Carl, once tried enticing me to join his management team by emphasizing how badly the company could use my process discipline skills; it worked. I felt bad for them, and I was intrigued by the challenge. But, I learned at least as much as they did during my tenure there.
Over the course of my career, I have seen many instances of people failing at release management. In this article, I highlight eight statements that I have heard over the years from people in our line of work. Even though these people abide by these statements, they would never dare to repeat them out loud. I hope you will find inspiration not to follow these sayings!
Alan S. Koch:I have added my editorial comments to each.
Don’t Think about Release until It Is Time
“Product requirements are what we need to get the project started. We need to understand what to build and what to test for, so we spend a bunch of time up front figuring these things out and writing them down. That prepares us for the project. Right?”
In Carl's shop, this thought process resulted in a commercially-sold product that was impossible for customers to install. For every new customer, a developer had to carry a tape to their site and do the install for them.
The Business Analysis Body of Knowledge (BABOK) guide focuses on the requirements process, while also highlighting a type of often-overlooked requirement. Implementation requirements refer to the requirements, not for what the system will do and be after release, but for what is needed in order to do the release and deployment.
“But, why should we worry about these things before release? We’ll be able to figure it all out when the time comes.”
Ask:We wish! Too often, though, the reality is unhappy surprises due to a lack of preparation for release (preparation that begins with implementation requirements).