Management Reserves & Estimated Monetary Value

In project management, a Management Reserve is “an amount of the project budget withheld for management control purposes. These are budgets reserved for unforeseen work that is within the scope of the project. The management reserve is not included in the performance measurement baseline” (PMBOK).

There are three different types of management reserves identified in the PMBOK. These are listed as a Management Reserve, Contingency Reserve, and Activity Contingency Reserve.

Management reserve: Controlled by the management, but not necessarily the PM. This is an overall management reserve that could be spent on any project and has to be approved by the managers above the PM.

Contingency Reserve: a fund controlled by the PM and part of the project budget for any particular contingency within the scope of the project.

Activity Contingency Reserve: a fund specifically earmarked for a high-risk activity that could require more resources to complete. This fund is controlled by the PM and a part of the budget.

Earned Value Management is the process of removing the ambiguity between actual cost and planned cost within a project. EV is calculated as % complete X project budget. When EVM is applied to a project it gives the managers a clear line from which to measure project progress against other known calculations relative to the project’s time line and overall expenses.

Expected Monetary Value (EMV) is another tool in calculating risk costs. EMV is calculated by multiplying the value of each possible outcome by its probability of occurrence. The results of an EMV analysis can be used to determine the size of the reserves for the project. The decision tree listed as Figure 11-6 in the PMBOK shows how EMV can also be used to understand the monetary value of certain outcomes. When charted this decision tree matrix can show managers the probable consequences of their decisions to the project in relation to its cost and profitability to the organization.

Risky Links

In Practice Standard for Project Risk Management the authors illustrate the structure of a quantitative risk analysis. The structure contains Risk Prioritization, Examine Interrelationships Between Risks, Collect High Quality Risk Data, Project Model, Perform Quantitative Risk Analysis, and Results. The second step in this process, examining interrelationships, can have significant impact on the risk analysis and mitigation measures employed by the project management team. This step involves mapping the identified risks in relation to other risks as well as underlying issues identified during the process. Eliyahu Goldratt spends a great deal discussing the transfer of risk across a series of dependencies with any particular development model. He discussed this phenomenon with regards to project management in his book, The Critical Chain and again in his book, The Goal with regards to production management. The interrelationships between risks are sometimes easy to spot as risks compound over a particular series of production steps. Generally later items with severe delay are those where risk was transferred across the dependencies.

The management tools Goldratt communicates in these books include his popular Theory of Constraints and Critical Chain Project Management. Both of these offer great insights that improve project management overall and contain four risk management strategies common in project management literature. These strategies are Avoid, Mitigate, Transfer and Accept. In critical chain project management the intent is to shift project risk from each individual task to an overall risk for the entire project. This forces managers within the project to look for ways to mitigate and transfer risks.

According to Adrienne Watt mitigating risk “means taking some sort of action that will cause it to do as little damage to your project as possible.” The goal is to mitigate the effects of the risk. One way critical chain project management reduces the effects of the risk is to remove risk calculations from the local managers. As mentioned above one of the major tenets of that methodology is to shift the risk from the different efforts within the project to the project as a whole. This tenet is a risk mitigation strategy. One of the other strategies explained in that book involves transferring risk. One way the book articulates this is with a project that has some of its labor contracted to others. In the book the project manager shifts the risk of late deliverables from the project itself back to the contractor under terms that are amicable to both.

A Black Swan in Oklahoma

Much of the conversation about project risk management approaches the subject from a negative perspective.  Project risk is just as much about improving the chances of a positive event as a negative one.  The PMBOK states that “the objectives of project risk management are to increase the likelihood and impact of positive events, and decrease the likelihood and impact of negative events in the project.”  In Tom Kendrick’s book, Identifying and Managing Project Risk, he describes the industry term “black swan” as “a large impact, hard-to-predict, rare event” and proceeds to primarily focus on the negative impact of a black swan to an organization.  In this post I would like to propose that the term black swan, while having primarily negative connotations, can be a positive event.  

In project management a schedule dependency is what happens when you have a task that can’t begin until another task is finished.  It is entirely possible that the preceding task can be done much later than originally planned creating a black swan situation or the task can also be done much earlier.  I initiated a project while I was in Oklahoma.  The project turned into an annual event and was passed along to another project manager for its second year.  The new PM was responsible for coordinating with all of the agencies and offices involved and building the planning documentation used to for internal and external communications.  He couldn’t publish the plan internally until these other requirements were met.  The schedule he was committed to required the earlier tasks to be complete before the latter.

