Project Life Cycle Management

BusinessObject Solutions, Inc. (BOS) combines systems development experience with different clients and various sizes of projects to prove that the Microsoft Solutions Framework (MSF) is a flexible interrelated series of models that guide an organization through the process of assembling the resources, people, and techniques needed to ensure that their technology infrastructure and solutions meet their business objectives. A summary of each model is provided in the following table:

Team Model

The Team Model defines a team of peers working in interdependent and cooperating roles. it communicates status, provides for the division of labor, and delegates task responsibility and shows how to structure teams to deliver quality solutions more cost effectively. Each team member has a well-defined role on the project and is focused on a specific mission. This helps ensure that quality-related issues are addressed before a product or solution is implemented. This can help reduce the burden of rework, reduce help desk costs, and minimize support costs during the transition.

A critical underlying element of success is unrestricted communication between all team members. The model is comprised of six clearly defined roles:

Six project team roles

The Process Model is a milestone-based model that provides guidelines on planning and controlling results-oriented projects based on their scope, the resources available, and the schedule. It is an iterative and adaptable model that:

• Defines critical manageable milestones for development.
• Creates explicit team accountability.
• Addresses the risks of a project early in the planning stages.
• Defines the variables and priorities that affect scheduling, features, and trade-off decisions.

These guidelines facilitate better decisions, reduce rework, improve morale, and can result in a better product. And, by addressing support and performance issues as part of the development process, the Process Model can lower the risks associated with rolling out new solutions; it can also lower the cost of ownership.

The Process Model consists of four phases: envisioning, planning, developing, and stabilization. Each phase culminates in a major milestone.

Process milestones

Application Model

The Application Model describes the development of multitier applications built on user, business, and data services. It establishes definitions, rules, and relationships that form the structure of an application. It also offers guidelines on splitting an application into a network of services so that features and functionality can be packaged for reuse across functional boundaries.

A service is a unit of application logic that implements an operation, function, or transformation that is applied to an object. Services can enforce business rules, perform calculations or manipulations on data, or expose features for entering, retrieving, viewing, or modifying information.

To further refine the distribution characteristics of the network of services, the Application Model defines three categories of service that make up an application: user services, business services, and data services. These have their own attributes, as the following table shows.

Three categories of service

These services are used in the development of multitier applications are particularly applicable when business systems are integrated with Internet technologies. In particular, you can:

• Provide an application with cross-platform support for a heterogeneous workstation environment.
• Promote a consistent user interface style and navigation model for all business applications.
• Establish and maintain a presence on the World Wide Web.
• Simplify deployment of applications through centralized maintenance of application logic on Internet servers.

Enterprise Model

The Enterprise Architecture Model provides a consistent set of guidelines for planning, building, and managing a technology infrastructure. It encompasses four perspectives: business, application, information, and technology. Visualizing each perspective enables you to develop better change-management strategies for your enterprise.

Enterprise architecture planning should take place continuously as business needs evolve. This is often referred to as planning while building. In contrast to top-down methods, projects are not only driven by an enterprise model; they directly impact the evolution of the enterprise architecture.

Solutions Design Model

The Solutions Design Model provides a step-by-step strategy for designing business-oriented solutions driven by a specific business need. This model ties together the Application, Team, and Process Models, and makes it possible for the information system staff to focus resources where they can produce the most value.

This model relates solutions development to the business in two key ways:

• Solutions are driven from the context of the business, which is an essential consideration when developing workflow applications.
• End users are brought in to address usability before incurring help desk incidents. Also, information systems professionals are brought in to help end users solve their concerns without changing the infrastructure.

The Application, Team, and Process Models help planners identify all business and technical requirements of an application up front, so that resources can be assigned more effectively. Together, these models help organizations to recognize the similarities between the process of designing software with the similarly complex process of designing a building. This is why Microsoft gives the title Architect to experts in software design.

Think of these three perspectives on design-the Application, Team, and Process Models-as convenient points along a continuum that help you apply a particular set of techniques and tools and address the needs of a particular audience. These perspectives describe the design process in a more focused way. At any given point, portions of your design can be revisited. Design is a continuing process of incremental refinement.

Conceptual Design

The design of a building starts with the architect's sketches. These provide a view of the building for the client. These sketches might include a site plan, elevations, floor plans, cut-away drawings, and other pictures or drawings. These views correspond to the conceptual design for the project. Conceptual design starts with an understanding of what users really need, and is followed by an easily communicated set of models that capture this understanding.

• Three Phases of Component-Based Design
• The Conceptual Design Process
• Team Roles and Responsibilities
• Design Deliverables
• Design Tasks

To understand the design of component-based solutions, we look at the process from three distinct perspectives:

• Conceptual design
• Logical design
• Physical design

Logical Design

The architect's sketches are followed by architectural plans that show the building as seen by the architect and contributing staff. This second phase in the architectural process combines the client's view with the architect's view and knowledge. Detailed drawings in each of many categories help the different contractors and other parties involved in the project communicate with each other. This corresponds to the MSF view of logical design, where the structure and communication among the individual elements of a system is established.

• Team Roles in Logical Design
• The Process of Logical Design
• Baselining the Logical Design

Physical Design

Finally, contractors' plans are drawn up for the builder, who adds detail to the architect's plans, makes adjustments for the physical environment of the site and the technology and materials that are available. This view directs all the construction activities and may add greater detail, such as shop plans for individual subcontractors. This view corresponds to the physical design, where the real-world constraints of technology, including implementation and performance considerations, are applied to the logical model. At this point, real resources, costs, and schedules are estimated.

These perspectives should not be thought of as stages. They do not imply a clear cutoff point or rigid boundary. You do not have to complete all of the work involved in one perspective before beginning the next. Elements of the process can overlap. Indeed, some parts of a system may be coded while other aspects are still being determined. If information is available before it normally would be uncovered or targeted in a particular design perspective, it should be used. There is no advantage in waiting to apply information until a predetermined appropriate point is reached.

One of the advantages of a well-designed component model (loosely coupled, strong cohesion) is that if the distribution needs for a particular component change, those changes can be incorporated into the component (or replaced by a new component) with minimal effect on the other components in the system.

Infrastructure Model

In Infrastructure Management, the MSF process, Team Models, and other principles are brought together to implement the information technology infrastructure. In particular, Infrastructure Management establishes MSF principles for managing the people, processes, and technology that support networks in a large enterprise.

The MSF process creates a structure for the following activities:

• Envisioning
• Planning
• Developing
• Stabilization

A project that takes more than one year to complete may lose its value because technology is evolving very rapidly. On large projects, for example, the deployment of any single version of technology may never be complete. As soon as one wave of deployment is nearing completion, another wave will be in the planning stages. To achieve this, the customer and project team must prioritize and make trade-off decisions on the three project management parameters: schedule, scope, and resources.

The result of the Infrastructure Model is a more flexible approach to technology deployment that secures new technology while delivering added value in less time. If your team is already familiar with the Team and Process Models, reusing this knowledge is a highly effective way to benefit the organization.

Total Cost of Ownership Model

The Total Cost of Ownership (TCO) model helps reduce costs and improve the return on your computing investment. TCO issues can include:

• The role of value.
• What is a real cost?
• Applying TCO to your needs.
• Seeing the whole picture.

The TCO Model is a continual process of ongoing improvement with three key stages: planning, building, and managing. This approach can be useful in developing business cases and priorities for infrastructure projects.

For comprehensive and latest information about Microsoft Solutions Framework, visit Microsoft website at www.microsoft.com/msf/.

< Go Back >