In The News & Press Releases

Projects at Work

Taking a Risk Plunge

May 8th 2017

Managing risk is not exclusively about minimizing it. Risk is also about maximizing rewards. Here, a lead project manager shares some thoughts on “playing it safe” to stay on track and avoid issues versus “taking a plunge” to pursue an unexpected opportunity.

Managing risk is a crucial part of being a successful project manager. Play it too safe and you can miss critical business opportunities. Approach it fast and loose and chaos is not far behind. But when it comes down to the day-to-day, how can you know you are in the right place when it comes to understanding — and exploiting — risk?

To get a real-time view from the field, we took some time to chat with Dan Kushner, a lead project manager at MBX Systems, a Libertyville, IL-based provider of engineering, hardware and fulfillment programs, as well as services for independent software vendors and other service providers. His primary focus: on-boarding new customers for new product development and managing internal projects. Kushner is also an adjunct instructor of Project Management at Northeastern University, College of Professional Studies, and part of the Experiential Learning Team that facilitates real-world project management opportunities for students.

ProjectsAtWork: We know that risk can actually be a good thing, such as when it pushes you to create a new process or product. What’s a good reminder example of this?

Dan Kushner: Absolutely! Last year while working on a number of custom hardware branding projects for customers, we noticed that the options for certain Tier 1 brands were very limited and overpriced. We realized we were gaining the experience necessary to develop our own product that meets these market needs. Thus, the Modular Bezel Project was born! This risk management strategy is related to exploiting something within a project in an unexpected way. After designing bezels for many customers, we knew their requirements always had certain commonalities, and we could leverage this knowledge to create our own superior, and less expensive, design.

PAW: How do you know when to “plunge” vs. “play it safe”?

DK: It’s about setting expectations. Never plunge without the stakeholders knowledge and sign off. For example, if a project is on the brink because of enterprise environmental factors or a requirement changes, and the impact creates an untenable risk, these are situations to consider “plunging” in order to mitigate risk. On the other hand, “play it safe” if the project is on track, the team and client are working well together, and there’s no externality that needs to be accommodated that could create issues outside of your control. We always try to control the scope and steer customers away from bad choices based on our own experiences.

PAW: Your company, MBX, made a major investment to build proprietary software to manage its manufacturing operation just a few years after going into the custom build business. What made this gamble make sense from a risk perspective? Did it pay off?

DK: This investment was made prior to my time here at MBX. I use the software every day, as do our manufacturing, engineering, and corporate environments. From the project management point of view, we run several projects concurrently to make incremental improvements in this internal software.

PAW: Proper risk management is supposed to be proactive but unexpected events and opportunities arise all the time in business. How should your approach to risk change when things come up out of the blue?

DK: When something unexpected arises, the response should envelop stakeholder management, impact analysis, and solid communication. If there’s no way around it, the change needs to be documented with an impact statement containing the financial delta, technical changes, secondary changes, and schedule changes, in full view for all stakeholders. At that point strategies for mitigating the impact can be discussed. When it’s unexpected, it typically means a risk event has already happened, so the choices that need to be made are often tradeoffs, and the sponsor needs to be involved in the discussion otherwise no plan of action can be approved. Our industry is stable enough that we don’t work in a high pressure environment that would necessitate daily risk management. The computer science world is mature, and external changes that come suddenly with a major impact are few and far between. Additionally, our projects range from three to 12 months, and often that means if something changes, I can re-plan and re-baseline, and we stay in good shape.

PAW: Have you ever been tempted to minimize any potential risks so as not to rock the boat? Overstate as a “CYA”? Or, if you prefer not to answer that, what are the risks to playing loose with risk assessment?

DK: No, we don’t do any CYA at MBX. It’s just not our culture. Occasionally a project comes up that doesn’t have the financial baseline to justify investing in a full risk assessment, particularly when it consumes a lot of overhead or is similar to other projects we’ve managed. We are moving to a new internal system that should make risk management planning easier and, therefore, extendable to workups for lower-level projects.

PAW: What has changed over the years in how you document risk and why? Are there any tools or approaches that have either come into favor or fallen out since you’ve been practicing project/program management.

DK: The spreadsheet I use began when I was in school, and I’ve modified it for continued use. Our methodology for risk management is to assess the likelihood and impact, and assign a strategy. Then we rank and redline the risks we are going to actively manage. What we’ve seen over the years is that certain risks come up over and over again, and it’s almost rote at this point that we take certain precautions as standard operating procedure. For example, the approach we use for certain technology and certain customers is to source redundant supplies to cover the possibility of dead-on-arrival parts that could delay our schedule.

Dan Kushner - MBX SystemsDan Kushner is Lead Project Manager of MBX Systems (www.mbx.com), a designer and manufacturer of custom server appliances for independent software vendors and service providers that need to deploy complex business software in a turnkey hardware/software package.

 

This article was originally featured in Projects at Work.