The assigned PM started building his products and working the plan only to discover several notes I had left behind. These notes referenced a folder on a shared drive and a binder in the office.  In it he found that while I had coordinated the resources for the first year, I also scheduled several of the resources for the second year.  On the shared drive he found that when I closed the project from the first year I had already applied the lessons learned to the planning docs for the second year as well.  The hundreds of hours of planning he budgeted were reduced by several fold.  That level of detail and foresight was rare in the organization and certainly serves as a positive example of a black swan.

Negative examples are more commonplace in project management conversations.  It’s not hard to understand why.  They can easily create poignant feelings about certain project aspects.  They also make for good hero stories where the PM team overcomes the challenge they faced to slay the impossible dragon and create victory from chaos.  I love a good hero story, but I love a good project that doesn’t have the problems that turn it into a hero story.

Balancing Your Bias

Everyone has a bias.  A bias is generally understood as a preconceived position on a subject often viewed as unreasoned by others.  The reality is the bias is generally not developed through unreasoned mental programming, but rather built out of causal reasoning.  Our experiences in our own life are the anecdotal evidence for much of the judgements we make during the day.  Sugar flakes will be sweet.  Potato chips will be salty.  Some people’s causal reasoning has them jumping the train tracks and believing that there’s floating spoons on mars.

In projects qualitative risk analysis and reliance on expert judgment can also lead to false conclusions.  A project manager with a short list of failures may believe he can will project success simply by forceful demands.  I’ve also seen PMs who grossly misinterpret the difference between a minor risk and a slightly higher risk.  In this situation they exaggerated the difference to the point where they felt the project was in severe jeopardy.  This lead to more worry and significantly lowered the productivity of the team.  

One way to balance a bias is with quantifiable information.  In the case of the PM who over exaggerated risk we were able to show him that the chances while still higher than the norm he was used to were so unlikely that it was a nearly negligible increase.  Using the hard data was only part of the equation.  Communicating the data in a way that allows the PM to be corrected while still saving face is also important.  Publicly disempowering a PM may create a dramatic situation that functions as a hand grenade to product progress.  Sometimes it makes sense to just leave a Lenore Skenazy quote on their desk and walk away.  “All the worry in the world doesn’t prevent death. It prevents life.”

Charting the Project Ocean

Navigating the risky waters of a project requires the same tools that helped navigators travel across the ocean, good charts.  In this post I review the usefulness of using tables and charts in communicating project risk.  Two common types of charts used in communicating about projects are Pareto diagrams and Probability & Impact Matrix.  Risk in projects occurs in some combination of four interconnected areas, Project Scope, Budget, Schedule, or Resources.

It’s important first to understand that scope, budget, schedule and resources are all interconnected.  One way to look at these is to consider them as parts of the same object.  If scope increases so will the budget and the schedule for the project.  Similarly, if any of the others increase it will affect the other three.

Scope is one of the more difficult things to chart because it may not include all of the project’s requirements.  The requirements it does capture can be charted and both the Pareto Diagram and Risk Probability & Impact Matrix can be useful in visualizing and communicating about the project’s risk.  

The Probability & Impact Matrix visualizes information based upon two scores, the probability and the impact.  These scores can be recorded qualitatively or quantitatively.  The PMBOK recommends qualitative analysis prior to a quantitative analysis.  When used as a qualitative tool this matrix’s inputs are usually in the form of rough descriptions.  When used quantitatively the descriptions of the risk become matched with a numeric value based upon their likelihood and severity.

Whether used qualitatively or quantitatively this matrix can be useful to identify parts of a project’s scope that communicates risk.  The process of building this matrix forces those involved to have a thoughtful conversation about different aspects of the project without worrying immediately about which risk is more prominent than another.  Because of the simplicity of its design this communication tool requires very little training for teams to discuss and build.  Similarly it requires very little explanation for the audience who it will be presented to.

Pareto Diagrams are solely quantitative.  Its input requires a dataset comprised of a frequency or similar sets of values.  This dataset must be arranged in descending order from largest to smallest.  Once the data is organized in this way, each datapoint must be calculated as part of its contribution to the whole.  The Pareto Principle is based on the philosophy “that roughly 80% of the effects come from 20% of the causes.”  So the goal is to find where the 80% mark lies on any given dataset.

