How to start using Portfolio for Jira? Resource planning.
Introduction
Many users have difficulty in the initial phase of using Portfolio for Jira. They try to start quickly, in connection with which arise many questions and difficulties and as a result they refuse Portfolio for Jira. How to understand the principle of the Portfolio? A slight immersion in the theoretical aspects of project management will help solve this problem.
About six months ago, I tried with all my might to figure out: "what is Portfolio?" and "what are its strengths"?
Having studied the product, I got the impression that the main difficulty at the “start” of use is not at all the complexity of the product, namely, the understanding of users of the theoretical foundations of project management (user goals achieved using Portfolio for Jira), which Portfolio definetely solves. Therefore, within the framework of this article, I want to dive a little into the theoretical foundations and to illustrate the methods of using them with the help of Portfolio for Jira.
Due to the large amount of theoretical information, as well as the complexity of the product itself, I plan to write several articles that will help new users to understand «How to start using Portfolio for Jira?».
In this article we will learn:
- What is Portfolio for Jira?
- What is project management?
- What is the “iron triangle”?
- What is resource planning?
- What is the resource for Portfolio for Jira?
- What depends on the resource plan?
- What does the resource plan depend on?
- Useful resources
What is Portfolio for Jira?
The agile roadmapping tool, built for Jira Software. (here you can get the high-level description of the tool, watch the video and determine the pricing policy of the product).
Portfolio helps you create plans, observe the big picture, track processes and easily share information with interested parties.
Portfolio works on the basis of the iron planning triangle, which defines scope, time and resources as the main constraints and planning parameters.
Portfolio not only provides visibility on your existing project data; it lets you plan different scenarios in a sandbox environment, view the outcome, and choose to keep or discard those changes. This scenario-based planning allows you to plan and (most importantly) re-plan, based on your team’s activity.
What is project management?
It is assumed that the theme of Project Management is widely discovered on the Internet, so I would mention only the definition of “Project Management” and its main concept (Iron Triangle).
Project management is the area of activity in which clear project objectives are determined and achieved while balancing between workload, resources (such as money, labor, materials, energy, space, and others), time, quality, and risk (PMBOK).
As we already know, most of the projects have a target date, budget, and scope of work. This trio of time, money, and scope of work are often called the project triangle (“iron triangle”).
For a project to be successful, these three factors must be balanced. There are other variants of the “iron triangle”, based on the type of project, where restrictions may vary depending on the type of industry, but the concept remains the same. If you break the Iron Triangle by making changes to one constraint, the other two must be adjusted accordingly, otherwise the quality will suffer.
Although all three elements are equally important for a project, as a rule, only one of them, depending on priorities, has the greatest impact on the others.
What is the iron triangle?
I highly recommend you to read the Atlassian article The Iron Triangle of Planning, this article is very detailed and interestingly described how the iron triangle is used in the waterfall development system (waterfall) and flexible development systems (Agile).
If you are a beginner or you do not mind to additionally study these methodologies, to know the main advantages and disadvantages of methodologies, then I would recommend the following article for reading.
According to the general opinion, the main asset and resource for almost every IT company is “the Company Team”. It is your team that makes projects, moves your company forward and earns money, and it is for salaries, bonuses, taxes, equipment, jobs and other payments to your team that account for the bulk of the company's expenses.
If at the right time you have an insufficient amount of your key resource, you will not be able to make an important project and miss the benefits. And if you have an excess of resources, you will incur losses by paying for the idle part of your team.
That is why in Portfolio "costs" are replaced by "resources".
As I said at the beginning, I plan to write several articles that will allow us to cover the topic of project management using Portfolio for Jira.
In this article, let's talk a little about resource planning.
What is resource planning?
According to PMBOK, it’s “determining what resources (people, equipment, materials, etc.) and what quantities of each should be used to perform project activities.”
For most creative and service-based companies the resources are people, so resource planning is a process you can use to identify team members you need to allocate for your project, and when you’re going to need them.
What’s important, resource plans may change and should be adjusted regularly to reflect changes in the scope, employees’ availability, etc, so that your schedule is always up-to-date.
What is the resource for Portfolio for Jira?
According to the Planning with Portfolio for Jira course, there are two approaches to managing a team using Portfolio for Jira:
- Team-level management is best suited to a Scrum process methodology, but can also be used with Kanban. One of the defining characteristics of a Scrum team is self-management. The entire Scrum team owns all of the issues in a given sprint. They decide, among themselves, how much work effort will go into each item, who will work on which items, and when bottlenecks come up during the daily standup meetings, they work together to remove them. Often this means that another developer steps in to help complete an issue. The team is well aware of the skillsets of each member, which is helpful for issue assignment.
- Individual level management is best suited to capacity planning, but not actually affecting the team task assignments. It just helps planners (development managers, especially) see the effects of team member assignment, scheduled time off, new hire scenarios, and even potential team sharing scenarios.
Before proceeding to planning, we first need to create teams and fill them with people (employees) with certain skills (by filling in the appropriate tabs).
Portfolio provides the ability to create "shared teams" that can be used in various plans and programs.
At the plan level, we should:
- to define an Agile board for each team;
- to determine the method by which the SCRUM or KANBAN command works;
-
- to define “planning unit”;
- to create “work stages” and set the correspondence with skills (it is possible to use “shared” skills or unique for the current plan);
- to determine for each employee the skills available to him and / or assign to certain stages of work;
- to define for each employee “the number of working hours per week” (weekly hours).
As a result, we get at the level of our plan: what teams we have, its possible weekly capacity and the specialization of its employees.
Let's further delve into the theory and try to understand “what depends on the resource plan?” and “What does the resource plan depend on?”
What depends on the resource plan?
- The correctness of the calculation of project marginality and financial plan. In each company plan finances. The revenue side of the company is the profit of the projects. If the project is less profitable than it was predicted at its start, the company will not receive the money it was counting on.
- Timeliness of closing open positions in the project team.Portfolio offers to solve the problem with the help of "virtual employees" or even "virtual teams"! Moreover, you can even specify the stages of work and with the involvement of potential employees (candidates), which will allow us to carry out planning, to create various scenarios (the planning process, which I will discuss in my next article). Thus, we will have a clear vision of what employees are missing in the team and the ability to inform the HR service in time.
- HR-service workload. What does HR get to work? Usually, HR gets to work the result of the analysis of the consolidated resource plans by resource managers in the form of a plan of unmet need for certain specialists. With this approach, HR understands what it is working on, seeing a summary image for all projects, and resource managers see the resource risks of projects and have the opportunity to prepare alternative options in case HR does not have time. Portfolio for Jira also allows you to solve this problem - for example, you can immediately see how the timing of project implementation changes as a result of an increase in the number of teams, the number of employees in a team, the development of new skills of employees and more.Also, you can always quickly predict the loading of teams using the Portfolio reports. An example of a report that shows us the team capacity (note that the load for KANBAN teams and SCRUM teams is measured differently).
- The optimal use of resources. You can get the same result in different ways. You can draw such a resource plan that some employees will be underutilized (we pay for idle hours), and some - overloaded (we pay at a double rate). In order to avoid such situations, resource plans are optimized both at the level of a specific project manager, and at the level of program managers and resource managers. As in the previous paragraph, we can use Portfolio for Jira to solve this problem, there are many options, how can we identify the indicator we need in a couple of clicks, for example, use quick filters or team capacity.
- The overall performance of the company. The conclusion that suggests itself - a company where well-planned resource planning is more likely to be an efficient company. And vice versa - if resource planning is lame, then the company constantly experiences a shortage, then an excess of resources and the cost of man-hours, compared with the first type of company, all other things being equal, is significantly higher. And that means lower profits that could be directed to the development of the company.
What does the resource plan depend on?
Let's think about what we need to have in order for us to make the first version of the resource plan. Of course it is the work assessment (I plan to see it in detail in my next article), the timing, complexity and coherence of the work (I also want to consider how task relationships(links) affect the work of Portfolio for Jira), budget and delivery methodology. So let's look at how each of these points affects the resource plan.
- The correctness of the initial assessment of the main scope. As we all know, the JIRA time tracking feature allows users to record the time they spend working on problems.
- The correctness and realistic timing of the project. The customer often places very tight deadlines for the execution of work, as a rule, to hedge up in case something goes wrong. In general, the rule works: “shortening of time can be compensated by additional employees”. Reducing the project timeframe (at a given labor input) leads not only to an increase in the number of performers, but also to an increase in the cost of managing the project. Of course, this is displayed in the resource plan. One of the biggest benefits of Portfolio is the ability to try out different What-If scenarios (I will try to tell you about it in the next article).
- Delivery methodology. Everything is simple - whether we work on one of the Agile methodologies, the classical or iterative Waterfall, each methodology requires a certain structure and logic of project management, team structure and configuration of the resource plan.
- The complexity and work dependences. In most cases, it is impossible to make a quality resource plan without first analyzing the structure of the work and identifying dependencies between the components of the project (I will also try to reveal it in the planning article in Portfolio).
- Budget. The budget is one of the determining factors when choosing a team in resource planning.
- The presence of the contract warranty. Many people forget about this stage of work. Often, resource planning ends with the stage of putting the system into operation. And the fact that then it must be serviced for a year under warranty is not in the resource plan, nor in the calculation of the project’s economy. Such an approach is possible only if we expect to conclude a separate contract for technical support. In any other case, the lack of resources provided for the implementation of warranty support will be a mistake that will complicate the life of resource managers, make the financial forecast wrong and distort the economic parameters of the project. The uniqueness of Portfolio is that you can easily consider additional off-project works.
- Universality of team members. We have to take into account the restrictions that impose specific skills of the members of the project team on resource planning. As we have already reviewed earlier in this article, Portfolio allows you to flexibly break a task into stages and specify the necessary skills for each of the stages.
- Quality and change management approach. This is a separate and very big topic. It is good if you live within one of the flexible methodologies(Agile). At the stage of resource planning, it is very important to understand which resources are reserved.
- The possibility of sharing resources. If we are talking about the program where you can share resources with colleagues from neighboring projects, then resource planning conditions become much more comfortable - you have the opportunity to plan ½, ⅓, ¼ FTE (full time employee), as the rest of the time will be involved in other projects. I would also like to note that in Portfolio we can involve one person in several teams and projects or programs at once, indicating at the same time the potential load of an employee for each team.
- Vacation. In the first version of the resource plan, when there is a rough estimate of the need for staff, it is quite permissible not to bother with regard to vacations. But when it comes to the resource plan, as a tool for daily project management, then it becomes very dangerous not to take into account non-working days. Portfolio provides an opportunity at the level of each team member to indicate:
- Global availability;
- Absences;
- Team availability;
- Exceptions.
- Holidays. If we talk about distributed teams where people work from different countries, each country has its own national holidays and the project manager will just have to learn a little about the culture of the countries where his team members work to create an accurate resource plan taking into account the holidays. And if not, you can go back to the previous point and double the deliberately put down shortage of labor hours and difficulties in the project. We use a similar approach with vacations. Perhaps,do you know how to fix a specific calendar with national holidays for each team?
Conclusion:
Well, having understood the theory of resource planning, supported by examples of the use of Portfolio, you can deal with many issues that arise for new users. Successes!
Was this helpful?
Thanks!
Alexander Bondarev
About this author
Atlassian Certified Expert
Russia, Moscow
131 accepted answers
3 comments