Part of project management is determining what risks your team will face as they progress. Whether you are starting a new project or working on an existing one, it is a good idea to identify the risks your project will encounter as it progresses. A few key areas to look into: Complexity, Budget, Trends, and Project Comparisons.

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.

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.

Team velocity is a crucial tool for effective project management. Not only does it track team delivery, it also allows for the projection of delivery potential.

When I was a QA Manager, I was frequently asked the question, “Why do I need to pay for testing?” Quality is a cost. It costs money to test and maintain those tests. The trick for project managers is to show the value of quality.

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.

A good friend of mine once told me, “A fast nickel is better than a slow quarter.” This is one of those statements that often sounds witty but is usually ignored. He told me this a couple of decades ago, and I didn't think much of it until later in my career.