Project Management in Real Life

The Project Team Members is an important risk on a Risk Register, there are many other risks to add to the register, but my focus on this article is Team Members. 

Project Managers need to focus up front on the availability of team members for a project. The Risk Register should include team members working on different projects, especially concurrent projects. We often assign key staff to multiple projects which is fine if their key dates and implementation have breathing room for safe multitasking. 

The Risk Register will provide valuable insight into how your project team is spread out. The reprioritizing of project dates might be needed to address overallocated staff. It's good to know up front that you are working with overallocated staff so you know the potential risk that could be a showstopper.

Roll the dice or play it safe. Just make sure that management understands all the risks that are involved with overallocated staff. 

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)

Project Management has been around from the beginning of time. Just think about the wonders of the world that have been built. A form of project management had to have been used to accomplish such feats. The Romans and Egyptians are examples of accomplishing amazing construction projects with only primitive tools and slaves. The use of slaves must have been ingrained into project teams through the years to joke about Project Managers being slave drivers.     

Fast forward to modern times. Project Management is a critical discipline to ensure successful delivery of projects on time within the budget. Projects are tied to a budget with a reasonable variance for the bumps in the road that could pop up. The bumps in the road are the project risks that should be identified and monitored all the time. The entire team needs to be onboard with open communication to immediately report any risks that are starting to materialize. If you stick your head in the sand and hope that the risk goes away without any mitigation, good luck, get your resume ready. 

The person overseeing the entire high profile project needs to be transparent, accessible and have integrity. Knowing when to say timeout takes guts when it's starting to look bad. Slapping on workarounds for deficiencies that eventually catch up with the project is just pure stupidity. Money and time are just wasted and your competency will questioned. 

Having an unrealistic attitude that we have put in many hours and spent big money on the project already so it's unstoppable because we are at the point of no return will not work in your favor. Any failing project can be shutdown to repurpose it or dismantle it to stop further financial loss. Repurpose or dismantling will come at a cost, but if you continue on with a poorly planned project that should have never gotten a green light to proceed, you better have deep pockets to keep funding that White Elephant. A lot of people will be outraged and at the same time relieved that bleeding will be stopped. 

It's all about gathering the required cost and time to complete a project on-time within the budget. Not an easy job for some projects, but it needs to be done properly without cutting corners to get an approval. That's the expectation you expect when you entrust a project team to embark on a major high risk project that is very expensive. 

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