How to balance scope, schedule, and resources for any project
How the open source model will soar above the rest
Learn how to balance scope, schedule, and resources.
Defining a project is more than just discussing the results of the deliverable. For a project manager, this definition is about learning how to balance a series of interrelated elements. When it comes to the process of creation, the project manager has to manage the dependencies and the project's critical chain. The project manager also has to communicate effectively with the various stakeholders' personalities and the dynamic differences between Waterfall and Agile development methods.
Schedule, resources, and scope
One way to define a project is to discuss the work along three interconnected dimensions—schedule, resources, and scope. The interconnected nature of these dimensions is considered a natural rule of projects. Violating the balance is nearly the same thing as defying gravity.
The schedule dimension refers to the amount of time needed to complete the deliverable and close the project. It is the dimension where time is represented. The resource dimension is where the physical cost of the project is calculated. The final dimension is the scope: defining what the project is and what the project isn't. The project to create a toaster involves creating a toaster. A project's scope statement will define exactly what type of toaster needs to be created. Yet, there's a big difference in development between a homemade toaster, regular toaster, or Wi-Fi-enabled toaster that prints the weather on your toast.
Scope creep is a real thing. The conditions that inspire a project at any given moment tends to change as time evolves. This is especially true in software development and one of the reasons why Agile can be such an effective method of development. Users don't always know all the requirements at the beginning of the project, and the process of collaboration can often lead to better solutions. In most cases increasing scope also increases cost.
One way to illustrate the cost difference is with Microsoft Windows. The kernel running Windows Server is the same kernel that's running in Windows 10, but the cost difference is several hundred dollars based upon the services associated with that kernel. The server suite is designed for projects with broader scope requirements than those expected on the desktop. In projects that require specialized solutions, customizations along the way can cost more time to create, and more development time increases the cost of the project.
Volunteers as a resource
It's understood as a general rule in project management that the interrelationships between these dimensions are a reality for all dimensions. But there are exceptions and they are worth noting. Projects that use volunteers as a resource keep their costs low while maintaining or increasing their project's scope, but they may cost more time in training volunteers for certain tasks. Local 5K runs are a great example of this. If the goal of the event is to raise money for charity, volunteers at the water booths don't just make the contribution larger, they make the contribution possible.
A similar phenomenon occurs with open source solutions. The freedom associated with open source gives project managers the opportunity to increase a project's scope without directly increasing the project's costs. This is because open source solutions are generally known to allow for plugins and add-ons that easily increase the capabilities of the software without increasing the cost. Two great examples of this are NextCloud and Firefox.
When Firefox emerged on the scene in the mid-2000s its competition was "one size fits all" browsing solutions by a closed sourced vendors. Customization in that space was minimal or nonexistent. In contrast, the upstart Mozilla allowed for customization through plugins and theming. Entire websites were dedicated to sharing screenshots of different configurations. Mozilla was a terrific example of a development team building a solid core that others could customize without shifting the maintenance obligation in labor to Mozilla. Because of this effort, we now have Adblock plugins available that not only help reduce the number of ads attacking our eyeballs, but also the malicious ads that attack our machines.
Today several open source projects follow that same line of development, which focuses on building a strong core that is ready for plugins. One of the companies in this space is NextCloud. When the development team behind NextCloud forked OwnCloud's stack they brought some of the code done with plugins under the umbrella of the main software while continuing to work compatibility for existing and future plugins.
NextCloud is a neat example of what open source offers for project managers in part because of its core functionality and its plugins. The project is marketed to an audience that wants to control their data. In some sectors controlling data isn't just an option, it's a legal requirement. Some of the more sensitive organizations require the code to be audited prior to its deployment. Two of its closed source competitors, SharePoint and Google Drive, are extremely capable in this space but have limits on customization that don't apply to their open source competitors. As scope creep continues to impact the project, using a closed source solution causes the project's cost to continue rising quickly. Issues become harder to research and resolve when the code they're based on is closed from a review.
Small differences are often what distinguish a company from its competitors. Making the adding of small details (such as branding) to a solution easy isn't just something that's nice to offer, it's a requirement that impacts functionality. I have always been fascinated by people who wear shirts with logos. They turn their bodies into billboards, and they have to pay a premium to be someone else's advertising. Similarly, I find it striking that corporations will spend large sums of money for software solutions littered with inefficient branding. Once you start noticing it, it's hard to ignore. One custom application at work loves to tell me who the contractor is each time I launch the app. With an open source solution, a project's scope may not grow dramatically, but one area where is does grow the easiest is by giving the team the ability to add all the polish and details that will make the solution work for them.
For a closed source solution the vendor's representative is only its salespeople. They are the face of the code and usually not very knowledgeable about specifics and specific customizations. While there are salespeople in the open source community, there's also a tremendous team of individuals enabling the solution. For the most part, when you choose to use open source you are choosing to have a relationship with the individuals in that community. Many of the folks in this community are not only good at what they do, but they are good ambassadors for what they do. Martin Wimpress and Ikey Doherty routinely participate in events as ambassadors for the teams they lead in their projects. Mark Shuttleworth has a very public presence. Jim Whitehurst and Linus Torvalds have carried their ambassadorships into printed books.
The responsiveness of this community can sometimes outpace the responsiveness of its competitors, cutting time and cost while increasing scope. In May of 2016, Thomas, an employee and Linux fan at an Austrian school, wanted to use KDE Neon as part of a lab for his students. During implementation, he found a few things that virtually halted his project. He contacted the KDE development team and within 30 minutes had a response. A quick dialogue over email continued to further confirm and clarify the issue. Within 14 days the problems were solved, and during this development Thomas wasn't kept in the dark. He was able to track the solutions rolling forward during the process.
In the project management environment managing stakeholders is often a process of sharing information with them. Open development makes this part of the project manager's job easier.
The cost to Thomas $0. He has now scaled his solution from an initial 15 students to over 40, and he did so without a significant increase in time or resources. In addition, he provided feedback that allowed all the users of KDE to have more reliable code at their disposal. I doubt these response times and cost could be matched by any closed source competitor.
Open source is to technical projects what the airplane is to defying gravity. While lots of organizations choose to walk their projects along familiar closed sourced paths, when they do so they are submitting to the rules of interrelation that grow the project across all dimensions as any one dimension increases. In industries where the pace of innovation is cutthroat open source thrives. For project managers looking to build a competitive name for themselves and their projects, looking to open source allows them to defy the rules that define the discipline, and they will rise above their peers.