CSE 370: Software Engineering Principles

W06 Learning Activity: Project Management

Overview

The previous lessons discussed the various phases of the Software Development Lifecycle. This week you will learn more about how to manage the people and processes that make up that lifecycle.

The topic of Project Management is deep and nuanced. There are complete courses, degrees, and professional certifications devoted to this topic. This lesson cannot cover all of the components of project management, but it is intended to help you understand why project management is important on a software development team, and what you can do to help projects run smoothly, even as a junior developer.

Key Points to Remember:

  1. People write software—and they aren't robots.
  2. Successful teams develop a culture of psychological safety.
  3. Project management is all about managing risk.

Preparation Material

Software is created by people

In the previous lessons, you have learned about the tools and techniques of each phase of the software development lifecycle that can help a software project be successful, even in the face of difficulties and changing requirements. It is essential to realize that each of these phases are ultimately carried out by humans.

People aren't robots. They have feelings. They make mistakes. They are creative. They get upset. They take satisfaction in there job. They take vacations. And many more things.

You have to treat a software project as a people project. Working with people requires flexibility. No matter how well you plan your project, in the end, it will look different than your spreadsheet.

People are the most valuable resource in your project, and the way they work together will ultimately determine the success or failure of your software project.

Creating a Culture of Psychological Safety

One of the ways you can help people work together well and ultimately have a successful project is to create a culture of psychological safety. Psychological safety refers to an environment where team members feel comfortable taking risks, sharing ideas, and expressing themselves without fear of judgment or reprisal. This kind of culture is crucial for fostering collaboration, innovation, and overall team performance.

In short, people need to feel comfortable saying what they think, even if it's not popular, and even if it turns out to be wrong in the end. The goal is to get as many good ideas as you can out in the open.

Establishing a culture of psychological safety requires the whole team, including both managers and team members, to buy in to its value and promote it. Even if you are a junior member on the team, your actions can play a key role in promoting this kind of culture.

Here are some strategies for building and nurturing psychological safety within a software team:

  1. Encourage Open Communication:

    Foster an environment where team members feel comfortable expressing their thoughts, concerns, and ideas openly. Encourage active listening and ensure that everyone's voice is heard and valued. Managers should lead by example by actively seeking input from team members and responding constructively to their feedback. Remember that some people on the team are more extroverted and love to express their ideas in a meeting, while others may be more introverted and like to develop and share their ideas away from the group.

  2. Embrace Failure as a Learning Opportunity:

    Cultivate a mindset where failure is seen as a natural part of the learning process rather than something to be feared or avoided. Encourage experimentation and innovation by rewarding efforts to try new approaches, even if they don't always succeed. Use failures as opportunities for reflection and growth, focusing on what can be learned from the experience rather than assigning blame.

  3. Address Conflict and Disagreements Constructively:

    Conflict is inevitable in any team environment, but it can be managed effectively with the right approach. Encourage open dialogue and respectful communication when disagreements arise, focusing on finding solutions rather than assigning blame or credit. Remember the counsel: seek first to understand, then to be understood.

Each person brings a unique perspective to the team, and there is great power in that diversity. By implementing these strategies, software teams can cultivate a culture of psychological safety that encourages collaboration, creativity, and continuous improvement.

Revelation Scattered Among Us

A principle that is often shared in the Church of Jesus Christ is that "revelation is scattered among us." The idea is that many people may have part of the solution, and by counseling together we can arrive at a better solution than any one person could on their own.

This principle is true in councils in the church, and it is also true in the workplace. By learning to counsel with your coworkers, especially when you have different backgrounds or opinions, the quality of your work will improve.

Risk Management

Problems and failures can happen in any system. When you include people or uncertainty, it only increases the chances of failure. Recognizing that there will be failure in your process, you should not be paralyzed by it, but instead, you need to consider ways to manage the risks associated with each potential problem.

At its core, project management is all about understanding and managing risks. You need to understand what the potential risks are, where they come from, and how you can manage them.

Categories of Risks

In a software project, risks can be categorized into several broad categories, such as the following:

  1. Technical Risks: These risks are associated with the technology and tools used in the project. They include:
    • Compatibility issues with different platforms, browsers, or devices.
    • Inadequate scalability or performance of the software.
    • Integration challenges with existing systems or third-party components.
    • Uncertainty about the feasibility of implementing certain features or requirements.
  2. Schedule Risks: These risks are related to project timelines and deadlines. They include:
    • Underestimation of time required for tasks.
    • Dependencies on external factors such as third-party services or approvals.
    • Scope creep or changes in requirements impacting project timelines.
    • Resource constraints or sharing of resources (especially people) among projects.
  3. Cost Risks: These risks involve the budget or money. They include:
    • Underestimation of project costs.
    • Unexpected expenses.
    • Fluctuations in resource costs.
  4. Quality Risks: These risks pertain to the overall quality of the software deliverables. They include:
    • Inadequate testing leading to undiscovered bugs or defects.
    • Technical debt from not following coding standards and best practices.
    • Poorly defined or ambiguous requirements impacting the quality of deliverables.
    • Insufficient documentation affecting maintainability and future development efforts.
  5. Communication Risks: These risks arise from communication breakdowns within the project team or with stakeholders. They include:
    • Misunderstandings or misinterpretations of requirements.
    • Poor collaboration among team members leading to inefficiencies or conflicts.
    • Ineffective communication channels hindering timely exchange of information.
    • Cultural or language barriers impacting communication with distributed teams or international stakeholders.
  6. Security Risks: These risks involve potential threats to the security and privacy of the software system. They include:
    • Vulnerabilities in the software code exposing it to cyber attacks or data breaches.
    • Insufficient access controls or authentication mechanisms.
    • Compliance gaps with industry regulations or data protection laws.
    • Inadequate measures for securing sensitive data or intellectual property.
  7. Legal and Compliance Risks: These risks relate to legal obligations and regulatory compliance. They include:
    • Non-compliance with licensing agreements or intellectual property rights.
    • Legal disputes over ownership of code or contractual obligations.
    • Failure to meet industry standards or regulatory requirements.
    • Risks associated with changes in laws or regulations impacting the project.

