 Thank you for coming in good numbers and sorry for the delay. What we are embarking upon is an activity in project management which will be used not only for the NVLI project, which is a new project that we are doing, but we will also use it for all other project management activities in future. We have hardly ever done formal project management. We attempted it once when we were working on the MOOCs platform initially. But when the government was not certain on the SWAM decision, we stopped that activity. And therefore, we did not capitalize on a little experience that we got there at that point in time. Of course, at that point, we were using some different tools and were driven more by enthusiasm and passion rather than by technique and skills. This time we want to correct that. Parag, once again, is in charge of the PMO. I believe all of you have a little knowledge about project management. Those of you who have never read any book or any material on project management, can you raise your hands? It is possible that many people have never done any formal project management. Just one or two people. So everybody else is familiar with project management. Then you can just ask them to read Jira and that's it. I'll pass back my session. No. I don't agree with this feedback from my colleagues because if I was asked the same question, I'll raise my hands and I will say, I do not know enough about project management. Even I have a huge gap. And I have taught project management. So please understand that project management, even if you have studied something or learned something, is completely different from the style in which projects are managed now. I do not know. Those of you who have used project management or learned project management or something, how many of you submit your daily time sheet or daily report on Vicky? And you raise your hands every day. But do you relate your daily report to some activity that has been interested to you which has start time, end time, dependencies on other activities? And is there a mechanism which tracks whether a particular activity is falling behind schedule or is getting done in time? What you are doing at individual level is one part of the project management activity. The larger activity starts at the beginning when you define different major sub-activities of a project, entrust that job to some managers who in turn divide that sub-activity into sub-sub-activities, entrust those to their junior colleagues. And eventually the entire pyramid structure which is formed, everyone knows what is my responsibility, what is my responsibility in terms of monitoring and who is going to monitor my activity. Secondly, there are tools which will permit all this information to be automatically deciphered in terms of its impact on the major project timeline and people would be advised on what is happening in the project. That is very crudely an overall project management view. But this time we will not be able to afford a single individual not familiar with this. And the success or failure of a project management system implementation depends upon every individual at the bottom of the pyramid. So if I am an administrative person or a software person working in a team which has its own hierarchy, if I fail to complete my reporting correctly and in time every day, then it has an impact on the entire project. So therefore this is, it is not permitted to slip on them. That is the main point I wanted to write. Parag and his team will be describing their project management strategy. In the past the traditional way in which software was developed and implemented which required technical people as well as administrative people was a prolonged process. We followed what was known as a waterfall model for development. In last 40 years the things have changed completely and what the industry follows is now called an agile programming model. An agile software development model does not have these separate compartments for specifications, design, development, testing and deployment. It is all rolled into one and you roll out versions. You deploy versions practically every week. Agile means quick. Now that method is extremely difficult to practice even for experienced software and administrative people. So Professor Aute has advised against using that methodology immediately, will not be implementing that methodology immediately. However, we will be training all of us into the use of that agile methodology which most probably be implemented by end of December or January early next year, six months down the line. So today your task is to fold, one, to understand the overall project management methodology, two, to understand the Jira related both reporting structures as well as visualizing structures and the embedded alerts etc which will come up and there will be hands-on training that each one will have to undergo on some simulated project. I think he will he will develop that with all of you and this training is obligatory for all including for me. I'll be missing the next presentation because of that continuation of the emergency meeting that I have and there is another emergency but good news is that AICT has approved running of two MOOCs based faculty development programs and if the additional secretary does visit on 18th, 19th as planned we might actually have funding resumed for the T10KT project as well where we run all our FDPs using only MOOCs. So MOOCs then becomes the main stay of our activities and therefore the projects will continue. So we'll have now double responsibility possible. It is absolutely essential that we become perfectly competent in and skilled in handling Jira-based reporting structures, Jira-based visualization structure, etc, etc. You're also planning to use confluence? Yes. Right. So there is also a mechanism for identifying uniquely all the documents that we ever put in place. Currently all of you are not even familiar with the requirement that every document must be having a unique identity number. Are you familiar with this? You write your program, you have a printout. Does that program have a line which says the unique identity for this document is this? You send so many letters, etc. Only on the covering note, covering letter, there is possibly a dispatch number and that too is put by the dispatching office. But are individual units completely comfortable with the fact that every document must have a unique ID whenever it originates? We don't do that. Our teams, including senior managers, don't do that. When they send me a mail for a draft document, they just send a draft editable document. It does not have a unique identity. Just to elaborate this point, suppose my workshop team sends me 20 documents in 10 days and I want to refer to a particular document. How do I refer to it when I call somebody from the workshop team? Our workshop team wants to tell me that they have sent me this document early. They will invariably try to say, no, they sent it to the 2nd April, no, not the 31st April, they sent it to the 31st March. In the 31st March, there are three mails. Now, look at the attachment of the second mail. Is that not how you identify documents which you exchange? This is simply not acceptable anymore. You cannot originate a document and send it unless the document has a unique ID. When I give you a reference to that unique ID, in exactly 30 seconds, you should be able to locate that document soft cup. This is a very fundamental re-disciplining that we ought to do for ourselves. We do not treat documents with the respect that they deserve. All of that is actually part and parcel of the modern project. So we will elaborate on that, listen to his presentation carefully. More importantly, do all the hands-on work that will be required to be done. I want all members of our team to be trained in that fashion. This training is the first kind of training that his team is undertaking. So it will have some shortcomings. But more importantly, exactly identical training will be delivered to our partner institutions which, as you know, in the NVLI project, they are IGNU, they are CDAC, they are NKN. And the supervisory authority is the Raja Ram Mohan Roy Library Foundation in Kolkata, which is part of the ministry. So all the people will be using exactly same identical process for project night. There is a non-trivial amount of work that is required to be done by everyone for the project night. So when you say I am working on a project, working on part of the project management is part of working on the project, part of the duty, part of the non-trivial. All right? So all you are spurred. Okay, so let's continue. I start with a brief introduction to PMI. PMI is Project Management Institute based in U.S., the world's largest not-for-profit membership. And it releases the PMBOC guide, updates it regularly, it is now in the fifth edition and it has all these standards for project management and also offers the PMP certification which is held by around 6 lakh, more than 6 lakh practitioners worldwide. People who are interested in project management, I recommend them to attempt this certification. It is not easy. The pass rate is 60 percent. So 4 people out of 10 fail in this exam. Incidentally, I am PMP certified since the past 3 years. You have to renew these certificate every year. Okay, I am talking about this slide because all the content that I am sharing with you today are based on this PMBOC guide, the project management body of knowledge. Let's start with what a project is. A project is something which is temporary. It has a definite start and a finish compared to what a process is or what a operation is. For example, an operation could be an assembly line manufacturing cars, but if you are building a prototype for a car, that is a project because it has a start and a finish. Again a project has a unique result which can be measured and it is progressively elaborated which means that as the project moves on, you come to know more about the project and you define the deliverables accordingly. Next we move to project life cycle. Again based on the PMBOC guide, there are 5 process groups initiating, planning, executing the project, monitoring and controlling and closing. So initiating and planning are done at the beginning of the project. Executing, monitoring and controlling go hand in hand and once the project closes, there is a process group called closing where you undergo a lot of processes. Just don't close the process, you document everything as historical information for future teams to refer. These 5 process groups are essentially based on the Deming PDCA cycle. I think few people must have heard about this. The plan do check and act cycle and these 5 processes, process groups have 47 processes and 10 knowledge areas. So, these 10 knowledge areas are listed here. It encompasses the whole project management cycle that one undergoes during managing a project. So, in this brief session, we will focus on only 3 knowledge areas, scope management, time management and risk management. I have chosen these 3 because these are essential to start using JIRA effectively. In scope management, you essentially create a work breakdown structure. You break down the scope into work packages. These are the deliverables which are then further broken down into activities and you also maintain a risk register so that you keep track of the risk that are involved in the project and take corrective and preventive actions. So the entire story begins with the project charter. This is where the project starts. This is a document which is issued by the project initiator or the sponsor of the project. It formally authorizes the existence of the project. It authorizes the project manager to start using the resources of the organization for project activities. It includes a bird's eye view of the project is all about. For example, the business need of the project, the scope description and the strategic plan. This is a sample, a very simple sample of the project charter. The slides are not very clear. We tried to fine tune it, but it did not happen. Anyway, the highlighted portions are important. Essentially it consists of the description, a brief description of the project, the requirements of the project, then who is the project manager assigned to the project, that is authority level, then summary, milestone, schedule and the business case. It is signed. Now we come to the main plan which is called the project management plan. This is essentially a collection of subsidiary plans. There are 10 plans each for each knowledge area. So there is a scope management plan, there is a time management plan, there is a cost management plan and so on. So most people have doubt that maybe the project management plan is something that you get out of MS project. It is not the case, what you get out of MS project is the project schedule plan and not the project management plan, just to make that clear. And finally we come to the project management information system. This is the software which helps you in managing the project. Most commonly used software is Microsoft project but now there are many competing project management softwares. One of them is Jira. There are more popular ones like Trello, Asan and various others. We have chosen Jira because it is given, it is a commercial licensed software developed by a company called Atlassian in Australia. And it gives those teams who are developing the system in open source free to use. So we have an open source license for this. In fact you can manage the project using Microsoft Excel also. So we begin with this knowledge area called scope management. Scope management includes all the work that is required to be done in the project and it also includes all the work that is not to be done in the project. It is specifically written down so that the scope is clear that this is the thing and only this thing has to be done. So the first process after you have the project charter assigned is collect requirements where you collect the various project requirements based on the stakeholders needs and the objectives of the project. There are various tools and techniques used to collect the requirements. This is a very huge phase and a very important phase while briefly go through some of the tools and techniques. You can interview in one to one conversation various stakeholders of the projects. As each stakeholder, stakeholder could be the customer himself, stakeholder could be the upper management, stakeholder could be the developers and each one will give you the requirements in his own perspective. Then you can also have focus groups which are conducted by a trained moderator. Subject matter experts are invited, stakeholders participation is solicited. Another technique is facilitated workshops where you have cross-functional stakeholders coming together discussing what the requirements of the project should be and try to reconcile differences. There are some examples of facilitated workshops here. Brain storming, I think you must be aware of this technique where people sit together in brainstorm ideas. So nominal group technique is again brainstorming but here we have an added voting process to rank the ideas. Then we have the Delphi technique so inspired by the oracle of Delphi of ancient times. Here questionnaires are sent to subject matter experts and it is an anonymous process where honest feedback is solicited. These experts are given questionnaires, the responses are collected and sent back to them again to build consensus. Next is idea of mind mapping. Mind mapping is also now a very popular technique used in various contexts where you draw out different things based on relationships. Another technique is affinity diagram where you group together ideas and then try to identify patterns. So the document that comes out of requirements apart from the requirements document itself is the requirements traceability matrix. So this actually helps you map the requirements with the deliverables throughout the project as it moves on. So it is used to trace each requirement back to a specific business case in the project charter and then forward to the rest of the scope deliverables. So I will show you a sample of the requirement traceability matrix. I do not think it is visible. So here each requirement is mapped to the WBS deliverables, the project objectives, the design test cases and other things. The unique ID is given to each requirement. So after you have collected all the requirements, you come up with the project scope statement. The scope statement tries to specify what the scope of the project is. This is a sample scope statement. As the scope description here has project exclusions, what all is excluded from the project. It has a list of deliverables that the project will deliver at the end of the project completion. It has a project acceptance criteria, has project constraints listed in it and the assumptions that you make for the project. So now we come to the very important part of scope management which is called the work breakdown structure also called WBS. Here each process in the PMBOK guide is represented like this. You have inputs and you have tools and techniques during the process and you have an output. So here the inputs are the requirements document from the collect requirements process. You have the scope statement and you use decomposition to create the WBS and the output is the work breakdown structure. So this is the technique decomposition. It is a simple technique of breaking down larger chunks into smaller pieces, more manageable components until you get to the smallest level which is called the work package. So these now I am talking about deliverables. Deliverables are broken down into work packages, the smallest unit of work that needs to be done. All the work packages aggregated together will give you the entire scope of the project. This is an example of a WBS, again the slide is faded. So you see you have deliverables at different levels, broken down further into a hierarchy structure and numbered in a similar fashion. For example here in deliverable 3 you have work package 3.1, work package 3.2, 3.3 and so on. So once you have, so the WBS structure is a visual representation and to store the information of each work package you use the WBS dictionary where each work package is detailed and various things listed in this, even this slide is, anyway the important thing to note is that in the scope management knowledge area we come up with the WBS and the WBS dictionary. Then we move on to the time management knowledge area. This is where most of the project management softwares are used to manage the schedule of the project. So project time management will lead you to creating the schedule of the project. The definition is manage timely completion of the project. There are various processes in this which are really simple and straightforward. You define the activities, then you sequence the activities based on dependencies, then you estimate the resources that each activity requires for it to complete, then you estimate the duration of each activity and finally you develop the schedule and you control the schedule using a project management software while the project is going on. So time management is all about activities. So in the scope management we saw that we created the WBS structure and we ended up with work packages, the deliverables were broken down into work packages. Now each work package is taken up and broken down into activities that are needed to complete or deliver that particular work package. So here is an example of this diagram would make it very clear, it is a simple diagram. You have the WBS at the top listed down diagrammatically in a hierarchical fashion. So here one of the deliverable the work package is creating dinner because the project is about providing a banquet. So the activities for it could be to decide on the menu, create the shopping list to buy the ingredients, shop it, cook it and serve it. Simple example, once you have identified the activities required to deliver each work package in the WBS, now time to sequence the activities. Sequencing is based on logical relationship between the activities, can be performed manually or automatically using a project management software. Tools are the precedence diagramming method called PDM and dependency determination. So this is the precedence diagramming method, it is essentially creating a graphical representation of the schedule activities in the order in which they must be performed on the project. So here each activity is represented by these rectangles called nodes and these arrows represent the dependencies and relationship between each activity. So if this is a work package, the delivery of the work package will start from here and these are the sequence of activities that has to be done to complete that work package. So dependencies, there are four main types of dependencies between activities. This is snapshot taken from the Gantt chart that is generated in the end, we will come to it later. So four dependencies finished to start, this small blue line is the predecessor activity and the lower blue line is the successor activity. So finished to start means that the second activity can only start once the first activity is finished. There is another called finish to finish where only when the first activity finishes, the second activity will finish. It will wait for the first activity to finish till that time it cannot finish. Then you have start to start relationship where starting of the second activity depends on starting of the first one and start to finish. Start to finish is normally not used, you think about it, it is very difficult to find a situation where you have a activity where the second activity will finish only when the first activity starts. But anyway for the sake of completion it is listed in most of the books. Once you have sequenced all the activities to the network diagram, now it is time to estimate. First you estimate resources that are needed for each activity, resources in the sense that what are the types of resources, the quantities of each resources, the material required, people, equipment and other things, you can also estimate the cost of to do that activity. So again there are some tools and techniques used to estimate the resources. Expert judgment is based on the experience of previous projects, similar activities that the project manager may have done earlier can use that to estimate this new activity. Alternatives analysis is figuring out different alternatives of combinations of resources and choosing the best one. There are some estimating data published in books and journals that you can use. Bottom up estimating is essentially what we saw earlier, the process of decomposition where you take up the smaller package, estimate it first, keep on moving up and then the sum of all the estimation will give you the estimate of the upper activity. And this is all automatically done in the PM software. So what are the outputs of the estimate activity resources process, there are two outputs. One is the activity resource requirements and the other is the resource breakdown structure. As the name suggests the resource breakdown structure is similar to the work breakdown structure drawn in a similar fashion, hierarchical structure of resources by type and category. We will see an example of both. See here you can see in this table, this is the activity resource requirements document. These are the activities on this side and these are the resources that are needed for each activity. For example, number of people needed, the equipment needed, supplies needed, logistical requirements, funds needed and other information. This is an example of the resource breakdown structure where you identify the resources classic, organize them in types for example, people, equipment, materials and then you find out the quantity of each resource needed for the activity. Once you have estimated the resources required for each activity, you estimate the duration that is needed, the time that is will be needed to complete that activity. This is again progressively elaborated in the sense that if you have divided the project into milestones. So, milestones are again different from activities in the sense that milestones do not have a duration, milestone is a fixed date that you wake up the entire project duration into. For example, if your first milestone is coming up three months later, you choose only those activities which are needed for achieving that milestone and estimate the durations for that and you leave the other activities to be estimated later. This is what is meant by progressively elaborated. So, there are various tools and techniques to estimate the duration required to complete that activity. So, managers do not just magically come up with some numbers of numbers for estimating the duration. There are some techniques used to find out how much time an activity will take. We will go through a few, these are very simple techniques. If you read more about it, you will find more complex techniques being used in the real life scenario. For the sake of simplicity, I have not added them here. Expert judgment is one tool and technique which is used everywhere. So, second one is analogous estimation. So, this is an estimating technique where you take a similar activity that you have done earlier. You extrapolate from that based on the relationship. There is a simple example here that supposing you have done an activity earlier which took you three days and the activity that you are estimating right now is roughly twice the size of that. So, you assign six days to this activity. This is an example of analogous estimation. Then we come to parametric estimation. This is essentially using some algorithm or some formula, some mathematical function to come up with estimation. Simple example again at the end is supposing a developer can write 300 lines of code per day and totally you have 3000 lines of code to be written. So, you estimate that it will take 10 days to do it. So, this is a simple example of parametric estimation. There are very complex scenarios also for this. You can read further. This is the most popular estimating technique for activities. Most of you must have heard about it, Sulpert program evaluation and review technique. This is essentially a three-point estimating technique where for each activity you come up with three estimates of the duration. You think about the most probable time it will take to complete the activity. You come up with an optimistic estimate and you come up with a pessimistic worst-case scenario estimate. Since, by the name itself the most likely estimate will happen most likely. It is given a weighted average of four. It is multiplied by four and the formula is this. This is the optimistic estimate P O. P P is the pessimistic estimate. P M is the most likely estimate. This is multiplied by four. So, it is a weighted average that we are taking. So, we divide the six. So, there is another technique called reserve analysis. This comes from risk management which will come just after this. If you have done quantitative risk analysis, you come to know the buffer to be added to each activity if a certain risk really happens during the project. So, you have a contingency reserve which is maintained for known unknowns. Known unknowns are identified uncertainties in your project. So, there is an example if during your quantitative risk assessment you discovered that there was a 25 percent chance of to do a particular activity in 10 days. So, you add a contingency reserve of 2.5 days. I think these things are very simple and straightforward. See, it is part of time management when you are estimating the time required for each activity, but the inputs come from risk management. See it is mentioned here that activities, this buffer is to be added based on the quantitative analysis carried out as part of developing the risk register. You come to it later. So, finally, you get the schedule diagram, project schedule network diagrams. These diagrams are created automatically in any project management software including 0. So, this diagram shows you the activities, the dependencies between the activities and the duration of each activity on top. And then we come to another important concept called critical path method. So, critical path is that path of the activity which if any activity in that path is delayed the project overall gets delayed. So, this is the path that is identified and a close look is kept on this active this path. So, to make it more clear let us see this diagram. This supposing this is the start and we move from here to here. There are two paths from in this diagram. One is this dark bold arrows here and one is this. So, you calculate the number of days in each of these paths. So, the longest path is on the critical path. So, here the critical path is 3, 4, 5, 6, 9 days and the other path is 3, 4, 5, 6 days. So, essentially what it means is that any of these activities on the critical path if any of them are delayed by even a day the entire project is delayed. But the activities on the other path you have some slack time in the sense that even if it is delayed by one day the overall project will not get delayed. So, a delay in any one of the critical path activities will cause the entire project to be delayed. So, now the output of the time management knowledge area is the project schedule. Project schedule is usually represented as a grand chart this term also most of you must have heard. This is essentially a horizontal bar chart created automatically again in a project management software. This is an exam snapshot of a grand chart. Here are the activities that are listed and this is the calendar the duration estimates. So, these activities and the dependencies which are shown in red this is the critical path. And one of the important task of any project manager is to keep a close eye on this critical path and the activities in this so that the overall project is not delayed. So, once you have the grand chart ready you know the critical path and let us assume that after two months into the project you realize that the project is going beyond behind schedule. So, what do you do about it? So, there are two ways of compressing the schedule one is called crashing the schedule there is called fast tracking crashing essentially means adding more resources to the activity. So, that the activity is done sooner, but it also involves extra cost because you are adding more resources and fast tracking is essentially means identifying activities which can be done in parallel. So, that you can complete and make up with the lost time with these are the two techniques. So, here we end the time management knowledge area last one is risk management. So, what is a risk and how to deal with it risk can be any uncertain event or a condition that might affect the project not all risk are negative some events which occur could help the project such events are called opportunities. So, there are four ways to handle the risk this is an interesting diagram taken from a book how do you deal with risk? So, this guy is standing on a cliff and the risk is that he might follow. The first strategy is to avoid just walk away from the cliff if you have that option if you if you do not have that option then the second strategy is to mitigate the risk. So, that little as little damage is caused to the project as possible here if you can see there is some prevention for the fall. If there is another response which is called transfer transfer is you transfer the risk to somebody else in a in a project scenario one of the examples could be if some module requires technical competencies which our team do not have you outsource that project you pay some other organizing body which has expertise give money to them and they take the risk from you. And the last is if you cannot do any of these things you accept the risk but at least you have looked into all the alternatives and you know what is going to happen. So, this guy falls off eventually fine. So, there are these processes in the risk management knowledge area you have a risk management planning process which comes up with the risk management plan. So, then the first stage is identifying what the risk are then doing a qualitative risk analysis then doing a quantitative risk analysis then planning the response to each risk and monitoring and monitoring and controlling them. So, again we come to the third breakdown structure called the risk breakdown structure RBS to categorize the risk. Even before you start identifying the risk you come up with an RBS basically you come up with categories where you can put each identified risk into which is a good way of organizing the risk when you come back to them later. So, broad categories could be technical risk, external risk, organizational risk and so on. So, once an RBS is created you move on to identifying the risk. You identify each risk document them their characteristics this is an iterative process new risk may evolve or become known as the project progresses through its life cycle. Again it has various tools and techniques documentation reviews you review all the documentation and try to identify the risk that might happen in the future. There are information gathering techniques which we saw earlier during collect requirements phase like brainstorming, Delphi technique, interviewing, root cause analysis is one technique. Then there is a checklist analysis where you check all the risk that you have identified. Assumptions analysis are go back to your assumptions and try to identify the risk based on the assumptions. There are some diagramming techniques like cause and effect diagrams and influence diagrams and there is SWART analysis which I think most of us will be aware of strength, weaknesses, opportunities and threats. So we come to information gathering techniques to identify risk again these are the same things that we saw earlier. Brainstorming is the first thing that you do with your team get them all together in a room start pumping out ideas. Brainstorming sessions always have a facilitator so that chaos is not created. Then you have interviews which are again an important part of identifying risk. It is about trying to find everyone who might have an opinion ask them about what could be the risk because the sponsor the client will think about the project in a very different way than the project team will think about the project. Delphi technique is again anonymous question as given to experts and again circulating the responses got from them and root cause identification. This is a new technique in risk management. So root cause analysis one of the technique is Ishikawa fishbone diagram where you take the risk here list down the categories and then brainstorm on the risk and assign each risk to each category and try to find what is the root cause behind each risk. During this process you come up with many risk which you had not thought of before. So what analysis is one we need not explain this where you categorize the risk in these categories. So the output of all these processes in the risk management knowledge area is the risk register. This is the important document all the talk about this knowledge area is to create this document. This risk register list all the risk together the potential responses in the second column and the root causes that you got from the root cause analysis than earlier. So this is a risk register keeps on updating as the project progresses. There are two more processes qualitative risk analysis and quantitative risk analysis. In qualitative risk analysis the risk list of risk that you have identified you rank them. How do you rank the risk? You rank them based on their probability of happening and the impact they will have on the project. So you create a probability impact matrix. Quantitative risk analysis is assigning numbers basically you numerically analyze the effect of each risk on the overall project objective. This is very important in decision making if a risk happens. So this is a probability impact matrix. So horizontal is impact vertical is the probability. So the risk that are shown in red are high probability and high impact. So it is essential that I is kept on them throughout the project execution so that necessary actions could be taken if those risks actually occur. So now you updated the risk register after you have done the qualitative and quantitative risk analysis. You have two more columns where you rank them based on priority and based on the agency. Again plan risk responses we have seen the four broad methods of avoid, mitigate, transfer and accept. And for risks that are essentially opportunities they are called positive risk. You have four techniques first one is exploit the risk take the most of the opportunity share the risk if you cannot make the most out of it alone you share the risk the opportunity with somebody else. So both can benefit you enhance the chance of that risk happening by influencing the triggers of that risk. And the last one is accept. So we have ended the introduction to project management session. This was just a tip of the iceberg I have tried to keep it very simple. It is not as easy as it sounds but I wanted to share some key concepts like WBS activity duration estimation and network diagram, critical path, GAN chart and the risk register. We can have further sessions, detailed sessions later on if needed. So these are the sources and references. At first PMP is a very good book. Most of the funny diagrams that I have taken are from that book like this one. It makes it very easy to understand so called boring subject. When the PMBOK guide itself I have taken one slide from slide share dot net. So that is it. So we will begin the second session which will be an introduction to the JIRA software. It should be taken by Yubhan Sharma.