I firmly believe that project management approach should be universal. It should fit in with software development project. It should work in any other industry.
Yes, there are differences.
They do shift your focus. However, this differences should not be an excuse not to apply proper processes and tools.
Read this article to ensure you address the most significant problems of software development project management.
Software Development is Mostly Agile
Scrum, Kanban, and their modifications dominate in the software industry.
The preference of agile approaches is dictated by all the aspects I mention below.
However, there is a catch.
Many project managers focus solely on one of the Agile frameworks. They think that it can cover the whole project life cycle.
But it is wrong.
Software development projects evolved through different phases. Some of them sequential. Some of them overlap.
Therefore, you may mix up different phases in one Sprint. But rarely you will be able to fit everything in one framework.
So, don’t let marketing aspect of Agile Frameworks derail you. You will need to know the basics of project management.
Software Development Project has a Lot of Uncertainties
The main problem with software development project management is uncertainty.
It is everywhere.
You can’t be sure that the technology stack you selected will cover all the requirements.
Sometimes technologies you choose seems like a good fit. Then, somewhere in the middle, it appears that something doesn’t work as expected.
It can be defects in the technology you selected. It can be in the hardware you need to use. It can be not compatible with other modules of your application.
That is not all.
Your customers are usually uncertain of the final result.
They can’t be sure until they see and play with the product you developed.
Actual Work is not Tangible
Software development is a labor of mind.
Quite often there are weeks of thinking, discussing, and trying things out. In the end, the actual work to write the code takes a day.
Also, software development is not standardized.
While there are coding conventions and general approaches each engineer can implement the same functionality in a magnitude of ways.
Stakeholders who are not familiar with software development may not understand this.
They don’t understand why writing 20 lines of code may take several days.
Why?
Stakeholders perceive the actual result only on computers, mobile devices, cars, or other hardware. They are tangible. The code is not.
Sometimes simple functionality of a product requires a lot of complicated coding.
Customers Cannot Assess the Required Work
Taking into account all the above, customers, clients and product owners have hard times.
They cannot assess the amount of work a deliverable will take.
Yes, they can work solely from the business perspective. They can provide business requirements only and not worry about technical stuff.
But here is a problem.
They don’t know the limitations of technologies and approaches. They don’t usually know available options as well.
They provide requirements.
We provide estimates and costs.
If estimates are beyond the available resources and time you need to come up with a solution.
You need to make ends meet.
Capabilities of your experts should match with available budget and timeline.
In the long run, you have to ensure that the end result will provide business value to your clients.
Misleading Flexibility
From one side it is relatively easy to make a change in an application or service.
Much easier than making a change in building, a model of a car, or a UI design.
Moreover, agile methodologies just scream at us how easy it is to adapt.
The reality is a bit different.
The cost of a change still follows the same curve.
You see each software application has an architecture. Just like a building.
While developing the architecture, we try to ensure that all requirements known to the moment will be supported by it.
We also try to ensure that this architecture is flexible enough to adapt to the changes to some extent.
However, the more flexible the architecture, the more complicated it is, the more efforts it takes to support it and implement a functionality.
And there is no silver bullet here.
So, some early mistakes will cost you dearly to fix.
Some (technical) decisions will have long-lasting effects.
The impact of each change is different. You will have to be very careful accepting a “simple” change request.
Conclusion
Software development project management requires strategic communication first of all.
To some extent, you need to drive the decision for your clients and take responsibility for the end results.
You can not avoid these two aspects if you want to be a good software project manager.
Do you want to become a Software Development Project Manager? Sign up and start your transformation today.