As a project manager I am responsible for a myriad of activities, but if I consider them in aggregate I realize that they are just different manifestations of the same thing: my job as a project manager is to recognize risk and manage it.
Concept: Successful project managers are masters at evaluating, mitigating, and avoiding risk. Their job is to bring a project in on time and within budget. Anything that can jeopardize that is a threat and must be avoided.
Details: The best project managers recognize problems BEFORE they are problems and either find ways to avoid them or have contingency plans in place to effortlessly address issues as they occur. They must maintain a vigilant guard against problems (or potential problems) and mentally have a Plan B (or Plan C or even Plan D) available to immediately bring to bear if necessary. Jiminy Cricket makes very poor project plans – wishing upon a star and hoping that things work out is NOT the way to run a project. During the project, continuously monitor how things are going against the plan and adjust quickly as necessary. If a manager acts when the project is a third of the way through, then he or she has time to catch up and still make the budget and/or schedule. If the manager delays taking mitigating action until the project is 80% or 90% complete, then failure is virtually assured.
Here are some potential sources of risk and ways to eliminate them:
• Choose the project team wisely. If at all possible, try to keep the same core team and only add a new member on occasion. A core team knows each other’s strengths, weaknesses, and quirks and can communicate at a much higher level with very little effort. They also can bring to bear a strong history of techniques from past projects and lessons learned.
• Know the technology. If the team is new to a DCS or network technology, try to work some smaller projects and gain some experience before jumping into a larger project.
• Know the process and/or the client. Understanding the process and the client’s needs is critical for project success. If the process is untested or the client is new to the team, budget more time to get to know the client and understand his needs.
• Send graphics or partially completed software to the client for early review. If possible, develop a graphic and all of the underlying modules (with imbedded simulation) as a unit and forward it to the client for review upon completion. If there is a disconnect between the client’s expectations and the team’s work product, the team needs to know that early!
• Build and test the control panels in advance. (This was discussed previously in Tip #29.)
• Avoid the latest version of software. If the project does not require the latest functionality, do not rush to utilize the latest software release. With increasing frequency, vendors are releasing poorly tested software and letting their customers debug it for them. Let someone else fight that battle.
Watch-Outs: Order any project material early and constantly check on its progress once ordered. Many projects have been delayed because the equipment failed to arrive on time. Sometimes the purchase order never got placed by the purchasing department, sometimes the vendor lost the order, and sometimes the factory got behind and failed to deliver or delivered the wrong thing. Assign a person to check up on each purchase order and when items arrive, open the boxes and make certain the material is correct.
Exceptions: There really are not any exceptions for risk management. EVERYTHING can be a source of risk and should be monitored. A subcontractor can have a long track record of success but fail to deliver on time due to internal organizational changes or workload. Valued vendors may have manufacturing problems and the usual two week delivery may extend to 12 weeks. Take nothing for granted.
Insight: If the project involves programming a safety interlock PLC consider staying at LEAST one major revision behind and if that revision was short lived or had problems, it may even be worth staying TWO revisions behind. When dealing with safety interlocks, the programming is rarely complex and system stability is far more important than getting the latest bells and whistles (and the bugs often associated with them).
Rule of Thumb: As a project manager, continuously monitor everything for signs of problems and immediately inquire if something seems amiss. No project manager wants to be surprised.