This is part two of the article that I wrote to advice on overcoming project management pitfalls in software development projects, as found in the original post here on tech republic. The first post can be found here.

6. Poor Communications. Avoid mistrust by keeping the communication lines open at all times. SCRUM states that during sprints you need to have a daily scrum. Invite everyone, and have a proper agenda you follow. Make sure that the daily scrum does not become a meeting where you solve problems, and take everyone’s time. Communication can also be a report or a dashboard showing the current status of your development cycle. Make your burn down graph and kanban board visible to all stakeholders, and make sure it is kept up to date.

Spec’ing your requirements is also done through proper communication only. Talk to your user to find out what they really need – or even better: Use a product design sprint to make sure that your prototype communicates both your understanding of the system and test it with your users.

7. Disconnected business priorities. Make sure that everyone is on the same page by, again, using the product design sprint to make sure that all your requirements are covered, and even user tested by day 5. This process is invaluable compared to former software development methods. It spec’s out the most important features in your product and makes sure that all stakeholders get what they want. The result is not only a great UX, It is a fantastic base for the development team to schedule their work.

8. Constructing a wall of process. The gist of this paragraph is that software development processes slow down because of the process. Change request forms needing be cross-signed, builds that require signing off by people that are hardly available. Avoid all these requirements by keeping your process lean. SCRUM is an excellent framework that keeps your process lean and your development agile. Avoid going too agile – keep your code maintainable and plan for your implementations properly, to promote reuse and staying DRY.

9. The “Hit the ground running” myth. This paragraph discusses the problem that is already addressed in point 1. That adding someone to the team will increase output proportional to the number of man-hours added. In software development you can speed up by adding manpower, but it takes a while before developers are going to be fully productive. As a developer you need to understand the business process that you are supporting and it generally takes a while. Again what you can do speed up on the technical side is

a. Make sure your application is implemented in the same patterns. You can teach the developer these patterns and he should find his way around in the code with more ease.
b. Make sure the code is well written – Write code that reads well. Code that expresses intent properly. Developers spend most of their time understanding other people’s code.
c. When the Product Design Sprint is completed successfully, the prototype can be used to explain the new developers what the actual result needs to be. This will help the developer understand the business process with more ease.
d. Pair up the new developer with a senior that knows the product inside out. Let the new developer do the work

10. Multi-tasking. People think they can multi-task, but all this adds is additional workload and the risk of burn-outs. In programming focus is everything. A phone call can break your train of thought and may require you to read all the code again, to find out what line you need to add your change.
a. Keep your development environment calm so people can focus.
b. People can choose to play music on their headsets so that they do not disrupt those who can not work with music.
c. Avoid having phones in the development area.
d. Put technical people together so they can discuss their issues and solutions. Nothing feels better than finally finding the cause of that issue that everyone is already blaming the framework or database for!
e. Schedule meetings, presentations, demos etc at fixed times to avoid too many distractions.

Overall, should you follow these guidelines, you should be able to avoid the typical problems during software development projects. Please comment if you have any questions, and share if you learned something new today!

‍