We are planning a project for the implementation and improvement of the information system in MS Project - quickly and beautifully
Recently, I have to work a lot with both project managers and customers, and I am increasingly convinced that the basis for a good project to implement and refine an information system is the project plan developed in MS Project. It can be shown to the customer, in order to clearly demonstrate the deadlines and scopes of the project, it can be included in the contract as a work schedule, it can be used to plan resources on a project, with the help of it one or other terms of the project can be argued, as well as count the internal and external cost, evaluating the resources on a special presentation.
In order not to explain to each new PMU how to make a plan in Project and what works and what structure to put there, I decided to make a draft of the plan, which would show the typical structure of work on the project of implementation and improvement of a simple information system costing approximately 5 million rubles and a period of about six months. Conventionally, the customer wants to start the project in May, and to finish in October, while the project’s start for us begins in April, with the preparation of the pilot and the control.
A certain company operating in the production of certain goods wants to automate a certain part of its business.
To do this, they decide to turn to a software company, to introduce one of the existing solutions and at the same time to refine the solution for their needs.
')
Since there is no Rocket Science in the project, its risks are about 10%. You can put them in different ways - add 10% to the cost of resources (but this does not take into account the deadlines), plan risk-based work, throwing 10% of the duration to each risky one (I used this option), or do the Contingency stage before the final stage (in my case it would be 3 weeks or ~ 1/10 of the project duration.
If the project plan will be shown to the customer, it is certainly better to use an approach that includes risks in the evaluation of all the work - not everyone will understand the appearance of another stage (for which the customer must pay). But if you are doing an internal project for your company, it is preferable to turn on the Contingency stage and use this time for emergency situations - diseases of key employees, sudden corporate events, etc. It will be easier for the internal customer to postpone the postponement.
The project manager is a manager with good technical expertise and business analysis skills. Well versed in the functionality of the solution, understands the business problem of the customer.
Analyst - conducts analysis meetings, develops project documentation (meeting minutes, description of functional requirements, specifications, instructions, etc.)
Implementation Specialist - responsible for implementing the solution, organizing the infrastructure for the servers, as well as their connection with the outside world. Those. configures the OS, database, is responsible for the support tracker, etc.
Of course, we need to score the project team on the “Resource List” presentation - I just indicated the roles, short names and internal rates (they are “hospital averages” and are not tied to a particular company), and also indicated my base calendar (in general, corresponding to the production calendar for 2018). If you use the project server, in the future you can specify instead of the role - specific performers, but at this stage, the roles are important for understanding the need for employees of a particular qualification. If you are preparing a project plan for presenting to customers, it makes sense to replace internal rates with external ones - both of which you probably already know, and if not, then this is the reason to turn to the owners of the resources that will open them.
Minimum minimum:
Of course, the roles may be different - it all depends on the company (and methodology) in which you are doing projects. One gift does not need an analyst and implementer, they have consultants, others divide analysts into business and system analysts and add technicians, others use trainee programs with connecting employees, etc. I have one of the many options for the team; on the resource sheet, you can safely replace the entities with your own ones and add new ones.
Here, we mark customers with a green color, and our company's specialists, who are not subject to payroll calculation, with purple. Besides the fact that it is visual, it is also convenient in the future, for example, if the customer asks to form a schedule for his involvement in the project - you simply upload the plan to Excel and filter by color.
In this case, a very simple and widespread project life cycle is used - the well-known “Waterfall” where several phases follow each other.
Some parts of the project are nevertheless made iteratively - for example, the development is divided into iterations, at the end of each of which - the developed functionality is shown to the customer.
But nevertheless, such a life cycle does not imply any major changes in the course of the project, therefore it is assumed that the project skoup is defined at the project entry stage, and the scopes are developed and included in the contract. It is also worth noting “Stage 0” - where the scopa is assessed and the pilot project is organized (for some companies this is now a rarity) - here it is assumed that the project manager also acts as a kind of head of the pre-sale, in which he describes and evaluates the functionality, as well as a certain head of the “pilot” project - the goal of which is to acquaint the customer with the functionality of the system, show him the interface and advantages ashore, in order to interest him. A pilot project can be called a project only conditionally - naturally, this is just a standard system procurement that is minimally modified to meet the needs of a specific customer. For example, a virtual machine with a stable version of the system in which a pair of simple but real customer processes can be quickly implemented, and, for example, a connection with one of the systems it uses is quickly configured (based on an existing driver or connector that requires only simple configuration). ).
Also, to save space on the screen, I removed the display of the “Task Mode” field - it is automatic on all tasks, there is no manual tool anywhere.
General overview of the stages, their timing and cost:
So, we have 8 stages (including stage 0) and the project, which begins on April 2, ends on October 5. To the customer, you can not show stage 0 at all, and of course, you should not take it into account if you do not consider the payroll of presales and pilots (but this is for the first bell of what you have to work on, since it is necessary to count such payroll).
Hereinafter, all milestones are painted in blue in order to quickly identify them. Milestones must be specified, because You will be able to insert them into the contract, link other tasks or payment stages to them, and generally follow them as the project moves.
In our project, everything will start with the pilot - one day, the account comes to the PM with the good news that he has a request for a pilot.
To organize a pilot, a customer will need a couple of descriptions of his processes, as well as a couple of wishes that he wants to see in the system - for example, he wants to load a list from his already existing standard database.
Here, we have a few days to communicate with the customer by phone, ask for a description of the processes or screen forms, then quickly we saw a pilot project to demonstrate and send to the customer. It is assumed that the pilot project does not require complex deployment, for example, this is either a virtual machine, which the customer can quickly deploy in its infrastructure, or a cloud service in general.
With average rates of implementer and PMA, such a pilot will cost us 59,400 rubles + another 10,800 rubles for his support, because the Customer will have questions about its deployment and use. Well, you still do not want to count the costs at the zero stage?
Further, if the customer liked the pilot, we proceed to the analysis of the project's scopes and its evaluation. It is assumed that the draft standard and all assessment methods have already been developed and tested in your company - if this is not the case, then you will find an exciting attraction compared to the cost of writing TK with the cost of developing functionality that covers a particular requirement (but this is a topic for a separate article). ).
Suppose you have put the process of describing the scopa and evaluation, and after the evaluation, the project curator approves it (and puts% on bargaining and non-project risks) after which the CP is sent to the customer for approval. Here these 7 working days can be clearly not enough, therefore this work is indicated separately, and the milestone “KP Approved” depends on it.
Separate tasks on the organization of the pilot and the evaluation of the project's scopes - it is necessary, because You should understand their cost well, and try to optimize the costs of pilot training and assessment (for example, create standard templates for assessment and standard virtualki for implementation).
So, you have successfully signed a contract (or received approval from a sponsor of an internal project) and now is the time to start, starting with collecting system requirements. But before that, we need to arrange a kick-off meeting, or as it is called in Russian, a starting meeting.
In some projects, it makes sense to show that developed by Project Charter, in some projects an official charter is signed with the contract, but regardless of this, a kikoff is needed - in order to clearly explain the goals and deadlines of the project to the team (or teams) and introduce everyone to each other, agree on interaction In general, Kick-off is also a topic for a separate article.
Since the project is small, we assume that 12 hours behind the eyes will be enough for us to prepare a small presentation in which we briefly outline the goals and objectives of the project, the participants and their role, clearly show the project timeline (for example, a beautiful Gantt chart) and present the following steps (for example, schedule meetings with the customer).
But by the way, and the schedule of meetings - for our simple project, we have provided 6 meetings at which different specialists participate and which stand for us in different ways. It is assumed that we have agreed in advance with the customers (or sponsors) on the schedule, so that business users and, in general, all interested parties, do not go on vacation or are not engaged in other activities. Of course, if you are working on an external project, it makes sense to include the project plan in the contract - in this case, no one will be able to blame you for the deadlines if the customer, for some reason, cannot attend the meetings.
Consider a few meetings with an example:
At some meetings - we only need a project manager and analyst, at others - we also need a leading developer, as well as an implementer. It depends on the specific project, but in general - plan meetings so that all the technical details pop up at the end, after the business demands - this will reduce the likelihood that arrangements at meetings will have to be agreed.
The logical end of the meeting we have is its protocol, sent to the review to the customer. Here it is important to consider the following - I have a meeting and a protocol is scheduled for 1 day, i.e. in the morning there is a meeting, then lunch and a protocol is written, which is sent to the customer for approval. The customer, while the project team writes the protocol, coordinates the minutes of the previous meeting.
Naturally, this is an ideal option, which only works if there are 2 very strong and motivated project teams.
In real life - to sit out at a meeting for 4 hours and in 4 hours to make a decent protocol describing the requirements and agreements (or otrevevit) - and so for 6 days in a row - quite hard. Not to mention that the meeting may be more than 4 hours (by the way, in this case the effectiveness of the meeting drops sharply and the protocol may not be agreed upon). If the deadlines (and the customer) allow - put 1 meeting in 2 days, and take a week's reserve - for additional meetings and review of the minutes. If you are not 100% sure of the customer and the team - never place more than 3 meetings during the week. And of course, it all depends on the region of presence - if you are doing a project in your city, or at least in your area - there is no sense in a hurry. If, however, your customer is from New Urengoy, and you - from Samara - alas, you will have to give everything at the meetings in full - it makes no sense to marinate a team without work in another city. Also, be sure to record the participation of the customer in the meetings in a separate line - and insert it into the contract.
The stage that looks quite simple on the project plan is actually one of the most time consuming and expensive. In addition, errors in the design of technical specifications (technical design, concept, or in general, any document that de jure serves as the basis for development and the reason for contacting the contractor under warranty) are usually very expensive. Changes at this stage are still welcome (if they do not go beyond the limitations specified in the contract), but since discussion is already over - new requirements are no longer recommended.
For internal projects, there is a higher risk that new requirements will appear (the fantasy of the sponsor and business users here is usually not limited to the contract), but at the same time the agreement is not so rigid and formal.
Does it make sense to detail these 5 days in the tasks and reflect them in the project plan? In my opinion, no, it is more logical to do this in Jira / Redmine, and the customer / sponsor to show such a plan.
I have provided 2 iterations of approval - this is perfectly reasonable, but it requires a certain responsibility from the customer - it’s worth explaining on the shore that the Customer puts all comments to the TOR in one iteration, and the second only checks that they are corrected, and new comments are not posted. If the customer insists on the third iteration of comments - well, the owner is a master, we insert the third (and the fourth, and the fifth ...) without forgetting to prescribe costs and explain to the customer how much the project cost will increase. It is reasonable to present TK for the first time reasonably together with the analyst, but it is necessary for the entire team to read it - for any large projects, this is a very capacious document that is a condition for completing the project phase (and therefore signing acts and payment), and random errors are not allowed in it . If you have free resources in the company, for example, analysts, it is logical to connect them to reading the TK as a fresh look - the TK will not make it any worse, and the project will not rise in price significantly.
So, the technical task is signed, and it would seem possible to start development.
The first thing I want to say is to warn about the inadmissibility of starting development, without an approved TK. This simply leads to the fact that the same work has to be done 2 times. Of course, if you are working on Agile, and you have no clear requirements, and there is a customer who pays according to the Time & Materials scheme, then safely ignore this requirement. If you have approved the project skoup, payment FixPrice and you did not set the budget and deadlines for reworking the tasks, then do not let the developers make a single commit without a signed TK.
The second - of course, implies that the infrastructure for development is deployed, and the processes are debugged. Negligent sponsors and project curators seek to include such expenses in the project budget - switching to CI, deploying Jira / Redmine, switching to a new version of software and libraries, databases, etc. etc. The task of the PMA here is to protect your project (and its budget) from such, arguing that such things should be made into separate projects with separate budgets.
If you are working on Waterfall - it is worth doing the development iteratively - i.e. break the entire scoop into parts and show it to the customer / sponsor according to the best practices. Let the software still be bugs, let no data, let the forms are not completed - it is better to spend the budget and time to write the display scripts and additional tests than to disappear for a month from the eyes of the customer and appear with the finished product. Customer feedback at the stage of completion of the development iteration is also useful, but this does not mean that he should be thoughtlessly shoved into the scoop - rate his comments. If he offers something irrelevant - for example, change the color or size of the field on the form - show that you are loyal and affably agree. If the customer offers frankly complex functionality - refuse, arguing the lack of a scoop, and if the customer insists - start your changemanagment machine (of course, you have it). It happens that the customer suggests something that is not essential, for example, changing the format of a telephone number, but this may affect the entire system. In this case, consult with the lead developer / architect, take his assessment under this feature, if it is small - you can meet the customer to increase loyalty (but you should remember about the risk of evaluation error).
But all this is still ahead, but for now, you will need to decompose the tasks from the TOR into tasks in the task tracker. There is no detailed universal recipe here, but in the general case, create tasks for each functional requirement, and create subtasks within it. Further, using assessment methods (for example, poker planning), you with a project task will assess the complexity of the tasks. Do not forget to prioritize the tasks, in accordance with the iterations (you can screw the sprint numbers to the task descriptions, and plan based on the team's performance). In the project plan, it is always reasonable to indicate what is the result of an iteration (for example, screen forms, integration, analytics, or something else are developed) - so that the customer would know what he gets at the shows and be able to track whether you are going according to plan, or linger on. Try to break the iterations based on your experience, but in any case - do not disappear for a long time, and keep a record of the show, where you enter comments from customers, with your decisions on them - this will cover you, in case of conflict regarding the project’s scopes - to avoid situations on handing over - “We will not sign, we did say that the window should have been made blue ...”.
So, all tasks in Jira are closed, all protocols are agreed and now we are entering the testing phase of the product being developed as part of the project.
Before testing, you will of course need a test plan and test cases, with an assessment of their passing.
Pay attention to task 110 (correction of defects) - it is parallel to 109 (search for defects) with a delay per day. Those. It is assumed that the tester, passing through test cases, describes defects in the system of tasks, and the developers correct them without departing from the cash register. This approach is reasonable and used, but there is another solution - to start repairing only when the testing is complete. Which of these approaches is right for you - your development manager knows.
Do not forget that the customer will also want to test the system - in this case you will provide him with a document called “PMI” - or the test program and method. It is logical to make it on the basis of the developed test cases, removing the entire internal kitchen and leaving only the things needed by the customer (including non-functional testing).
PMI must be read and approved by the customer and it is based on the results of the passage of the PMI, the customer will make the final decision on transferring the system to commercial operation.
In my project - the agreement of the PMI is not included, since in my practice, customers rarely read the PMI and test cases, because they poorly understand what kind of functionality they are talking about and how in one case the check box differs from the radio button in another case (this is a joke, this is not necessary at all in PMI). Therefore, when developing a document, special attention should be paid to the list of cases, the passage of which will be discussed, and, of course, to ensure that they are properly worked out inside.
Not only testers, but also PM and analysts should pass MIT, and implementation is desirable - everyone will have to take the system together, and to have an idea of ​​how the functionality works is very useful, and of course. increases the chance to find unobvious defects.
Hooray! We got! The system on the test servers works like a clock, the QA team sleeps and goes away, and the implementation team’s finest hour came. It begins with the deployment of the environment - and right there I have in my plan a certain amount of time, because I mean that the environment has already been deployed at least 100 times and in the worst case there are detailed deployment instructions on your corporate wiki, and at best - the implementer wrote it himself. The main thing to remember is that after deployment it is useful to test everything that you can test using a pre-designed Smoke test, of course, it remains with you from the testing phase.
Now - the main thing, because if the devil and lies somewhere, then it is in the integration and migration of data. How many beautiful Gantt charts were ruined by the fact that integration was not tested thoroughly and by the fact that customer data was in a terrible state, unnormalized, going beyond all facets of reasonable (and field limits) other than what is written in the TK.
The main thing here is not to let the customer play on the fact that integration (or migration) may not earn and shift responsibility to you - warn him in advance that if these works will be delayed due to his fault, the responsibility for extending the time frame (and budget) of the project will fall on his shoulders. Feel free to write letters and convene a ProjectBoard (or whatever you have) for the integration and migration of user data is the most common problem of failing to meet deadlines on such projects.
Training (here you will find a pleasant surprise) - almost does not conceal the pitfalls. Agree on a training plan with the customer, and write the minutes to all present under the painting. And of course, if you are not confident in the work of your analyst, plan another day of training rehearsal (either by including it in three days for writing instructions, or using the internal budget for project risks).
On the passage of the PMI - plan from 25% of the time of the PMA and higher, depending on your experience and the validity of the analyst who participates in the project - ideally, the tests should be run smoothly, well, in any case, the customer should be sure of this at least before the test.
If the tests go through the stump deck - PM, PM and PM again are to blame - then the previous phases were either poorly planned or poorly implemented - look for the cause and solve the problems, but not at the expense of the customer, but due to the risks you laid at the start of the project.
Or, as it is called, the support of the OPE (since it almost has nothing to do with guarantee or technical support). So, the whole pizza has been eaten, the sleepless nights are over, and your project has gone into commercial operation. This means that the customer does not (or he simply failed to find) critical comments to the system developed during your project, and gives users the command to work in it, as in the main system (or as in a clone of the combat system, this also happens).
Now, your task is to hold out for a certain period (from 5 days to 4 months) and make sure that the system is working correctly. The choice of dates depends on the purpose of the system - sometimes there is enough a week of work in a new system, sometimes you need to work on it for a month or two, and even close a quarter. Plan for this time of people, so that they could quickly deal with issues raised by the customer, but note that there may be (must be!) Few questions - so it’s logical to schedule internal project activities as well - archiving documentation, putting the wiki and tracker in order tasks, retro training, etc.
Do not forget that all the problems arising during the pilot operation should be recorded in a special journal (and ideally in the task tracker) and daily monitor their status together with the customer.
At the end of the stage, you can also schedule one team meeting with the customer, where you solemnly announce the closure of the project and the continuation of cooperation and summarize the results. Unless your customer is in New Urengoy.
In general, this is all, of course, I would like to lay out the project plan somewhere in the mpp format - so that the respected habrovchane would not forget about it all with their hands, but look at an example of how the tasks are related.
Suggestions for this - I will listen in the comments, and be sure to publish the mpp in a place where it can be easily and safely picked up.
In order not to explain to each new PMU how to make a plan in Project and what works and what structure to put there, I decided to make a draft of the plan, which would show the typical structure of work on the project of implementation and improvement of a simple information system costing approximately 5 million rubles and a period of about six months. Conventionally, the customer wants to start the project in May, and to finish in October, while the project’s start for us begins in April, with the preparation of the pilot and the control.
Project Description
A certain company operating in the production of certain goods wants to automate a certain part of its business.
To do this, they decide to turn to a software company, to introduce one of the existing solutions and at the same time to refine the solution for their needs.
')
Project risks
Since there is no Rocket Science in the project, its risks are about 10%. You can put them in different ways - add 10% to the cost of resources (but this does not take into account the deadlines), plan risk-based work, throwing 10% of the duration to each risky one (I used this option), or do the Contingency stage before the final stage (in my case it would be 3 weeks or ~ 1/10 of the project duration.
If the project plan will be shown to the customer, it is certainly better to use an approach that includes risks in the evaluation of all the work - not everyone will understand the appearance of another stage (for which the customer must pay). But if you are doing an internal project for your company, it is preferable to turn on the Contingency stage and use this time for emergency situations - diseases of key employees, sudden corporate events, etc. It will be easier for the internal customer to postpone the postponement.
The project team
The project manager is a manager with good technical expertise and business analysis skills. Well versed in the functionality of the solution, understands the business problem of the customer.
Analyst - conducts analysis meetings, develops project documentation (meeting minutes, description of functional requirements, specifications, instructions, etc.)
Implementation Specialist - responsible for implementing the solution, organizing the infrastructure for the servers, as well as their connection with the outside world. Those. configures the OS, database, is responsible for the support tracker, etc.
- The lead developer is the architect. He participates in the study of the solution architecture, the assessment of development tasks, provides mentoring to the development team and help in solving complex problems.
- Developer - the main developer of the project,
- The junior developer, a junior at the pickup of the code, solves problems under the control of the developer, and learns in parallel.
- Account - customer service manager, responsible for interacting with the client, drafting and signing contracts, monitoring customer satisfaction, etc. It is not directly included in the project PHT, since his work is not planned RP.
- The curator is the highest manager of the executing company, providing control and support for the project. Maybe the same - portfolio manager, etc. It is not directly included in the project PHT, since his work is not planned RP.
- Customer - all employees of the customer involved in the project. In the plan, they are not detailed, it is assumed that the customer himself will decide which of his specialists to involve in this or that activity.
Of course, we need to score the project team on the “Resource List” presentation - I just indicated the roles, short names and internal rates (they are “hospital averages” and are not tied to a particular company), and also indicated my base calendar (in general, corresponding to the production calendar for 2018). If you use the project server, in the future you can specify instead of the role - specific performers, but at this stage, the roles are important for understanding the need for employees of a particular qualification. If you are preparing a project plan for presenting to customers, it makes sense to replace internal rates with external ones - both of which you probably already know, and if not, then this is the reason to turn to the owners of the resources that will open them.
Minimum minimum:
Of course, the roles may be different - it all depends on the company (and methodology) in which you are doing projects. One gift does not need an analyst and implementer, they have consultants, others divide analysts into business and system analysts and add technicians, others use trainee programs with connecting employees, etc. I have one of the many options for the team; on the resource sheet, you can safely replace the entities with your own ones and add new ones.
Here, we mark customers with a green color, and our company's specialists, who are not subject to payroll calculation, with purple. Besides the fact that it is visual, it is also convenient in the future, for example, if the customer asks to form a schedule for his involvement in the project - you simply upload the plan to Excel and filter by color.
Project life cycle
In this case, a very simple and widespread project life cycle is used - the well-known “Waterfall” where several phases follow each other.
Some parts of the project are nevertheless made iteratively - for example, the development is divided into iterations, at the end of each of which - the developed functionality is shown to the customer.
But nevertheless, such a life cycle does not imply any major changes in the course of the project, therefore it is assumed that the project skoup is defined at the project entry stage, and the scopes are developed and included in the contract. It is also worth noting “Stage 0” - where the scopa is assessed and the pilot project is organized (for some companies this is now a rarity) - here it is assumed that the project manager also acts as a kind of head of the pre-sale, in which he describes and evaluates the functionality, as well as a certain head of the “pilot” project - the goal of which is to acquaint the customer with the functionality of the system, show him the interface and advantages ashore, in order to interest him. A pilot project can be called a project only conditionally - naturally, this is just a standard system procurement that is minimally modified to meet the needs of a specific customer. For example, a virtual machine with a stable version of the system in which a pair of simple but real customer processes can be quickly implemented, and, for example, a connection with one of the systems it uses is quickly configured (based on an existing driver or connector that requires only simple configuration). ).
Also, to save space on the screen, I removed the display of the “Task Mode” field - it is automatic on all tasks, there is no manual tool anywhere.
General overview of the stages, their timing and cost:
So, we have 8 stages (including stage 0) and the project, which begins on April 2, ends on October 5. To the customer, you can not show stage 0 at all, and of course, you should not take it into account if you do not consider the payroll of presales and pilots (but this is for the first bell of what you have to work on, since it is necessary to count such payroll).
Hereinafter, all milestones are painted in blue in order to quickly identify them. Milestones must be specified, because You will be able to insert them into the contract, link other tasks or payment stages to them, and generally follow them as the project moves.
Stage 0 - project preparation
In our project, everything will start with the pilot - one day, the account comes to the PM with the good news that he has a request for a pilot.
To organize a pilot, a customer will need a couple of descriptions of his processes, as well as a couple of wishes that he wants to see in the system - for example, he wants to load a list from his already existing standard database.
Here, we have a few days to communicate with the customer by phone, ask for a description of the processes or screen forms, then quickly we saw a pilot project to demonstrate and send to the customer. It is assumed that the pilot project does not require complex deployment, for example, this is either a virtual machine, which the customer can quickly deploy in its infrastructure, or a cloud service in general.
With average rates of implementer and PMA, such a pilot will cost us 59,400 rubles + another 10,800 rubles for his support, because the Customer will have questions about its deployment and use. Well, you still do not want to count the costs at the zero stage?
Further, if the customer liked the pilot, we proceed to the analysis of the project's scopes and its evaluation. It is assumed that the draft standard and all assessment methods have already been developed and tested in your company - if this is not the case, then you will find an exciting attraction compared to the cost of writing TK with the cost of developing functionality that covers a particular requirement (but this is a topic for a separate article). ).
Suppose you have put the process of describing the scopa and evaluation, and after the evaluation, the project curator approves it (and puts% on bargaining and non-project risks) after which the CP is sent to the customer for approval. Here these 7 working days can be clearly not enough, therefore this work is indicated separately, and the milestone “KP Approved” depends on it.
Separate tasks on the organization of the pilot and the evaluation of the project's scopes - it is necessary, because You should understand their cost well, and try to optimize the costs of pilot training and assessment (for example, create standard templates for assessment and standard virtualki for implementation).
Stage 1 - Requirements Collection
So, you have successfully signed a contract (or received approval from a sponsor of an internal project) and now is the time to start, starting with collecting system requirements. But before that, we need to arrange a kick-off meeting, or as it is called in Russian, a starting meeting.
In some projects, it makes sense to show that developed by Project Charter, in some projects an official charter is signed with the contract, but regardless of this, a kikoff is needed - in order to clearly explain the goals and deadlines of the project to the team (or teams) and introduce everyone to each other, agree on interaction In general, Kick-off is also a topic for a separate article.
Since the project is small, we assume that 12 hours behind the eyes will be enough for us to prepare a small presentation in which we briefly outline the goals and objectives of the project, the participants and their role, clearly show the project timeline (for example, a beautiful Gantt chart) and present the following steps (for example, schedule meetings with the customer).
But by the way, and the schedule of meetings - for our simple project, we have provided 6 meetings at which different specialists participate and which stand for us in different ways. It is assumed that we have agreed in advance with the customers (or sponsors) on the schedule, so that business users and, in general, all interested parties, do not go on vacation or are not engaged in other activities. Of course, if you are working on an external project, it makes sense to include the project plan in the contract - in this case, no one will be able to blame you for the deadlines if the customer, for some reason, cannot attend the meetings.
Consider a few meetings with an example:
At some meetings - we only need a project manager and analyst, at others - we also need a leading developer, as well as an implementer. It depends on the specific project, but in general - plan meetings so that all the technical details pop up at the end, after the business demands - this will reduce the likelihood that arrangements at meetings will have to be agreed.
The logical end of the meeting we have is its protocol, sent to the review to the customer. Here it is important to consider the following - I have a meeting and a protocol is scheduled for 1 day, i.e. in the morning there is a meeting, then lunch and a protocol is written, which is sent to the customer for approval. The customer, while the project team writes the protocol, coordinates the minutes of the previous meeting.
Naturally, this is an ideal option, which only works if there are 2 very strong and motivated project teams.
In real life - to sit out at a meeting for 4 hours and in 4 hours to make a decent protocol describing the requirements and agreements (or otrevevit) - and so for 6 days in a row - quite hard. Not to mention that the meeting may be more than 4 hours (by the way, in this case the effectiveness of the meeting drops sharply and the protocol may not be agreed upon). If the deadlines (and the customer) allow - put 1 meeting in 2 days, and take a week's reserve - for additional meetings and review of the minutes. If you are not 100% sure of the customer and the team - never place more than 3 meetings during the week. And of course, it all depends on the region of presence - if you are doing a project in your city, or at least in your area - there is no sense in a hurry. If, however, your customer is from New Urengoy, and you - from Samara - alas, you will have to give everything at the meetings in full - it makes no sense to marinate a team without work in another city. Also, be sure to record the participation of the customer in the meetings in a separate line - and insert it into the contract.
Stage 2 - Architecture and Design
The stage that looks quite simple on the project plan is actually one of the most time consuming and expensive. In addition, errors in the design of technical specifications (technical design, concept, or in general, any document that de jure serves as the basis for development and the reason for contacting the contractor under warranty) are usually very expensive. Changes at this stage are still welcome (if they do not go beyond the limitations specified in the contract), but since discussion is already over - new requirements are no longer recommended.
For internal projects, there is a higher risk that new requirements will appear (the fantasy of the sponsor and business users here is usually not limited to the contract), but at the same time the agreement is not so rigid and formal.
Does it make sense to detail these 5 days in the tasks and reflect them in the project plan? In my opinion, no, it is more logical to do this in Jira / Redmine, and the customer / sponsor to show such a plan.
I have provided 2 iterations of approval - this is perfectly reasonable, but it requires a certain responsibility from the customer - it’s worth explaining on the shore that the Customer puts all comments to the TOR in one iteration, and the second only checks that they are corrected, and new comments are not posted. If the customer insists on the third iteration of comments - well, the owner is a master, we insert the third (and the fourth, and the fifth ...) without forgetting to prescribe costs and explain to the customer how much the project cost will increase. It is reasonable to present TK for the first time reasonably together with the analyst, but it is necessary for the entire team to read it - for any large projects, this is a very capacious document that is a condition for completing the project phase (and therefore signing acts and payment), and random errors are not allowed in it . If you have free resources in the company, for example, analysts, it is logical to connect them to reading the TK as a fresh look - the TK will not make it any worse, and the project will not rise in price significantly.
Stage 3 - Development
So, the technical task is signed, and it would seem possible to start development.
The first thing I want to say is to warn about the inadmissibility of starting development, without an approved TK. This simply leads to the fact that the same work has to be done 2 times. Of course, if you are working on Agile, and you have no clear requirements, and there is a customer who pays according to the Time & Materials scheme, then safely ignore this requirement. If you have approved the project skoup, payment FixPrice and you did not set the budget and deadlines for reworking the tasks, then do not let the developers make a single commit without a signed TK.
The second - of course, implies that the infrastructure for development is deployed, and the processes are debugged. Negligent sponsors and project curators seek to include such expenses in the project budget - switching to CI, deploying Jira / Redmine, switching to a new version of software and libraries, databases, etc. etc. The task of the PMA here is to protect your project (and its budget) from such, arguing that such things should be made into separate projects with separate budgets.
If you are working on Waterfall - it is worth doing the development iteratively - i.e. break the entire scoop into parts and show it to the customer / sponsor according to the best practices. Let the software still be bugs, let no data, let the forms are not completed - it is better to spend the budget and time to write the display scripts and additional tests than to disappear for a month from the eyes of the customer and appear with the finished product. Customer feedback at the stage of completion of the development iteration is also useful, but this does not mean that he should be thoughtlessly shoved into the scoop - rate his comments. If he offers something irrelevant - for example, change the color or size of the field on the form - show that you are loyal and affably agree. If the customer offers frankly complex functionality - refuse, arguing the lack of a scoop, and if the customer insists - start your changemanagment machine (of course, you have it). It happens that the customer suggests something that is not essential, for example, changing the format of a telephone number, but this may affect the entire system. In this case, consult with the lead developer / architect, take his assessment under this feature, if it is small - you can meet the customer to increase loyalty (but you should remember about the risk of evaluation error).
But all this is still ahead, but for now, you will need to decompose the tasks from the TOR into tasks in the task tracker. There is no detailed universal recipe here, but in the general case, create tasks for each functional requirement, and create subtasks within it. Further, using assessment methods (for example, poker planning), you with a project task will assess the complexity of the tasks. Do not forget to prioritize the tasks, in accordance with the iterations (you can screw the sprint numbers to the task descriptions, and plan based on the team's performance). In the project plan, it is always reasonable to indicate what is the result of an iteration (for example, screen forms, integration, analytics, or something else are developed) - so that the customer would know what he gets at the shows and be able to track whether you are going according to plan, or linger on. Try to break the iterations based on your experience, but in any case - do not disappear for a long time, and keep a record of the show, where you enter comments from customers, with your decisions on them - this will cover you, in case of conflict regarding the project’s scopes - to avoid situations on handing over - “We will not sign, we did say that the window should have been made blue ...”.
Stage 4 - Testing
So, all tasks in Jira are closed, all protocols are agreed and now we are entering the testing phase of the product being developed as part of the project.
Before testing, you will of course need a test plan and test cases, with an assessment of their passing.
Pay attention to task 110 (correction of defects) - it is parallel to 109 (search for defects) with a delay per day. Those. It is assumed that the tester, passing through test cases, describes defects in the system of tasks, and the developers correct them without departing from the cash register. This approach is reasonable and used, but there is another solution - to start repairing only when the testing is complete. Which of these approaches is right for you - your development manager knows.
Do not forget that the customer will also want to test the system - in this case you will provide him with a document called “PMI” - or the test program and method. It is logical to make it on the basis of the developed test cases, removing the entire internal kitchen and leaving only the things needed by the customer (including non-functional testing).
PMI must be read and approved by the customer and it is based on the results of the passage of the PMI, the customer will make the final decision on transferring the system to commercial operation.
In my project - the agreement of the PMI is not included, since in my practice, customers rarely read the PMI and test cases, because they poorly understand what kind of functionality they are talking about and how in one case the check box differs from the radio button in another case (this is a joke, this is not necessary at all in PMI). Therefore, when developing a document, special attention should be paid to the list of cases, the passage of which will be discussed, and, of course, to ensure that they are properly worked out inside.
Not only testers, but also PM and analysts should pass MIT, and implementation is desirable - everyone will have to take the system together, and to have an idea of ​​how the functionality works is very useful, and of course. increases the chance to find unobvious defects.
Stage 5 - Implementation
Hooray! We got! The system on the test servers works like a clock, the QA team sleeps and goes away, and the implementation team’s finest hour came. It begins with the deployment of the environment - and right there I have in my plan a certain amount of time, because I mean that the environment has already been deployed at least 100 times and in the worst case there are detailed deployment instructions on your corporate wiki, and at best - the implementer wrote it himself. The main thing to remember is that after deployment it is useful to test everything that you can test using a pre-designed Smoke test, of course, it remains with you from the testing phase.
Now - the main thing, because if the devil and lies somewhere, then it is in the integration and migration of data. How many beautiful Gantt charts were ruined by the fact that integration was not tested thoroughly and by the fact that customer data was in a terrible state, unnormalized, going beyond all facets of reasonable (and field limits) other than what is written in the TK.
The main thing here is not to let the customer play on the fact that integration (or migration) may not earn and shift responsibility to you - warn him in advance that if these works will be delayed due to his fault, the responsibility for extending the time frame (and budget) of the project will fall on his shoulders. Feel free to write letters and convene a ProjectBoard (or whatever you have) for the integration and migration of user data is the most common problem of failing to meet deadlines on such projects.
Training (here you will find a pleasant surprise) - almost does not conceal the pitfalls. Agree on a training plan with the customer, and write the minutes to all present under the painting. And of course, if you are not confident in the work of your analyst, plan another day of training rehearsal (either by including it in three days for writing instructions, or using the internal budget for project risks).
On the passage of the PMI - plan from 25% of the time of the PMA and higher, depending on your experience and the validity of the analyst who participates in the project - ideally, the tests should be run smoothly, well, in any case, the customer should be sure of this at least before the test.
If the tests go through the stump deck - PM, PM and PM again are to blame - then the previous phases were either poorly planned or poorly implemented - look for the cause and solve the problems, but not at the expense of the customer, but due to the risks you laid at the start of the project.
Stage 6 - Support
Or, as it is called, the support of the OPE (since it almost has nothing to do with guarantee or technical support). So, the whole pizza has been eaten, the sleepless nights are over, and your project has gone into commercial operation. This means that the customer does not (or he simply failed to find) critical comments to the system developed during your project, and gives users the command to work in it, as in the main system (or as in a clone of the combat system, this also happens).
Now, your task is to hold out for a certain period (from 5 days to 4 months) and make sure that the system is working correctly. The choice of dates depends on the purpose of the system - sometimes there is enough a week of work in a new system, sometimes you need to work on it for a month or two, and even close a quarter. Plan for this time of people, so that they could quickly deal with issues raised by the customer, but note that there may be (must be!) Few questions - so it’s logical to schedule internal project activities as well - archiving documentation, putting the wiki and tracker in order tasks, retro training, etc.
Do not forget that all the problems arising during the pilot operation should be recorded in a special journal (and ideally in the task tracker) and daily monitor their status together with the customer.
At the end of the stage, you can also schedule one team meeting with the customer, where you solemnly announce the closure of the project and the continuation of cooperation and summarize the results. Unless your customer is in New Urengoy.
In general, this is all, of course, I would like to lay out the project plan somewhere in the mpp format - so that the respected habrovchane would not forget about it all with their hands, but look at an example of how the tasks are related.
Suggestions for this - I will listen in the comments, and be sure to publish the mpp in a place where it can be easily and safely picked up.
Source: https://habr.com/ru/post/347426/
All Articles