MSF Deployment Phase. MSF Deployment Phase Tasks. Starting the deployment Going Live Stabilizing the deployment Transferring ownership to operations Closing the deploying phase. Starting the deployment.
PowerPoint Slideshow about ' MSF Deployment Phase' - bertha
An Image/Link below is provided (as is) to download presentation
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
At this point, the pilot has been tested and the team and key stakeholders have agreed on the acceptance criteria.
Acceptance criteria might mandate that all issues have been resolved, or that the solution is ready for deployment with the knowledge that some issues might exist and will be resolved in later versions.
The team should review the checklists for potential issues, and if all appears to working properly, it is time to go live.
It is vital that the project team continues to monitor the site after deployment until the transfer of ownership is finalized; This allows the team to establish baseline performance records to determine whether performance is going up or down.
Neither testing nor live pilots can completely reproduce the type of use and amount of load that the servers will experience after going live.
If the stress and capacity tests are performed well, the team should have both test scripts and test results available providing the baselines.
It is important to compare the baseline numbers to the new numbers any time a change is made to the servers, visualizing what effects the change has on performance.
Monitoring will continue on a regular basis, even after ownership is transferred to operations.
A joint venture between the project and the operations teams.
Usually begins in the later part of the developing phase and continues throughout the deploying phase.
Important to include time in the master schedule for stabilizing because it gives both teams an opportunity to fine-tune the solution, resolves any issues that might arise, monitors the site to ensure it continues to work properly after going live, and assists the operations team after the transfer of ownership.
Verifying that the operations team has the proper resources to maintain and manage the new site.
Confirming that the knowledge base for transfer to the operations team is finalized.
Reviewing operations’ logbooks and ensuring that the procedures are being properly performed; The developer should clarify and correct any irregularities that were logged, and ensure that these activities are being maintained and monitored on a daily basis.
Confirming that all project sign-off affidavits are correct.
If the site needs extensive add-in information or if the architecture or design needs upgrading, the product planning or marketing personnel might choose to initiate a new or second version project.
No matter how the initial project was deployed, the second version would be deployed by establishing a development, testing, and staging environment that is transferred to production after successful testing and initiating a live pilot.
Although it is possible to manually install the operating system on the servers, using a cloning process like Sysprep.exe is an easy and efficient way to deploy the operating systems on new servers.
MOF recognizes that current industry best practice for IT service management has been well documented within the Central Computer and Telecommunications Agency’s (CCTA) IT Infrastructure Library (ITIL).
MOF combines these collaborative industry standards with specific guidelines for using Microsoft products and technologies.
MOF also extends ITIL code of practice to support distributed IT environments and current industry trends, such as application hosting and Web-based transactional and e-commerce systems.
MOF embraces the concept of IT operations providing business-focused service solutions through the use of well-defined service management functions, which provide consistent policies, procedures, standards, and best practices that can be applied across the entire suite of service solutions found in today’s IT environments.
Upon project closure, the product manager obtains the final sign-off from a representative of the customer, signaling approval of the solution and permission for the team to disengage from the project.
Although, at this point, the team is busy informally closing outstanding tasks and wrapping up deployment, the sign-off should be a formal acknowledgement that the project is complete.
When the project is complete, the team should hold a review meeting to discuss the project and identify what went well, what didn’t go well, what to replicate in future projects, and what to change.
Without assigning blame, team members conduct the project review with the goals of learning from mistakes and improving future projects.
Often called a postmortem, the project review meeting sometimes takes place shortly before the end of the project rather than afterwards, because team members might be required to leave the project before it ends.