Role-based Tool Support
As we gain an understanding of the breadth of information we need to manage and the range of stakeholders we need to satisfy as we bring a project to fruition, the roles that need to be represented for major project decisions will tend to naturally break into 3 areas – the Product Champion, the Requirements Analyst, and the Project Manager. While your organization might have different names for these roles (product manager, marketing, systems analyst are common pseudonyms) and you may consolidate several roles into a single person (or even expand individual roles into teams), the roles tend to remain the same.
We need someone to act as the representative for the user community – to make sense of the cacophony of voices that a broad community will have up front, and to ensure that the resulting product will actually address their needs. We need someone to act for the breadth of other external stakeholders and for the business, to ensure that the needs of the users are translated into a clear, complete specification that can be used to build the product correctly. We also need someone to take that specification and run with it, to manage the development community, plan a project and deliver the product to the end user to complete the cycle. Bringing a product to market is a lifecycle that spans ideation, implementation and deployment, with a different focus at each phase.
Our understanding of the roles themselves has been refined over time, from back to front. The role of the Project Manager is by far the clearest, and the discipline of project management has been well established for many years, even if it remains strongly debated in many circles (try subscribing to the NewGrange listserver for a few months to see what I mean). In software, there is a growing understanding of the role of the Requirements Analyst, and the need to invest the time up front to collect and collate the specification of the system so that the development community can forge ahead in an efficient manner. While many organizations have Product Managers or Marketing departments, what is often lacking is the synergy with the analyst and the development community, the cooperation that makes the Product Champion an equal partner in the success of the entire operation. Many small shops will have a project manager, but far fewer even superficially address the other two key synergistic roles.
A well defined tool to support each role can provide a great deal of value to the organization, once the roles have been understood and established. For project managers, tool support is by far the best understood, from Microsoft Project to Primavera to a range of web-based offerings. A huge selection to choose from to support a very well understood discipline – for most medium-to-large projects it would be unthinkable to try to run a project without tool support.
There are a number of tools on the market that support the role of the requirements analyst. Borland’s CaliberRM, IBM/Rational’s Requisite Pro and Telelogic’s DOORS are the gorillas in the market that allow the analyst to collect the requirements information in a form that can be used by the development community, track progress against this information, and manage the evolution of the requirements over the life of the project. This class of tools still has not ‘crossed the chasm’ into mainstream use – there are early adopters in large organizations that are testing the waters – but these tools have become quite refined and support a well understood role. They are not nearly at the stage where it would be considered ludicrous to attempt a project without them, but this is changing.
Just as the effectiveness of the project management tools is a function of the fidelity of the specification that is used to build the schedule (this fidelity being supported by the requirements management tools), the effectiveness of the requirements management tools is a function of the clarity of the information inserted – the voice of the customer. The tool support for the product champion role is just beginning to materialize, with tools that help synchronize the broad range of customer perspectives, and prioritize the broad range of features and capabilities to be developed and delivered. The people that built CaliberRM has tackled this space with a new company and a product called IdeaScope, and there are others growing into the space, such as ProductPath and their Customer Collaboration Server. These are early stage products, the first to tackle what is just becoming a well understood role in the overall product lifecycle. Expect this tool space to become more prominent and crowded in the next decade.
It is interesting to see the industry evolve over time, with an ongoing improved understanding of appropriate roles to develop products, followed by efforts to support these roles in the tool space. As your organization evolves, it would seem reasonable to clarify and understand the roles that are appropriate for your culture and business needs, and then focus on supporting these roles with tools that clearly support each role’s demands. – JB