The Product Champion in an IS/IT Shop
In some ways, from a product championing perspective, the independent software vendor environment is fairly well defined. The customer is external, and we typically have a sophisticated marketing organization we can leverage to elicit the requirements and help determine who is accountable for balancing all the conflicting needs. A customer whose needs are not met is simply not a customer. Although that may not be a good thing, at least they aren't hanging around to complain about it.
Such is not the case in an IS/IT shop. There is no marketing department, your customers all work with you, and they will certainly be hanging around after this release to make their feelings known.
Where do you find your champion in such an environment? Perhaps we can again learn from an example.
In one shop, a new enterprise support system was being developed to provide global 24- hour -a-day access to customer records for sales support and license management. The problem analysis exercise identified the following stakeholders:
Each of these departments was quite vocal in its needs, yet it was clear that not all needs could possibly be met. The question "Who owns the Vision document?" looked like a metaphor for the question "Who would like to make a great career-limiting move by attempting to manage this project?"
On analysis, it was clear that none of the leads in the development team had the authority to make such hard decisions, and yet a champion had to be assigned. In this case, the team decided to name Allie, the current project lead, as the product champion and empowered her to elicit and organize the requirements. She owned the Vision document. She interviewed the users, established their relative priorities, and collected the data into a feature-oriented format. But a special steering committee, or project change control board (CCB), was also immediately established for the project. The CCB consisted of three senior executives, each with responsibility in a functional area.
Initially, Allie facilitated a decision-making process whereby the CCB established the relative priorities for the initial release. Thereafter, the CCB, and only the CCB , had the requisite authority to add or delete features, with recommendations coming from the product champion. In this way, there was only one champion, Allie. The results of elicitation and the vision of the project lived in her head and in the Vision document, but the responsibility for the hard decisions was given to the CCB. The CCB would take the heat for the hard decisions. The champion had "only" to see that the agreed-on features were properly elaborated on and communicated to the development team.
Once Allie was empowered to drive the process and had the CCB, including members of upper management, backing her up and taking most of the heat, the project was successful and was used as an organizational model for new projects. Each new project used different project champions . This provided an opportunity for personal growth and development for these individuals. It became an empowered role within the company. And, of course, we can't forget the CCB. For each new project, the makeup of the CCB was established, based on the themes of each new release and the stakeholders that would be most directly affected.
Although there is no prescription you can follow to create a project champion, it is extremely important for your team to identify one, to promote one, or to empower the one who seems to be leading the process already. Then it is the team's responsibility to assist that champion in every way possible in managing the requirements of the applications. This will help ensure a successful outcome. Besides, if you don't help make that person successful, he or she might ask you to be the project champion on the next project.