| Description ¨ Background Until relatively recently, software development was based on simple straight-forward mainframe architecture and delivered through independent Information Systems (I.S.) service organizations dedicated to specific business units. However, more advanced technology was required to support business operations and the old organizational structure could not support this more complicated, diverse, and volatile environment. To control the chaos, almost all I.S. departments developed their own processes, none of which were aligned or interrelated. Many of these were informal, requiring ‘tribal knowledge’ to penetrate. Given the close dependence that Architecture, BSD, P.S. and PBO ave on each other for delivery and information, a tight, integrated process is clearly called for. With the advent of newer technology and larger, more complicated projects, another issue has been exposed – a lack of estimating skills. Recently, in addition to these other changes, outside vendors have been called upon to assist in the development of the large projects, each with their own methodology. Without a standard process, however, it is difficult to hold them accountable. In another development, I.S. is being called upon to develop systems that will either be adopted by, or must interact with, other members of the COMPANY NAME family. This has put additional pressure on efforts to improve the I.S. department’s capability to deliver high quality systems and provide measurable value to their customers. In an effort to adopt some common process suitable for developing applications based on newer, n-tier and object oriented technology, the Rational Unified Process was proposed as a COMPANY NAME's development methodology. The higher costs for these projects had to be evaluated and managed, making accurate estimation a necessity. This industry standard process must be tailored to fit COMPANY NAME's needs and be institutionalized across the company. ¨ Purpose The Process Project has been undertaken to develop and document an integrated end-to-end IT delivery process for COMPANY NAME using RUP as the framework for developing software. The Rational Unified Process (RUP) is being customized to meet the specific needs of the environment. The Process Project will consider and blend the needs of every group involved in proposing and delivering technology such as the Business Units (BU), Application Development (AD), Portal Integration Management (PIM), Financial Services (FS), Production Services (PS), the Competency Center Organization (CCO), the Project and Business Office (PBO), Architecture (Arch), as well as the needs of the project teams themselves. ¨ Objective The objective of the Process Project is to improve our ability to make more accurate estimates during the early Inception and Elaboration phases of projects and to improve our ability to estimate the Construction phase where most of the dollars and project effort is typically spent. In addition, a Process supported by appropriately updated examples, templates, standards and guidelines, QA checklists, metrics measurement and recommended training will significantly increase the success rates (defined by quality products delivered on time and on budget) of project teams. Process Objectives Requirements follow documented standards o Requirements are documented and available for review by a QA process Changes to requirements past Inception Phase are agreed to by affected groups o Change control boards review and validate changes o Written policy governs changes o Effects on schedules and budgets because of changes are documented and publicized Estimates are derived according to documented procedure o Guidelines for early estimating are documented o Methodology for detailed estimation (Function Point?) is developed o Estimates are documented and tracked o Actuals are documented and tracked and linked to financial plans All project resources and activity are tracked and managed o Niku entries are accurate o Standard reporting is developed and maintained Provide visibility to software development project progress o Metrics are identified and documented and made accessible o Standard reporting is developed and maintained Standard Process Identified & followed o Documentation to support process (standards, checklists and guidelines) is accessible o Methods for validation and compliance are followed Subcontractors are managed o Reviews of Sub-contractor work are conducted o Cost Benefit analysis of services are computed and considered Quality assurance practice is established o Guidelines for QA are available o Process to govern non-compliance is established o Early inclusion of QA in project life cycle is practiced Changes to work products are controlled. o Configuration Management practice is established and followed Resources are available o Portfolio management (initially simple) is established Common terminology regarding documents, phases, and processes are documented and adopted o A glossary of COMPANY NAME's Software Development terms (stripped of redundancy) is developed, maintained and easily accessible Microsoft Solution Framework R&R are integrated into I.S. Process o MSF model for roles and responsibilities is modified for RUP phases and workflows Process Assets (standards, processes, guidelines, samples) are kept in common library o A central knowledge repository is established and maintained Change to Process over time is managed o An organizational structure will be created to maintain the new process and manage change to it ¨ Business Justification Exorbitant Costs § Projects cost 2-3 x original estimate § Costly amount of rework § Software development extremely expensive Poor Quality § Quality of vendor artifacts can’t be measured § No regard for existing resources/ infrastructure § Inconsistent successes § No way to measure vendors Can’t Measure Progress § No standard way to chart § No standard milestones § Difficult to gauge effect of a change on a project Lack of Morale § IS depts. not involved early enough § Redundant requirements docs § Contingents use own RUP versions § Management frustrated w/ project “surprises” § Heroic efforts needed to succeed ¨ Stakeholders Executive Management Need accurate info on IT investments. Need to track progress with standard reporting tools Project Managers Want standard methods & artifacts to assess vendors, guide workers & work with other departments IS Contracts/ Legal Want guidelines & standards to hold vendors accountable & be able to get accurate, competitive bids I.S. Supporting Departments Need better requirements to make IT better decisions & be involved earlier Business Units Want accurate estimates for time & cost, and more support from IS in developing requirements Corporate Planning Wants accurate info about deliverables & costs & to know if project has changed over course of its development Procurement Need assurance of appropriate involvement in project purchases during development & delivery Business Partners Want appropriate compatibility, connectivity, & communication regarding their systems taken into account Initiative Team Structure (graphic) Practice/ Policy/ Process/ Methodology Used The technical approach to achieving an integrated end-to-end IT delivery process will employ five elements: 1. The CMM Activities for Level 2 Compliance The Software Engineering Institute (SEI) has set up a methodology to institute standard processes for developing software, which is documented in its Capability Maturity Model (CMM), and accompanying Guidelines for Improving the Software Process. The methodology itself reflects a process that has been refined and perfected with usage by hundreds of companies involved in process improvement through the institutionalizing of a common practice. The Process Project will utilize the activities for CMM Level 2. This would not, at this time, include the formal pre-assessment process or certification reviews. 2. The Rational Unified Process While the CMM methodology recommends the use of no one software development process, the iterative approach is the one most recommended by SEI professionals. The Rational Unified Process incorporates this approach and follows the industry Best Practices of software delivery. 3. The Rational Tool Suite and central repository The Rational Tool Suite provides an integrated central repository for the documents required to support a repeatable process. 4. Artifacts and guidelines developed by existing projects We have available to us the artifacts, plans and guidelines that have been developed by the projects that are already in process. The best of these will be incorporated into the process repository as examples. 5. Pilot Projects to drive and test the process The Process Project will add another element: a hands-on team of people driving the process through an actual project. This approach will provide the necessary interactions between I.S. departments and an actual project on which to base the process. Under the umbrella of a Pilot Project, project artifacts will be created to supply the standard process with the necessary samples. Project interactions will be worked out and documented. Thus, the Process Project will become a project within a project, and as such, should have its own project plan with its own set of deliverables. Benefits In addition, the Process will feature a variety of deliverables providing specific benefit to its customers: Assure more accurate estimation of project phases o (5.3) Metrics programo (5.4) Guidelines for estimating Reduce initial complexity of the RUP framework o Provide guidelines for small, medium and large projects Faster project startup o Guidelines and Standards o Skills and Experience Requirement by Role o Skills Assessment Template o (5.2) Niku project plan template(s) o (5.8) Roles and Responsibilities Descriptions matched to artifact deliverables o MSF to RUP Role/Responsibility Map o Central Repository of RUP templates, examples, process flow o RUP Glossary of terms Provide a standard way to measure each project phase o (5.3) Metrics program Support projects by assisting team members new to Rational technology in becoming full team contributors quickly. o (5.12) Training and Education plan Provide outside resources and vendors (planners developers, analysts, and others) with a standard process o (5.11) Documented COMPANY NAME RUP process Improve Quality Assurance o Provide QA artifact Check Lists Continuous Process Improvement o Provide a historical database that tracks and evaluates projects based on performance measured against estimates. Provide postmortem measures to determine success of the Process and related Standards and Guidelines Improved Change Management and Configuration Management Support o Change Management and Configuration Guidelines and SECC support Business Case and Vision Document alignment o BTC and RUP Requirements alignment and approval Production Services and RUP Process alignment o Production Services Volere and RUP process integration Diagram The online prototype* is located at: http://..... * Directions for optimal viewing of the Proces: Once in the process flow, you may wish to press the “F11” function key to super-maximize your screen. Pressing F11 again will let you toggle back and forth between a super-maximized screen with a minimized menu bar and your normal maximized screen. Other Pertinent Information ¨ Timeline As a RUP project itself, the Process Project will be developed in iterations. The first release will result in a basic process appropriate for small-medium size projects (3 months- 1 year). Subsequent releases will result in a version of the process targeted at large and very large projects, commercial off-the-shelf (COTS) products, data warehouse initiatives, ebusiness, etc. as well as added details of the incorporation of other business and IS processes. 11-Apr 13-May Mar-02 Apr-02 May-02 Jun-02 Jul-02 Aug-02 Sep-02 Oct-02 Nov-02 Dec-02 Elaboration - Refine Inception Construction - Refine Inception Transition - Refine Inception Elaboration - Management Discipline Construction - Management Discipline Transition - Management Discipline Elaboration - Governance Discipline Construction - Governance Discipline Transition - Governance Discipline Elaboration - Environment Discipline Construction - Environment Discipline Transition - Environment Discipline Elaboration - Config & Change Mgmt Discipline Construction - Config & Change Mgmt Discipline Transition - Config and Change Mgmt Discipline Elaboration - Production Discipline Construction - Production Discipline Transition- Production Discipline Begin Escorting Pilots Through Discovery and Inception ¨ Key Performance Indicators (KPI) 1. Steps to Measuring Process Adoption a. Create Process Adoption Assessment · Take Six Best Practices from Rational RUP b. Develop a series of questions for each practice · Define Process Maturity (PM) Levels c. Develop Yes / No answers for questions relating to the 6 Best Practices · Objective, can see deliverable and has evidence · Subjective, based opinions and assertions · Refine against existing projects · Establish Adoption Assessment approach d. Stress value, reduce threat 2. Adoption Assessment Scorecard a. In PM terms this project is “Level 1” b. Reveals areas requiring focus Process Project Maturity (BPM) Levels Develop Iteratively -- Level 2 Repeatable Manage Requirements --Level 3 Defined Use Component Architectures-- Level 1 Initial Model Visually (UML) -- Level 4 Managed Continuously Verify Quality -- Level 2 Repeatable Manage Change -- Level 4 Managed 3. For Pilot Projects a. Perform Assessment “base-line” of projects in the departments involved in development b. Set realistic Adoption Assessment “targets” c. Analyze and define gaps in capabilities d. Plan activities required to bridge gap e. Review Process Adoption Assessment · Requirement of lifecycle/phase objectives · Activity part of Environment Discipline |
| Toyota - About the BluePrint Process Project (overview) |
| Note: Also see my A3-size presentation on the BluePrint Process |
| Anne P. Sharp Los Angeles CA, USA Telephone (310) 600-9247 |
 |
 |
 |
 |
 |
 |
 |
| Anne P. Sharp |
 |
 |
 |