When working on software projects, it’s crucial to consider the three pillars of time, quality, and cost. These are not independent factors but rather interdependent elements that can be likened to the three legs of a stool. Changing one inevitably affects the others, highlighting the need for a delicate balance in project management for both project owners and development leads.
Quality
Quality is a simple concept; how well was a piece of software written? It is evaluated primarily by functionality and reliability, i.e., does it do what the stakeholders need, and how critical is it to business operations? Quality is an area where developers and stakeholders are in alignment. Everyone wants their software to look nice, operate effectively, and work without errors. Building high-quality products typically requires high costs (resources allocated) and time to develop methodically.
Time
When discussing time in the context of software projects, it’s crucial to understand that it’s about more than just deadlines. It’s about the potential for the success or failure of a project. Developers need to understand that deadlines are not just dates on a calendar; they are crucial to stakeholders and the business’s ability to plan for the future and budget accurately. The more time a team has to work on a project, the better job they will do, and the more likely they are to meet those critical deadlines.
Cost
Cost is the measure of a company’s investment in a project. Projects are often scoped in Man Hours, the number of hours it takes one developer to do. So if a project is scoped for 120 man-hours, you can have one developer working 120 hours or two developers working 60 hours. This is not a perfect measurement because as you add developers to a project, you get diminishing returns from collaborative overhead. This is where costs can increase on a project. However, understanding this concept can help stakeholders make more informed decisions about allocating resources for maximum impact.
Relationship
For a given software project projected at 120 man-hours, consider what happens when these variables change. If the deadline for the project is three weeks, one could have one developer working three weeks for 40 hours a week. If the deadline changes to 2 weeks, the quality will go down, or the cost will go up because another developer will have to be brought onto the project. Due to collaborative overhead, it will likely take two developers two weeks rather than one developer one week because now they have to coordinate their efforts. Suppose it’s found that this project is much more critical to business operations than initially realized. In that case, it will probably need to be tested more rigorously, meaning more developers or time must be allocated.
Keep in mind that every project has a sweet spot for the number of developers who can contribute without stepping on one another’s toes, and finding this balance is one of the jobs of project owners. Stakeholders often want to negotiate with development leads on how fast a project can be done. Still, the reality is the only way to do something faster is to either increase the resources allocated or reduce the quality of the end product.
