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)

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)

I worked on a project that was eventually terminated due to scope creep causing enormous cost overruns. The Project Manager did not stay within the scope. This happened slowly over time like a small crack in a dam leaks water. Change requests kept coming in and they were all getting approved. The cost of the project just kept going up. Change requests are a part of every project it happens. This project had change requests beyond sanity. We were replacing a system with the same system in the end if we did not pull the plug on it and cut our losses already.

Some causes of scope creep:

(1) Poorly defined requirements that don't clearly highlight the objectives you want to achieve. You need your deliverables defined clearly.

(2) Weak change control.
 

(3) Sponsors that are weak.
 

(4) Selecting the wrong vendor solution.

(5) A Project Manager that does not raise the flag when he sees the project spiraling out of control. He thinks he can salvage it.
 

(6) Having no sign-off from all parties that have a stake in the project. They need to speak up if they feel the proposed project falls short of their objectives. Hash it out before you formally kickoff the project.

My granddaughter loves playing Minecraft. The creepers job is to ambush players. Players can avoid creepers by running away or facing them to get rid of them. You can runaway from the creepers to avoid them, but they are still out there looking to cause trouble. Exterminate the creepers to get rid of them. The same goes for scope creep in project management. Don't allow numerous changes without challenging it. Face it head on and ask for a compelling justification. If your given a weak justification terminate that change request.

Minecraft Creeper

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

Hawaii Civil Defense

Hawaii gets a nice Saturday morning wake up alert on their phone.

Words cannot describe the initial reaction you get when you receive an alert that you need to seek immediate shelter because a ballistic missile is on it's way. You only have about 20 minutes to find your hiding place. 

Project Management failed on setting up the new civil defense preparedness for a ballistic missile attack on Hawaii. The failure caused panic and pain. Your life could be ending in 20 minutes. You keep waiting for the all clear and nothing happens. It took over 38 minutes for the Hawaii Civil Defense to send out an alert that there is no threat.

Some lessons learned:

1. There was no leadership from the top to bottom that day. Just confusion. They knew immediately that the alert was and error.

2. Step up, no one had the guts to take charge of the situation to immediately send out an alert that there is no missile on it's way.

3. How does one person have access to such a critical life and death alert without management authorizing the alert to be sent out.

4. Training and safeguards was obviously missing in the project plan.

5. No contingency plan was properly developed to execute in the event of an erroneous alert going out to the public.

My final thoughts on the incident is that Project Management and Leadership play such an import part no matter what type of project it is. In this case the residents and visitors in Hawaii will never forget this date 01-13-2018 because a Project Manager and lack of Leadership really really messed up bad.

It's a good idea to complement your project by defining KPI's to present to your stakeholders. KPI's will demonstrate that the project is on track by meeting it's goals. Assemble your team to come up with ideas on what to measure and how you will achieve the measurement.

Project milestones are important, but they just mean that you reached a given point in the project. Stage your KPI's at milestones to get a thorough health check on the condition of the project then celebrate the milestone.

It's all about ensuring that you deliver the right results when you get to the finish line.

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