Tips for a functional customer. Press Δ to read
Sometimes, there are not enough prompts in the course of fulfilling the mission of an IT project - “press W to move forward . ” In order to somehow help those who were in the place of a functional customer (a lot depends on him on the project), we collected the top 10 tips that will help you successfully accomplish the mission, codenamed “Implementing an Automated System”.
By functional customer (FZ), we mean a person or a group of people who broadcast the basic functional requirements for an IT system. If you fall under this description, or manage projects, then the article will be useful to you and, we hope, interesting.
This article is the "cry of the soul" of one of the project managers of our company Digital Design Sasha. Sasha made a lot of good and very good projects, so we believe him and heed. He knows exactly how to successfully close the project. Sasha shared the algorithm with us, and we share with you.
Earlier in Digital Design there were more projects on office automation, now the vector has shifted towards individual business processes. So have accumulated stories about projects for the automation of audit, corporate governance, HR-processes, contractual and procurement documents, claim-related activities and even the processing of suspicions of bank fraud.
We do it all on Docsvision's native BPM platform, but these recommendations apply to automating any other process using other platforms.
To be fully prepared and assess the scale of the project, you need to gather comprehensive information and study it:
Aware - it means armed. That's just not to fight to prepare. If the war, then consider the project can already be buried.
If the RP read this article (and we would like to believe in it), then they have already filled this phrase with teeth. As a rule, it is the PM that is responsible for identifying the stakeholders.
But why do we recommend this to a functional customer? Yes, because he knows much better how things are organized within the company, where and how the interests of colleagues overlap.
In the project management textbooks there is a classification that helps not to miss any of the stakeholders - we’ll leave it for the RP and the Federal Law, in order to make this list, it’s better to answer these questions in as much detail as possible:
When the project receives an official start (by order, for example), it is important not to forget to notify all these people, declare the goals of the project, set deadlines and introduce the participants.
Further, in the course of the project, it is necessary to periodically return to this list and plan your actions taking into account the interests of the parties listed in it. For each of them, you need to understand how and when we should involve them in the project, in what context this should be done and under what sauce they should be given information.
On the customer side should be your project manager. Believe me, the RP contractor will not be able to fully replace it. At least, the deadlines will not be exactly met, if only the contractor will be engaged in the whole organization of work.
The RP must be the project manager, i.e. to have project management experience is a unique entity that cannot be replaced even by a bookcase of textbooks. And an accountant with good organizational skills here will not work. If we are talking about an IT project, it is highly desirable that the RP of the customer understood the IT field. If this is not the case, let him take a person from the IT department into his team.
Without this golden man, you can immediately increase the planned deadlines four times! It is better to spend your strength, time and influence in order to isolate this person from the project office (if you have one) or to find and hire them by any other means.
And when you find it, make sure that he does step 1 and 2.
The working group is those who will formulate system requirements, both functional and technical.
It is necessary to determine the working group together with the RP, based on its own and its lists of stakeholders (see p.2).
In determining the working group, it should be guided by the rule that a group of more than 10-12 people is difficult to manage, and it will be difficult to reconcile interests in such a group. (If KPI is to finish the project before the end of the current year, then 10 is the limit).
The working group must include (except for the Federal Law and the RP):
By the way, one person can combine several functions.
The working group, as a rule, is also fixed by an order (decree).
In general, this is the task of both project managers and in many respects is a squeeze of the “Project Charter” document, which they prepare at the start of the project.
And here’s what it would be good to declare at this meeting:
Project goals.
And what goals we, in fact, want to achieve. And do the project objectives stated in the documentation coincide with the real pain that we are eliminating? If the documentation is written nonsense (it happens), then do not hesitate to tell the contractor the truth. He will understand everything.
Stages and terms of the project.
Let the contractor tell you what will happen at each stage of the project, when the active participation of the working group is required, and when not, how this or that work will be organized (tests, for example).
The resulting project documents.
And in a nutshell, what each document means and what it is for.
Terms of coordination of project documentation.
It is important that all members of the working group understand how many days they have to make comments and how long the contractor has to process them.
Informing about the project.
How often and in what format will the reporting meetings, project progress reports take place? Who should be informed: only the working group or all employees of the company, if the project, for example, affects the entire organization. In this case, you can publish news on the progress of the project in the corporate media.
The procedure for making changes.
What is the procedure for informing participants about change requests that could potentially affect the timing, cost, or content of a project, and what actions should be taken after informing?
For the remaining sections of the installation presentation, add salt and pepper to taste (work schedule on the project, communication channels, etc.)
When forming requirements, all members of the working group are recommended to adhere to the following rules:
Long thought, whether it is necessary to declare axioms ....
It is necessary.
Project documents must be studied! Study carefully and in detail. And also to check that all the members of the working group do this carefully and in detail. And the point is not that the contractor is so bad and may not write what was discussed (although it is also worth checking for sure), it will just be much worse if the process is described incorrectly.
Tests on test data is not bad. But all the most unpleasant inconsistencies come out when the system works with a real case. Yes, it is labor-intensive, and there are never any resources available for this, but this extremely increases the success rate of implementation.
Let the employees take the real task and, together with the contractor, go through the PME (program and test method) with the real scenario.
Pro excellent syndrome have heard? They should get sick if you automate the process of dispatching takeoffs and landings at the airport or something similar. In other cases, take for granted that the system will not be 100% ready at the time of the start of operation.
Yes, it's sad. Yes, integrators need to be showered with rotten tomatoes and say that this should not be so and, in general, “are you testing your system or how ...” (c) . But the reality is that going into pilot production is likely to be raw. On the objection that the users will not like it, I will say that this will happen with the 100% ready system. To avoid this, it is necessary to gradually prepare users for a new life and for stress, talking about the project in corporate media, newsletters, etc.
Therefore, you just need to take courage and start.
When you run a project, you need to remember that you can not cover everything at once. Do now what you can do now. Leave the rest on the development of the system.
This is where the idea of future contracts, a sitting on a “financial needle”, etc. can arise. But it is not. Attempting to embrace the immense has a very high risk of becoming a longevity, which may not just disrupt time, it may not end at all.
After the project is completed, it is important to hold a closing meeting, summarize the project results, assess the level of achievement of the goals and discuss further plans.
The above:
By functional customer (FZ), we mean a person or a group of people who broadcast the basic functional requirements for an IT system. If you fall under this description, or manage projects, then the article will be useful to you and, we hope, interesting.
This article is the "cry of the soul" of one of the project managers of our company Digital Design Sasha. Sasha made a lot of good and very good projects, so we believe him and heed. He knows exactly how to successfully close the project. Sasha shared the algorithm with us, and we share with you.
Earlier in Digital Design there were more projects on office automation, now the vector has shifted towards individual business processes. So have accumulated stories about projects for the automation of audit, corporate governance, HR-processes, contractual and procurement documents, claim-related activities and even the processing of suspicions of bank fraud.
We do it all on Docsvision's native BPM platform, but these recommendations apply to automating any other process using other platforms.
Step number 1. Collect information
To be fully prepared and assess the scale of the project, you need to gather comprehensive information and study it:
- contract,
- tender documentation,
- technical task,
- information about the contractor
- project timeline
- which units / subsidiaries are involved,
- information about the business process to be automated (as it is being implemented, what regulations are documented, how relevant they are),
- current state of automation (if, for example, you change the old system to a new one).
Aware - it means armed. That's just not to fight to prepare. If the war, then consider the project can already be buried.
Step number 2. Identify stakeholders
If the RP read this article (and we would like to believe in it), then they have already filled this phrase with teeth. As a rule, it is the PM that is responsible for identifying the stakeholders.
But why do we recommend this to a functional customer? Yes, because he knows much better how things are organized within the company, where and how the interests of colleagues overlap.
In the project management textbooks there is a classification that helps not to miss any of the stakeholders - we’ll leave it for the RP and the Federal Law, in order to make this list, it’s better to answer these questions in as much detail as possible:
- Who will be affected by the project during implementation? Who will have to move? Who will have to give something (budget, resources, time)?
- Who will be affected during commercial operation (when will everyone use the system)? Whose work will change after implementation?
When the project receives an official start (by order, for example), it is important not to forget to notify all these people, declare the goals of the project, set deadlines and introduce the participants.
Further, in the course of the project, it is necessary to periodically return to this list and plan your actions taking into account the interests of the parties listed in it. For each of them, you need to understand how and when we should involve them in the project, in what context this should be done and under what sauce they should be given information.
Step number 3. Find RP
On the customer side should be your project manager. Believe me, the RP contractor will not be able to fully replace it. At least, the deadlines will not be exactly met, if only the contractor will be engaged in the whole organization of work.
The RP must be the project manager, i.e. to have project management experience is a unique entity that cannot be replaced even by a bookcase of textbooks. And an accountant with good organizational skills here will not work. If we are talking about an IT project, it is highly desirable that the RP of the customer understood the IT field. If this is not the case, let him take a person from the IT department into his team.
Without this golden man, you can immediately increase the planned deadlines four times! It is better to spend your strength, time and influence in order to isolate this person from the project office (if you have one) or to find and hire them by any other means.
And when you find it, make sure that he does step 1 and 2.
Step number 4. Define a working group
The working group is those who will formulate system requirements, both functional and technical.
It is necessary to determine the working group together with the RP, based on its own and its lists of stakeholders (see p.2).
In determining the working group, it should be guided by the rule that a group of more than 10-12 people is difficult to manage, and it will be difficult to reconcile interests in such a group. (If KPI is to finish the project before the end of the current year, then 10 is the limit).
The working group must include (except for the Federal Law and the RP):
- The owner of the process (if it is not the Federal Law) is a key success factor. There must be a person who will unequivocally say what is needed and what is not, who will resolve all conflicting requirements and who may decide that the process will be changed after the introduction of the system, if necessary. As a rule, this is the head of the department to which the automated process belongs: director of the department of case management, if it comes to paperwork; Director of Internal Audit, if we are talking about audits of financial and economic activities, etc.
- The specialists of the department who will use the system, who work sufficiently in the company and know how the automated business process works, know where it differs from the documented procedures, and what “loopholes” exist in it ... It’s great if there are those among them ever worked in such a system before, or already participated in the formation of requirements for an automated system (not necessarily even a similar one). If there is such - in the team!
- If the automated process goes beyond the organization’s boundaries (for example, representatives of subsidiary companies will work in the future system), then, according to the principle described in the paragraphs above, representatives of third-party interested organizations should be pulled, without forgetting the rule of 10-12 participants.
- Safes must have! The sooner you connect them to the project, the better.
- A representative from IT will be required when it comes to allocating capacity to host the system, organization of infrastructure, network bandwidth, etc.
By the way, one person can combine several functions.
The working group, as a rule, is also fixed by an order (decree).
Step number 5. Participate in the setup meeting
In general, this is the task of both project managers and in many respects is a squeeze of the “Project Charter” document, which they prepare at the start of the project.
And here’s what it would be good to declare at this meeting:
Project goals.
And what goals we, in fact, want to achieve. And do the project objectives stated in the documentation coincide with the real pain that we are eliminating? If the documentation is written nonsense (it happens), then do not hesitate to tell the contractor the truth. He will understand everything.
Stages and terms of the project.
Let the contractor tell you what will happen at each stage of the project, when the active participation of the working group is required, and when not, how this or that work will be organized (tests, for example).
The resulting project documents.
And in a nutshell, what each document means and what it is for.
Terms of coordination of project documentation.
It is important that all members of the working group understand how many days they have to make comments and how long the contractor has to process them.
Informing about the project.
How often and in what format will the reporting meetings, project progress reports take place? Who should be informed: only the working group or all employees of the company, if the project, for example, affects the entire organization. In this case, you can publish news on the progress of the project in the corporate media.
The procedure for making changes.
What is the procedure for informing participants about change requests that could potentially affect the timing, cost, or content of a project, and what actions should be taken after informing?
For the remaining sections of the installation presentation
Step number 6. Interview Responsibly
When forming requirements, all members of the working group are recommended to adhere to the following rules:
Don't be silent
Когда во время интервьюирования в голову закрадывается мысль, что в процессе, о котором идёт речь, есть исключение или какой-то малюсенький нюанс, который «вроде не влияет», не надо молчать. Лучше потратить ещё пару минут на изъяснение и дать возможность подрядчику оценить, влияет это или нет.
Be empathetic
Да, да, чутким. Если вдруг возникает сомнение, что подрядчик правильно понял заложенный смысл какого-то предложения, то лучше потратить ещё пару минут на объяснение и удостовериться, что все участники одинаково понимают сказанное.
Check the completeness of the documentation
При предоставлении регламентов нужно убедиться, что комплект документов, подготовленный к отправке подрядчику, полный. Пусть все члены рабочей группы проверят его целостность. Миллион случаев, когда какой-то регламент забывается и всплывает где-то на предварительных испытаниях.
Вообще, хорошая практика перед стартом проекта и началом интервьюирования перечитывать эти регламенты, чтобы вовремя понять, где они отличаются от реальности или от ожиданий, а затем подсветить эту информацию подрядчику.
Вообще, хорошая практика перед стартом проекта и началом интервьюирования перечитывать эти регламенты, чтобы вовремя понять, где они отличаются от реальности или от ожиданий, а затем подсветить эту информацию подрядчику.
Allow the contractor to participate in the process.
Нужно дать подрядчику возможность поучаствовать в рабочей деятельности в рамках автоматизируемого процесса. Пусть он пронаблюдает этот путь — от начала и до завершающей стадии процесса — и вникнет, как это происходит. Но это не заменяет интервьюирования; и лучше даже это сделать после интервью.
Step number 7. Negotiate documents carefully
Long thought, whether it is necessary to declare axioms ....
It is necessary.
Project documents must be studied! Study carefully and in detail. And also to check that all the members of the working group do this carefully and in detail. And the point is not that the contractor is so bad and may not write what was discussed (although it is also worth checking for sure), it will just be much worse if the process is described incorrectly.
Step number 8. Conduct real tests
Tests on test data is not bad. But all the most unpleasant inconsistencies come out when the system works with a real case. Yes, it is labor-intensive, and there are never any resources available for this, but this extremely increases the success rate of implementation.
Let the employees take the real task and, together with the contractor, go through the PME (program and test method) with the real scenario.
Step number 9. Do not be afraid to go into pilot production
Pro excellent syndrome have heard? They should get sick if you automate the process of dispatching takeoffs and landings at the airport or something similar. In other cases, take for granted that the system will not be 100% ready at the time of the start of operation.
Yes, it's sad. Yes, integrators need to be showered with rotten tomatoes and say that this should not be so and, in general, “are you testing your system or how ...” (c) . But the reality is that going into pilot production is likely to be raw. On the objection that the users will not like it, I will say that this will happen with the 100% ready system. To avoid this, it is necessary to gradually prepare users for a new life and for stress, talking about the project in corporate media, newsletters, etc.
Therefore, you just need to take courage and start.
Step number 10. Complete the project nicely
When you run a project, you need to remember that you can not cover everything at once. Do now what you can do now. Leave the rest on the development of the system.
This is where the idea of future contracts, a sitting on a “financial needle”, etc. can arise. But it is not. Attempting to embrace the immense has a very high risk of becoming a longevity, which may not just disrupt time, it may not end at all.
After the project is completed, it is important to hold a closing meeting, summarize the project results, assess the level of achievement of the goals and discuss further plans.
PS
The above:
- Applicable to modern companies, large and small.
- Applicable (oddly enough) in the implementation of projects according to GOST 34 and documentation on RD 50.
- Can be combined with flexible methodologies, there is no contradiction.
- It is gained through personal experience, it is not complete, but it will definitely be supplemented.
- It is designed to help the customer to better understand the contractor and increase the chances of mutual success.