CM: THE NEXT GENERATION of ALM Transparency

• well the process is working and how well the team is performing.

From a process perspective, reporting must clearly indicate how things are working.  It's not sufficient any more to have printed documentation (typically out-of-date) showing the process.  Instead, at a minimum, live state flow diagrams should be available and should
reflect the actual data driving the process.  These need to be augmented with a list of "to-do lists" provided for each role.  The executive wants to know that the process is well oiled.  He wants to be able to observe the process from an overview perspective, and make sure that everyone has their data-driven marching orders.  Form reviews, for data entry, will likely be delegated down to the project or process office.  The executive should be able to assume proper forms exist based on the data and capabilities he has through the reporting function.

"To-Do Lists", sometimes referred to as "Inboxes", need to be visible and easily specified on a per-role, and sometimes on a per-user, basis.  The CM/ALM function should drive the team based on the data within it.  When a piece of data is in a given state, it requires a
certain role to advance it through to the next state.  That means it needs to be on somebody's to-do list.  The user interface must make it easy to identify what is on a user's to-do list so that the user is aware of his or her priorities without the need for manual intervention.

From a data perspective, the executive is largely driven by a combination of charts and risk reports.  It must be possible to provide these across the CM/ALM function.  Charts may cover things such as problem/defect arrival rate/fix rate, customer-specific response rates, project schedules, product and development status, requirements coverage and verification results.  At one level, a basic set of functionality must be provided out of the box. But at another level, the executive must be able to ask for specific reports and have them readily available.  Better yet, the tools must support easily-specified, interactive queries for facilitating meetings.  If reports don't have to be cut and pasted into a presentation all the better.  If what-if scenarios can be easily dealt with, even better.

Data reporting includes the ability to design custom dashboards for each management role.  In some cases this will take a few minutes, in others a few days.  When it goes beyond that, it tends to be less useful.  Dashboards need to be in drill-down format so that the top-level status information can be expanded into summaries and drilled-down to the details in specific cases - such as for emergency problems or for high-risk items.  

Summary charts should be interactive so that any line of a graph or bar of a gantt chart can be zoomed into for a greater level of detail.  In particular, the need to traverse traceability links must be present.  One record at a time traceability is better than nothing, but the ability to instantly traverse a whole set of records is much better oriented to the manager.  Some managers want to know which requirements have failed in a test run.  Others want to know what features and problems are being delivered in a new release.  Others want to know what resources are required to complete a proposed set of
functionality.  These all involve a level of traceability.  Advanced database capabilities are a pre-requisite to such capabilities.

From a tools perspective, it's important to be able to identify which tools are in use at which time.  Did a new accounting system cause the sudden change in corporate performance or was it a real change?  Are the CM tools adequate to ensure that what we say we're delivering is what we're delivering?  Are changes to the toolset properly verified
and authorized?  This is a level of functionality that more directly impacts on the Sarbanes-Oxley