If used to analyze risks in a project’s scope the Pareto Diagram can quickly focus the group on the largest 20% (known as the vital few) and monitor, but not be distracted by the trivial many.  The Pareto Principle requires a valid dataset and an audience familiar with the principle and the format.

Any project is likely to hit some rough seas and choppy waters.  Good charts can be crucial in helping the team navigating past them and safely arrive at the intended destination.



Minimizing The Risk of a Second Hand Project

Taking over any project no matter what the phase takes a great deal of effort.  For the project manager it’s a time when their reputation is getting married to something that has an increased chance of failure.  The project manager should enter into that relationship with caution and I would recommend taking the following approach.  First I would review the existing documentation.  Second I would conduct a stakeholder survey to gain insight on the who of this project.  Finally I would engage in discussions on resource adjustments necessary to get the project manager to commit to a successful project.

A project without a project manager (PM) is doomed for failure.  This gives the potential PM a lot of leverage coming into the conversation.  The first thing to do is to read the project’s documentation.  This is because it signals the least amount of commitment allowing the potential PM to maintain a high power base against is potential clients while allowing him visibility on the technical details of the project itself.  Sometimes documentation isn’t always available in the planning stages.  Those are the stages after all where a lot of the documentation is getting created.  Whether in draft or final form, I would recommend the potential PM review the project’s proposal, budget, and communications plan.  These documents can lend insight to the project’s scope and methods that may have lead it to a its current dead end.

The project proposal will illustrate the scope.  Among the many things to look for is whether the project’s scope clearly explains what the project is and isn’t.  A vague scope can lead to project creep that increases the changes over time without increasing the resources to be successful.  The proposal will also contain the statement of need.  While it may seem commonplace a well written statement of need and professionally crafter project plan will encourage stakeholder buy-in.  Professionalism matters.  The plan messages a lot more than the words on the page.  It represents the level of quality expected throughout the project’s lifecycle.

The budget and communication plan can be reviewed rather quickly.  For the budget it’s important to check first for how thorough it is and secondly check for accuracy.  Its thoroughness can be referenced from similar successful projects while its accuracy can be tested by spot checking certain line items.  For example, office space rental can be confirmed by calling local realtors to verify quotes within the project’s budget.  The communications plan can be check for thoroughness to ensure that all the stakeholders are listed and their preferred method of communications also listed.  Ideally the communications plan would have a diagram outlining the methods and nodes (stakeholders) so that it can be easily visualized and analyzed to increase efficiency.  If the communication methods are beyond the capacity of the potential PM then the project will again fall short of expectations.  It’s easier to have fifty people adjust to one person than it is to have one person adjust to fifty people.

The next step after review the documentation would be to conduct a stakeholder survey.  Im Jim Collins’ book Good to Great he talks about how important the who of an organization is to being able to get a job done (Collins, 2001).  The project may have failed due to a small population of highly expressive personalities or a few key stakeholder absences.  The results of a stakeholder survey would end up being consolidated a type of internal facebook.  Just as organizations have customer relationship management (CRM) software a PM should have similar products to manage his stakeholders including notes on their pet peeves and what motivates them to produce high quality deliverables.  This survey will also help illustrate if there is a remaining loyalty towards the previous PM.  In some cases certain stakeholders may be happen to see a new PM come in.  In other cases a new PM creates an unwelcome dynamic and obstacle to reforming a team.

The last step after reviewing the documentation and conducting a stakeholder survey engaging in discussions to adjust the project resources.  As mentioned above the potential PM Is in a position of power.  This power base should be leveraged this to ensure the resources are appropriate for the project going forward as well as negotiating the final language and scope of the project.

A good persuasive argument for taking on a new project is difficult to pass up.  The 1992 movie Sneakers was made in large part because two of Phil Alden Robinson’s friends asked him a compelling question.  Paraphrased it went something like “if you were to direct this movie how would you film this one scene” (Robinson, 1992)  Once he started giving an answer he knew he was trapped.  He showed his hand on how he was thinking through the problem.  The same can be true about a potential project manager.  Utilizing the steps listed above the potential PM can get the information he needs while maintaining his power base to ensure he is in a position to negotiate terms that will lead to the project’s success.



