The Elements of the Enterprise Architecture
Achieving a Shared Vision for the Infrastructure Deployment Project Team
Vision/Scope Approved Milestone Envisioning Phase
Tasks That Occur During the Envisioning Phase
Deliverables Produced During the Envisioning Phase
Writing the Vision/Scope Document
Vision/Scope
Document: Description of Deliverables and Content
SMART
Vision/Scope Document Content
Exercise
5-1: Envisioning Phase
Setting the Target for the Project Plan Approved Milestone
Roles and Responsibilities That Lead to the Project Plan Approved
Milestone
Deliverables To Be Produced at Project Plan Approved
Design
Specification Drill Down and Detailed Descriptions of Deliverables and Content
Master
Project Schedule Drill Down and Detailed Descriptions of Deliverables and
Content
Master
Project Plan Drill Down
Defining the Focus and Deliverables of Each MSF Team and Their Role at
Project Plan Approved
Tasks That Lead to the Scope Complete/First Use Milestone
Identifying
the Interim Milestones Leading to Scope Complete/First Use
Listing
the Interim Milestones Leading to Scope Complete/First Use
Defining the Focus and Deliverables of Each MSF Team and Their Role at
Scope Complete/First Use
Describing the Process for Driving to the Release Milestone
Exercise
5-3: Developing Phase
Defining the Release Milestone
Tasks That Occur During the Release Milestone
Describing the Deliverables for the Release Milestone
Describing the Focus for Each MSF Team Role at Release
Exercise
5.4: Stabilizing Phase
Exercise
5.5: Identify the phase for the following interim milestones and deliverables
· Enterprise Architecture Overview
· Infrastructure: Overview and Drill Down
· Infrastructure: Deployment and the MSF Process Model
· The Vision/Scope Approved Milestone
· The Project Plan Approved Milestone
· The Scope Complete/First Use Milestone
· The Release Milestone
You’ve learned about the MSF team model and process model. You’ve applied these models to software development. Now it’s time to apply them to infrastructure projects. Why should a programmer, an MCSD, care about infrastructure projects? Because we do so much more than code. Much of what we do requires working with networks, hardware, and even phones. We increase our professional value by expanding our expertise out of the developer’s cube into the real-world workings of the enterprise. In this chapter, we’ll discuss the MSF guidelines for infrastructure deployment.
Enterprise architecture is built on the interdependencies of people, process, and technology. We have technology to aid productivity, and each team member brings unique skills and characteristics to the process. Figure 5-1 illustrates the MSF enterprise architecture.
Figure 1: Enterprise architecture consists of people, process, and technology
Thinking about the architecture of our enterprise helps us to categorize the various components of an organization. It’s a way of breaking down the whole into understandable pieces. Not only can you view the enterprise architecture of an entire business, but also the architecture of the IT organization, which is, the focus of this chapter. The enterprise architecture consists of people, technology, and processes.
One crucial element of the enterprise architecture is people. People use technology, create processes, and provide the intellectual energy to keep our enterprise moving forward. In the end, the benefit comes back to people. Sometimes developers want people to adjust to the technology, and we may even want them to change processes because of how our technology works. A more balanced view of the enterprise architecture leads developers to value the people in the organization.
The second element of enterprise
architecture is processes. For
example, computer departments commonly buy new desktop systems in batches after
a bidding process. The bidding process is a well-established procedure for
getting good prices. There are forms involved, relationships with vendors, and
reasonable criteria for making a decision. Processes exist on every level of the
organization, for everything from rudimentary daily tasks to the hiring of a new
CIO. Every good programmer knows how to isolate the process from the people who
use it, and from the technology it may run on.
The third element of enterprise architecture is technology. Technology doesn’t mean just the network. It includes things like writeable CDs, Visual Studio 6.0, and phones. Remember that the enterprise architecture is not limited to a location, nor is not identified by size. It’s a model that we use to define organizational roles.
Let’s understand the technology infrastructure of organizations by using an analogy. The infrastructure of a nation consists of things like roads, power facilities, waterways, airports, and phone lines. These are the systems that keep the country functioning. Infrastructure consists of both facilities and services. A school can be considered part of the infrastructure because of the service that goes on there, education, which produces people with the necessary skills to contribute to the larger enterprise.
Exam Watch: Understand the relationship between enterprise architecture and technology infrastructure.
The technology infrastructure consists of the resources that support the organization’s computing environment; that is, the systems that we need for the functioning of the computing environment. Figure 5-2 shows the relationship between the enterprise architecture and the technology infrastructure. Like the overall architecture, the technology infrastructure includes people and processes, as well as technology. The people in the infrastructure use, buy, and maintain the technology. Common processes in a technology infrastructure include network design, setup of personal systems, and training. The following are Microsoft’s eight categories of the technology portion of the infrastructure:
1. Data transmission links
2. Local area network architecture
3. Wide area network architecture
4. Protocols and transports
5. Network operating systems
6. Computer hardware
7. Computer software
8. Domain/site models
Figure 2: People, process, and technology come together in the technology infrastructure
The technology infrastructure exists to meet the business needs of the organization. We are the roads and bridges, the power lines and coal mines of the organization; the job we do makes it possible for the rest of the organization to meet the business goals.
Deploying a new technology infrastructure element brings up issues such as the technical problems of getting operating systems to work together, dealing with aging hardware, getting enough server power for the job, and a number of resource allocations. Managers need to assign the appropriate resources to the task, establishing an appropriate budget. Managers also need to rally people around the business need that the new project is to address. Even with the best equipment in the world, you cannot neglect the workplace environment.
No one can fail to be impressed by the array of quality products Microsoft has produced in recent years. They have solved the problems involved in rolling out new technologies, and they share the answers with the rest of us.
At the core of the solution development discipline is the MSF process model, the subject of the rest of this chapter. You’ve already seen this model applied to software development; now it’s time to apply it to infrastructure deployment.
Exam Watch: Develop a thorough understanding of the MSF process model.
Figure 5-3 illustrates the MSF process model. From the first spark of an idea, envisioning leads to the vision/scope approved milestone. Planning will take you to the project plan approved milestone. The scope complete/first use milestone yields itself after a healthy dose of development. And finally release signals the end of the deployment phase. Working with the MSF model helps us to minimize problems, efficiently use resources, and achieve our business goals. The details of each milestone and phase make up the rest of this chapter, the core of the infrastructure deployment process.
Figure 3: The MSF process model has phases and milestones
The process model is an iterative process that allows for multiphase development projects to assume an organized, continuous, development process. It ensures the necessary emphasis on design and planning, which is often overlooked in many development projects. Special emphasis should be placed on the development of scope documents. Without a properly developed scope document, all aspects of a project are subject to increased risk and will not reach the desired milestones. Remember the SMART requirements of a vision/scope document: Specific, Measurable, Achievable, Results-based, and Time-oriented.
In preparation for the exam, or for leveraging the MSF process model for the first time, become familiar with the interim milestones and deliverables that map to each of the four phases of the MSF process model. It is also important to become familiar with the functionality and responsibilities of each of the six roles identified. Be able to match up a given project task with both the phase within which it should reside or be carried out, and the role responsible for carrying out the task.
— by Michael Lane Thomas, MCSE+I, MCSD, MCT, MCP+SB, MSS, A+
When you achieve the first milestone of the infrastructure deployment process, you will have articulated a clear and inspiring vision and will have set an achievable scope for the project. A team effort must begin with a sense of vision. The larger the project, the more important a strong vision becomes. The vision motivates a team—it’s the focal point around which they can concentrate their best efforts. A team with a strong vision has members who feel they are important to the overall goals, and are all committed to a common purpose.
Vision supplies the why, which inspires the how. Good team leaders communicate vision both verbally and visually. Developing vision is much more than coming up with a mission statement that you post on your wall. The overriding sense of purpose must be active in the minds of team members. Remind your people of the vision; get excited about it; show everyone how they can have a fulfilling part of the new mission. Once a team begins to congeal around the vision, it’s ready to begin a phase of high-quality action.
Vision and scope work together. Vision points the direction; scope says how far. Scope helps team members see that real achievements can be met. Once the excitement of vision fades, the task can seem daunting, but scope reigns in the vision and helps people see the end of the tunnel.
Vision grows from a business need. The sustaining force of vision is the value to the organization. Vision has to result in something good for the business. Everyone should be able to agree on the fact that your project will be beneficial to the college, bank, charity, investment firm, or manufacturer you work for.
Achieving vision and scope takes time, lots of communication, and some interim steps. Microsoft suggests some interim milestones to mark your progress along the way. Deliverables mark the conclusion of each step. The envisioning phase culminates in the vision/scope document.
The process of envisioning brings the team to the vision/scope approved milestone. At this milestone the members of the project team, the customer, and key project stakeholders reach a common agreement on the essential parts of vision and scope. These elements include the overall vision, the business requirements to be met first, time frame, risks, assumptions, business constraints, and the level of effort to give to the next phase, which is planning. Envisioning is a very creative process, characterized by excitement and enthusiasm.
Vision addresses how the business will change with the new solution. It identifies the business problem and provides the context for the solution. The vision doesn’t have limits. During envisioning, team members do not need to consider technical constraints. To reach the milestone, the differing ideas of vision must converge into a single agreed-upon statement.
During envisioning people take the vision and compare it to the reality of the situation. This gives the vision appropriate scope. Scope includes the elements essential for success, as made clear by the customer. While deciding on scope, team members consider things like the urgency of various pieces of the solution, which things can wait until the next release, and the constraints and risks involved with the project.
Resources, schedules, and solution functionality each impact the shape of the project. More functionality demands more resources and time. Envisioning is the time to decide how much time and money the result is worth. The scope should let the project achieve solid results while keeping costs and risks down. With most projects, the law of diminishing returns will eventually kick in. Setting an appropriate scope will make sure that benefit is maximized.
Before you reach the vision/scope document and the approval milestone, Microsoft suggests some helpful intermediate points to measure progress. A team should have a deadline for each of these points. These interim milestones are: team formation complete, draft vision/scope, and final vision/scope. Table 5-1 describes the nature and effect of each milestone.
Interim
Milestone |
Description |
Effect |
Team Formation Complete |
Team roles have been scaled to the needs of the project. Skill sets are identified. Primary team members are assigned tasks. |
Encourages ownership of tasks. Ensures the timelines and quality of deliverables. |
Draft Vision/Scope |
Has problem statement, solution concept, and procedure for training during the project. Identifies the customer. |
Defines what the teams do and why. Ensures that participants are together on the nature of the problem and solution. |
Final Vision/Scope |
The deliverables have been produced. Success factors and business improvement metrics are documented. |
Establishes viability. Team and customer understand their responsibilities. |
Table 1: The Envisioning Phase Has Three Interim Milestones
Microsoft identifies six roles for members of a team: product management, program management, development, testing, logistics management, and user education. Team formation happens when particular team members take on each of these roles. During team formation, leaders match skill sets to roles, and each member commits the time necessary to complete the project.
Getting the right people for the job assures the quality of the product. Once the team has been formed, members take on a sense of ownership of the project. Reaching this milestone means that the project has gotten off the ground. Members have a sense that the project is underway. Once together, the core team can do the work of crafting a central vision.
The two key elements of the vision/scope draft are the statement of the problem and the sketch of the solution. Make sure that your solution matches the problem! Establish the customer for the project. This is not always as simple as it might seem. For example, an IT department of a college may want to deploy an ATM network. Who is the customer here? All the potential users? The president of the college who got the grant for the network in the first place? Keep in mind that the customer will play a part in the rest of the process. You want to clearly identify the customer to allow them to participate in the following steps. The customer should see your draft statements at this stage, and give preliminary approval.
At this milestone the deliverables for the envisioning phase are complete. When this milestone has been met, both customers and team members understand their responsibilities for the project. By this point, the viability of the project should be apparent to all.
Each team member has a part to play in the envisioning phase. Product management identifies the problem, and documents the need. Product management also articulates the vision. Program management comes up with the design goals and documents the solution. Developers do the critical job of researching solutions and coming up with technical options. User education prepares by deciding on the requirements for training, as well as training scope. Testing creates criteria based on design goals. Logistics management reports on material constraints and considers long-term management and support.
Table 5-2 describes the deliverables that the team produces in the envisioning phase.
Deliverable |
Content |
Vision/Scope Document |
· Problem statement/business objectives · Vision statement · User profile · Solution concept |
Risk Management Plan |
· Identifies risks · Identifies new technologies that should be monitored · Identifies organizational issues that might impact the progress of the project |
Project Structure |
· Defines how the project will be managed and supported · Defines the administrative structure for the project team, such as reporting structure, meetings, and schedules |
Table 2: Deliverables of the Envisioning Phase
The vision/scope document, the deliverable that marks the vision/scope approved milestone, has several necessary characteristics:
· It provides a clear direction for the team.
· It sets customer expectations.
· It approximates the risk involved in the project.
A baseline for planning, design, and deployment comes from the vision/scope document.
The vision/scope document has four parts. The first is the problem statement and business objectives, which address what you want to do and why you want to do it. Next is the vision statement itself, the heart of the document. This statement articulates the direction of the business and shows how the project contributes to the mission. The user profile lists the people that the project impacts. Finally, the solution concept gives the timeline for the project and, of course, sketches how the team intends to solve the stated problem.
A SMART vision/scope document is Specific, Measurable, Achievable, Results-based, and Time-oriented. If the vision for your project is vague and hard to measure, how will you know when you’ve reached your goal? A specific and measurable vision and scope can help the team recognize the progress they are making as well as giving the project a clear end point. The middle of a project is not the time to discover that you don’t have the resources, expertise, and technology to get it done. You should be able to determine up front whether you can reach your objective. A good working timeline should be defined in the vision/scope document. In addition to the qualitative and quantitative measurement set out in the document, you should make sure that the document keeps the results in focus.
Exercise 5-1: Envisioning Phase
Identify the role responsible for each of the following tasks:
Research potential technical solutions: _____________________
Determine the requirements for training: ____________________
Articulate the vision and identify the problem: ________________
Determine the design goals: ______________________________
Create criteria for test suits based on design goals: _____________
Determine any material constraints: _________________________
The main task of this phase is planning. Your vision is in place; you know what the problem/need is; and you have a good handle on a solution. Now you have to plan the many details of your project. Have you ever been in the middle of a seat-of-the-pants project and thought that some day we’re going to do this the right way? Well, now is your chance. Just as a well-designed program tends to flow from your fingers and come together in good order, a well-planned infrastructure project puts peace in your soul.
At the project plan approved milestone, agreement has been reached on a number of important items:
· Project deliverables
· Functional priorities
· Risks
· Ship date
· Project plan
· Business requirements
· Conceptual design elements
· Design specifications
· Time and effort to complete project
As with envisioning, three interim milestones occur during planning: conceptual design complete, design specification complete, and master project plan complete. Deliverables for this phase considerably outnumber those for envisioning. Table 5-3 lists each milestone with its measurement and effect on the project.
Interim
Milestone |
Measurement |
Effect |
Conceptual Design Complete |
The vision, characteristics, distinctive benefits, and how the target audience will interact with the proposed solution are defined. |
Structures the solution and ensures that activities adhere to the overall mission and objectives. |
Design Specification Complete |
Defines the technical components of the solution in detail and determines how they will be implemented. |
Assigns technical detail to the structures defined in the functional specification. |
Master Project Plan Complete |
The master project plan includes the approach, dependencies, and assumptions of the project, as well as budget and costing information. |
Ensures that all the participants have a common understanding relative to the functionality desired, resources required, and time constraints. |
Table 3: Milestones of the Planning Phase
The deliverables produced during this phase set the parameters and establish a guide for development. The planning phase documents can and do still change with time; they are not set in stone. These documents belong to the program management role, who should alter them as the process helps to define itself. Figure 5-4 illustrates the deliverables for the planning phase.
Figure 4: The planning phase has three deliverables
Conceptual design, a non-technical document, describes what the final product includes. This detailed document covers the functionality of the solution, how the product might impact the current infrastructure, and the relationship between user and product. The conceptual design document includes a vision/scope summary, which is a refined distillation of the results of the previous phase. Of course the conceptual and logical design is fully detailed within the document. This deliverable also includes design goals, usability goals, constraints, and expectations. Besides acting as a guide to developers, the design goals give the testing team something to test. Detailed field surveys can be an important part of this deliverable. The project team must be able to gauge expectations for the solution. Documenting these expectations at this stage can be very helpful. Finally, the conceptual design document includes user profiles and usage scenarios. The scenarios focus on the environment as it will be, comparing it to the present environment.
While the conceptual design provided a non-technical view of the solution, the design spec itself fills in these technical details. Here’s where you get into the fun stuff, thinking of hardware and all the nuts and bolts of your solution. Additionally, this deliverable lists standards and guidelines, change control methodology, the life cycle management plan, and the security plan. Table 5-4 presents these parts.
Item |
Description |
Logical and physical design |
The details of the team’s solution. |
Standards and guidelines |
Ensures that the proposed solution facilitates the communication, integration, and consistency of information between and within elements of the organization. |
Change control methodology |
Framework for establishing why the change is needed, who is accountable for the change, what the impact of the change is, and how the change will be traced. |
Life cycle management plan |
Considers the rapid evolution of individual and aggregate technologies, together with dynamic organizational factors. |
Security plan |
Serves to ensure that data, resource, and service integrity are maintained during the project. |
Table 4: Design Specification Content
The schedules contained in this deliverable are also not set in stone. Scheduling can be an iterative process, but the mechanism for dealing with project schedule changes must be established. The master project schedule evolves over time. This deliverable consists of a task list, implementation schedule, test schedule, preliminary training estimates, logistics schedule, and marketing schedule.
The master project plan consists of the following plans: implementation, test, user education, logistics, solution marketing, and also a budget. The user education plan can be a key component of this deliverable. Your team should have idea of what kinds of solutions it will take to help users work with the product. A needs assessment, purpose statement, and evaluation strategy are parts of the user education plan.
Table 5-5 gives a complete listing of each MSF team role during the planning phase. As with all the other phases, each team has a very important role in planning. Ownership for the project really starts to take off in this phase, as each member gets a clear grasp on how they’re going to contribute to the solution. The remaining deliverables are test lab setup, risk assessment, and business manager approval.
Team |
Role |
Product Management |
· Project vision · User needs analysis · Schedule |
Program Management |
· Project design · Project master plan/schedule |
· Technology evaluation · Physical design · Development plan/schedule |
|
User Education |
· User performance solution strategy · Training needs |
Testing |
· Design evaluation · Testing plan/schedule |
Logistics Management |
· Materials/facilities procurement · Rollout plan/schedule |
Table 5: Responsibilities of Each Team in the Planning Phase
Planning test lab setups includes deciding who will be responsible for the labs, what activities will be performed there, how the lab should be configured, and how to establish the guidelines and policies for the lab. Like the SMART vision/scope document of the previous phase, Microsoft suggests a BEST way to define the main focus of the test lab. BEST stands for:
· Baseline and backup, making sure that your system can return to the original state in the case of a problem
· Eliminate risk by working through the problems and coming up with acceptable solutions
· Stress testing the solution under full load
· Testing and tracking, testing transitional components and generating useful statistics
Risk assessment goes on through all phases, but planning is a good time to start eliminating risk. The team should prioritize and identify the most probable risks. Work on plans to mitigate these top risks and incorporate the plans into the project plan, providing necessary additional resources.
The business manger approves the budget and resources required for the project. This deliverable represents the last element of the planning phase. Once you’ve got your resources, you’re ready to move to the next phase.
This milestone comes as your hard work begins to pay off. The scope complete/first use milestone occurs when your solution has been tried in a production environment and your team has consensus on the solution meeting the objectives of the vision/scope document. Figure 5-5 shows our progress through the process model. The developing phase has its own set of interim milestones and deliverables, which we will discuss in turn.
Figure 5: Developing leads to the scope complete/first use milestone
Identify the role responsible for each of the following tasks:
Project vision, user needs analysis, and a schedule: _______________
Project design and the project master plan/schedule: _______________
Design evaluation and the testing plan/schedule: __________________
Materials/facilities procurement and the rollout plan/schedule: _______
Technology evaluation, the physical design and the development plan/schedule: _______________
User performance solution strategy and training needs: ________________
As with other phases, interim milestones help developers track progress on the way to the completion of the phase, the scope complete/first use milestone. In this section we’ll look at each of the interim milestones and discuss how they fit into the developing phase.
Three somewhat similar milestones happen along the way to scope complete/first use. Each involves testing. The lab test complete interim milestone makes use of a test lab, which the team planned in the previous phase. This lab does not mimic the production environment, but verifies the soundness of the solution’s functionality. At lab test complete, the pieces of the solution have been tested. Some problems will be discovered and alternatives tested.
The proof-of-concept complete interim milestone takes place in the proof-of-concept lab. This lab, a successor of the test lab, does mimic the production environment. Here the whole model of the solution gets a test. The main goal of the proof-of-concept complete milestone is to reduce as much of the risk as possible. Here’s where you try the product without risking other enterprise resources.
The pilot complete interim milestone means that you’re almost ready to begin deployment. During the pilot, your team deploys a portion of your system in the actual user environment. Hopefully the bugs have been worked out by this stage, but you’ll likely find any that are left, without sharing them with the whole organization.
Table 5-6 gives each milestone’s description and effect.
Interim
Milestone |
Description |
Effect |
Lab Testing Complete |
Testing has been completed in an isolated technology infrastructure lab. |
Validates the technology |
Proof of Concept Complete |
The solution has been installed in a controlled test environment that mimics the anticipated production. |
Validates the solution |
Pilot Complete |
The solution has been tested in a limited, controlled production environment, and all known issues have been resolved or a contingency plan has been developed. |
Real-world validation |
Table 6: Interim Milestones of the Developing Phase
Your team will produce five deliverables during the development phase: pilot plan, training plan, capacity plan, business continuation plan, and rollout plan. Each MSF team has a role to play in developing these documents. Communication through this phase is essential. You want your teams not only to keep each other up-to-date on their progress, but also to let them share ideas and input. First, we’ll discuss the deliverables and then the roles of each team.
The pilot plan sets up the pilot test. It should contain all the necessary steps and procedures to run the test. Be sure that the plan accounts for each usage scenario. You’ll want the pilot to give a realistic representation of the product. Keep in mind that the pilot happens once. The pilot plan sets the stage for escalation to deployment.
Scope/complete first use is the time for training. Your team should complete a training plan as a deliverable for this phase. Good training doesn’t just teach users the mechanics of a solution; it also helps the organization get the greatest advantage possible for your project. With this in mind, your training plan should include a view of how job functions will change with the new solution, training logistics, and conclusions based on the user profiles.
The capacity plan functions as a kind of check to see if you’ve got enough of what you need. Is your infrastructure solution up to the job? Your team must determine if the components of your system can handle their required functions. Additionally, the product should allow for growth, without going overboard. The capacity plan is also a good place to check if your solution fits the vision, at least in terms of being adequate for the job.
The business continuation plan reduces risk by establishing procedures to recover to an acceptable threshold of performance in the case of a disaster. The plan doesn’t restore everything to its pre-failure state, but just gets things working enough so business can continue. To do this, your team must identify the critical systems that have to stay up, and what it would take to bet them back up. Identify areas where load can be reduced; in other words, functions that are not essential and can be shut down to devote resources to the more critical operations. A recovery plan takes the enterprise back to normal from where the business continuation plan leaves off.
And finally, the rollout plan! This plan gets your team ready for the next phase. It contains step-by-step procedures for delivering the solution. The strategy includes who gets the product when, and who will give it to them. The plan addresses how to get this done with minimal disruption. A good key to success for the rollout plan is for your team to get consensus, participation, and ownership of the user community. Don’t assume that everyone will think the product is as super as you do and worth the effort of change. Get the users involved and excited, and they’ll make rollout a lot more fun.
Table 5-7 shows the role of each MSF team during the development phase.
Team |
Role |
Product Management |
· Customer expectations · Schedule |
Program Management |
· Functional specification management · Project tracking/communication · Pilot plan |
Development |
System compliance |
User Education |
User/deployment team training |
Testing |
Issue identification |
Logistics Management |
· Operations/support/systems administration · Final release schedule |
Table 7: Team Roles during Development Phase
As your team approaches scope complete/first use and starts to think about deploying, some tasks help to wrap up development. During this phase, your team has validated the project. You know now that it will work. Plans made earlier, such as conceptual design, design specification, and project plans should be in their final form and consistent with the solution you are about to deliver. As your team transitions to deployment, work on stabilization of the system, making sure everything is settled and functioning as load begins to increase. Also, take a look at the milestones reached so far, and review what when wrong, and what went right. Examine your successes and failures so the team can be ready for the release milestone.
Exercise 5-3: Developing Phase
Identify the role responsible for each of the following tasks:
Functional specification management, project tracking/communication, and the pilot plan: _____________
User/deployment team training: _______________
Issue identification: _____________________
System compliance: ____________________
Operations/support/systems administration, and the final release schedule: _____________
Customer expectations and the schedule: _________________________
Figure 5-6 shows how far the team has gotten in the process: we’re almost there! The last phase, deploying, leads to the release milestone. Microsoft defines the point of release as when management of the system shift from the product team to the normal operations and support mechanisms. At this milestone the solution has been deployed and is considered stable. The customer has accepted the product and signs off in some way. Your team then moves on to the next project.
Figure 6: The last milestone: Release!
Four milestones occur during the deploying phase: rollout begins, training complete, rollout complete, and stabilization complete. Rollout begins is pretty easy! Your team should pretty much be there having finished the pilot of the previous phase. Training has been ongoing for some time now, but as rollout continues training concludes as users jump on the system and take off. As your team reaches rollout complete, there may be some significant problems remaining that prevent you from handing over support to the operational staff. Your team must complete stabilization before your role can end.
Table 5-8 describes each of the interim milestones in more detail. As your team reaches these milestones, a number of tasks are underway. Logistics management comes to the fore in this phase as they handle site preparation and rollout itself. In preparing the site, the team checks the site against operations requirements and sets up user administration.
Interim
Milestone |
Description |
Effect |
Rollout Begins |
Deployment of the new technology solution is extended beyond the safety net of the pilot group. |
Allows business to begin to realize incremental benefits from the solution. |
Training Complete |
Trainers, implementers, administrators, users, and operations personnel have all received the training they need. |
Meets explicit training needs of all user segments. |
Rollout Complete |
Technology solution has been deployed to all of the targeted users. |
Conveys the project business benefits to the customer. |
Stabilization Complete |
Rate of new problem reports has declined steadily and is at or near zero each day. |
Facilitates the transfer of support for the new technology to the infrastructure management team. |
Table 8: Interim Milestones Leading to Release
During the previous phase, development has adjusted the rollout plan to fit the solution. Now it’s time for logistics to execute the plan, providing the material and doing the legwork for getting the system in place. Logistics also sets up the appropriate help-desk mechanisms for long-term support after your team withdraws.
The testing done up to now has been good and has eliminated a lot of problems, but you know that problems will pop up when the system hits the production environment. Now your labs switch over to solving real-world problems. Testing continues throughout deployment as you work to bring the solution to stabilization and optimize its performance.
The deploying phase has two deliverables: post-rollout baselining of user profiles and usage scenarios, and project review. Do you remember the predictions of how the enterprise environment would change at the conclusion of the project? In the initial phase, your team developed a vision for a new system. In the planning phase your team took that vision and produced a document outlining the new environment. Now is the time to compare these predications to reality. How did your solution match what you envisioned? For the post-rollout baselining of user profiles and usage scenarios, you take the user profiles and usage scenarios of the previous phases and compare them to the result.
The project review examines the course you took in the deploying phase. Your team looks at what went wrong and what went right. The project review documents what you learned from your mistakes. Your team can then use these best practices for future infrastructure projects.
Table 5-9 gives a complete listing of the role of each MSF team during the deploying phase. As your team moves towards the goal, each segment still needs to focus on its role, keeping communication open throughout.
Exam Watch: Remember how each MSF team role relates to each phase of the project.
Team |
Role |
Product Management |
· Promotion · Feedback · Assessment · Signoff |
Program Management |
· Solution/scope comparison · Project tracking/coordination |
Development |
· Problem resolution · Release |
User Education |
· Need-specific training · Training schedule |
Testing |
· Performance metrics · Problem resolution |
Logistics Management |
· Site prep setup/support · Rollout management · Change approval |
Table 9: Team Roles during the Release Phase
Deploying culminates in the release milestone. The solution achieves release when all the users identified in the scope have received the solution, the rate of new problems approaches zero, the solution can be supported by permanent staff, and the customer expresses satisfaction with the performance, quality, and functionality of the solution.
So what do you do after product management obtains customer signoff? You celebrate, of course! If you’ve achieved your vision, your team has indeed done something worth celebrating. During this happy time, you can receive feedback from users, review milestones, and prepare for future technology infrastructure projects.
Exercise 5.4: Stabilizing Phase
Identify the role responsible for each of the following tasks:
Promotion, feedback, assessment, and signoff: _____________________
Solution/scope comparison and project tracking/coordination: _________
Need-specific training and training schedule: _______________________
Problem resolution and release: __________________________________
Site prep setup/support, rollout management, and change approval: _______
Performance metrics and problem resolution: _______________________
Exercise 5.5: Identify the phase for the following interim milestones and deliverables
Interim Milestone |
Deliverables |
Phase |
Conceptual Design Complete Design Specification Complete Master Project Plan Complete |
Conceptual Design Document Design Specification Master Project Plan |
_________________ |
Team Formation Complete Draft Vision/Scope Final Vision/Scope |
Vision/Scope Document Risk Management Plan Project Structure |
_____________ |
Rollout Begins Training Complete Rollout Complete Stabilization Complete |
Post-Rollout Baselining of User Profiles and Usage Scenarios Project Review |
______________ |
Lab Testing Complete Proof of Concept Complete Pilot Complete |
Pilot Plan Training Plan Capacity Plan Business Continuation Plan Rollout Plan |
________________ |
The enterprise architecture consists of people, process, and technology. The technology infrastructure is an intersection of these three. The MSF process model can guide infrastructure deployment projects. The model consists of four phases: envisioning, planning, developing, and deploying. Each phase concludes with a milestone: vision/scope approved, project plan approved, scope complete/first use, and release. Each phase has interim milestones and deliverables. The MSF team model organizes the deployment team into six roles: product management, program management, development, user education, testing, and logistics management.
· The technology infrastructure exists to meet the business needs of the organization.
· Microsoft’s eight categories of the technology portion of the infrastructure are: data transmission links, local area network architecture, wide area network architecture, protocols and transports, network operating systems, computer hardware, computer software, and domain/site models.
· The process model is an iterative process that allows for multiphase development projects to assume an organized, continuous, development process.
· Remember the SMART requirements of a vision/scope document: Specific, Measurable, Achievable, Results-based, and Time-oriented.
· The process of envisioning brings the team to the vision/scope approved milestone. At this milestone the members of the project team, the customer, and key project stakeholders reach a common agreement on the essential parts of vision and scope.
· Microsoft suggests some helpful intermediate points to measure progress: team formation complete, draft vision/scope, and final vision/scope.
· Microsoft identifies six roles for members of a team: product management, program management, development, testing, logistics management, and user education.
· The vision/scope document, has several necessary characteristics: it provides a clear direction for the team; it sets customer expectations; and it approximates the risk involved in the project.
· Conceptual design, a non-technical document, describes what the final product includes. This detailed document covers the functionality of the solution, how the product might impact the current infrastructure, and the relationship between user and product
· Planning test lab setups includes deciding who will be responsible for the labs, what activities will be performed there, how the lab should be configured, and how to establish the guidelines and policies for the lab.
· Your team will produce five deliverables during the development phase: pilot plan, training plan, capacity plan, business continuation plan, and rollout plan.
· The rollout plan contains step-by-step procedures for delivering the solution.
· Four milestones occur during the deploying phase: rollout begins, training complete, rollout complete, and stabilization complete.
· The deploying phase has two deliverables: post-rollout baselining of user profiles and usage scenarios, and project review.
Developer Team
User Education Team
Product Team
Program Team
Testing Team
Logistics Team
Product Team
Program Team
Testing Team
Logistics Team
Developer Team
User Education Team
Program Team
User Education Team
Testing Team
Developer Team
Logistics Team
Product Team
Program Team
Product Team
User Education Team
Developer Team
Logistics Team
Testing Team
The third column should have the following answers:
Planning Phase
Envisioning Phase
Stabilizing Phase
Developing Phase