Quick guide to optimizing project scope

Every day we deal with many doubts from our clients, and one of them is often the question: "What has the most crucial impact on the project costs?" The most obvious answer is project scope. The amount of investment in the project depends largely on how many functionalities the client wants to receive and how complex they are. On the other hand, a project that implements nothing is not needed by anyone. So how can we optimize the scope of an IT project?

Focus on the business goal

For the project to be effective, the business goal must be at the center of our considerations. All our conversations with clients begin with an attempt to understand what goal they want to achieve and what their business is about, as well as the key factors necessary to achieve those goals. Only by understanding these aspects can we support the client in optimizing the project scope, i.e. determining which functionalities are crucial and essential, and which can be cut, limited, or delivered later without compromising the project's success. We often encounter resistance at the beginning, because of course everyone wants to achieve 100% of what they have planned. However, it is worth remembering the Pareto principle (80/20), which states that 20% of efforts yield  80% of valuable results. Therefore, it is necessary to identify the part of the scope that will bring us the greatest and most important effect, and look for optimization in functionalities that do not provide such great benefits and are not strictly required for formal and legal reasons. We all operate in an environment that sometimes forces us to comply with certain formalities that do not provide tangible benefits, but failing to consider them significantly increases investment risk. Examples of such formalities in the area of IT systems are the principles of GDPR, collecting required consents from users, or requiring acceptance of the service terms.

 
Don't create unnecessary functionality

Another argument in favour of focusing on key requirements is experience, which shows that in every IT system there is a certain range of functions that have been built and then either are not used at all or are used by users so rarely that that the investment in their implementation will never pay off. It is often difficult for the creator of the concept of a given system to break away from his own vision and look at the system through the eyes of other people, which is why a joint analysis of requirements with someone from the outside, in terms of achieving a business goal, is so important.  This is especially true if we are dealing with complex functionality that will be very time-consuming to implement. For example, we once built a time tracking system. The main idea was to create a tool that would allow for easy reporting of work on individual tasks and the generation of task summaries in various perspectives, needed to verify work efficiency and settlements with clients. One of our investor's requirements was to add functionality that would provide him with greater control over the editing of previously entered tasks. It worked in such a way that if an employee entered a task and later wanted to edit it, the change was not immediately saved, but went to a separate list of changes for approval by an authorized manager. Implementation of this functionality turned out to be quite time-consuming due to specific requirements regarding the way of showing differences in two versions of the entry and the impact of these tasks on the current reporting of working times. The development of this requirement delayed the system’s launch, and after some time of system operation, it turned out that this option was hardly ever used. Why? The volume of edited tasks was so high that the person who was supposed to be responsible for reviewing and accepting these changes did not have enough time to do it on a daily basis. Effect – we created complex functionality that was practically not used and even made reporting tasks more difficult.

Build incrementally

To limit the occurrence of such negative effects, we offer our clients approach of incremental system development. We start building the system with the most important functionalities necessary to achieve business goals - the so-called MVP (Minimum Viable Product), and then we add further functionalities or expand and automate those that have already been implemented. This allows for faster commercial launch of the project in the base scope and earlier reaping of business benefits. Additionally, it allows to collect feedback about the system or product and improve it in subsequent stages (you can learn more about the advantages of the MVP approach in our earlier article "Should you be afraid of MVP?"). In virtually every project, it is possible to select a range of functionalities to be implemented or developed after the commercial launch, i.e. up-selling processes for the main product sold in the system, processes for changing or maintaining the service after the initial fixed-term contract, extensive complaint handling processes (often, a simple complaint form, operated by a dedicated person, or even sending the complaint via a dedicated e-mail address is enough to start), some more detailed reports.
Moreover, it is worth considering the profitability of building a system that is fully configurable by the business administrator. In every IT system there are parameters that change frequently and must be easy to change, e.g. the prices of products in an online store. For such parameters, it is worth implementing from the beginning mechanisms that allow for easy change by the business administrator. Unfortunately, clients often fall into the trap of wanting to change many system parameters themselves, without having to ask the developer to change them. It may appear to be a good idea, to become independent from the work of a programmer and leave the entire configuration in the hands of the business. Sometimes, however, this leads to building very complex and time-consuming system administration modules that allow for fully flexible configuration. Why are these system elements so labour-intensive? Because frequently changed parameters create complex dependencies, and the investor usually wants the system to ensure that an inexperienced administrator does not enter incorrect data. This requires analysing and programming complex dependencies, often in a user-friendly interface. If given parameters are changed once every few months, once a year, or we do not know how often they will be changed, it is not worth investing in an extensive administration panel at the start. It is better to optimize the scope and agree with the software supplier on how to introduce such changes. Then, it should be verified on a commercially launched system for which parameters it is profitable to create easy business configuration options in the future.

Automate wisely

We often see a similar situation in the area of process automation. Many of our clients want to run their business using systems that automate as many business processes as possible. We understand this perfectly, because who would want to do something that the system can do for us? Nevertheless, it is worth considering whether this is always a good idea. Some business processes are very complicated, based on complex decision-making algorithms and have numerous alternative paths. Programming all these options can be time-consuming because when creating a system we have to tell the system how to proceed in each possible path. This is often easy to define for the most obvious options, but much harder for the rare ones. Clients then say "but that's an unlikely case." We believe, but the system must know how to operate in this situation. In such cases, we often propose a compromise solution, we completely automate the most common cases for which the path of action is clear, and we redirect the unlikely and time-consuming ones to be handled by a human. Not because it cannot be completely automated, but because such an investment is simply not worth it. Why add, for example, 2 weeks of programming to handle a case that appears once every few months and can be handled by an employee in 15 minutes? Such scope optimization alternative is worth considering whenever the development of single functionality seems very time-consuming.

To sum up, it is not always worth implementing 100% of the originally planned scope so as not to waste resources on useless functionalities. This is especially important when we are dealing with an innovative idea or a completely new system. It is worth focusing on the business goal and the minimum solution that will enable it to be achieved in order to test the business concept. Then, based on real data, key functionalities that bring the greatest business value should be developed and processes for which it is profitable should be automated. Scope optimization is the key to the success of any IT project!

Author: Alicja Polak

#ITProjectOptimization #ScopeManagement #MVP #ProcessAutomation #ProjectCosts #BusinessObjective #SoftwareDevelopment #BusinessEfficiency #Pareto8020 #ITInvestments