ProDev #2: Managing Projects as an Individual Contributor
Hey, Caique here with your weekly issue from ProDev! ✌️
This article introduces the basics of project management as a discipline. It provides practical tips that offer a new perspective on managing time, cost, and scope as an individual contributor.
Additionally, it briefly covers agile methodologies, how to handle different levels of quality, and how to manage risks.
If you are not a subscriber, you might miss other practical advice like this one. Subscribe for free and get weekly articles directly to your inbox.
Being able to drive projects from inception to launch is a crucial skill for any professional in the tech industry. Even when working on a product, we can treat initiatives as individual projects that operate within a larger context and are subject to similar conditions.
A project is a planned effort with a clear beginning, middle, and end, aimed at achieving a goal.
Examples of projects include:
Adding a major new feature to a consumer-facing product
Launching a product in a new market
Executing a marketing campaign to reach a specific segment
Changing a cultural aspect of the company
Adopting a new tool
The list above is obviously not exhaustive, and smaller (and less glorious) initiatives are often run as projects in the tech industry. I adopt project management practices in almost every work that I lead, and the practices depend on the size of the work to be done. It can be as simple as defining a clear goal for a user story in the form of acceptance criteria or setting a weekly routine with ceremonies and milestones to keep the flow within a larger group.
As an individual contributor (IC), you lead initiatives mostly through influence. Since you lack a formal mandate over other people in the project, it's important to make smart and pragmatic decisions. Most of the time, this means communicating effectively to ensure everyone is on the same page and executing under the same conditions.
While project management is complex enough to justify its own career, having some basic knowledge can work wonders for anyone who needs to complete any type of work as part of an organization.
History of Project Management
The need to execute projects exists since the beginning of civilization, just like the need of managing them.
The pyramids, the Great Wall, the atomic bomb, and many other historic milestones are the resulting success or failure of project execution. The practices applied were indeed rudimentary but shared a lot of similarities with the projects we run nowadays.
In 1910 the Gantt chart became popular and the two World Wars are considered the period when the discipline of project management became to be formalized and employed in industrial endeavors.
Between 1958 and the early 2000s, project management evolved into a formal discipline, and best practices and standards began to emerge. The Project Management Institute (PMI) was founded in 1969 and began offering certifications in the field in the 1980s. The PMI's Project Management Body of Knowledge (PMBOK) guide, which was first published in 1987, has become the standard guide for project management best practices.
When software projects first began, they borrowed standard practices used in other industries such as manufacturing and engineering. This led to the widespread adoption of traditional project management practices for software development.
In the late 1990s and early 2000s, the Agile methodology emerged in response to the inefficiencies of traditional project management methods when applied to knowledge work. During this time, most software was developed for internal departments, and the formalities of traditional methods were often overwhelming when defining work contracts between different parts of the same company.
Software is not primarily developed to serve internal customers, but due to various other reasons, traditional formalities remain unsuitable for most businesses. As a result, Agile has become the industry standard for software development, and it has expanded into different industries, exchanging influences with other approaches, such as Lean Manufacturing and Design Thinking.
These new schools of thought challenge the old “Command and Control” approach by demonstrating impressive results across different contexts. They emphasize customer-centricity, employee empowerment, diversity of thought, collaboration, and continuous improvement.
Today, projects remain at the core of most organizations and project management continues to evolve with new technologies and practices. It has transformed from an auditing discipline into an enabler of innovation and efficiency.
The Iron Triangle
The iron triangle in project management describes the interdependence of three variables: time, cost, and scope. Changes to one variable will have an impact on the other two.
Managing a project means balancing these variables to achieve the desired outcome, and the tension between these variables defines the advantages and constraints of a project. For example, if a project has a strict deadline, the cost may need to increase, or the scope may need to be reduced. Similarly, if the scope is expanded, either the cost or the time required to complete the project will need to increase.
In a traditional approach to project management, these variables would be predefined at the planning phase, and the execution should just respect these boundaries. Modern approaches assume a level of uncertainty that incurs natural adjustments in these values as we learn more during execution.
In my experience, the main cause of project failures is the lack of realistic expectations regarding time, cost, and/or scope. Nearly every project starts with wrong estimations, and project leads often fail to adjust these estimations as they learn more. When the true context of a project is not understood, the resulting decisions often fail to address the actual problems that need to be solved. This leads to projects that deliver less than promised, take too long, and exceed their budget.
A brief note on quality
In classic project management, quality is considered a dependent variable that is often described in terms of a combination of the other variables in the Iron Triangle. Different levels of quality can only be obtained by changing one or more variables, and changing one or more variables will affect quality.
It is important to understand that not every project demands the same level of quality, and determining the appropriate quality level can serve as an argument to negotiate better conditions and transform constraints into levers during project execution.
As a rule of thumb, you should always aim to use as fewer resources as possible to achieve an equal or higher perceived quality.-level
A brief note on risk
You can spend as much time as possible crafting a "perfect" plan, but there will always be some uncertainty, which means there will always be a risk of things not going as planned.
It is virtually impossible to predict how every variable will behave during execution. In addition, we operate on assumptions simply because it is not feasible to confirm all possibilities beforehand.
Managing risks and communicating them properly can help avoid surprises during project execution.
Great project execution can sometimes be reduced to effectively monitoring variables and managing risks.
A brief note on agile
The innovation that Agile methodologies brought about was the idea of focusing on quality and measuring progress in terms of customer satisfaction. It prioritized delivering value early and often to meet the customers' needs, rather than solely focusing on the expectations of the iron triangle.
Each Agile methodology offers different ways to manage and adjust the iron triangle. For example, Scrum sets a constraint on time by using a fixed timebox (the Sprint), making the scope explicitly negotiable. Kanban, on the other hand, sets a fixed scope at the task level and allows for flexibility in time and cost based on each task execution.
Of course, allowing a variable to be flexible does not mean ignoring it completely. Each methodology has its own mechanisms to manage risk and optimize resource utilization.
One of the main misconceptions about Agile methodologies is that they do not care about these variables. In reality, they provide much more control over them since planning, designing, documenting, and assessing risks are done continuously (often on a daily basis) through different techniques. In addition, most Agile methodologies make the whole team accountable for keeping healthy boundaries for each one of these variables and bring the idea of continuously improving efficiency to maximize outcomes.
Practical Tips
As mentioned before, project management is complex enough to justify its own career. While there are no silver bullets, there is some general advice that is worth mentioning. By incorporating each one of these tips, you will most likely make better decisions and significantly improve your success rates.
Do not limit yourself to one way
Every team or organization has its own unique characteristics, so no single agile methodology can solve all problems without some adaptation to your context. As members of an organization, our work is to fill these gaps, and often the best way to do so is to mix and match components and ideas from different methodologies to create a unique way of working that fits our equally unique value proposition.
Some people argue that agile methodologies are nonsense and that it's not worth learning about them. While there is a whole industry that profits from selling courses, certifications, coaching, etc, without being able to show results, I have yet to encounter a modern organization that does not operate based on agile principles and practices. I believe that part of the reason for the disbelief in agile is that it has become such an industry standard that people take it for granted. Some people do not even know what it is like to work with classic project management and the struggles that come with it.
In my experience, learning about techniques such as lightweight planning, retrospectives, and daily alignments will expand your toolbox and enable you to navigate situations where technical skills alone are not enough.
For a more in-depth understanding of this topic, I highly recommend reading The Pragmatic Engineer’s blog post about “How Big Tech Runs Tech Projects and the Curious Absence of Scrum”. This post provides insight into the project management landscape and what you may experience in different types of tech organizations.
Estimate time as a range
Answering the question "When will it be done?" is a challenging task, particularly when the work to be completed is complex and ambiguous. Providing a single number as an answer is only feasible if the work is linear or extremely straightforward. If this is not the case, I suggest that you answer with a range.
Instead of saying something like "today" or "in 3 weeks", say "between today and the end of the day tomorrow" or "between 2 and 4 weeks".
Providing lower and upper bounds instead of a fixed date increases the likelihood of delivering on time. This approach also recognizes the inherent complexity and ambiguity, and the uncertainty that comes with it.
Alternatively, you can provide a single value but give context about the sources of uncertainty. For example: "I believe it can be delivered today, assuming nothing changes" or "Assuming X and Y, it is likely that it will be done in three weeks.”
Whenever possible, rely on historical data to forecast probable dates with greater accuracy.
Describe cost in terms of ROI
Nowadays it is more common to describe investments in terms of products and teams rather than by individual projects. Even if your project has a separate budget, chances are that managers have come up with the final numbers in other instances.
Individual contributors are typically not responsible for requesting funding. But, if you need to provide a cost estimate, it is better to present the Return on Investment (ROI) instead of just the cost of execution.
A "$1 million project” is expensive. "A $1 million investment with projected returns of $2 million” is an amazing deal.
This advice goes beyond just "using the right words". Any serious businessperson would ask, "What is the expected return?" when presented with only the cost of a project. Doing this demonstrates that you have a mature understanding of standard business practices.
One extra piece of advice is to estimate the ROI based on the Total Cost of Ownership (TCO) instead of just the cost of execution (or "Purchase Price"). This will make the numbers more interesting and realistic. More importantly, it will demonstrate that you know what you are doing.
Just like time estimation, whenever possible, rely on historical data to forecast values with greater accuracy, and be ready to explain your thought process.
Prioritise and negotiate the scope
A common pitfall is to view the scope of a project as a fixed checklist that must be completed. While there are a few scenarios where this is true, approaching it as a rigid and non-negotiable list increases the likelihood of project failure.
In my experience, scope is the easiest variable to negotiate because stakeholders are not as interested in the project's output as they are in the project's outcomes. Different scopes can achieve the same outcome, so you have the opportunity to choose which one you prefer to accomplish.
Always identify the expected outcomes of a project, and describe your scope as a prioritized list where each item's completion results in a partial outcome. This approach will provide many opportunities to negotiate the scope as you learn more about the project.
Techniques such as MoSCoW and Opportunity Solution Tree can help you define the scope of a project. Any other technique related to backlog management is equally useful here.
Identify different levels of quality
I suggest identifying different levels of quality that can be achieved over time. This will allow you to plan incremental deliveries.
Typically, achieving a lower level of quality requires fewer resources. Therefore, a good strategy to minimize risk is to make multiple deliveries with increasing levels of quality, corresponding to increases in resource consumption. By doing so, you create a feedback loop that gives you the opportunity to validate your assumptions and estimations.
This advice pertains to the concept of a "Minimal Viable Product" (MVP) and the notion of "pivot or persevere.”
Continuously monitor the risks
The discipline of risk management is so vast and interesting that it deserves its own article (let me know if you would like to read about this).
But, to provide something in this area, here is a general framework:
Brainstorm risks with as many people as you can. Diversity of thought is the best approach to make sure you covered as many angles as possible.
Refine the list of risks by merging similar ones, removing irrelevant ones, and adding context for those that lack it.
Classify risks in terms of likelihood and impact. "Likelihood" refers to the chance of the risk occurring, while "impact" refers to the negative outcome if the risk does occur.
For each risk, decide what action to take: mitigate, eliminate, accept, or transfer.
During execution, it is important to closely monitor the risks and make adjustments as you learn more.
While each project is unique, you can use past executions and historical data to predict potential risks, their likelihood, and their impact.
Now it's your turn!
Take a moment to reflect on your current and past projects.
What do you consider to be key to a successful execution?
What do you consider as pain points?
Which practical tips can you incorporate into a project you are a part of?
Do you have any other advice that you would like to add to the list?
Bonus: Share your reflections with a colleague involved in one of your current projects and discuss how you can work together to make the project better.
I also would love to learn more about your context. If you feel comfortable, also share your answers with me. You can reply to any of my emails or reach me at prodev@substack.com. I promise to reply to all of you.
Last but not least, please let me know if managing projects is a topic that you want to read more about here.
Thank you for reading and have a lovely week. 👋