By an end user we mean a person or a group of people who is going to be using the IT system after implementation and is imposing major functional requirements. If you fit this description or manage projects, then this article will be useful for you.
Earlier on, we’ve been involved mostly in office workflow automation projects. Now our customers turn to us to automate individual business processes. This is how we collected a portfolio of automation projects in such areas as audit, corporate governance, HR processes, contractual and procurement document flow, judicial activities and even processing of suspected bank fraud.
We use our BPM platform, Docsvision, for these purposes, but these recommendations can be applied to any other processes and platforms.
Step #1. Collect Information
Collect comprehensive information from the following sources and study it to evaluate its scale:
- contest documentation;
- technical requirements;
- information about contractor;
- project duration;
- which departments/subsidiaries are involved;
- information about a business process to be automated (how it is held and regulated now, how relevant it is);
- current system condition (for example, if you change an old system to a new one).
Step #2. Identify Stakeholders
If project managers (PM) read this article (we hope so), they are aware of this phrase. Identifying stakeholders is usually their responsibility. But why do we recommend end users do it? This is because they know the internal structure of the company much better and surely know how coworkers’ interests align.
There is an established classification in project management textbooks which helps to take into account all stakeholders into the process. We’ll leave it for PMs, and advise end users to answer the following questions to make up this list.
- Who will be affected by project implementation? Who will have to share something (budget, resources, time)?
- Who will take part in the project during the industrial exploitation (when everybody will already use the system)? Whose workflow will change after its implementation?
When the project gets started officially, don’t forget to inform all these people about it, set the aims of the project, deadlines and participants.
Later on, get back to that list and plan your actions according to the interests of stakeholders listed. You need to find a way to understand when and how to involve each of them into the project, and how to present information to them.
Step #3. Find a Project Manager
A customer must have a project manager on his side. A contractor’s PM cannot fully replace it and is likely to miss deadlines.
A project manager must be experienced in managing projects and it cannot be replaced even by dozens of textbooks. An accountant with good organizational skills won’t suit to it as well. If we speak about an IT project, it’s highly desirable for a customer’s PM to be an IT specialist. If he isn’t, bring one more person from the IT department to your team.
Without him your timeframes will be increased by 4 times! It’s better to spend your energy, time and influence to take this person from project office or to hire one by any means.
And when you find him, make sure he has done steps 1 and 2.
Step #4. Appoint a Working Group
A working group is a group of people who will formulate system requirements: functional and technical.
Ask your PM to help you appoint a working group, based on your stakeholders’ lists (see step 2). By the way, one person can combine several functions. While appointing, don’t forget that a group of more than 10-12 people is hard to manage.
A working group should always include the following members (apart from an end user and a PM):
- Process Owner. There has to be a person who will definitely say what is needed and what’s not, who will solve all contradictions in requirements and change the process after system implementation, if necessary. Usually, it’s the head of department whose processes are automated: e.g., head of Business Administration Department for office workflow automation, director of internal audit for financial and economic activities audit and so on.
- The department team members who will use the system, who have worked in the company for a long time and know how the business process in details. It would be great to have people who have worked in similar systems or have taken part in automation system requirements formulation. If you have such people in a company, they should be in a team!
- Third-party company representatives. If an automated process also affects other companies (for example, their employees are about to work in the system), don’t forget to involve them. But do not call too many of them and remember not to collect more than 10-12 team members.
- IT security specialists. They are must have! The earlier you call them to take part in the project, the better.
- IT Department representative. You will need him to provide capacities for a new system, set the infrastructure, network bandwidth and more.
Step #5. Take Part in the Kickoff Meeting
It would be great to enshrine the following on this meeting:
What do we want to achieve? And do the aims of the project stated in documentation match the real problem we want to solve? If there is nonsense in documentation (it happens sometimes), don’t hesitate to tell a contractor the truth. He will understand.
Stages and Terms of the Project
Let the contractor explain what will happen on every stage of the project. Point out when the working group is required to take action, how some specific stages will be organized (e.g. trials).
Final Project Documents
And a short explanation of what each document is meant for and consists of.
Timeframes of Project Documentation Approval
All members of a working group need to understand how many days they have to comment the documentation and how much time a contractor has to process the comments.
How often will the working group meet and discuss the project reports? Should all the employees in a company be informed about the project or is it better to leave to the working group only? Maybe, in this case, project news can be published in corporate media sources.
In what order should you inform the participants about requests for amendments if they influence timeframes, cost or content of the project? What actions are supposed to be taken after?
Other things (like working schedule, communication channels, etc.) are optional to discuss on the kickoff meeting.
Step #6. Take Part in Discussions Responsibly
While forming requirements, we recommend all members of a working group to stick to the following rules:
Do Not Keep Silence
If you have an idea during a discussion that there is a little point in the project that may influence it but might be irrelevant as well, don’t keep silence. It’s better to spend a couple of minutes to explain it and give a contractor an opportunity to decide whether it is worth considering.
If you have a doubt whether a contractor has understood the meaning of a point, you’d better spend a couple of minutes to explain it and make sure that all the participants understand everything in the same way.
Check the Documentation Completeness
When presenting the terms and regulations, make sure that the set of documents prepared for the contractor is complete. Let all the working group members check it. It’s a good practice to read these regulations once again before the start of the project and before discussions. It will help understand if they differ from reality or expectations.
Let the Contractor Take Part in the Process
You should let the contractor to take part in the working activity of the project. Let him watch this path from the beginning till the finishing stage of the process and realize how it goes. But it doesn’t replace interviewing and discussions and it’s better to be done after it.
Step #7. Negotiate Documents Carefully
It may sound obvious but is still important to highlight. Study all the project documentation, and do it very carefully. We don’t mean that a contractor may forget to include something that has been discussed (though it should also be checked). It will be much worse if the process is described in a wrong way.
Step #8. Run Real Tests
Using test data is not wrong. However, the most unpleasant inconsistencies come out when the system is working with real data. Yes, it requires more working hours, and there are never any resources available, but it increases the success of implementation extremely.
Let the employees take a real task and use it in the system together with the contractor.
Step #9. Don’t Be Afraid of Pilot Exploitation
You have to make project 100% perfect if you automate the work of aircraft dispatchers or something similar. In other cases, accept that the system will not be 100% ready when you start using it.
It’s sad. But the reality is that you will most likely have to start pilot exploitation when you haven’t completed everything. You may say that users won’t like it, and I will say that it will happen with a 100% finished system. To avoid this, you need to gradually prepare users to it by talking about the project in corporate media, newsletters, etc.
So you just need to have the courage to start.
Step #10. Finish the Project Gracefully
While implementing a project, keep in mind that you can’t cover everything at once. Do what you can do now. Leave the rest to the development of the system.
Trying to complete everything may turn the project into a long-term construction, which may not just miss the deadlines, but also won’t finish at all.
After the end of the project, hold a final meeting, summarize the results, assess the level of objectives achievement and discuss future plans.
All the above mentioned:
- Is applicable to all modern companies, large and small.
- Can be combined with flexible methodologies.
- Is based on personal experience, is not complete, but will definitely be supplemented.
- Is about to help the customer understand the contractor better and increase the chances of a mutually beneficial success.