Bring in the Business Analyst

We live in a world with technology to give businesses the ability to run an efficient operation. Well that's not going to happen if the wrong components and processes are in place or it's time for a technology refresh.  

The Business Analyst is the person that needs to understand how the business operates to meet their objectives now and into the future. A good Business Analyst needs to roll up their sleeves and get dirty digging for information. A Business Analyst needs to work with the business units by documenting the process flow by observation and asking a lot of questions. Spend a week with the business unit that is targeted for improvement to get a good feel on how they operate.

Something to remember when you work on improving a process. I was told by an instructor in a class I attended on process improvement, "If you can measure it, you can manage it."

My Utility Server

I was privileged to work at two companies that allowed me to have my own personal Microsoft Server to support the enterprise. I had a physical server at one company and a VMware server at another company. I was responsible for maintaining my server. I installed all my support utilities and applications on it. I staged documentation on it to latter upload to SharePoint.

The server was my personal assistant that I could not live without. I used it all the time to VPN into to provide remote support. I had a desktop PC in my office to use when I was there. I was a very busy Systems Administrator who also was a Project Manager too. Always away from my desk all the time so my personal server came in very handy to connect to from a guest PC when I was not in my office. 

The System Failure Assessment

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 theses 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.

Your Database is toast get out the butter and jelly

It's Aloha Friday morning on my way to work and I get get a call from the Data Center that the mission critical system for the organization is acting strange. Users are unable to access the system. Moments latter I get a text page from the system that a process that needs to run is gone. I had scripts monitoring the system so I knew something bad happened. 

I logon on to the system and it's not normal and the process that needs to be running was missing. I spoke with the Data Center staff and determined that an operator error caused the problem. The database that was in production was an interim database version to migrate to a new permanent database later in the month. It had known bugs that we just stepped on by accident.

I call an emergency meeting with management to brief them that the database has been corrupted. I contacted the application vendor to take a look at the database integrity. I advised management to implement downtime procedures. Hours elapsed working to fix the database with no luck. The database cannot be repaired. My only option now is the last system backup. I asked the Data Center Manager to bring the backup tapes to me. I’m holding in my hands the tapes of the mission critical system of the organization. I need a successful restore to minimize the window of data loss.

I call another meeting to break the bad news to management and staff. It’s going to be a long night we need to inform our users that the system will be down for an extended time and we will be giving periodic updates on the recovery progress. Key personal needs to be on standby and available when called.

The restore process is initiated. Restoring a large system takes hours and patience waiting for it to complete. Once the restore completes we need to run the integrity checker utilities to make sure no corruption exists on the restore. The system was validated to release back to the users with some minimal data loss between the backup and the time of the database corruption. Made some minor tweaks on the system. It's back on-line for everyone to use.

I got in the office at 8am Friday and it’s now Saturday 8am. I just experienced a System Administrators nightmare. When you are coordinating a major Disaster Recovery effort it's all about teamwork. You need to remain calm as you become the point person that knows everything that's going on. All eyes are on you. My Project Management experience definitely came into play on this recovery effort that had to be put together on the fly. You really know what you are made of when you go through an experience like a major system outage. It's a real good feeling seeing everyone work together as a team. 

Proposals for solutions the three options way

Present your solutions with the three options approach. When you are on a budget and faced with a problem that needs to be addressed you need to look at various options to address the problem. 

1) Look at the short term cheap fix solution if it will meet your needs until a long term solution is implemented in the future. 

2) When you are uncertain when a long term fix will be implemented you need to look for a solution that has the capability of going the distance without all those bells and whistles. 

3) The long term solution with all the bells and whistles that will address all your needs into the future. 

It's all in how you present the options to management. You need to upfront commit to your first pick and hard sell it. Management will have a chance to see the three options and decide to just fork out the money to address a permanent fix or select one of the two cheaper solutions to buy time to get that permanent solution in the budget.

Taking one for the team

Project Management requires thick skin and controlling your emotions. You are in the spotlight all the time. How you react to a situations defines you in front of everyone.

Once upon a time years ago I was verbally assassinated and yelled at by an IT Director at a monthly Project Management Office Stoplight meeting. I was going to explain a major change in a project that postponed a phase of an implementation to a later stage in the project. Earlier in the the day before the status meeting the Senior IT Director called me and my core team to meet with him. He asked me to defer implementing a phase of the project requiring me to rework the project plan. We all agreed that this would not delay the overall completion of the project but allow focus on other areas of the project that would deliver a better solution.

The Stoplight meeting was held in a conference room and if you could not attended in person a bridge line was setup to call into. The Senior IT Director called into the bridge line and the IT Director attended the meeting in person. Once I started to explain the change in the project the IT Director just unloaded on me not giving me a chance to explain why the project is changing to deliver a better solution. She turned red with anger raising her voice at me with the attendees in the room in shock. The Senior IT Director in a calm voice asked the IT Director many times to let me speak. I just sat down and could not get a word in and just looked at her as she insulted me. She then stormed out of the room slamming the door. The Senior IT Director asked me to leave the meeting and go back to my office so he could call me. I was not shaken up but disappointed that a person that I knew for a long time would behave so unprofessional in a meeting. I received the call from the Senior IT Director and he told me "thank you for taking it for the team". I will speak with her he said. Sadly that IT Director was terminated a week later.

The project was delivered on-time and a big success.

The Risk Assessment

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.

Tales of Project Management

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 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.