As project managers identify and address these types of risks, they mitigate potential issues that could arise and improve the chances of successful project delivery.

The Iron Triangle

Related to these categories of risks is a concept referred to as The Iron Triangle. It is a fundamental concept in project management that represents the interdependent relationship between three primary constraints: scope, time, and cost. Recognizing the relationship of these constraints of the Iron Triangle, project managers make informed decisions about the trade-offs that must be made.

  1. Scope: Scope refers to the features, functionality, and requirements of the software project. It defines what needs to be accomplished and delivered to meet the project objectives. Changes in scope can significantly impact project timelines and costs. Increasing the scope typically requires more time and resources, while reducing the scope may result in faster delivery but may sacrifice certain features or quality.

    Reducing scope is not very common. Almost always, as the project becomes more developed, people find additional features or functionality that is needed. The challenge—and this is precisely what the concept of the Iron Triangle is meant to convey—is that increasing scope also increases costs and/or delays the schedule, which is never popular.

  2. Time: Time represents the project timeline or schedule to complete the project. Time constraints are often driven by deadlines or market demands. Delays in project completion can result in missed opportunities, increased costs, or customer dissatisfaction. Recognizing the constraints of the Iron Triangle, accelerating the project timeline may require additional resources or a reduction in scope to meet deadlines.
  3. Cost: Cost refers to the financial resources allocated to the project, including personnel, equipment, tools, and materials. Cost constraints are typically defined by the project budget. Exceeding the budget can lead to financial risks and constraints on future projects. Managing costs involves optimizing resource utilization, controlling expenses, and prioritizing project activities based on budgetary constraints. In terms of the Iron Triangle relationships, decreasing costs typically requires sacrificing features or slowing down the timeline.

The Iron Triangle illustrates the inherent trade-offs among these constraints:

As a developer, you often face pressure to build things faster (without reducing scope) or to add more features (without increasing time). It is tempting to say "yes" so that people will like you or so that you can get a promotion. But the truth is, you will set yourself up for failure in the end. Instead, if you face this pressure, you should help your manager or customer recognize the connection between these components and to make the necessary trade offs.

For example, if you are asked to add more features, you could respond that you are happy to do so, but it will require more time. Or if you are asked to reduce cost or to deliver earlier, you could brainstorm potential features that could be delayed to a future release. Helping your managers or customers understand these tradeoffs will help you all be more successful in the end.

Brook's Law

A common solution to try to compensate for adding more features or reducing timeline, or to help a project that is behind schedule, is to add more people. Unfortunately, rather than help the project, adding more people can actually make matters worse. This principle is so famous that it has a name: Brooks' Law.

Brooks' Law is a principle in software engineering that states: "Adding manpower to a late software project makes it later." This adage was coined by Fred Brooks in his seminal book "The Mythical Man-Month," published in 1975.

Brooks' Law

Adding manpower to a late software project makes it later.

Brooks' Law is based on several underlying factors:

  1. Communication Overhead: As the size of a project team increases, the complexity of communication also increases exponentially. Additional team members need time to get up to speed with the project, understand existing code, and coordinate with other team members. This overhead can slow down progress, especially in the short term.
  2. Ramp-up Time: New team members require time to become productive contributors to the project. They need to learn the project's domain, technology stack, coding standards, and existing codebase. This learning curve can delay progress, particularly if the project is already behind schedule.
  3. Dependencies and Coordination: In software development, many tasks have dependencies on other tasks or require coordination with team members. Adding more people to the team increases the complexity of managing these dependencies and coordinating efforts. This can lead to bottlenecks and inefficiencies, further delaying progress.

Brooks' Law serves as a reminder of the importance of careful planning, effective communication, and thoughtful management of project resources in software engineering.

Effective Communication

Brooks' Law highlights the importance of effective communication in a software project. There are two main types of communication to consider, intra-team communication (communication with other people on the same team) and inter-team communication (communication with people on other teams).

