Project Goals
When we started the project idea, way back in 2012 and earlier, we clearly realized the power of this idea and excellence of the solution we have imagined, and we have set several tough goals for ourselves. That were the goals that we pushed to the desired limits of good project management and proper software development.
Some of them you clearly see directly all the time in our product whitepapers. Some of them you can easily get when you read between the lines. Some of them are maybe still in you wish-list, but most probably they are already in our FURIA Project Backlog waiting to see the light in some of the upcoming versions.
But all of them have common last name – the first-class management tools, not just for the organization management, but for the organization governance.
In introductory chapters you have seen how FURIA interacts and how it can be used with different subjects and types of information. We will not stop there. What you can expect in further development is integration of other functionalities most relevant to management processes.
Customers can check back on Annual and Quarterly Project Plan and interact with R&D Team, so if there are some new opportunities for the customer – then the preparations can be made planned and timely.
Methodology
Our vision of good things gets out the standard box of software development. We see our software solutions as tools for getting us all better, productive, reliable, secure.
Our approach to the solution design goes from the natural human needs, not the process needs or the specific software requirements.
In communication about the customer needs, we insist on usage of everyday common language. English, Serbian, Greek – no matter, as long as it is simple and crystal clear. In that communication you will not need to write something as “Please, implement complexity and encrypted of credentials within application authentication”, rather “Make my passwords safe from breaking”. Or, you will not write demand “Audit supervisors need to have assigned all necessary permissions on the Findings”, rather “I, as an role of Auditor, want to have permissions (a) and (b), so then I can do the actions (x) and (y)”. Get it?
When we think of the solution, we follow certain set of rules simplified as this:
- We start with identifying the real needs, no matter how complex they are.
- Then we break it into crucial demands, the mandatory things and the principles.
- Then we do the Project Backlog.
- Then we use the Scrum.
- Then we split it into functional pieces of work.
- Then we run the Sprints.
- After each step we check back with customer course of our actions.
- Then we test. Again and again.
- Then we publish. And listen and act.
And then you smile happy and wait for more of it coming.
When publishing, we are following the logic than every distribution has to have fully tested and fully functional pieces of code, regardless of the size and scope of changes. This way you always get the current maximum from the application, at all the time.
The frequency the updates applying depends exclusively on your appetite and availability of your resources, unless you delegate maintenance process to the FURIA team and set agreement on the update rules, sit back and relax.
When we initiate some new ideas and improvements, we discuss it and evaluate with the customers. You are not forced by anything to accept them. However, we make sure that you properly understand the goals and the advantages, reflected in your world.
When some other customers initiate improvements or changes, the story is very similar. You choose what you like to implement, as long as the licensing policy is active.
The further development of the system is not and will never be the exclusive right of some privileged or preferred customer, although the special requests can be made to fulfill your specific requirements, e.g. to connect the system with your internal application or to created some reports specific to your organization solely.