Managing project risk

  • 291 views
Uploaded on

Open source software projects need to ensure that people are willing and able to engage with their software communities. Similarly, businesses seeking to adopt open source solutions need to be sure …

Open source software projects need to ensure that people are willing and able to engage with their software communities. Similarly, businesses seeking to adopt open source solutions need to be sure they can do so without exposing themselves to unmanageable risk. Evaluating technical risk of open source is often easier than it is with closed source, simply download the code and conduct and build a basic proof of concept. But dig a little deeper, there are many non-technical questions buried underneath, such as:
•Will the project still be there in a year, five years, ten yeats, longer?
•Can I influence the project to ensure it suite my needs?
•Can I buy support if I need it?
•What if the project leadership stop development tomorrow?
•Will the license restrict my business model?
•What are the main risks and how do I mitigate against them?
•If I do bet my business on it what aspects of the project must I focus my attention on first?

This session will introduce an approach to evaluating the maturity of the non-technical aspects of an open source software solutions. Using this evaluation we can clearly see any weak points in a projects development and governance processes. Once identified those weaknesses can be addressed or avoided as appropriate. Through a number of case studies we will demonstrate how this model assists in project planning and resource allocation when adopting open source solutions.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
291
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Managing project risk when using open source Ross Gardler OpenDirective@rgardler rgardler@opendirective.com
  • 2. Software Failure• Sainsbury write of $526M invested in supply-chain automation• Hershey unable to fulfil $100M of orders due to failure of $112M IT system• 60,000 pensions and benefits claims unprocessed in UK due to IT failure on a budget of £413M• Sift (UK SME) wasted £1M on cancelled IT rewrite Source: http://lessons-from-history.com/node/89
  • 3. It should only cost 7p• Proper• Planning• (and) Preparation• Prevents• Piss• Poor• Performance Source: British Army
  • 4. Ross Gardler• Co-founder of OpenDirective • Consultancy specialising in open innovation of software• Open source developer since 1995• Executive Vice President of The Apache Software Foundation• Mentor to projects large and small • in companies large and small
  • 5. Managing risk• Emphasis on MANAGING• Need to: 1. Understand common risk factors 2. Evaluate candidates against those factors 3. Understand risk management strategies 4. Allocate project resources to manage risk 5. Repeat
  • 6. Common Open Source Risk
  • 7. Legal• Does the licence allow you to…?• Can the software be released under that license?• Can you release your software under the chosen licence?• Are there fees associated with the software?• Are contribution terms acceptable?• Can the software be bought and removed?
  • 8. Standards• Does the software play nicely with other software?• Can you move away from the software?• Are the standards used encumbered?• Who owns and manages the standards?• Can you influence the standards?
  • 9. Knowledge• Can your people work with the software?• Can your people or sub-contractors adapt the software?• Can you add to the knowledge?• Is there a restricted group who control critical project information?• Is there a paywall to critical information?
  • 10. Governance• Can the project pivot without your knowledge?• Can you influence project strategy?• Can your interests be blocked?• Is the playing field level?• Will your contributions be accepted?• Will contributions be managed for the good of the project?
  • 11. Market• Is there (potentially) multiple suppliers?• Can newcomers enter the market with new product/services?• Does one supplier have an unfair competitive advantage?• Do the majority of project committers work for a single company?• Is there a supplier who understands your market?
  • 12. Measuring risk
  • 13. Apache project• Labs • High risk• Incubator • At your own risk• Top level projects • Managed risk• Attic • At your own risk
  • 14. What does the incubator do?• Community development• Ensure the project is governed according to the Apache Way • No BDs • Clean IP • Supportive and open community • Etc.
  • 15. What if it’s not an Apache project?• Openness Rating • Evaluates development model• Identifies areas of potential risk • Plan for risk management• One part of a larger evaluation process • Software Sustainability Maturity Model • In addition to development model evaluation • Fitness • Reusability • Capability
  • 16. Evaluating OpennessMore open projects = more flexibility for users
  • 17. Conducting an openness evaluation• Series of questions in five categories • License • Standards • Knowledge • Governance • Market• Decide on acceptable risk profile • Weight categories of evaluation • Weight individual questions
  • 18. Result is a “score”• Quantitative evaluation • numbers are indicators only• Need to ensure consistency in the evaluation responses• Low scores indicate areas of risk • Compare risk across different alternatives • Invest resources to mitigate risk?
  • 19. Layered evaluation SSMM • Maturity of project Openness • Freedom to engage Rating Openness • Areas in need Categories Specific • Actions Questions
  • 20. The Categories
  • 21. License• What kind of license?• IP due diligence• Traceability
  • 22. Standards• Standards compliance• Openness of standards used• Royalty or Patent requirements• Recognised governance body
  • 23. Knowledge• How we got here• Where we are going• User support• Developer support
  • 24. Governance• Structure• Succession• Codes of behaviour• Transparency• Accountability• Who can participate• Roles of project participants
  • 25. Market• Money makes the world go round• Money pays for developers• Money raises awareness• Money provides better user support• Is there a healthy commercial ecosystem?
  • 26. Can I use it?
  • 27. Can I use it?• In constant development• Use it and help us improve it• Open Content (CC-BY-SA) • Mail me at rgardler@opendirective.org for a copy• The sales pitch • 1, 2 and 4 day training • Consultancy services
  • 28. Discussion• Ross Gardler • @rgardler • rgardler@opendirective.com