Hadrone PPM is a ready-made (boxed) software that is tailored to the Client's needs during implementation through proper configuration. The implementation of a ready-made product offers many benefits (including faster and cheaper implementation and maintenance), but it may also have limitations when it comes to accommodating the specific needs of a given organization.
When using ready-made software, it is particularly important to understand its business architecture and the scope of its functionalities, so that we know what to expect from it now and how it may evolve in the future. Implementing a PPM system is a significant organizational change, so we always recommend testing the solution (or several) before making a final decision. We write more about this in the article „Can I test Hadrone PPM before purchasing (pilot)?".
However, the current needs of the organization are not everything. The question arises, how does the ready-made product, such as Hadrone PPM, evolve over time to accommodate changing Client needs? And what influence do Clients have on these changes? In our case, this influence is very real, in contrast to solutions from other global vendors with whom we compete.
Customer-driven development is embedded in our DNA. When a product is developed, the author initially has an idea and shapes it accordingly. This was also the case with Hadrone PPM – we noticed a gap in the market and decided to create a product that would be comprehensive enough to meet the needs of demanding organizations, while being easy to implement and user-friendly.
After some time, as the number of users of the software increased (with Hadrone PPM, there are thousands of users), we started receiving more and more detailed needs and development ideas from users, arising from various situations organizations face. We greatly value this input and are happy to use these suggestions, as we wouldn’t have been able to come up with everything on our own. Over time, our role has also changed. We now listen to client needs, standardize them and implement features that will be applicable in the specific situation as well as in many others. Often, we get feedback from Clients that not only did we help them in that specific situation, but we also anticipated several other potential scenarios. :) So, we are building universal mechanisms that allow us to adapt to different circumstances.
One example of this approach is the stages of projects that correspond to the project lifecycle. Our Clients expect that in one place in Hadrone PPM, they will be able to manage and monitor the entire portfolio of projects, which may include very different types of projects: IT, investment, renovation, R&D, marketing, etc. Each of these projects has different stages that correspond to the key steps in that type of project. At one point, we introduced the functionality of project stage templates, configured individually for each Client. A given template is created for a specific type of project and includes stages that are characteristic of that type of project. Within the portfolio monitoring, we can simultaneously see all the projects, taking into account their individual stages.
Of course, we are also continuously developing new functionalities, where the inspiration comes from our team. Here too, it often turns out that a Client receives a new feature they hadn’t thought about the day before, but today can’t live without it. :)
How do we develop the Hadrone PPM system to meet the needs of our Clients? In three ways:
- Hadrone PPM development roadmap for the year,
- ongoing changes submitted by Clients,
- development triggered by a specific Client.
Hadrone PPM development roadmap for the year
Work on the Hadrone PPM roadmap starts in October and the final roadmap for the year is published in January or February. The roadmap includes a list of features that will be introduced in the various quarters of the year (we publish 4 new versions of Hadrone PPM each year).
The steps for working on the roadmap are as follow:
- Collecting needs from Clients.
- Preparing proposals for changes and new features for the roadmap.
- Clients voting.
- Preparing and communicating the roadmap.
Roadmap planning begins in October of each year. At that time, we send our Clients a request to submit proposals for changes and new features that should be included in Hadrone PPM in the upcoming year.
Once we receive the Clients' development needs, we organize and standardize them, sometimes asking for additional details. Based on this, we create a list of proposed changes and new features for clients to vote on. These proposals also include our own ideas that Clients can later evaluate.
In the third step, Client representatives vote on the proposed changes and new features, ranking them from most to least important. This creates a ranking list, which serves as the starting point for creating the Hadrone PPM development roadmap for the next year.
The fourth step involves our analytical work, resulting in the final roadmap. We measure each change and prioritize them, ultimately grouping them into four releases planned for the year (roadmap planning and monitoring is done in Hadrone PPM itself). The final roadmap is sent to our Clients, so everyone knows when and what changes to expect in the software. This allows our Clients to prepare in advance to take advantage of the new features in Hadrone PPM.
Ongoing changes
The roadmap outlines the main changes to be implemented in Hadrone PPM for the year. However, these are not all the changes we implement. During the year, our Clients continuously submit smaller and larger change requests. Some of these are implemented in the "interim" periods (even small changes are often very important to our Clients), while others wait for the roadmap planning for the next year.
Additionally, technical changes are made to ensure the proper level of security and performance of the application and to prevent the accumulation of technical debt.
Development triggered by a specific Client
In principle, Hadrone PPM is developed according to the roadmap, taking into account smaller changes made continuously. However, exceptions do occur.
For new Clients, it sometimes happens that Hadrone PPM meets most of their needs, so the Client would like to use the ready-made solution. However, there are also important needs that Hadrone PPM currently does not meet. Sometimes a Client really needs a specific feature that is not as important to most Clients and therefore hasn’t appeared on the roadmap. In other cases, a pressing need arises during the year. Is it possible to implement such changes "outside the roadmap"? Yes, although it doesn’t happen often.
In such cases, we first analyze whether the idea for the change or new feature aligns with the domain of our software.
For example, we do not intend to add a customer invoicing feature for projects – Hadrone PPM can provide information about how many hours someone has worked on a specific project and based on this, the appropriate invoice can be issued in the accounting system. The data flow between systems can be automated using API and webhooks.
If the scope of the proposed change fits within the domain of our software, we agree with the Client on how they may participate in the development costs of such functionality. Once the change is implemented, it is available to all Clients, not just the one who initiated it. We make sure that the product remains consistent – of course, there is no obligation for Clients to use new features if they do not find them necessary. If we don’t configure them, they often won’t even appear in the application interface.
