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 lead projects, the article will be useful for 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 office automation projects, 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 fraud in the bank.
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 this phrase has already set the edge on them. As a rule, it is the PM that is responsible for identifying stakeholders.
But why do we recommend this to a functional customer? Because he knows much better how everything is arranged 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 gets 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. having a 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, one should follow 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 (instruction).
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 it would be good to declare at this meeting:
The objectives of the project.
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 be shy 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 why it is needed.
Terms of coordination of project documentation.
It is important that all members of the working group understand how many days they have for the formation of comments and how long the contractor must 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 timeline, 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 available resources 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 by the time the operation starts.
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 there 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 the new life and stress, talking about the project in the corporate media, newsletters, etc.
Therefore, you just need to take courage and start.
When you run a project, you need to remember that you cannot cover everything at once. Do now what you can do now. Leave the rest to the development of the system.
Here 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 lead projects, the article will be useful for 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 office automation projects, 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 fraud in the bank.
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 this phrase has already set the edge on them. As a rule, it is the PM that is responsible for identifying stakeholders.
But why do we recommend this to a functional customer? Because he knows much better how everything is arranged 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 gets 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. having a 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, one should follow 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 is organized, know where it differs from the documented procedures, and what “loopholes” exist in it ... It is great if there are those among them have ever worked in such a system before, or has 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 up, while not forgetting the rule of 10-12 participants.
- Safe have must! 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 (instruction).
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 it would be good to declare at this meeting:
The objectives of the project.
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 be shy 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 why it is needed.
Terms of coordination of project documentation.
It is important that all members of the working group understand how many days they have for the formation of comments and how long the contractor must 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 timeline, 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
When, during interviewing, the thought creeps in my head that in the process in question there is an exception or some tiny nuance that “does not seem to affect”, should not be silent. It is better to spend another couple of minutes on the explanation and allow the contractor to assess whether this affects or not.
Be empathetic
Yes, yes, empathetic. If suddenly there is a doubt that the contractor has correctly understood the intended meaning of a sentence, then it is better to spend another couple of minutes explaining and make sure that all participants equally understand what was said.
Check the completeness of the documentation
When submitting regulations, you need to make sure that the set of documents prepared for shipment to the contractor is complete. Have all members of the working group verify its integrity. A million cases when some kind of regulation is forgotten and floats somewhere on preliminary tests.
In general, it is good practice to re-read these rules before starting a project and beginning an interview in order to understand in time where they differ from reality or expectations, and then highlight this information to the contractor.
In general, it is good practice to re-read these rules before starting a project and beginning an interview in order to understand in time where they differ from reality or expectations, and then highlight this information to the contractor.
Allow the contractor to participate in the process.
It is necessary to give the contractor the opportunity to participate in the work activities of the automated process. Let him observe this path - from the beginning to the final stage of the process - and understand how it happens. But this does not replace interviewing; and even better to do it after the interview.
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 available resources 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 operation
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 by the time the operation starts.
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 there 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 the new life and stress, talking about the project in the corporate media, newsletters, etc.
Therefore, you just need to take courage and start.
Step number 10. Complete the project beautifully
When you run a project, you need to remember that you cannot cover everything at once. Do now what you can do now. Leave the rest to the development of the system.
Here 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.
Source: https://habr.com/ru/post/436590/