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.

Agile, when not strictly adhered to, can be an effective tool for keeping teams on track and garner impactful story telling. In my 2 decades of experience in IT and web software development, I have found that a phased Agile-ish approach with a focus on regular and frequent communication around features/releases to make the most sense.

I am a big proponent of scaled agile. Agile works best when everyone in the organization is on agile and on the same cadence. A big decision for an organization is choosing whether to have 2 weeks sprints or 3 weeks. I think it depends on the line of business, nature of changes in the product etc. At the end of the day your spring size will depend on how frequent you are able to provide incremental benefits to your end users. Another item coming to my mind is measuring relative across pods. Work is estimated by the pod, so when you have multiple pods delivering similar values, the relative performance becomes important. That's where DORA metrics could become very useful.

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, software quality can be achieved/improved via code reviews, testing, refactoring, etc. But the best way to achieve extremely high quality in newly developed software is to create extremely high-quality software in the first place. This often requires highly skilled developers with extensive experiences related to the kind of software being developed. Rookie software developers are not usually capable of this (with some exceptions). When assembling a team for developing new software systems, a competent PM should be sure to look for this kind of expertise along with the right attitudes regarding quality.

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.

I remember that in a software project, the most important stakeholder of the project did not have a correct understanding of our path and often hindered the growth of the project. I tried many times to correct his attitude, but because of his work experience from the steel industry, which was far from the software space, it was very difficult.

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.

This is so true. One more thing is to ensure diversity, equity, and inclusion rules in the team. Have a clear, collective purpose and agreed objectives. Align these objectives to the needs of their stakeholders. Recognize the need for effective team collaboration to achieve these objectives.  

I agree with this completely, and I think it is one of the most important things stated in this entire discussion. Elements I would emphasize are consistently showing respect for everyone in the team and building personal relationships whenever possible.

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.

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.

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.