Collins, J. C. (2001). Good to great: Why some companies make the leap … and others don’t. New York, NY: HarperBusiness.

 Robinson, P. A. (Director). (1992). Sneakers [DVD]. (Director’s Commentary).

The Foggy Risks of Running OwnCloud

IT history is riddled with stories of monumental failure and staggering success.  In the branch of IT that covers the video game industry Atari’s release of E.T. The Extra Terrestrial in 1982 is discussed as a game that nearly destroyed an industry (Snead, 2015).  Netscape’s collapse was considered a death sentence for alternative browsers until its code was open sourced, reworked, and released as FireFox a few years later.  This turnover makes it difficult to determine the true failure of particular projects.  For this paper we’ll be reviewing the collapse of OwnCloud a popular do it yourself infrastructure as a service cloud platform.  The downturn has been recent and sudden garnering enough media attention to describe how various project risks led to its current situation.

In early June of 2016 OwnCloud Inc. closed its doors in Boston after lenders to the project learned the project had forked (Darrow, 2016).  Unlike some forks in the open source community started by a fan with a different vision this fork was started by OwnCloud’s initial developer, Frank Karlitschek who had resigned from OwnCloud just weeks prior.  Fortune’s coverage written by Barb Darrow describes the German based organization as soldiering on through the difficulty (Darrow, 2016) while OwnCloud’s own official blog took a rather firm tone in addressing the fork while assuring customers of continued service (Owncloud, 2016).  The official blog post from the company lists Frank as having “poached” developers to the fork–a strong term in the open source community as developers are often volunteers who choose to contribute their time and talent to someone else’s ideas.  

The funding shortfalls and thinning of community developers has left a significant scar on OwnCloud’s ability to develop on its projected pace.  It may also be putting the company in jeopardy as Frank’s fork, NextCloud has not only gone live, but garnered considerable press attention (NextCloud, 2016) in the process.  This developer exit and fork are likely the death sentence for OwnCloud.  While funding and developers are explicit risks identified by OwnCloud in their press statement, media attention/momentum and schedule are implicit risks that affect the project going forward.  In this paper I will describe each of these four risks, as their impact and the company’s response/potential response using the Project Risk Identification Framework illustrated in our text (Marchewka, 2015).


Resource constraints exist in all projects and presents a risk towards project completion.  Early on in the creation of OwnCloud there was a need to raise revenue in order to hire the staff that would be able to move the project forward.  To solve this problem, OwnCloud created a business model that would license certain features of the platform.  This payment model would allow the business to continue to develop the software.  

Working with the Project Risk Identification Framework we see that the Measurable Organizational Value (MOV) would increase if the project were successful.  A budget was required to be able to achieve the project’s scope and quality goals.  This required people to be able to create the product.  Since all of this was within the same organization the risk was internal and known.  Since the risk was identified early on the team developed a project charter and plan.

The initial impact of this decision was immediate.  Funds began coming in enough to hire employees and coordinate other resources that gave the project a legitimate status among its competitors.  The longer term impact was that the implementation of the licensing program alienated large parts of the community over time.  The organization behind OwnCloud became beholden to those who were paying the bills at the loss of those who were contributing code to take the project in new directions.  As a result the project forked in June of 2016 with several core developers moving to build the forked version’s functionality under the title of NextCloud.

The company’s response to the risk has always been to cater to the hand that feeds it.  This is not to say they haven’t tossed a bone or two in the direction of the community contributors, but the company devalued input on proposed features from the community (Fisher, 2016).  After Frank and other key developers had already left OwnCloud the company they did announce a community board stating,  “One of Frank’s criticisms concerned the need to strengthen the Community. In this regard, we have been working on the creation of the ownCloud Foundation, the formation of which we announced earlier this week” (OwnCloud, 2016).  This effort was seen as too little and too late.  

If the company had formally adopted a risk management plan they might have been able to more fully calculate the risk of losing the software’s founder and several key developers.  Since the key person to leave was the original author of the code it might have been taken for granted that his contributions would remain constant.  If a risk matrix was developed early on this would have been a sure assumption, but as time went on updating the risk matrix to adjust for shifting attitudes within the work environment would have been key.  Unless key decisions were made to find other budgetary models early on I believe that the results would have been inevitable.  This is like 1990’s Kodak having the patent on the digital camera and not being able to do anything with it because it would mean destroying their film business (Pachal, 2012).  


