We examined risks very closely in our last class and I can’t think of a better example of risk in project management than those experienced at a startup. As an entrepreneur venturing out on your own, or with a small group, building up a business is a process of trial and error. You can become really passionate about an initial idea but once you’re out in the field talking to customers it may become obvious that the idea doesn’t solve their problem. Then it’s back to the drawing board!
Hopefully this realization occurs before you’ve arranged the people and resources needed for the business. Otherwise all the investments you’ve made can become a sunk cost. Many startups today follow a lean model where failure is incorporated into the project. Instead of starting full production on a product, prototypes (or a minimum viable product) are used to get feedback on the product’s functionality. A few, hundreds, or thousands of prototypes may be scrapped in the process. Dyson’s vacuum technology took 5,127 prototypes to get right (Dyson, 2011). Therefore, by testing and retesting ideas before fully going to market, entrepreneurs can mitigate the amount of risk they take on and get to know their customers better.
How can we apply the startup approach to project management?
Some projects, especially event-based, don’t allow for testing or mock runs. It would be extremely costly to simulate a concert in a particular location along with all the vendors that are scheduled to participate. Yet there are a few key elements from startups that can be applied to project management settings.
- Address risk early and often
- Monitoring relevant metrics
- Continual learning and acceptance of failure
First, consider addressing risks early on. Even if this can’t be in the form of a prototype the project should be exposed to risks and tested. For example, does the project have enough designers to complete a new mobile app? Estimates may not be enough in this case. Instead the project manager could have the designers solve a small task (subset of the problem or project) together within a limited timeframe to test their capabilities as a team. Additional risks may crop up as a result of their collaboration together.
Next, identify metrics that relate to risk. Stakeholders are often focused on budget and deadlines but there are other ways to measure a project. Why not tie metrics into risks that were identified at the outset of a project? In class we discussed the case of Futuronics which carried a greater amount of risk due to their industry and future-oriented products. If the company was able to quantify risks, they could better report on them and gain stakeholder and sponsor attention (Feldman, 2012). For Futuronics, metrics could include number of competitors looking to enter the industry, amount of patents into similar technologies, or number of qualified engineers throughout the country.
Lastly a project’s risks should be considered in terms of the overall team and organization culture. If learning and failure are not embraced then it can be harder to have conversations about risk. When the message from the top-down is “We’ve been doing this for years and it’s the right way!” there are natural blockades to identifying and handling risks in projects. Furthermore failure can lead to insights in a project that were not initially considered.
Questions to Consider:
- What is the most challenging risk you’ve faced in a project? Did you have a contingency plan?
- Would you be able to put the three elements, mentioned above, to action on projects in your company?
Dyson, J. (2011). James Dyson: In praise of failure. Retrieved from http://www.wired.co.uk/news/archive/2011-04/11/james-dyson-failure
Feldman, J. (2012). Project Management Gets Lean. Retrieved from http://www.informationweek.com/applications/project-management-gets-lean/d/d-id/1102570?