Software development is tricky. It takes time and is usually much more complicated than e.g. building something physically.
People have much more experience in building, because we have done it for thousands years. Today, if you want to build a house, you have to go to an architect, plan it very carefully and then build according to the drawings you got from the engineer.
During the process, you can plan most of the work and you know how you want it to look like when you finish.
We don’t have that much experience in developing software though. The history of programming dates back to 1940s, and became more popular when the Internet has become accessible for the whole world. So we can say that we have ca. 30 years of experience in developing software as humanity, which is really little.
That is one of the reasons why we often can’t plan the process of software development as we do when we build a house.
What is a scope change?
A project’s scope is the totality of requirements, goals, costs and resources. The scope is often defined early on during the process of software development, based on what we know we want to build.
A scope change is any change of the requirements, goals or resources, which often has an impact on the costs and deadlines.
Why would one want to change anything?
As we go, we gain more knowledge about the problem we want to solve with our software. We often discover that we haven’t planned everything perfectly and it would be much better to change a certain part of the project/product.
One can also refuse to adapt to the circumstances, but then you often end up with something that you know is not optimal for your needs.
How to deal with scope changes?
As a software house we often face changing needs/wishes from our clients. We understand it perfectly, as we work closely together with the businesses and see that often a change has to be made – because some of the problems have changed or we got more information about it than we had in the beginning.
Now, there are two cooperation types: Fixed Price and Time&Materials. We prefer the latter, because then we can be truly agile together with the client and use our time to solve a problem in new or changed circumstances. In the first one, it is really important to carefully write down a project’s specification and this way describe the scope before starting. Then, during the process, if the client changes the requirements, it is the Project Manager’s job to handle the change and make an agreement with the client about the new goals of the project. Keyword here is: Process.
First thing and the most important one is understanding the reason of change. Is it a new ‘nice to have’ feature or is it really essential? If the PM doesn’t understand the reason of scope change, how is he going to communicate it further to the team?
The second thing which has to be considered is rejection of the change. Sometimes the client doesn’t understand the technology or the process and the new costs would be unbearable. Clear communication is key to cover all aspects of the change.
Imagine you agreed with someone to plant 2000 apple trees. You have already bought all the seedling and planted 500 of them, when the client wants to have cherry trees instead – but he hasn’t visited the orchard and doesn’t know how much effort it is to change it on this stage.
Third thing is to measure the impact of the change on other aspects of the project. If we change X, maybe we should also change Y? Document it, and again, communicate clearly with the client how big the change is going to be. If it affects the budget, it will probably also affect the schedule. Although it seems obvious, a clear communication is important.
Read about the key to the success of the project – by Oskar Poprawski.
Effective communication at any point of the project is essential to succeed.
Want to talk with us about your project’s scope?