ADF89BCD-00AA-6386-7030-CD80071F2D26 Business_Corporate_Goals 2 0|0|0|0

Vision:

'XYZ plc will ... by yyyy'

  • Determine how this drives the goals for each department - Production, Support, etc.
  • Ensure we communicate these to everyone in each department and gain complete buy-in.
  • Help managers to set goals for all staff, agree specific action plans and review their progress.
  • Provide the format for managers to communicate upwards about progress and issues (potential bottlenecks, slippages, resourcing, etc).
  • ]]>

    Section Document Description

  • Definition * Functional overview Gives guidance on how a requirement maps to a feature. One specification is written per feature.
  • * Functional specification Describes features in terms of the product's behavior as seen by a user. It defines the functionality, but it does not describe implementation strategy or details. It does provide technical information needed for design. One specification is written per feature.

    * Marketing Requirements Only one MRD is used per project.

    Document (MRD)

    * Product Requirements Only one PRD is used per project.

    Document (PRD)

    * Requirements Only one spreadsheet is used per spreadsheet project.

    * Use case template description - This template gives guidance on how to use the use case template.

    * Use case template - This template gives guidance on creating a use case, including author, date, use case flows, preconditions, postconditions, and so on. Typically one use case is written per feature.

    Design

    * Configuration Management Plan - This template covers all of the IEEE standard aspects of configuration management, including work product identification, naming, baseline creation, labels, branching, merging, and so on. Typically, one plan is written per release.

    * Design plan - This template's purpose is to capture important aspects of the new or updated design of the system. It provides sections intended to identify how the system is to be changed. Typically one specification is written per feature.

    * Software architecture document - This template provides guidance on the most critical decisions about software design, including components to be designed and relationships among them. Typically, one software architecture document is written per release.

    * Systems architecture document - This template provides guidance on the most critical decisions about the system-level elements and relationships between system-level elements. Typically, one systems architecture document is written per release.

    Code & Build

    * Code review - This template explains how to document code review expectations and approach. It also provides questions to ask during a review.

    * Development guidelines - This template provides guidelines for developers.

    Testing

    * Test case - This template that explains how to document an individual testing sequence. Typically, one test case is written per requirement.

    * Test plan - This template that explains how to document the scope of testing, items to be tested, testing approach, and so on. Typically, one test plan is written per release.

    Deployment

    * Deployment checklist - This template gives guidance on documenting activities that lead to successful release of the software to customers.

    * Release management plan - This template that gives guidance on documenting release objectives, installation requirements, the pre-rollout meeting, post-implementation testing, and so on.

    * Release notes - This template gives guidance on documenting release highlights and customer-facing defects resolved in the release.

    * Software installation guide - This template gives guidance on documenting software installation, initial configuration, and start-up.

    Support

    * Support plan - This template that gives guidance on documenting the support mission, support success criteria, support roles and responsibilities, and an area to capture a strategy for the support process areas. One support plan is written per release.

    Section Document Description

  • Project * Business case Provides sections for the business problem, Management proposal for a project that would solve the problem, and the project value proposition.
  • * Project completion Captures the lessons learned from a completed review project based on using a strengths, weaknesses, opportunities, and threats (SWOT) method.

    * Project plan Provides sections for a project summary, scope, success criteria, lifecycle approach, assumptions, constraints, risk management plan, human resources plan, a work breakdown structure, an outside supplier plan, and so on.

    * Project schedules Separate files for each type of process.

    (Waterfall, Iterative

    and Agile)

    ]]>

    At the start of 2009 we had 0.5% faulty components. So far we have reduced this to 0.4% so we are 20% complete (Pareto principle notwithstanding).

    ]]>

    Collect and monitor complaints

    ]]>

    Check competition

    ]]>

    Including editorial

    ]]>

    Face-to-face, phone, email.

    Every employee should be a salesman.

    ]]>

    Blog and Forum on website

    ]]>

    Homepage and blog

    ]]>

    For existing customers and new visitors.

    Moderation strategy.

    ]]>

    Make all customers referenceable.

    Communications standards: level and frequency

    Check why they buy

    Loyalty? Average length of relationship?

    ]]>

    We need to recruit, train and retain the best people in every department.

    ]]>

    Role definitions;

    Personality: 'best fit'

    ]]>

    Minimal standards; professional development.

    ]]>

    Goal-oriented approach

    Salary review schedule

    Incentive schemes

    Social activities - with and without families

    ]]>