As you might imagine, intra-team communication is essential to ensure that everyone on the team is working as efficiently as possible. Nearly all of the techniques of popular agile methodologies like Scrum are put in place to maximize this intra-team communication (for example, stand up, planning, and retrospective meetings).

A project manager often helps facilitate the intra-team communication, but it is the inter-team communication with others in the organization where the project manager's value really shines. Project managers maintain important channels of communication so that when the team needs resources or help from other people, they can facilitate these needs. They also help communicate about potential risks or future needs so that others can plan for them.

Open and honest communication is essential

One of the most important things members of the team can do is be open and honest in their communication. Since the essence of project management is to know about and prepare for any risks, it is critical for you to help your project manager have visibility to any problems that could arise in the future.

Often, junior developers make the mistake of hiding problems. They mistakenly feel that they will look bad or that people will be disappointed in them if they report on a problem they are having. On the contrary, your job is to help your project manager and others know about any potential risks that arise so they can help you and the team overcome them. Be open and honest about how your work is going.

Do not try to hide problems or risks. Be open and honest in your communication.

Estimating your contributions and progress

One of the most difficult tasks in software development is estimating how long something will take to complete. There have been many different techniques for estimation that involve trying to balance the best and worst case estimates, but none of them are terribly accurate. One of the reasons for this is that, unlike a home builder who might build many similar homes, when you write software you are almost always creating something that has never been done before, so there is a large amount of uncertainty.

To handle the uncertainty and to help make better estimates, agile methods reduce the event horizon, or the distance into the future that you must estimate. The idea is that you might not know exactly what things will look like six months in the future, but you should have a decent idea what they will look like in two weeks. Hence a common Sprint length is a short, two week window.

Similarly, as a member of the team, you need to develop your ability to estimate how long small tasks will take. You do not need to estimate a huge project, but you should develop a sense of how quickly you can accomplish smaller tasks.

Almost all software engineers are notoriously optimistic and tend to tell people the first possible chance something could be done, rather than taking into account the risks that might delay our progress. The reality is that tasks almost always take longer than you think, so you will need to resist the urge to plan for everything to go perfectly, and instead account for risks that may come up.

Learning to properly account for risks and improve at estimation is difficult, but it comes with practice. One way to improve at estimating your own abilities is to track the work that you are doing and how long it takes. In each sprint (or even in each stand up meeting) you will estimate how long a task might take you. Keep track of how long it actually takes and compare that to your initial estimate. As you continuing practicing, you will find your estimates get better over time, and more importantly, you will become better at looking for risks that could impact your estimate. These risks are exactly what the team and the project manager want to know about.

Estimation is hard. Through practice you can improve at estimating small tasks.

Team Velocity

In addition to understanding your personal velocity, or the pace of how quickly you can accomplish tasks, it is very important for teams to develop an understanding of their team velocity. Team velocity is a metric that represents the amount of work a team can complete in a given space of time. It is not about predicting the duration of the complete project or about comparing individual developers productivity. Instead, it helps you know what the team can accomplish collectively during a given time frame, which can help with planning and forecasting.

By tracking team velocity over successive sprints, the team can better predict their capacity and adjust their commitments accordingly, leading to more reliable planning and execution.

Metrics and Key Performance Indicators (KPIs)

In addition to managing risks and tracking velocity, an important part of project management is to make sure that your work is aligned with your organization's strategic priorities and that you are making progress toward those goals.

Key Performance Indicators, or KPIs, are quantitative measures that help you track the quality and progress of your project. Each team and company will define its own metrics. They could include any of the following:

Once a company or team decides on its KPIs, project managers help ensure that the work of the team directly contributes to success in these areas.

For additional discussion about goals, planning, and monitoring progress, see Chapter 8 in Preach My Gospel, Accomplish the Work through Goals and Plans.

Maintaining Flow and Managing Disruptions

One of the biggest factors that can slow an individual or team's progress are distractions. It takes a significant amount of time to get back into the flow of the the work you were doing after you were distracted by an email, phone notification, or person stopping to visit with you.

Perhaps ironically, one of the principles of agile processes is to maximize communication through techniques such as open floor plans and tools like Slack or Microsoft Teams that make it easy to ask quick questions at any time. The goal is to make sure that information is flowing naturally and quickly to anyone that needs it. The challenge, however is to make sure this constant flow of information and questions does not completely ruin your ability to focus and accomplish tasks.

Managers need to resist the urge to micromanage their team, prescribing every little detail to be done and the way to do it. Individual team members need to find solutions that work best for them to stay available, but still remain focused. This could involve relying more on asynchronous communication which allows people to respond when they are able, time blocking, or blocking out certain periods of time when you will focus on work, or even simply buying a set of noise-canceling headphones. The trick is to find a pattern that works for you so that you can be helpful to others but still productive.

Continue the conversation

After completing this reading, ask 3-5 follow up questions about project management to an AI system of your choice. (You may use ChatGPT, Bing, Claude AI, Gemini, or any other system of your choosing.)

Good questions may include:

Submission

After you have read this material, return to Canvas and submit the associated quiz there.

Other Links:

ChatGPT assisted in the creation of this learning material.