It was simple. Submit our request for changes or enhancements to the product. It then goes through a prioritization effort and depending upon where it lands, we get our features or we don’t. That was the process, but few people believed in it. A lot of requested features never got into the product, at least not through this process. Instead, many of our new capabilities were introduced by what could best be described as “hostage taking.”

Just as a product was ready to ship was a very vulnerable time for us. We had huge financials and huge volumes hanging on shipping the product on time. The account managers, who were supposedly on our side, would then tell us the customer needed an additional “X” capability for the customer to take the product. Wait a minute? Didn’t we already work out what we planned for this release?

An investigation showed that the customer would complain that a product didn’t work as desired. The account managers would “agree” and “go to bat” for the customer. Yet, under closer scrutiny, the account team never submitted the needed feature to be prioritized. Even though the customer complained about the same thing on the last few product releases, it never got formally requested. What was going on here?

What we found out was there were a lot of small features and small changes the customer wanted. With each new product customer review, the customer would mention them again, and the account team would raise them to the product team as “we have to have these to ship the product.” The account team would tell us that these were “defects” because the product didn’t work as the customer expected it to. Because they were small and because we had so much riding on the release, we would relent and say “OK, we have to do this.” In fact, this method worked so well, as compared to formally submitting a request for a new feature, that this was the primary way the account team would get small features and changes into the product. It worked better to hold the product hostage at the end then it did to use the formal process.

Well, I decide to fix this. First off, no last minute “features pretending to be bugs.” Secondly, I got the account teams to submit all the requests direct to the requirements process (product owner), just like the process was laid out. The product owner and development team project manager agreed that this was the way to go. Development got a huge list of small features. After considerable discussion, the development management PM finally said they just couldn’t do it. The account team, unhappy with me, went back to trying to hold the product hostage as a method of getting a few small changes into the product.

The core problem appeared to be that we were formally structured as a huge waterfall, while in fact we operated incrementally. Because we were always late with a product and always adding new features after the “formal” deadline, development had concluded that “requirements creep” was the main reason we were not delivering products on time. Since we actually operated incrementally, building up the product and adding features over time throughout the entire project, development could always show a large creep relative to the waterfall deadline that existed about 12 months prior to the product shipment. The creep was not real, more just the disconnect between the plan and reality, and we discovered it didn’t contribute significantly to project lateness (once we got the schedule right). Holding the product hostage at the end of the release was just the final step to get in the last needed refinements.

If the way changes get into our product is by hostage taking, then that is a good indicator that something in our requirements process is not working. It may be too much “waterfall” or is might be a lack of process discipline (e.g. no confidence that the process works). Whatever the reason, taking hostages is a big neon sign saying we need to look closely at and probably fix our project management process (e.g, make it more incremental, agile, etc.).