How do you manage software projects differently?

As a Project Manager with over 4 decades of experience with IT software-related projects, I have to disagree with the basic premise of this "collaborative" article/discussion. It proposes that "software projects" are inherently different from other projects. It completely fails to include the idea/fact that there are many different kinds of "software projects" that vary significantly in how they might be managed effectively. It vaguely addresses "Agile" as one approach to conducting and managing "software" projects while failing to address any other approaches that are non-"Agile." For many kinds of software projects, "Agile" can be the worst and least effective approach that could be chosen depending on the project's characteristics.

Using software can help with this, for example Pivotal Tracker, Jira, or Shortcut are some tools I have found helpful. These tools allow you to managed your stories/epics and give you insight into how your department is running. Additionally, you are able to integrate with GIT so you can push commits to the relevant story.

One of the best ways to ensure quality, in my opinion, is using the Test Driven Development (TDD) approach. The reasons that I believe this helps with quality is that you write the minimal amount of code to satisfy your unit test. If the test passes, you move on. Assuming you correctly defined your tests, then your code should be of high quality and should be concise.

In my experience, the non-functional requirements are often overlooked. Performance and security need to get baked into the roadmap or you will be refactoring later. Performance is a huge one that needs to get tested at the beginning to ensure the architecture can handle the "as-is" load and a trajectory of the "to-be" load. It's way more complex to pivot on a performance issue than any other. Simulating loads to test your proof of concept is key to long term success. I typically 3x what I think we need today.

Yes, stakeholder engagement and management are critical parts of any project, be it software development or any other kind of IT project. While this should involve most or all project team members, I believe there are 2 particular people who are most critical in doing this and positioned most favorably to be successful with it: the Business Analyst and the Project Manager. (This applies whether the project is utilizing an "Agile" approach or any other approach.)

It is equally important to remain flexible here. Delay interviews until all parties are prepared; Demo only when valuable; Time-box feedback; and re-incorporate only the actionable items that align with scope.

Practicing transparency with everyone involved in the team is the key to success, in my opinion. Every project I have ever worked on where I was told to keep this from the customer took longer and were miserable implementations. No one should feel left out or ignored.

I disagree with the concept of "positive risks." An event that might be positive with regard to the project is an "opportunity," not what we would normally call a risk. Also, we should not be calling an event a "risk." In ordinary language a risk is a probability that an event might happen, not the event itself. I believe we should be using the term "risk event" when referring to the event itself.

Building a team is an art in itself. You need to make sure you and your team share the same goals, trust each other, most of you have experience with each other and with the skills needed for the project, and that you're doing something you all consider important and meaningful. Working directly with the team gives you insight into whether you've got all that, or whether there are areas you need to work on. Most of all, a team needs a leader, not just a manager. They need someone who will be visionary, inspirational, motivational, and lead from the front.

Software teams are often like herding cats. They learn about some new app or new idea and want to deviate from the plan, so they must be watched closely. I always say that in physical world projects the staff has an impulse to do less than planned but in virtual project the staff has an impulse to do DIFFERENT from planned.

Retrospectives can also serve as a constructive way to easily identify conflicts. Any items that are hot buttons can become actionable items for one-on-one follow ups.

I was once asked in an interview, 'How did you successfully manage 70+ projects? Literally, how did you do it?' While the answer can be extensive, based on my experience, it boils down to these key points: Start on time: Ensure timely project initiation. Assemble your team beforehand: Have your team ready before kickoff. Clear roles and responsibilities: Everyone knows their tasks and deadlines. Maintain accountability: Keep your team honest and responsible. Minimize distractions: Allow the team to focus on project tasks. Communicate value: Constantly highlight the value of their contributions. This approach can be adapted to any PM framework. You can manage projects effectively regardless of the specific methodology you choose.

In my understanding, none of these are out-of-the-box. Basic understanding of a PM. Perhaps, using neuroscience (deep know how) to improve team fluid intelligence and emotions management.

With the exception of Agile approaches, none of these items are unique to software development. All are part of project management fundamentals.

I agree with @Bill Duncan, except many of those Agile Practices are also generic and usable in other environments. All projects are unique, and should have a customised execution approach. I do not see how picking certain kinds of software and suggesting they are unique is helpful. Showing how these approaches to software projects flow from generic project management theory seems much more useful than continuing the misleading claims that software is somehow materially different.

I do think the Agile concepts of more regular and frequent communication, planning and retrospectives provide tremendous value to many projects. The biggest problem with non-Agile is the tendency to not allow for change to scope (and triggers for adjustment to compensations) throughout the course of a project. What happens if your supplier of base materials fails to deliver high enough quality to meet standards? Do you have other stuff you can do while you wait to identify a new source or maybe do you have a way to improve the quality on-site? Backlogs, Sprinting, stand-ups, inter-mediary retrospectives can help to provide controls to measure and respond to changing project needs.