The second explicit risk identified by OwnCloud is that of their developers.  While we have already discussed how the developers were impacted as a result of budgeting decisions, we need to look at how the developers are a risk to the project.

Developers add value to the MOV by creating the code that fulfills the project’s scope and quality goals.  They are a cost to the budget and more developers properly organized are required to get the project to stay on schedule for its paying customers and loyal fans.  There are two categories of developers contributing to OwnCloud, paid and volunteer.  

The paid contributors are few but have a large impact on the budget.  The volunteer contributors are much larger and indirectly reduce some of the budgeting items by contributing code that would otherwise need to be paid for from a hired developer.  Open source community developers have a reputation for being security conscious and are known for finding security flaws in code and applying patches quickly.  From this standpoint the OwnCloud community saved the company a considerable sum auditing nightly code for vulnerabilities.  Their disorganized nature often results on costs from an organization standpoint.  Sometimes it’s hard to herd cats.  Eric S. Raymond talked about this in his book, The Cathedral and The Bazaar.  He argues that the chaotic nature of organizing open source contributors may be difficult, but if managed properly can lead to tremendous results.

The risk of losing these developers directly impacts the organization’s ability to deliver and improve its MOV.  Because there are two categories of developers the risk is both internal and external.  These risks were known unknowns.  Thanks to the abolishment of slavery individuals have the right to choose their employment.  Paid and volunteer employees can choose to exercise their talents for other organizations beyond their current affiliation.  Since these issues were known unknowns but weren’t captured on an updated risk plan the company failed to act until after the results were realized.  Their announcement of the split appears to be evidence of an organization in the executing and controlling phase, but with less resources to execute and control.

The risk response has been to hire a new CEO, Tobias Gerlinger who as noted in the blog post announcing his ascension to CEO, has spent a great deal of time securing funds for the organization (Dyroff, 2016).  This clearly addresses the issue with budgeting, but does not necessarily create a focus that encourages community programmers to return to the effort.  It’s very likely that more paid developers will appear on staff soon with reduced emphasis on community developers.


One implicit risk associated with any business or project is media attention.  Media attention works to improve the organization’s MOV by reducing the budget required for advertising a particular project.  This free advertising can in turn affect the process for releasing information.  Good press encourages more press releases changing the internal processes to keep up with demand.  While this may affect internal processes.  Media attention is primarily external.  OwnCloud certainly had a compelling story to tell of a small OpenSource project operating in a tough market against giants like Google with their drive solutions, MS Sharepoint, and DropBox (Darrow, 2016).  Media attention is a known unknown.  It’s certainly something that’s anticipated, but can’t be fully calculated.  Some press builds upon itself while other releases never reach that critical mass.  In response to a lot of OwnCloud’s positive press throughout the years the organization has really been able to evaluate project success as the press has provided feedback for iterative successes in each release.  In addition they’ve been able to adapt this feedback towards the next release and incorporate recommendations that become part of the next project plan.

Media attention with any software system is important as it can translate to free advertisement and increase customer awareness and broaden customer base.  With OpenSource it’s crucial.  OpenSource developers are often motivated by the credibility they gain from contributing to projects.  The more high profile projects they contribute to the more credibility they gain.  The more high profile the project is the better target it is for attracting developers looking to get an ego boost (Raymond, 2003).  

Positive attention can make a significant contribution in attracting developers to further the work.  The response to the negative attention was equally detrimental.  In some cases the coverage focussed on OwnCloud’s press release but in many cases the coverage focussed more on Frank’s new fork.  While not overly critical of his former company he was critical of parts that allowed him to garner the sympathy of several who interviewed him (Lunduke, 2016).

Since the press is so influential in open source development I believe it is important to have a full time press agent as part of the paid staff of any project.  Having a trained professional who can clearly communicate and improve community perception when things go wrong can only serve to assist the organization.


The final implicit task I would like to discuss is that of the project’s schedule.  With fewer developers, bad press, and a restricted budget OwnCloud may be as near to failure now as it ever will, but failure doesn’t always mean the organization is closing shop.  Often in open source development failure means a reduction in output over time and reduced adoption as feature sets become more dated.  A good example of this is Apache’s OpenOffice vs LibreOffice (Hoffman, 2015).  

