Microsoft Solution Framework (MSF) Planning Phase Overview

Damir Dobric Posts

Next talks:

 

    

Follow me on Twitter: #ddobric



 

 

Archives

The planning phase is when the bulk of the planning for the project is completed.

During this phase the team prepares the functional specification, works through the design process, and prepares work plans, cost estimates, and schedules for the various deliverables. 

Planing Process

Early in the planning phase, the team analyzes and documents requirements in a list or tool. MSF specific requirements fall into four broad categories:

 

  • Business requirements,
  • User requirements,
  • Operational requirements and
  • System requirements (those of the solution itself).  

Design

 

As the team moves on to design the solution and create the functional specifications, it is important to maintain traceability between requirements and features. Traceability does not have to be on a one to one basis. Maintaining traceability serves as one way to check the correctness of design and to verify that the design meets the goals and requirements of the solution.

 

The design process is a systematic way to work from abstract concepts down to specific technical detail. The results of the design process are in general documented in the document called functional specification(s). This document describes in detail how each feature is to look and behave. It also describes the architecture and the design for all the features.

 

Design steps

During design the team has to cover following steps:

 

  • Analysis of user profiles (also called “personas”) which describe various types of users and their job functions (operations staff are users too). Much of this is often done during the envisioning phase. 
  • Describe user activities into a series of usage scenarios. A particular type of user is attempting to complete some activity, such as front desk registration in a hotel or administering user passwords for a system administrator.  
  • At the end break each scenario into a specific sequence of tasks, known as use cases, which the user performs to complete that activity. This is called “story-boarding.” 

Design Levels

Keep in mind that there are three levels in the design process, which are documented in the given sequence: 

 

  • Conceptual design,
  • Logical design and
  • Physical design.  

Design Requirements

Note that the functional specification should fulfill following requirements:

 

Instructions to developers on what to build.

Basis for estimating work.

Agreement with customer on exactly what will be built.

Point of synchronization for the whole team. 

Detailed Planing

Once the functional spec is baselined, detailed planning can begin. Each team lead prepares a plan. Examples of such plans include a

 

  • Deployment plan,
  • Test plan,
  • Operations plan
  • Security plan and/or
  • Training plan.  

All plans are synchronized and presented together as the master project plan (do not confuse this plan with the Microsoft® Project® .mpp file). The number and types of subsidiary plans included in the master project plan will vary depending on the scope and type of project.

 

Team members representing each role generate time estimates and schedules for deliverables (see the Bottom-Up Estimating section for more details). The various schedules are then synchronized and integrated into a master project schedule.

At the culmination of the planning phasethe project plans approved milestonecustomers and team members have agreed in detail on what is to be delivered and when. 

Major Milestone

At the project plans approved milestone, the project team and key project stakeholders agree that interim milestones have been met, that due dates are realistic, that project roles and responsibilities are well defined, and that mechanisms are in place for addressing areas of project risk.

 

After the team defines a baseline, it is placed under change control. This does not mean that all decisions reached in the planning phase are final. But it does mean that as work progresses in the developing phase, the team should review and approve any suggested changes to the baseline.

 

For organizations using MOF, the team submits a Request for Change (RFC) to IT operations at this milestone.

 

Suggested Interim Milestones

 

Technology Validation

During technology validation, the team evaluates the products or technologies that will be used to build or deploy the solution to ensure that they work according to vendor’s specifications. Often, technology validation involves competitive evaluations (sometimes called “shootouts”) between rival technologies or suppliers.

 

Another activity that must be completed at this milestone is baselining the customer environment. The team conducts an audit (also known as “discovery”) of the “as is” production environment the solution will be operating in. This includes server configurations, network, desktop software, and all relevant hardware.

 

Functional Specification Baselined

At this milestone, the functional specification is complete enough for customer and stakeholder review. At this point the team baselines the specification and begins formally tracking changes.

 

The functional specification is the basis for building the master project plan and schedule. The functional specification is maintained as a detailed description, as viewed from the user perspective, of what the solution will look like and how it will behave. The functional specification can only be changed with customer approval.

 

The results of the design process are often documented in a design document that is separate from the functional specification. The design document is focused on describing the internal workings of the solution. The design document can be kept internal to the team and can be changed without burdening the customer with technical issues. 

Deliverables 

The deliverables for the planning phase are:

 

  • Functional and design specification (can be separated in two documents)
  • Risk management plan
  • Master project plan and master project schedule 

Team Focus

The following topic describes the focus and responsibility areas of each team role during the planning phase.

 

Product Management

Conceptual design; business requirements analysis; communications plan

 

Program Management

Conceptual and logical design; functional specification; master project plan

and master project schedule, budget

 

Development

Technology evaluation; logical and physical design; development

plan/schedule; development estimates

 

User

Experience Usage scenarios/use cases, user requirements, localization/accessibility requirements; user documentation/training plan/schedule for usability testing, user documentation, training

 

Testing

Design evaluation; testing requirements; test plan/schedule

 

Release Management

Design evaluation; operations requirements; pilot and deployment plan/schedule


Posted May 06 2006, 01:10 AM by Damir Dobric
developers.de is a .Net Community Blog powered by daenet GmbH.