Build Service Management Function Overview

 

Build management is the process of developing solution components: the code for any in-house application or infrastructure solution, and documentation that developers create, as well as the infrastructure that supports them. All team roles participate in the building and internal testing of the deliverables. The purpose of the Build SMF is to help IT organizations successfully build solution components. The Build SMF corresponds to the Developing Phase in the Microsoft Solutions Framework (MSF) Process Model.

Building follows the project planning portion of the Deliver Phase and culminates in the Scope Complete Milestone. At the Scope Complete Milestone, all features are complete and the solution is ready for external testing and stabilization. This milestone is the opportunity for customers, users, operations and support personnel, and key project stakeholders to evaluate the solution and identify any remaining issues that must be addressed before releasing the solution to production.

Build SMF Role Types

The primary team accountability that applies to the Build SMF is the Solution Accountability. The role types within that accountability and their primary activities within this SMF are displayed in the following table.

Table 1. Project Accountability and Its Attendant Role Types

Role Type

Responsibilities

Role in This SMF

Solution Manager

  • Accountable role
  • Owns all SMFs in this accountability
  • Acts as project director for all projects
  • Resolves conflicts between projects

 

  • Ongoing oversight

Program Manager

  • Drives design, schedule, and resources at the project level

 

  • Ensures specification maps to what is being built

Developer

  • Builds the agreed-to solution

 

  • Prepares for development
  • Develops the solution

Tester

  • Tests to accurately determine the status of solution development

 

  • Prepares for testing the solution
  • Tests the solution

Product Manager

  • Acts as the customer advocate
  • Helps drive shared project vision
  • Manages customer expectations

 

  • Ongoing management of customer expectations

User Experience

  • Acts as the user advocate on project teams
  • Helps define user requirements
  • Helps design to meet user requirements

 

  • Reviews solution specification to ensure it meets end user needs
  • Creates user documentation

Release Management

  • Evaluates the solution design
  • Documents operations requirements to ensure they’re met by the design
  • Creates a pilot, deployment plan, and schedule
  • Manages site deployment

 

  • Creates deployment and site-preparation checklist

Operations Experience

  • Advocates for operations on the project team
  • Brings in operations experts as needed for detailed information
  • Coordinates with release management

 

  • Reviews solution specification to ensure that it meets operations requirements

Test Manager

  • Owns all testing across all project teams
  • Develops testing strategy and plans
  • Ensures that best practice test methods are used

 

  • Ongoing oversight

Goals of Building

The primary goals of the building process are to develop the solution deliverables to the customer’s specifications, develop the solution documentation, create the development and test lab, and prepare the solution for pilot deployment.

The Developer role type is primarily responsible for this goal, but all roles participate in building the solution. To achieve this goal, Development provides low-level solution and feature design, estimates the effort to deliver that design, and builds the solution. Additionally, Development serves the entire team as technology consultant, validating technical decisions and mitigating development risks. Table 2 shows the desired outcomes of the Build SMF’s goals and lists measures you can use to gauge how successfully you have achieved these goals after completing this SMF.

Table 2. Outcomes and Measures of the Build SMF Goals

Outcomes

Measures

A solution delivered to the customer that is free of defects

  • Number of bugs unresolved or deferred
  • Signoff on the Scope Complete Milestone

A solution that meets the customer’s specifications as described in the functional specification

  • Number of design change requests filed
  • Number of bugs filed for incorrect implementation
  • Signoff on the Scope Complete Milestone

A solution delivered to the customer within the schedule’s specified timeline

  • Date the Scope Complete Milestone is approved

Key Terms

The following table contains definitions of key terms found in this guide.

Table 3. Key Terms

Term

Definition

Baseline

A baseline is a known state by which something is measured or compared. Baselining is placing something under change control. Baselines make managing change in complex projects possible.

Bottom-up scheduling

Team members representing each role generate time estimates and schedules for deliverables. Each team’s schedule is integrated into a master project schedule.

Conceptual design

Conceptual design involves understanding the business requirements and defining the features that users need to do their jobs. Product Management takes the lead in creating the conceptual design, which begins during envisioning and continues through project planning.

Customer

The person or organization that commissions and funds the project.

Interim milestone

An early progress indicator that segments large work efforts into manageable portions. The Deliver Phase suggests a set of interim milestones, but project teams should define interim milestones that make sense for their projects.

Logical design

Logical design uses the conceptual design and the current state of the technology infrastructure to define the new architecture at a high level.

Milestone

A project synchronization point. Major milestones mark the transition of projects from one phase to the next phase. They also transfer primary responsibility from one role to another role. The Deliver Phase SMFs correspond to major MSF milestones.

Physical design

Physical design goes into greater detail about the desired architecture than logical design, and it defines the hardware configurations and software products to be used. As a general rule, the solution design should contain enough detail to enable the team to begin work on the project plan.

Scope

A view of the project’s vision limited by constraints such as time and resources. Solution scope describes the solution’s features and deliverables. Project scope describes the work to be performed by the team.

Solution

A coordinated delivery of technologies, documentation, training, and support designed to successfully respond to a unique customer’s business problem. Solutions typically combine people, processes, and technology to solve problems.

Stakeholder

Individuals or groups with an interest in the outcome of the project—although their goals and priorities are not always identical to the customer’s. Examples of stakeholders include departmental managers who will be affected by the solution, IT staff who are responsible for running and supporting the solution, and functional managers who contribute resources to the project team.

Use case

Describes an individual task performed in a use scenario.

Use scenario

Describes a particular activity that a user tries to accomplish, such as processing a transaction or checking e-mail.

Users

The people who interact with the solution to perform their jobs.

Vision

Describes the fundamental goals of the solution.

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.

Download

Get the Microsoft Operations Framework 4.0

Solution Accelerators Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions