Many project owners do not have a clear vision of the way their software will be rolled out. They focus on development instead of solving business problems. Then, when it comes to launching the product, they rely on some "magic" behind software development that should allow the software to be integrated in the business.
When I was an ERP roll-out engineer, my job was to help people launch different automation systems. Albeit these products were promoted as ready-to-use, they often were not tailored to specific business needs, users appeared to be not ready to use them out-of-the-box, reports were not good enough, so the customer needed someone to help with that. The ERP infrastructure produced me, a roll-out engineer - a specialist who could get into the company’s problems, customize the product and eventually launch it.
As it is mentioned in the previous article, ERP systems are more specific software than many people think, but general principles of rolling it out are the same as for smaller management systems. Let me briefly describe what an owner of this type of project should deal with when going live.
Not a long time ago I had a conversation with one of our ex-customers who wanted to refer a project to Anadea. The project was a complaints management system meant for government ministries in his country. They arranged a request for tender and the referrer wanted us to apply to it.
He said that the government wanted the selected developer to be present at their offices to do the job. I felt some misconception about what he understood by "doing the job" and decided to clarify.
"Our developers are developers", I said. "They are focused on their tasks. They are not taught to be roll-out engineers, gather requirements from people, teach them to use the system and so on. We can develop the system. But we need a person on the customer’s side to do all the above".
He did not understand. He asked if we could hire such a person and do all work ourselves. So, I had to explain the difference between roles of Business and Developer.
I said, "The government will have to give that person an appropriate power. It would be better if the manager was someone from their community. This way, he would know many aspects of the everyday activities at the offices. He would be a field expert".
So, let’s conclude that there are two different roles - Developer and Business - which are focused on different tasks and have different responsibilities. Now I will explain why the developer should not take on the responsibilities of the business more thoroughly.
Once I rolled out a paperflow automation system at a branch of Ukrainian Ministry of Agro-industry. It was the toughest project I ever launched. It took a year to go live and all of us who worked there felt like torn to pieces eventually.
At the same time, all our projects rolled out at private companies and enterprises were successful. The reason was the absolutely different attitude on the part of the customer.
Owners of private enterprises:
- pay their own money;
- are interested in success;
- try to get bigger value for less investment.
On the contrary, offices belonging to government:
- do not pay out of their pocket;
- interested in starting a project as long as they get part of the funding provided by the government;
- do not give a damn to the project value after it is started.
I am telling that not to provide another opportunity to criticize the government, but because there is something a project owner can learn from this. Here is what I would like to highlight: there is an explicit dependency between success of the project and how much the customer wants to do for it personally.
That sounds too obvious, doesn't it? Let me be more specific. To successfully launch a software product at an enterprise, the owner should assign (or hire) a manager. He can be that manager himself if this work is too important to allocate it to anyone else.
That manager can be called a "business lead" or a "head of roll-out" or whatever. At Anadea Inc we call this person simply a "customer" because for us he is the main person to collaborate with.
That type of managers have specific responsibilities at their company. They should:
- be personally responsible for success of the project;
- gather requirements from all departments of the enterprise;
- give assignments to the camp of Development;
- have power to penalize employees who sabotage the roll-out;
- maintain the rolled out software full-time.
Obviously, such a manager cannot be an employee of the development company. Developers come and go while the head of roll-out should stay at the enterprise after the software is launched. He should have a real interest in getting maximum value out of the management system and enough power to ensure seamless work of the product.
We did not have that manager when dealing with the Ministry of Agro-culture. It led to a great disaster. The executive who was the mastermind of the project disappeared right after work was started. I was left face to face with several employees I had to force to use a new paperflow automation system.
Imagine the situation I found myself in. I could gather requirements. I could customize the system and write code facilitating work of the Ministry. I could teach people to use the software.
But nobody cared. Employees thought I was there to give them additional work and potentially replace them by a software (what nonsense! but employees at enterprises tend to think so). The head of the department was 8 months before a retirement, so she did not want any problems to appear until she is out. She explicitly asked me not to trouble her before that time!
I couldn’t force anyone to anything because I was not their chief. The real chief was away all the time. Eventually, he got a promotion and moved to another Ministry. The new head did not know anything about the project.
Oh, yes! They had an IT department. But they were very busy with receiving and printing emails, so they could not help me in any case.
It is worth mentioning that the project could not be ceased. My company signed a contract with the government and received a prepayment, so ceasing a project could draw us into a real trouble.
Ouch. More than 8 years have passed since that but I cannot mentally return to that point in time without feeling despair. It took a year to somehow finish the project and sign all required work completion certificates.
They called me on my cell phone two years after the project was rolled out and asked how to move old documents to the archive. I told them that I joined another company (Anadea Inc), so they would rather forward this question to their executive manager responsible for automation software.
Customers tend to transfer responsibility to the camp of development. In their turn, developers prefer to solve all problems by writing more code. This is how they see the life. Obviously, not all problems can be solved that way.
In particular, writing code does not help when it comes to rolling software out. Top managers of manufacturing enterprises with ERP systems know that the amount of work needed to install the software and teach the staff to properly use it is greater than the amount of software customization. They know they will have to live with the automation system after the developer completes the customization and switches to other projects.
The same is valid for projects smaller than ERP. When a project owner wants to integrate a business management software in their company, the best result is achieved when the company forces the development camp to solve their biggest problems in the simplest way possible. By the way, this is exactly what the agile software development principles recommend.
They should show a real interest in making their business more productive and be ready to do whatever it takes on their side.
There is a very effective iterative approach which can be applied when rolling out a management software. We will certainly talk about it in the next article.