Open source software (OSS) is very well known for allowing free access to the source code of the application. The idea is to allow for the creation of a better product. The more people working to make each aspect of an application better, more minds create more ideas, create a better project. OSS runs the internet since all of the protocols—network time protocol (NTP), HTTP, amongst many others—are OSS projects with many years of use. These projects are run by volunteers worldwide. But, none of these projects are run using the traditional methodologies of project management: Waterfall and Agile. This chapter asks: How does an open source development environment facilitate conventional Waterfall project management approaches? and How does an open source development environment facilitate Agile project collaborative work? The method used to determine the answers used surveys and questionnaires involving actual participants in a variety of OSS projects from across the United States (US). The questions asked concerned the organization OSS projects, did they use a particular traditional methodology or some other non-defined method of organization? The answers received by this study centered on non-defined methods of organization; traditional methodologies were considered too restrictive and not agile enough to allow for the freedom cherished by their volunteers.
TopIntroduction
Information and communicating are keys to managing projects to a successful conclusion. There are major differences in the management of information and communication between traditionally managed projects using traditional management techniques and methodologies such as Waterfall or Agile and the management styles that Open Source Software (OSS) projects use. Knowing the work and the risks are the best defense for handling problems and delays. Assessing potential overall project risks brings to the forefront the need for changing project objectives. It is these risk analysis tools that allows the Project Manager (PM) to transform an impossible project into a successful project (Campbell, 2012). Project risks become increasingly difficult when dealing with an unrealistic timeline or target date when given insufficient resources, or insufficient funding. Knowing the risks can help to set realistic expectation levels of deliverables, and the work required given the resources and funding provided. Managing risks means communicating and being ready to take preventive action. The PM cannot be risk-averse; accepting risk will happen remains part of the job, doing nothing is not an option (Gido & Clements, 2012). The PM needs to set the tone of their projects by encouraging open and frank discussion on potential risks. The PM needs to encourage identifying risks, the potential impact of the project, and the likelihood of occurrence, develop risk response plans and monitor those risks. OSS seems to want to do it differently. It claims to be more collaborative, yet it is also very closed in many ways, to the point of being very possessive, not willing to share.
This chapter will explore the various properties of traditional project management and how they are, or are not, applied to OSS projects. Examples abound showing real-life case studies from both traditionally managed projects from the corporate world, and from open source software projects currently active in the OSS world. The key in this comparison is in showing how it is that OSS has become successful, even to the point of literally running the internet as we know it today. What makes OSS so successful in spite of the way projects are managed?
Starting a new project can be a very interesting experience, and yet it can also be a terrifying experience. Interesting or horrifying depends greatly on your level of experience. The most interesting and challenging part is putting the team together. There are many aspects to consider such as what are the tasks to complete the project? What level of expertise will be needed? What amount of time will be required to complete each task? What if the task requires certain expertise for a short time, is that expertise available when you needed?
Other questions that need to be considered involve governing the project. The processes that will need to be established will need to be considered by both the team and by management. Processes that involve communicating, conflict management, risk management; all need to be considered and planned. Many of these processes are not practiced initially in many OSS projects. Most leaders of OSS projects consider this type of organization to be cumbersome at best; more a chore to be avoided.
Project Oversight
The Project Management Office (PMO) provides the integration of procedures, technology, organizational structure, staffing, and guidance that ensures projects are in alignment with company strategy and goals. The three tiers of management in the PMO model form the relationship between project, the project’s resources, and company strategy. Project management concentrations are on the successful completion of selected projects. Program management serves to coordinate projects and the resources of each project. Usually, these projects share a similar goal and processes. Project portfolio management links the selection of projects and programs to the strategic goals of the company.
Program management is the management of numerous related projects. Each project is managed by individual project managers, and one Program Manager oversees the whole. The goal is to remove the confusion characteristic of many related projects by efficiently organizing limited resources between each project. Project portfolio management (PPM) makes sure that projects and programs meet the organizational strategies and goals of the company. It does this by managing the limited resources available within the company. It requires well-organized decisions compelled by priorities established by the Project Management Office or Executive decision. The benefits of PPM are in choosing the right projects with the right resources to complete those using strategic priorities to direct resource allocation.