Schedule directly affects the organization’s MOV as the pace of development often impacts the quality of the output and improved feature sets can often attract more customers.  The risk to schedule is one that affects both product and technology.  Schedule is primarily internally driven although it may depend on external factors.  Schedules are generally known-knowns as they are built on calendars with accurate work times associated with them.  There is risk involved in not properly estimating the duration of time for a particular effort to be completed, but this can be reduced through similar iterative tasks and organizational experience.  For OwnCloud it’s issues occurred just as they were about to release version 9.0.3 and version 8.2.6 both of which seemed to be unaffected by the larger issues with developers (OwnCloud, 2016).  The pace moving forward is expected to be much slower.  Its earlier projected pace was determined when a certain quantity of developers were available and now the organization finds itself with a deficit of developers.  Instead of directly wooing those who might contribute the new CEO has announced increased funding resources to be able to continue to maintain contractual obligations with existing customers.  NextCloud will likely overshadow OwnCloud with features over the next few iterations.

While the CEO’s response was to be able to secure the company’s financial viability moving forward I would have recommended that he immediately hire individuals capable of managing the community and work to rebuild relationships with volunteer developers.

In part 2 of this paper I intend to discuss three other risks, their potential triggers, rankings and recommended responses.  The three risks I have selected are project scope, quality, and organization.  The failure of OwnCloud to maintain its founder and other key developers is a serious blow to the organization and its ability to move towards a higher quality product.  While we’ve already discussed various risks and their impact in this section we’ll look specifically for risk triggers and rankings for the associated risk with a recommended response.


The first risk to discuss in this section is the risk to the project scope.  Much of the conversation that lead to Frank leaving OwnCloud.  Although cautious about going into detail in his initial post, Frank explains his reasons for exiting thusly:

I thought a lot about this situation. Without sharing too much, there are some moral questions popping up for me. Who owns the community? Who owns ownCloud itself? And what matters more, short term money or long term responsibility and growth? Is ownCloud just another company or do we also have to answer to the hundreds of volunteers who contribute and make it what it is today?

These questions brought me to the very tough decisions: I have decided to leave my own company today. Yes, I handed in my resignation and will no longer work for ownCloud, Inc. (Karlitschek, 2016)

The moral questions Frank expresses here are really questions of scope not only with the code, but with the organization he helped to found that underwrites that code.  He identifies the risk trigger as being the culmination of uncomfortable answers to these important questions.

From the perspective of OwnCloud the risk trigger would have appeared much earlier.  It’s very likely that Frank asked these questions of his coworkers, but was unable to find suitable answers.  The asking of those questions should have been seen as a risk trigger since they indicate a different attitude toward the project scope than what was being implemented by the organization.  

When a person frames an argument in moral terms there is no higher level of argument for them to present.  From Frank’s perspective the moral scope of the project was paramount.  From OwnCloud’s perspective this risk was also highest among the three discussed in this section as it contained the highest potential for negative consequences moving forward.  We do not have a clear time scale illustrating precisely when the scope risk become an issue or when the triggers were ignored over the project’s lifespan, but we do know that triggers were ignored between its initiation and its current status.

The proper response should have been to review the project’s documentation for information about change management.  The business’ scope for the project had evolved from what Frank’s initial scope was (Lunduke, 2016) to the point where his presence was untenable.  


The second risk I would like to discuss in this section is that of quality.  Quality refers to matching customer expectations with the product itself.  Although specific feature sets being adopted or rejected is certainly a question of project scope, the ability of those feature sets to meet customer expectations is certainly a question of quality.  OwnCloud’s responsibility to quality includes code capable of performing in accordance with its defined feature set.  This includes a large amount of effort applied to hardening the code.  In addition to code fortification, quality also includes giving priority to certain users.  This preferential treatment of features for paid customers disagreed with the philosophy of quite a few in the community.  In short they believed they were shipping a product to the community that was inferior to the potential the project could achieve for its customers.

Despite Forbes’ article highlighting that the cloud storage market has serious competitors (source), the self hosted cloud storage market has only a few.  So while OwnCloud might be competing with big names for average users to the user base that categorically rejects the big names, they were effectively the only game in town.   The risk of not having quality software meant losing a critical mass of marketshare to its competitors or losing the critical mass of marketshare to the community that the organization was based upon.  The critical mass of users and volunteer developers is key in open source projects.  Losing them would mean losing the momentum of the effort.

