In my last post, I introduced a new way to leverage Cim for group-to-group Channels that increase interactivity. In this article, we are going to look at a business scenario that takes the Channel approach and integrates it with a more standard innovation management workstream. The scenario is IT Requirements Gathering and the solution provides a solid way to reduce costs, increase collaboration, and drive efficiencies and effectiveness.
Does your organizations’ IT department gather requirements for new applications, changes to existing applications or infrastructure, or new infrastructure projects? How is this done? Meetings perhaps? Emails? (lots of both) Is it considered effective? Are the “customers” all local or are they distributed? Do you ever get the questions later on as to who wanted a given requirement, or how important it was ranked, or whether it got into the project?
Requirements gathering is an art. If you take a look at the normal requirements gathering process, in most organizations, it not easy or neat or efficient. It is a challenge of engagement, balancing, documenting, feedback, prioritizations, and politics. When you are working on requirements with “customers” that are across the earth, it is even more challenging. Further, the flow from the “customers”, through the requirements manager/process, and to those that are doing the project is usually quite constrained – particularly the upstream visibility and interaction from the “developer” to the customer. The historical record of how the requirements came to be is usually impossible to decipher or get your hands on in a convenient manner. We can do better.
Below is a schematic that depicts a process leveraging CorasWorks Idea Management and the Channels approach. The IT department has a management hub to gather and work up requirements and manage all requirements projects. When a new potential project comes up, they create a Channel community between them and the associated “customer”. Most often the customer is a single business group or department. That customer then has the UI for this requirement process right there in their portal – very convenient. If the potential project is with a cross-functional team, then, you create a Channel from IT to a site being used by the team (it is a cross-functional portal).
Then, the interaction starts. IT may set a timeframe, say 30 days for the requirements process to happen. The customers start entering requirements or the IT department can post those that they have. Everyone within that Channel can review, rate, and comment. There is high visibility. The customer (usually many people) can “trade” amongst themselves and the Star Power ranking shows their prioritization. IT can respond with feasibility information or comments. It is highly interactive. It is asynchronous – meaning people can engage whenever they want or need to.
IT then processes the requirements in the hub. They are already initially prioritized by the customer. They may feed back summary documents or specs to the customer for vetting via the Channel. Once they are set they push the approved requirements into the project sites that they have created. The people working on the project can do their work and can interact directly with specific people from the customer on specific requirements. If you leave the Channel open, new requirements or changes can flow through. There is a visible and persistent history of what was proposed, said, by whom, decided, assigned, and the status. Routine updates can be provided via the Channel as the requirements process becomes a development/implementation project.
This scenario is a standard idea to innovation workstream using Cim. Except these are not individual ideas but a collection of related requirements for each IT project. They use point-to-point Channels to make it convenient for people to engage from wherever they normally work and to enable a high level of visibility and interactivity for this specific project. The Channel can be used for the Requirements process, the implementation/development process, and even, future change request management.
The upshot is that this solution can take a challenging and not so neat process of requirements gathering and make it considerably better. Just add people…