When people discuss quality in software development, they typically refer to quality assurance testing. While testing is a significant factor in software quality, it isn’t the only thing to consider. For project or quality managers, there are a few other areas to consider for your organization. Three significant considerations are code reviews, continuous feedback loops, and knowledge sharing.

In software development, technical debt can come in many forms. For instance, a new product was created using a prototype that was never architected after the proof of concept was created. Another example is bugs that had workarounds, but a fix has not been implemented yet. Another issue is that a series of software upgrades need to be implemented, but the team is understaffed. These are only a few examples of technical debt, but all of them create a problem that can haunt a project in the form of risk. How does a project manager dig their way out of technical debt?

Project management has been a staple of business for decades. It has undergone significant changes, particularly when it was formally adopted for Agile development. It wasn’t always that way, though. Let me take you back three decades, to a time when Waterfall was still the king of software development processes.

Root Cause Analysis (RCA) is a troubleshooting technique used to identify, mitigate, and resolve issues. In the software development realm, RCAs often involve multiple people, making them a costly endeavor. Because of this, many organizations do not participate in performing an RCA, or save them for severe incidents. This isn’t necessarily a bad business practice, but RCAs are an essential part of continuous improvement for the software development team and project growth.

Many teams today have specific “go-to” people on a team. There is often a person who is the only one who has dealt with a specific feature or issue, and they are always the one that the team turns to when work needs to be done. What happens if that person is unavailable or busy with something else? Is the team sharing knowledge, or are they using the specialist’s capability as a crutch? Should someone be allowed to continue as the single point of failure?

There are many project management tools in the tech sector. I have worked with Jira, Azure, Asana, and TFS (to name a few). Over the years, I have noticed that organizations like to use them but don’t always use them to their full extent. Since they are paid apps, wouldn’t it be a good idea to try to get your money’s worth?

Project deliverables are essential to everyone on a project, not just the project manager. They are a way to measure the project's success or failure. Deliverables can be as large as a milestone or as small as an email, but all deliverables should be treated with the same quality standards. So, what is a deliverable, and why is it essential to ensure it meets the standards of success?

Many software development companies want to move to a Continuous Integration/Continuous Delivery (CI/CD) model, but still have long release cycles. There are several reasons this happens. One example is that the company is holding a release until features are complete and is not using a feature flag system. I’ve also seen that they are holding onto the idea that they can only release at the end of a sprint. While I get the concept from a project management perspective, after all, it does make release tracking easier, it doesn’t have to be that way.

Recently, I was asked what I usually do to set up a new Quality Department. I have done it several times over my career, and here are a few lessons I’ve learned. It isn’t a difficult task, but it requires analysis and project planning.

Total quality management (TQM) is a top-down organization concept that dedicates quality to every function of an organization. It was developed in the 20th century and was initially created for product manufacturing. Over time, it was adopted by numerous agencies to gain a competitive advantage in their market. TQM is a way to harness an organization’s resources to improve effectiveness and efficiency with support, training, and guidance.

Over the years, I have worn many hats in various roles. I have managed projects, products, processes, development, and testing throughout them. One requirement has always been to make our work as efficient as possible. While I see the business value of efficiency, bringing value to the development sphere while keeping costs down, I always look at effectiveness first.

Over the years, I developed a series of training documents and videos for my teams that discuss Story Point estimation. They discuss how they are used and why they are essential. Since I did a previous post about Velocity, it is crucial to lay the groundwork for Story Points so that teams can estimate adequately.

When an organization starts a new project, there is often a flurry of activity. Most of it revolves around cost in some form or fashion.

In software development, project managers are often tasked with building or modifying features that add scope to an application. Scope is something that most project managers are painfully aware of, as it frequently increases costs and complexity. In an Agile environment, new features are broken down, refined, estimated, and then developed.