Task: Launch Development Process
This task describes how to rollout a development process to the project team.
Disciplines: Environment
Purpose

The purpose of this task is to:

  • Ensure that the project members are properly introduced to the process.
  • Harvest any feedback on the process and refine the process, as necessary.
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
    • None
    Outputs
      Main Description

      The Development Process needs to be re-launched for every significant update of the Development Process during the project lifecycle, focusing on the changes.

      Steps
      Make the Changes Public

      Inform all project members about any significant update to the tailored Development Process. If the project has a project web site, the changes should be posted there, in addition to notifying the project members. 

      The process Website of the configured process is typically published to a location on a Webserver accessible to all project members. Alternatively, the Website may be copied onto the project member's local hard drive.

      Educate Project Members

      Unless the change is trivial, you need to educate the project members about the new Development Process, including  any guidelines, templates and/or tools.  This can vary from an informal 2 hour presentation to more formal training, depending on the size of the project and the project members' familiarity with similar development processes.

      The following are commonly used ways to educate the project members:

      • Seminar.
        If the change is small or easy to understand it can be acceptable if the process engineer presents the new on a seminar. This type of seminar typically takes 1-3 hours. This is often the preferred choice when re-launching the process for an iteration, and the changes from the last launch are minor.
      • "Kick-start" workshop.
        Arrange a one-day workshop for all project members, where they follow the new development process and use the tools. See Guideline: Development Process Workshop, for details on how to arrange such a workshop. Notice that a "kick-start" workshop assumes that the participants have taken the relevant standard training courses. Always consider the cost of the workshops against the expected value to the project.
      • Customized training courses.
        If the project member have not attended the standard training courses in process and tools, an alternative is to customize the standard training courses, to cover the project's development process, including guidelines, templates and tools. However, it can be expensive to customize training courses. Generic process training, like an introductory course to the Rational Unified Process™, should be conducted prior to project startup, or in the early days of the project. More specialized training in techniques, methods or technologies, is often conducted "just-in-time". This means that the training is given shortly before the method or technique is to be applied in the project, to ensure that new knowledge is fresh in mind.
      • "Boot-camps".
        1-5 weeks of concentrated hands-on training. Not many organizations can afford to arrange these kinds of boot-camps, but they have proven to be efficient if there are many new factors for the people in the project. A boot-camp is typically a mixture of seminars, training courses and hands-on work with the process and tools.
      Collect Feedback

      While presenting the new material and educating project members, you are likely to receive feedback and discover defects in the development process and/or tools. Generate Change Request, where appropriate. Some changes may be need to be addressed outside the scope of the project, for example by the process group responsible for the organization wide development process. Other issues may be raised against the way the project has chosen to tailor the process and a resolution to the problem should be considered for the next internal release of the process.

      It is often worth while to follow up a process launch to ensure that the project members "got the message". It is perceived as difficult by many individuals to ask for clarifications during a presentation, especially when a lot of people, internal and external, are present. In many projects, the responsibilities of a Process Engineer also includes performing process mentoring to help the project members applying the techniques described by the process. This work will often result in feedback you don't usually capture during a launch.  For more information, see Concept: Mentoring.

      Key Considerations

      The Process Engineer needs to work with the Project Manager to make the project-specific Development Process public, and decide on how to educate the project members.

      More Information
      Concepts