This risk is second in priority to that of scope.  While quality does affect the number of users and contributors, it doesn’t affect the idea behind the code itself, simply its implementation.  The disagreement that lead to developer exit manifested itself in quality (different code for different payment models) but it was in large part a question of scope.

My recommended response for this situation would be in line with what NextCloud is currently doing.  They are re releasing the software without the restrictive CLA agreements of OwnClouds’ customers.  They’re truly open sourcing the entire stack of code.  While OwnCloud was unable to find a business model that supports such a move, NextCloud appears to be focusing heavily on community contributions to the code first and the business model second.  If you’re going to have community input on a project then you’re going to have to respond to the risk of losing the community early and often.


The final risk worth mentioning in part two is that of change management.  This risk occurs when a project fails to adopt a plan to manage changes that will occur throughout the project’s lifecycle.  In some software development models change management is more prevalent than in others.  An agile software development method allows for small incremental changes over time that lead to a user focussed deliverable that generally meets expectations.  The Systems Development Life Cycle (SDLC) method is generally more difficult to inject change during the process than agile.

As mentioned earlier the conversation about what is and isn’t OwnCloud’s software and who does and doesn’t own it is really a question of scope.  As OwnCloud moved from an individual project to a fully licensed company the goals began to diverge.  The feature set for each incremental release adopted fewer of the ideas of the community over time.  When meetings took place to determine the correct feature set community members were given more and more limited voice.  In this regards it’s not just that OwnCloud didn’t have a good change management plan, it’s that they became complacent in adopting the feedback from the one they did have.

The severity of this risk has certainly contributed to the developer exit, but I would rate it as the third highest risk because it wasn’t as likely to occur.  Unlike closed source software models OwnCloud clearly had community input.  This meant that there existed a change management plan.  These two things on the surface make it appear unlikely that this risk would have increased in probability, but through ignoring the community that’s precisely what happened.  In the process several risk triggers (frustrated contributors voicing concern) were ignored over time.

My recommended response for this risk is similar to that of the other two discussed in part two.  Cater to the community!  Addressing this specific risk is less about communication strategy and more about adopting community ideas and publicly complementing the effort.  By ignoring the community you communicate that you devalue their input.  Supporting their ideas and incorporating their potential into your change management strategy would show the opposite.

In conclusion ignoring the risks that OwnCloud faced from inception to fork directly contributed to the project’s developer exodus.  Several key triggers were missed during the project’s lifecycle including key contributors asking deeply moral questions about the scope.  This research has further exposed to me the potential weakness of open source projects in partnering with community developers.  Such partnership appears to be extremely valuable but adds the risk of losing their input if key points they rely upon are ignored.


Darrow, B. (2016, June 02). Why Did File Sharing Startup OwnCloud Shut Down? Retrieved July 17, 2016, from

Dyroff, H. (2016, July 14). OwnCloud. Retrieved July 17, 2016, from

Fisher, C. (2016, June 5). Jumping to the Nextcloud | Linux Action Show 420. Retrieved July 17, 2016, from

Hoffman, C. (2015, August 28). Why you should ditch OpenOffice and use the free LibreOffice suite. Retrieved July 17, 2016, from

Karlitschek, F. (2016, April 27). Frank Karlitschek_. Retrieved July 17, 2016, from

Lunduke, B. (2016, June 02). Live Q&A: OwnCloud contributors create Nextcloud. Retrieved July 17, 2016, from

Marchewka, J. T. (2015). Information Technology Project Management, 5th Edition. John Wiley & Sons. (2016, June 2). Nextcloud. Retrieved July 17, 2016, from

OwnCloud GmbH. (2016, June 2). OwnCloud. Retrieved July 17, 2016, from

OwnCloud GmbH. (2016, July 1). OwnCloud. Retrieved July 17, 2016, from

Pachal, P. (2012, January 20). How Kodak Squandered Every Single Digital Opportunity It Had. Retrieved July 17, 2016, from

Raymond, S. (2003). The Art of Unix Programming. Retrieved April 04, 2016, from

Snead, J. (Director). (2015). Video Games: The Movie [Motion picture on DVD]. United States: ANCHOR BAY.