Author: sam598sum15

Stop What You’re Doing. Read My Blog Post on Risk.

Posted on by sam598sum15

Over the course of my career, I have witnessed many projects.  I run sales for one of my company’s divisions.  If our sales group wins an application, it gets moved to program management/engineering group for execution.  The sales team is aware of the project, gets status, details, etc., but is not a true team member of the project.  Our sales group has a stake in the success of the project, because our customer won’t be willing to speak with me again if the project is a disaster.

So, all these projects have occurred, and I have had my fair share of disasters.  One very important piece of the program management pie is RISK.  Yes, risk identification and mitigation; what some may call the most boring part of a project.  The exclusion of this boring process has also led to me having very difficult conversations with customers.  So boring or not, stop what you are doing and make sure you go through risk identification/mitigation on your next project.  I don’t want to be yelled at anymore.  Help me, help you.

Here are some things that will help.

Know Thy Project – I have often seen projects go through risk identification and mitigation, only to get burned up on schedule and cost by an adjacent risk that nobody ever thought about.  This is due to rushing through project planning to start development.  BIG MISTAKE.  SIPOC is a great acronym to utilize at project onset.  It stands for Suppliers/Inputs/Process/Outputs/Customers.  It also helps with risk identification.  By utilizing SIPOC, the risk of not identifying risks is mitigated!  You’re welcome.  The following link explains SIPOC and how to utilize it: http://www.discover6sigma.org/post/2007/06/sipoc/.

Alright, great, we are now confident that risks have been fully identified because we looked at Risk through the SIPOC lens.  Now, it is important to have a Risk Register developed before beginning project execution.  Jumping the gun and moving to project tasks always seems to be the Achilles Heel of a project.  Risk Register’s avoid disaster.  There are many ways to develop risk register’s.  I found this link to have a good explanation and guide: http://hse.ie/eng/About/Who/OQR010_20090422_v_11Developing_and_populating_a_Risk_Register_BPG.pdf

The guide was based on health service industry, but the risk development process is solid; which would be expected considering the industry.  On page 5 and 6 of the above link, there is a really good visual for creating your project’s risk register.  The pages that follow provide guidelines for gathering risk and is similar to SIPOC.

Lastly, once a risk register is developed, and developed based on truly understanding risk, the most important thing to do is utilize the documentation.  I find it odd that project teams go through the risk process and then forget about it.  Bright hub had a nice article on managing risk throughout the project: http://www.brighthubpm.com/risk-management/45164-tips-on-managing-project-risk/

This article reminds PMs that risk registers should be reviewed with the team weekly.  This keeps the information that was so painstakingly developed right in front of the team.

Have you been involved in a project that utilizes these types of risk strategies?  Do you find that these strategies are effective, or, do you have alternate risk strategies that you feel are better?  Risk identification and reduction are often implemented, but overlooked later.  Why does this happen when risk processes are commonly employed at the beginning of a project?

Project Communications Plan – The Secret Sauce

Posted on by sam598sum15

Within the aerospace firm that I work, there are dozens of projects being completed on any given day and time.  We have a matrix organization in which PM’s lead projects by utilizing members whom have their own functional manager and have multiple project responsibilities.  Our company, which is small relative to other aerospace divisions whom manufacture similar systems, has made great strides in developing PM tools to be successful; our PM’s are now trained in and utilize MS Project and its toolset, they have developed WBS tools that are utilized across each project being utilized, and most importantly, all tools are standardized so that each PM and project team have a repeatable game plan and tool set for projects which change ALL the time.  However, our company has continued to see wide variation in project success in terms of timeliness, cost and performance.  Even with the added tools, we have only seen marginal improvement.  What could possibly be missing?  Enter the Project Communications Plan!

A Project Communications Plan, as described in the text in Chapter 4, highlights the importance of internal planning for communications.  Projects see all types of variance against original plans.  This communication tool ensures a constant cadence in which all functional units of a matrix organization understand their responsibilities and accountabilities as the project progresses and changes.  I felt that this piece of project management was the missing link for our company’s projects; project charters, WBS baselines, RACI charts (responsible, accountable, consult, inform), and weekly project meetings were simply not enough for our team to meet the mega trifecta of project success – on time, at cost and meeting performance requirements.  After doing some searching, multiple sources identified that a formal PCP was the most vital form of team collaboration.  An excellent explanation can be found on TechRepublic’s website: blog 1\Communication plans are key to project success – TechRepublic.html.  The PMI Institute also further quantified the importance of communication via a white paper, and PMI identified that 80% of highly effective communicating project teams met original goals: blog 1\Communications_whitepaper_v2.ashx.

The text highlights (5) important segments of a PCP that ensure a team that is aligned with its internal and external expectations; of which (2) I feel provide singular value above the Project Charter.  I felt that the (1) Information Needs and (2) Sources of Information piece to the PCP offer an excellent way of ensuring team success.  By identifying the “When/Who” a team member receives its information, positive project pressures are applied to each individual.  I feel that positive project pressure is an excellent way to ensure team cohesion and “buy in”.  I feel the best way to implement PCP is to have the team get together right after the WBS and milestones for the project have been defined.  Then, each member can understand upfront, how they are impacting each phase of the project, at a task level, and more importantly, how each individual relies on the other to ensure tasks remains on schedule, on cost and meet performance.

A PM can act as the guide for the PCP and also better understand the flow of information between functional departments (especially when the PM is not the resident expert for any of those functional departments) in order to make sure each task is implemented on time.  Does the class feel that this is true of projects worked in past?  Are other similar applications of a PCP utilized in PM efforts?