On a project that I worked on a few years ago, we were building a system for managing discounts and promotions on an ecommerce website for a Fortune 500 retailer. The system had two parts, a management system and full integration into the website so that the promotions would show up in the user’s shopping cart.
The development team was small at 6 developers, but was part of a larger effort of about 50 developers. As we came up with the requirements, the development team selected WinForms as the technology so that the end users could get a better experience. They decided that they wanted multiple ways to access the management system functionality, similar to a standard Windows application. The application would have a menu bar, button bar and a side bar showing the objects with right click popup menus.
For an application that is going out to the general public, this potentially might be a great paradigm. In this particular case, I questioned the value as the user population of the management system was only 4 people who were creating the promotions and then managing them through the various lifecycle stages.
I demonstrated that the multiple menu options could not trace back to any business goals and that with even limited training, the users would know how to use the management system. Unfortunately I could not convince the team that this extra work was unnecessary. The client product manager felt that the user interface was “design” and thus should be left up to the development team. My interpretation of the situation is that the development team had several reasons for wanting to implement the functionality in this way: 1) They wanted to work with new technology; 2) They wanted to create a Windows style application as they had been exclusively writing Web applications; 3) They had plenty of bandwidth (by 3 or 4 developers).
What was the overall impact? The extended project team had incredibly tight deadlines and was actually understaffed. If we could have taken 3 or 4 developers from this team, we might have been able to add them to project teams that were in danger of not meeting their key functional requirements.
The final result was that while the promotions project was able to deploy, the extended project was put on hold and not implemented until just this year. I’m not saying that this one subproject caused the meltdown of the entire project, but I would say the development of functionality that did not map back to clearly defined business objectives across many subprojects absolutely contributed.
To close, I will leave you with a question, when was the last time you truly questioned the value of each of the requirements in your application?
