Project Management in Real Life

You are the Project Manager for two important projects that need your attention on a Saturday night what do you do? Have the right people on the project. 

I had a Radiology/Pharmacy system relocation go-live that involved moving the system across town to a new Data Center. The second project required some critical tasks to be performed for another project that cannot move forward until two critical tasks are completed.

The players that supported me was a Business Analyst, Data Center Operations Supervisor, and HP Field Engineer to shut down and pack up the hardware at 23:00 to let the moving company deliver the system to the new Data Center.

The system arrived in the new Data Center in good condition. The Data Center was already prepared for power, network connectivity, and telephone lines. Everything went well except an issue with a legacy application that had issues with a modem. I had to leave the team and work on my second project that I was the only player that could do two critical tasks to keep the project on track.

I had to drive back to the old Data Center to perform the two critical tasks. It's 03:00 and I go to work and everything went according to my plan and I finish at 04:30. 

Time to drive back to the new Data Center to help the team get the legacy application working. We get the application to work at 11:00 Sunday morning. 

The key to a successful project go-live is teamwork, it's so important to support each other. Having a good Risk Assessment review meeting to make sure you cover everything in your go-live plan is so important to catch anything that you might have missed on the plan.

Tip for your project go-live plans. When you develop your plan break the timeline tasks down in half hour increments when possible. By breaking down your tasks in half hour increments you can measure your progress better. You will see what areas are taking more time or less time to complete. You can determine if you need to back out the implementation or continue to move forward. In some cases you can't go back so it will help you give a status report to management.

(Note - this article was originally written by Drake Settsu and published on DrakeSettsu.BlogSpot.com in December 2013)

It's a good idea to evaluate all your systems to determine on a scale of 0 - 5 what level of risk you are exposed too. Develop a spreadsheet to track all these systems. Items for example to list on the spreadsheet are hardware, operating system, database, applications, vendors and any other information that you feel is important to support the system. While you are doing the assessment it's a good idea to update your Data Center floor plan diagram identifying where each system resides. Once you complete the assessment place a sticker on the hardware indicating that it was evaluated already and come up with a code to cross reference it back to your floor plan diagram.

Doing a system failure assessment is a big project that takes commitment. Depending on the size of your organization it could take months to complete depending on how deep you dig for information. I suggest you do a thorough examination that will expose all vulnerabilities. While performing the evaluation it's a good time to review all your support contracts. You also get a heads up to budget for system upgrades or replacements. You really find out a lot of information to present to management from a system failure assessment.

Grading your findings for example could be a 5 for the highest level of risk if it's a black box that just runs and no one really has a clue how to support it because the person who installed it left 10 years ago and it just keeps on running, don't re-boot it ever. If you are running on an old hardware platform and it's off support and you are unable to patch the operating system that will be a level 5 risk. Just a few examples to give some ideas on how to rank your risks.

The System Failure Assessment will need to be a living document updated periodically to keep it effective and valuable. It will serves as a disaster avoidance / disaster recovery document. It's your decision how to act on level 3 - 5 risks. Don't wait act now.

(Note - this article was originally written by Drake Settsu and published on DrakeSettsu.BlogSpot.com in February 2015)

Holding a Risk Assessment meeting prior to implementing a modification to a process or system that could result in loss of productivity to a business unit. Invite business units with a stake in the implementation. Encourage feedback to tear up your plan and look for any holes in it. You need to really know your stuff when you hold a risk assessment meeting because they can get intense. The meeting is your time to shine and field questions. Show what you are made of. Be confident and never get defensive or offended by the reviewers. You should have a subject matter expert on your team to help you out when a discussion gets out of hand. Sometimes the risk assessment meeting has hecklers to distract from the productivity of the meeting and your job is to shut that person down diplomatically to keep the meeting on track.

The risk assessment document should include an implementation timeline giving a summary and anticipated duration of the activity that is being performed. Build your timeline with appropriate padding to allow you some extra time should you run into issues or take a little longer than anticipated. Break down your timeline into half hour increments to gauge your progress. The Go/No-go decision needs to be placed at a critical point in your timeline to evaluate your current progress to determine if the implementation is on track or not on track with numerous issues encountered warranting a back-out of the implementation. The plan should also include names and contact numbers of key people that you might need to reach out to at anytime during the implementation.

(Note - this article was originally written by Drake Settsu and published on DrakeSettsu.BlogSpot.com in December 2013)

Implementations in a 24 x 7 x 365 organization needs to be planned out carefully to ensure minimal down-time to the organization.

1. Test Test Test in an environment that resembles your production environment to ensure a successful implementation in your production environment. Get your sign-offs to document that the objectives have been met.

2. Change Management approves the project to go live, but there are some risks that need to be addressed in a Risk Assessment meeting. This meeting requires an audience that represents key players from all departments that will be or could be impacted by the implementation to give their feedback on the implementation. Present a timeline of the implementation tasks. Set a point of no return that means no looking back. You are committed to finalizing the implementation. Set a backout point to return the original system back to users if the implementation is encountering issues. You will need to know how long it takes to restore your system. Provide an estimated time when users can expect the system back. Pad your timeline to not take all day, but allow for the things that go bump in the night. 

3. Have your standby spreadsheet of contacts that do not need to be onsite, but could be consulted during the implementation.

4. Send out periodic status updates on the progress of the implementation. 

I wrote about the risk assessment and going-live on my blog Just Drake's View:

The Risk Assessment

It's the 11th Hour the Curtain is Going Up