Raising the BarIT organizations are looking for new levels of productivity. In an era of relative talent shortages, the ability to seize business opportunities depends on making dramatic increases in productivity. At the same time, the government has raised the bar substantially with governance mandates such as Sarbanes-Oxley. Add to this globalization, outsourcing and distributed work forces that have the effect making even smaller companies manage teams over geographic and time zones. However, the coming whammy is the dramatic loss of talent looming up as baby-boomers retire.
Increased productivity is no longer a prerequisite for profitability; it is becoming essential for survival.
Integrate to Automate, Automate to Increase Productivity
The oldest standby for increasing productivity is to achieve new levels of automation. Back to basics, the biggest enabler of automation has always been new degrees of integration. Therefore, IT organizations are poised to make huge leaps in the area of integrated tools and processes.
Large vendors such as Serena and Borland, as well as newcomers such as Neuma Technologies with their CM+ product, are moving into this space. They are or will soon offer deeply integrated suites of software and out-of-the-box process models. Moving into this brave new world of deep integration without creating corporate trauma will require a clear understanding of what the functional elements are and how they fit together.
Make the Foundation Simple and Strong
The first concept to understand is that these systems must sit on a foundation with one key characteristic:
Incoming requests must be separated from outgoing changes, and both must sit on a universal task management facility.
Incoming Requests
Incoming requests to fix defects or add feature enhancements will always include some we will defer immediately, some indefinitely. If not deferred, those requests will require further consideration, before we decide how to dispose of them.
Therefore, incoming requests will consume some portion of available resources to research need. Need includes specific and general importance, impacts and resources. Need also includes time estimates and approvals.
After establishing need, demand planning will include formal funding availability, allocation of resources and project creation.
Because incoming requests will always exceed supply, only a subset of incoming requests will become outgoing changes.
Outgoing Changes
An outgoing change does not occur until someone decides to approve, fund, resource a request and, most importantly, make it some type of project.
Projects can be large, medium, small or tiny - but we must treat every outgoing change as some type of project. Projects can include sub-projects, iterations and deliverables. Deliverables can have sub-deliverables, parallel sub-tasks and relationships to files, other deliverables and objects like file-sets and baselines. Baselines can have releases and we can deploy them to multiple customer destinations.
Tasking
Both incoming requests and outgoing changes will consume resources. Therefore, it is important to feed all resource use information into a single resource repository from where we can share it. This includes both planned use as well as actual use.
Standard Building Blocks
After the foundation, we need to establish the standard building blocks out of which we will build our integrated system. The following building block summary lists these management tools. The tools represent both data ownership and processing functionality:
- ticketing
- requirements
- portfolio of projects
- projects
- deliverables
- cross-project views
- baselines
- releases
- customers
- deployment
Understanding the Standard Building Blocks
While there are many details associated with each building block, this section identifies the essential characteristics. Where you are already familiar with a building block, you can skip over that section (or compare notes).
Ticketing Management
A subset of tickets will always be enhancement requests and problem reports. These will flow into requirements management. Ticketing will also provide feedback to the persons associated with the incoming ticket with messages and notifications of implementation, rejection or questions.
While the bulk of support tickets are NOT enhancement or defect reports, there is little or nothing to gain from separating help desk ticketing. Enhancement requests can have a business or technical orientation. You can orient defect reports by external users and internal test or development.
Note that the distinction between and enhancement and a defect can be moot. For example, is a hole in a design a defect or an enhancement? In the same way, the distinction between a help desk ticket and a defect or enhancement can be difficult to determine. For example, single reports can encompass all three, and multiple reports can duplicate all three in myriad combinations. Therefore, it is only important to keep ticketing pure and, at a minimum, let the sorting and filtering of defects and enhancements take place in requirements management.
Requirements Management
Requirements management is perhaps the most important of these development tools. Study after study shows that the cost of finding and fixing problems explodes after the requirements phase.
The first requirements step is categorization. This is followed by analysis for impacts, resources - both general and specific, approval to implement and implementation prioritization. Enhancement and problem analysis and investigation might also include return on investment, architecture, technologies, restrictions, abeyance and non-technical subjects. A subset of enhancement and repair requirements will flow into portfolio management.
On the feedback side, requirements notify ticketing of implementation, rejection and questions.
Requirements can also include standards covering government, industry, platform, corporate or departmental needs.
Requirement can include early planning, collaboration and polling. These can cover needs related to the business, technical, test, documentation, system, facilities, finance and staffing. The integration of these functions under a single roof is an area where both vendors and IT have many opportunities to improve productivity.
Because requirements have a categorization component, they will include logical structures, responsibility and physical systems, in addition to product functionality. Relationships between other integrated objects, including parent/child and named relationship needs analysis.
In addition, there is a growing awareness that requirements analysis is not complete until test execution and results reporting are in place. These include such things as testability, logs, exception handling and metrics.
Portfolio Management
After combining sub-sets of requirements approved for implementation into projects, they flow into project management system. Every requirement must become part of a project to progress. Project managers should no need to assemble projects so they can focus on the details of managing projects. Projects can be tiny - a single change, or scale up to huge - hundreds or thousands of participants.
On the feedback side, requirements management is notified of implementation, inability to schedule or questions.
Inside portfolio management, approved implementation requests have two states: awaiting addition to a project or in a project. The available resources are match to specific and generic resource requirements, as well as the time needs. There are three types of projects: actual, proposed and in-progress.
Project Management
After decomposing project requirements in deliverables and deliverable responsibility, including sub-projects, and deliverable hierarchies, they flow into deliverables management. It is important to note that every project completion requires some set of completed and approved deliverables. In the same way, any completion of any phase or milestone will require approval of some deliverable sub-set.
Project managers must work with development management to identify all deliverables requiring either creation or update. Every project must be decomposed into deliverables. Deliverables can be tiny - a single change, to an existing file or records, or scale up to huge - hundreds or thousands of deliverables.
Deliverables are grouped by responsibility and any required sequence of completion.
Projects feed back to portfolio management notification regarding implementation, inability to start or complete project and questions.
Project phases include task hierarchies organized by deliverable responsibility, as well as milestones and critical path analysis.
Deliverables Management
After decomposing project requirements into deliverables, development managers must work with individual developers and others to identify new or existing files, records, schemas, hardware and other artifacts needed to complete that deliverable. Developers and their managers must manage sub-deliverables by responsibility area.
The feedback loop notifies project management of implementation, changes to deliverables, inability to start or complete deliverable work and questions.
After identifying specific version control file artifacts, identify others such as requirements repository artifacts, non-version controlled file attachments, text, table and graphics artifacts, as well as non-requirements repository meta-data.
Each deliverable type must follow a standard lifecycle workflow for managing the change work. Each needs to establish and finalize relationships to other integrated objects, including parent/child and named relationships.
Cross-Project Management
Deliverables management feeds Cross-project management. The facility provides a way to see a horizontal slice of responsibility through multiple projects. It is a facility needed and used by line managers and individuals working on multiple projects. It lets them manage their tasks and critical path. Cross-project management can be restricted to receiving and presenting data, but needs no such restriction in a well-designed system.
File Version Control
After deliverable and subordinate artifact identification, sets of files must be baselined. Hardware and other non-file artifacts can be represented by files and baselined also.
On the feedback side, deliverables management is notified of implementation via changes to artifacts or deliverables and by the inability to start or complete artifact work.
Standard resource for storing formally controlled file revisions include meta-data, file revision comparison and file type lifecycle workflows for managing the work. Each file needs to establish and finalize relationships to other integrated objects, including parent/child and named relationships.
Baseline Management
Baselines must be released to pre-production and, when they pass muster, into production. Version control is notified of new or rejected baselines or the inability to release baseline.
Baselines are named sets of version controlled files and requirements artifacts. Each baseline type uses a lifecycle workflow to manage progression. In addition, each baseline can have meta-data, file state filters and relationships with other integrated objects.
Release Management
Releases must go to customers, including any packaging differences, SKU's and so on. In the other direction baseline management is notified of each release, the inability to release or of a rollback to a previous baseline.
Named releases can include meta-data, release path information and file type filters.
Customer Management
Customer releases must be deployed into their environment after which release management is notified as required. Named customers can include meta-data.
Deployment Management
Customer management is notified as required. Named customer deployments include meta-data and deployment conditions. Deployment conditions include pre-deploy, deploy, post-deploy, source and destination information.
The End Result
The end result is a contiguous, integrated system combining data and functionality that is capable of managing every aspect of change, from inception, to final deployment. Graphically, the incoming request and outgoing change sides looks like this:
