Notes on the Solution Delivery Process

IT Solution Delivery Processes are basically road maps for taking IT-related ideas from conception through implementation and maintenance. These IT ideas are inevitably affected by (driven by) one or more corporate Business Practices (e.g. business principles, business goals, business processes, and the quality of services and products provided). Add to this mix that Corporate Governance is an increasingly important corporate issue, and IT solution delivery processes can become bogged down in administrative overhead. My general management-level techniques for handling these complexities, including governance, is outlined in the upper right-hand corner sub-image (expanded view) of the following figure. Below this sub-image are listed some typical project-management-related activities. The larger portion of the figure below shows high-level relationships between various solution delivery components (represented as packages in a model-driven development environment). Relationship lines indicate the component realization paths and who "owns" each component. How these components fit into general project activities is indicated by the solution delivery swim lanes. Actual projects will generally implement some subset of these components.

Note: The intent of this diagram is to indicate general relationships between Solution Delivery components, not to show rigid processes.

While there are many solution delivery methodologies for launching projects or designing, building and testing solution components, the ones most popular, currently, are "command-and-control" and "agile" (my form of agile project management, taken from Scrum principles, is outlined in Agile Project Management, which also touches on some of my agile application development techniques, taken from XP principles and previous RAD experience). Specific activities and tasks, their order of execution and the tool sets used for implementation generally depend on the type of problem at hand, the corporate environment-of-the-moment and the methodology used (e.g. Agile), though many activities, tasks and work products are common across methodologies:

Project Launch: Start with a vision; define scope / constraints; identify stakeholders; gather requirements; build use cases; gather as-is enterprise architectural and business processes; gather possible to-be architecture(s) and create high-level interaction diagrams; formulate high-level release schedule; explore choices with stakeholders; build prototypes, pilots, simulations as necessary; insure development environment adequacy; document status and plans.
Risk Investigation: Identify, categorize and rank requirements and to-be architectures with respect to timeframe, quality and costs -- associate risks; identify ways to mitigate risks that may jeopardize one or more of the project’s objectives; explore choices with stakeholders and document status.
Component Design, Build and Test: Refine use cases, interaction diagrams, to-be architecture and release schedule as needed; review and refine run-time to-be test topology, exercise change management as necessary; develop component test cases, database schemas and code as necessary; unit/integrate test as necessary; import development environment functionality into test environment; perform usability/acceptance tests as necessary; perform stress/load tests as necessary; re-estimate project particulars. Each component cycle produces a working, tested, documented and integrated (yet incomplete, from a project viewpoint) version of the final product.
Production Build: Plan release; review and refine run-time to-be production topology, exercise change management as necessary; import test environment functionality; build and load/stress test the production environment. Document run-time topology.
Production Deploy: Produce the latest working and tested version of the product, in the production environment. Document deploy.
Corrective Maintenance: Transfer ongoing maintenance responsibilities to appropriate groups.
Production Build Cycles: Incrementally build toward (convergence to) the original long range client objectives.
Extended Production Build Cycles: Incrementally build toward (convergence to) extended client requirements, re-evaluating risks as necessary.
Evolutionary Production Build Cycles: Incrementally build toward (convergence to) evolving client requirements, re-evaluating evolutionary requirements and risks as necessary.
Work Products: The outcome of an activity task. May or may not be a deliverable.

Site managed with MyEclipse, a multi-language, multi-platform IDE