In this article, I would like to combine two different subjects - ERP integration and the Agile approach - because they work well together.
Let’s start from a learning metaphor. Integration of a business management system has something in common with how a human learns new skills. As a result of management software integration, the enterprise being automated gets new workflows, starts relying on new reports and changes roles of some departments - this is very similar to a human getting professional expertise.
The enterprise is learning new "habits". This process requires gentle treatment. Thinking about it, I can see parallels with my hobbies. I like guitar and martial arts; in both areas teachers arrange lessons in an order that helps a student to learn new techniques and then immediately integrate these techniques in their improvisational activities. If you have another hobby, you may see the same methods applied by those who teach the stuff.
Now let me move to the ERP subject and go through the process of step-by-step software integration.
From development to integration
There is a commonly used procedure suitable for custom business management software roll-out. The procedure assumes that the project should evolve in stages or so called releases. Every release includes the following steps:
- development of a specified set of features;
- immediate roll-out of the set of features;
- receiving user feedback.
So, we are talking about the same loading - integration approach again. The first activity should be performed by the development camp, the second one - by the customer. The feedback should be processed by both sides. As a result of the processing, a new set of features appears and the three steps are repeated again.
Very often, roll-out and collection of feedback appears to be more effortful and valuable than the development work. "Applying techniques" takes more time than "growing muscles".
This is a nature of ERP integration that should be acknowledged by any enterprise or customer who is willing to set up a management system.
Do things effectively
Those who have experience working with agile projects could notice that the procedure in the previous paragraph is very similar to practices recommended by the agile software development methods:
- the whole process is split into releases;
- feedback plays a significant role;
- the procedure is repeated until the desired result is achieved.
Now let's remember what the agile authors say and think about how we can make the whole process more effective. The approach recommends:
- starting with a small investment and adding more resources as the integration progresses;
- building the core architecture as part of the very first release;
- making releases often. From our experience, development cycles from 2 to 4 weeks long work best because they allow the developers to keep related information actual and make small adjustments on the fly;
- moving the most essential features to the beginning of the plan. This recommendation assumes either moving features to earlier releases or making them a higher priority within the current release.
Some other areas of business
The approach described above is not only applicable to ERP or business management systems integration, but also to other custom projects that assume input from users.
A good example of our successful custom project that incorporated the agile methods is eBookingServices. Its owner Robert Den Hollander did amazing job launching the project in stages. Positive experience is always worth to share.
The trick is that the project is a collaboration platform. Collaboration platforms are similar to social networks. Customers who develop such projects should overcome a network effect. It means that the software becomes valuable for users after it already has users - but how to get first participants? And how many people should be brought to the system before new visitors will come and join it voluntarily?
I still wonder how Robert managed to do that. I do not know where he took first providers and clients. I just know that he hired at least 40 to 50 managers to make cold calls, perform content management, posting new deals and be ready to resolve issues.
At the same time, he had only 2 (two) developers! His project management style was very strict. He requested only features he considered essential which helped us to make releases often.
This illustrates a functioning proportion of how much development is required to launch a project compared to the amount of integration work. Very often, projects that appeared to be unsuccessful simply lacked releases and feedback or their development iterations were too long.
When talking to new customers, I often feel that my mindset is different from theirs. Usually, they know what they need from development very well. But they are not aware of how much effort the job requires in terms of management.
I hope this series of articles helps people effectively arrange things when developing and integrating business management systems or another custom software. Let’s repeat what we have learned so far.
Project owners have their own responsibilities which can be even more significant than responsibilities of the development camp.
One of their main responsibilities is to decide what is valuable and what is not from the business perspective.
It is very appropriate to follow the agile principles while rolling out a management software. In other words, it is reasonable to grow the project in stages, collect feedback and make adjustments in the plan.
Next time we will talk about planning game and about nature of estimates customers receive from the camp of development. I hope to present some interesting stuff, so stay tuned!