Hello, project manager. Most probably you have
just watched a random video on a tool, technique or
process in project management, but it's still not clear how does project management
work as a whole, as a system. In the next hour, I'll share my whole practical
project management approach that I use in the real
world with real people. So without what I do, let's dive in. First of all, we need a correct mindset
towards project management. Many project managers fail
to answer a basic question. What is a project? A project is a time limited endeavor to create a unique
product, service or result, but here's what's the standard definition. We produce unique results in order to achieve a specific business goal. Therefore, project
management is the application of skills, knowledge,
and tools to increase a project's chances for success in reaching its business objective, not to create some random
products or services. Yes, this mindset makes project
management harder for you, but it results in exceptional
products, client satisfaction, and your career growth. Also, as the definition says, a project is a time limited endeavor. It means it has a start and an end. So most of the work happens
in between these points. This leads us to the first critical
project management concept, the project life cycle. Right at the start of a project, we break it down into phases
to make it more manageable and phases usually include specific work to produce one of the
pieces of our project. Moreover, these phases may consist of work different in nature. So for example, on a large
software development project, we may have the following phases: Pre-sales, project initiation,
concept development, prototyping, planning, requirements
definition, UI designs, development, integration,
testing, deployment, hypercare, maintenance, and handoff, closure or support phases. For sure it's a list
of all possible phases, but you don't use them all in
every single project you lead. But in any case on a big project, each phase may take several
weeks to several months so you can treat them
as small sub project. On a small project, these
phases mixed together, and it's hard to differentiate them, but here's what you need to understand. You can and should use
different processes and tools or even different project
management approaches in each phase. For example, you'll use this
current framework to manage the implementation phase
of a software project. That's precisely how
agile project management with Scrum or Kanban works, but you'll never use Scrum
to manage UI design creation or handoff phase. For those phases, you'll
use something simplistic. For example, you'll track
tasks and their due dates. It sounds complicated, but
here's great news for you. If you work in one industry
for the most of your career, you need to learn no more than two or three typical project life cycles. I want to pause here and
stress out the importance of what you learn just now, especially if you are not
a project manager yet. You see, the industry
and niche where you work will dictate the available life cycles and project management approaches. So if you already know
where you want to work, you need to focus your attention
on those life cycles only. You don't need to learn the whole project
management knowledge domain, but there is one more limiting
factor of your choices for processes, tools, and
techniques that you can use. So let's get back and pay
close attention to this. You see, you don't run
projects in a vacuum. You always lead projects
inside environment of the organization where you work. As a result, you always have many
custom processes, policies, and tools that emerge from the organization's
business administration. So you can simply ignore the environment and do project management
at your own discretion. It will produce too much
friction and inefficiency. So instead you have to play
along with the environment. In the real world, each company develops its own
project management approach based on its needs. Therefore, there is no such thing as standard project management. That's why project management is more like Frankenstein's monster
tailored in one piece rather than a seamless Captain America. For the same reasons, popular project management certifications won't help you become a
better project manager. With this in mind, let's
consider two cases. First, you work in an organization and you run a so called in-house project. It's a project for the needs
of the organization itself. In this case, you have only
one environment to deal with. Second, you work in
client-vendor relationships. You have your organization, a so-called performing organization, and you have a client's organization. They operate in completely different ways and that's a real world challenge. You have to take into
account the requirements of both organizations to run a project and find common grounds. It includes life cycle,
processes, tools, roles, responsibilities and approaches. On the bright side, your environment should
provide you with office space, hiring department, templates, project management
software, lessons learned, best practices from other projects and access to subject matter experts. So in most cases, your environment should
help you run the project. Usually it takes off the burden of organizing every aspect of
the workplace for your team so you can focus on your project work. So again, you should always align your project management approach with the environment where you work. It should be like swimming with
the current, not against it. And now is a great moment to start talking about
project stakeholders. A stakeholder is an individual
group or organization that may affect, be affected
by or even perceive itself to be affected by a decision, activity or outcome of a project according to the definition
from the PMI's PM guide. So in other words, your client, the project owners are your
stakeholders, but likewise, your boss, some team members
and subject matter experts are also stakeholders of the project. So stakeholders are all possible
people and organizations who may gain or lose
because of your project. There are many types of stakeholders and many reasons why
they care about project and that's why you need
to identify them all. Here, you start using
a stakeholder register to capture all the information
about stakeholders, and then you need to
perform stakeholder analysis and decide how you want to
interact with each of them. Here's what I want you to remember. Stakeholders provide requirements. Some of them provide requirements towards the product or
service you need to create, others provide requirements towards your project management approach. They want you to use in their environment. And here's a critical part. It's your responsibility to
collect all the requirements from all stakeholders for your project. In the real world, if you misidentifying
important requirements from an important stakeholder,
it'll be your fault. In the worst case scenario, this stakeholder will use their authority to force you to include the
requirements into the project. You have to change your
project management plan, explain to other stakeholders
how it would happen and maybe ask for
additional budget and time and usually it's an
unpleasant conversation, or even it may put the whole
project at risk of failure. So for example, you have almost finished
building an expensive house in the woods, but somehow
you fail to identify an environmental organization
as a stakeholder. It appeared your house didn't comply with their environmental
policies for these area, which you failed to identify
at the start of the project. Now you have to pay a fine
and change the heating system of your house so it results in additional
expenses and a rework. You must identify key
stakeholders early in the project, but likewise, you should be on the lookout for other stakeholders throughout the project's lifetime. In the real world, if you work
in the company for some time, you should already know
many internal stakeholders. And in fact, you need
to continuously build working relationships with them. Not only when your project
starts and after that, you need to identify external stakeholders from the client side and
those from your industry or niche that may impact your project. Now we have set the stage
for a project to start. Let's get back into the lecture room. So imagine the client's organization, they have a business need to
develop a product or service, but they don't have the expertise and human resources to do that. They start searching for
a vendor organization that can help. As a result, their representatives
contact the sales team in your organization. That's how the pre-sales
phase of a project begins. You see, before it gets into
the project management reel, the sales team and the
client should negotiate the terms and conditions of a contract. As a project manager, you may help the sales team
to develop realistic terms. So you may need to perform
super high level planning here to ensure visibility and
identify the duration and the budget for the project. Here's a critical point
where theoretical books on project management may mislead you. They talk about risk
management way too late. In the real world, you start risk management
activities in the pre-sales phase. You may have critical risks right at the beginning of the project. Moreover, there might be urgent risks that you need to resolve right away. For example, such risks
may embed a problem at the start of the project that will fire up late
during the execution, or it may simply kill
the project's visibility before it starts because
you missed an opportunity. That's why you do risk
management continuously and the framework may be
as simple as this one. You continuously apply risk
identification techniques in all project activities. And the simplest one is
always to ask the team and stakeholders, do
you see any risk here? Then you log or identify the
risks into their risk register. After that, you perform risk analysis, you should do qualitative risk analysis and you may consider the a
quantitative one in some cases, then you select several
most critical risks and developer risk response
plans based on your analysis. There is one critical concept about creating risk response
plans that I'll explain later when we talk about planning. So then during execution, you monitor risks and
implement risk response plans. In essence, this process never stops during the whole project lifetime, but again, in early stages of the project, you usually focus more
on identifying risks and you are always on the
lookout for those urgent and critical risks that
can ruin the project. But let's get back to the pre-sales phase. Again, the outcome of this phase should be assigned
contract with the client. Quite often, clients talk
about their real goals for the project during
the pre-sales phase, but here's the case. Usually a contract doesn't
include all those details of a project. Instead it outlines only the
overall business relationships between our organizations. If you don't participate in this phase, you need to find a way to get access to the notes, emails, and
agreements that were made here. On the other hand, a contract may have a strict
deadline or total budget for the project. It's a constraint for you so you should know about it. In any case, whether you participated in
the pre-sale phase or not, next you need to initiate a project. It's a transition from the
sales and contract negotiations into project management. And as you remember from the definition, we need to identify three things: The business objective, the unique result we're going
to produce and the boundaries of the project. And in practice to initiate a project, we use a tool called a project charter. So the project charter
includes high level information about the project and
we need this information before we start planning process. Project charter is a simple text document. You can use it in Word, in Google Docs or in email if you want. I also recommend that if you
use a project management tool, keep the project charter
right inside there. A project charter usually
includes project description, business case, project objectives, preassign the resources,
stakeholders, known requirements, description of product,
services and major deliverables, assumptions, constraints,
and project risks. Keep in mind that it's not
a comprehensive description of the project. The project charter should be
no more than five pages long. The shorter, the better. In the real world, you may need to create a formal
document, but in most cases, you'll simply collect this information and talk through it
with your project owners so you need to develop
a common understanding of the project. It's critical because in the process, you remove lots of
miscommunications right at the start and also you begin to control
the client's expectations. You do it by showing what's
in the scope of the project. What are the boundaries of the project? And whether the constraints look realistic to develop the results that were outlined in the project charter, but
what's even more important, you should align all your future efforts with the project charter. You need to question
everything that doesn't align with the project goal or
business case in this charter. Now let me show you why it's so important to have a project charter and how we use all this information. After getting a sign off
on the project charter, you need to pause. Take a broader look at
the project charter, contract your clients, your
environment, available tools, process and templates and
everything else at your disposal. Now you must decide what
project management approach to take and what frameworks
to use, but again, it's all based on the project life cycle. So it's not like you need
to invent something new. You need to choose from one, two, maybe three available
options in your organization. Then of course you'll need to
adjust them a bit to the needs of a project, but in most cases, you'll simply follow the organization's established project
management approach as is. Next, you need to outline
a project management plan, and I want to stress this out once more. A project plan may be a mandatory document in some industries so it should contain all the details, but the majority of projects don't need a fully written plan so it's totally fine to
keep it all in your head until all stakeholders understand how you manage the project. However, if you have never created a formal project management plan, I recommend doing this
exercise at least once. So take the major project
management knowledge domains that PMI describes: Integration, scope, time,
cost, budget, quality, risk, stakeholders,
communication, resources, and procurement management. Now list all the processes, tools, templates, and workflows
inside your organization. Then illustrate how they
interact with each other. This exercise will help you identify weak spots and inefficiencies in your project management
approach and knowledge. In addition, it will help
you systemize your knowledge and understand the whole system. At this point, we start planning process. Following the project management
approach, we select it, but there are two fundamental
principles you need to follow. First, you plan the project specifically to reach the objective stated
in the project charter. Second, you focus on
specifying and digging deeper into the high level information
you captured in the chapter. These two principles will safeguard you from spending resources on
something clients didn't ask for. Moreover, it will keep your
clients expanding demands within the constraints and
boundaries of the project. On the other hand, if clients want to adjust
project objectives, it's totally fine, but they
need to update the charter, which will allow you to renegotiate project budget, timeline, and scope. So as the starting point of planning, we need to take high level requirements and scope of the project
from the project chart. We break these requirements
into smaller pieces and start to work out the details
of each requirement. Then if needed, we write specifications,
user stories, draw mockups, wire frames and so on. So first you need to collect
business requirements from the clients. Then you need to identify
stakeholder requirements from clients and subject matter experts of all relevant fields. And after that, you need to work with your project team and subject matter experts
to produce solutions and specific product
or system requirements. So that's why stakeholder identification starts here as well and it continues throughout
the whole planning process. Again, keep in mind that
each new stakeholder may provide you with new requirements, but what's even more important, your goal here is to ensure
that all stakeholders press you, the project's objective
in the first place. To help you manage
stakeholder requirements, you can use requirements
traceability metrics. It's just a spreadsheet that
maps all project requirements to stakeholders who requested them, project objectives that these
requirements help to achieve, work breakdown, structure elements, and any other aspects of a project. By the way, I believe you should not
collect requirements yourself. Business analyst is a
dedicated role on a project specifically trained to collect
requirements professionally. But in any case, when you
define the requirements, you also need to think
about quality management. In essence, the quality of the product is the part of the project scope. You see later, you will need to identify specific tasks and make resources of time and resources so that your team can ensure
quality and fix defects. Here's another intervention
from the real world. In many industries, you can start implementing
the product or service before you have collected
all the requirements and finished planning. In this case, you can apply the rolling wave planning technique. This is a progressive operation technique in which you plan for
the imminent requirements in all the details, but requirements that
are logical in the future can remain on a high level. Nevertheless, you do plan
for these future requirements on a high level in all
terms of project management, like project scope, budget,
schedule, risks, and other, and yes, you do it right at
the start or the project. And you go is to allocate
enough time and resources so that you can implement
these requirements considering all the uncertainties
you have at the moment. That's exactly why you don't
spend months planning out the whole project in for
example, waterfall methodology, or any other planned driven methodologies. Instead, you plan for the
next few weeks of work in all the details and you
keep the rest on a high level, but then during the execution, you elaborate on your
project man piece by piece. So keep this specific technique in mind because your overall
project management approach should allow for
additional efforts required to operate your project management plan. And if you apply the rolling
wave planning technique, then all the processes and tools that you use will be
impacted by this decision. No matter what planning technique you use, the next step is vital. You need to transition from
the abstract requirements to tangible results that your
project team will create. These tangible results
or parts of the project are called deliverables and
here's the main challenge. Unfortunately, there
are no simple techniques or step by step instructions for this transition. From one side, your industry
and the nature of the project will dictate the most common deliverables. On the other hand, you need to decide which
deliverables will include which sets of requirements
and the requirement's traceability metrics combined with the word breakdown structure may help you map requirements
to specific deliverables so this way you can ensure you don't forget about this
requirements in the process. It's a critical concept, and we'll get back to it in a
minute so stick with me here, because first you need to create the project scope statement. It's another critical checkpoint
in project management. You see, you collected requirements and identified deliverables, but don't assume that your clients have the same industry knowledge and understanding as you do. You need to explain what they will get as the result of the project. So the project scope statement describes all project deliverables
and how you will create them in simple language. Clients should understand what you'll do, even in a technical industry. It's critical because next
you'll put a lot of time and effort into creating
a plan to implement those exact deliverables and as a result, you'll spend all the allocated
resources of the project to create those deliverables. So you've got to be
certain that that's exactly what your clients need. Moreover, they should be
confident that these deliverables will help them reach the
project's business objectives. Ideally, clients need to put a signature on this scope statement. Next, we have another
critical integration point. We need to transfer deliverables
that clients signed off from scope statement into
work breakdown structure. The work breakdown structure
is the tool that helps you break down the whole project
scope and identify 100% of it. And by the way, project scope is simply the
description of all the work that your project team needs to do to create these deliverables. Usually we describe them as tasks. From a practical standpoint, I recommend that you keep
the naming of deliverables and the meaning that comes from clients. You're still watching, good for
you because now we are going to talk about cool stuff, the
project management software. As you already understand,
there will be hundreds of tasks. These tasks will have lots of attributes and then you'll assign dependencies and line them up on a gun chart. So tracking all these attributes
manually, for example, in Excel is a waste of
your time and effort. Making a change in the project
management plan like that will be painful as hell. That's exactly why creating
a work breakdown structure is the common starting point for all these project management
software applications. So the decomposition of deliverables and the rest of the steps
I will explain further should happen in the
dedicated PM software. And in general, you should try to keep all project information in one tool right from the start. A word of warning though, any project management
application is dumb. It's just a fancy calculator so it does what you tell it to do. So if you use incorrect
project management principles, for example, the principles of creating a high quality work breakdown structure. Your software will give
you a misleading picture. Therefore, you must understand the underlying project
management principles used in these apps. That's why we are going
back and will discuss the decomposition technique
in project management and here are the key principles. WBS consists of big
pieces of tangible results that we call deliverables and small pieces called work packages. This all have unique identifiers that clearly state their
position in the structure. So we put deliverables
from the scope statement on the first level of decomposition. The idea is that we first
list all the major pieces of the project. Then we need to decompose each deliverable into smaller components,
the work packages. Again, work packages
should also be finished, tangible and testable pieces
of the project, but smaller. The rule of thumb from
the practical standpoint is to make work packages
small enough to fit within reporting period and
here's another important rule. If something is not in the
work breakdown structure, it's not a part of the project. You see, it means that
if you can't logically put a piece of work under one of the major deliverables, you most likely fail to identify
100% of the project scope in the beginning. It's a warning sign of scope creek. Next we go one step further. We decompose and breakdown all
the work packages into tasks. Ideally again, from practical standpoint, one team member should
be able to finish a task from start to finish and from experience, I prefer tasks no longer
than three working days. Such level of decomposition
provides better accuracy. By the way, some way at
this point in planning, you may also need to start thinking about whether you need to outsource
some project deliverables. It's called make or buy decisions. Many considerations go
into these decisions. The major one is whether your organization has the required resources and expertise to implement all these
deliverables, but let's move on. We have decomposed the
work packages into tasks. Now our goal is to estimate each task. Usually we start by assessing
what kind of resources we need to finish this task. You need to think about people, their skill set and
their level of expertise. If you don't have a team yet, you have to create these role descriptions for the recruitment department. Or if you have a team already, you can assign people
to the tasks at once. On the other hand, we need
to analyze what equipment, materials and tools we
need for these tasks. So then we need to plan to
acquire all these resources. Sometimes a company has a pool of people we can take for our project, so we'll need to negotiate
internally, but likewise, we may need to hire these people. From an equipment and
materials perspective, we have the same situation. The company may have the
stock that we can use. It may have a list of
vendors that we can contract, or we may need to find all
these vendors from scratch. These analysis of required resources will result in two separate documents. The first one is the human
resources acquisition plan. Nothing scary here, it's
just the list of vacant roles on your project and the dates when you need them to join the team. The second document is the
procurement management plan. Again, you need to plan how
you will acquire equipment, tools and materials,
and when you expect it. So here you may need to engage with the procurement department or procurement manager
of your organization. In any case, these two plans will impact your schedule because we can't hire people the next day when we need them, it may take months. The same goes for equipment and materials. Your project schedule will have due dates for all those resources. Now we need to estimate
the duration it takes for the assigned roles or real
people to finish each task. And a critical side note here, you as a project manager should
not estimate task yourself. If you have the team already,
obviously they do it. However, if you don't
have any team members, you should ask for a preassigned expert to help you out here. So always consider the
average productivity of a role based on the experience
level you identified, not the knowledge level of an
expert who does the estimates. With all this information, we can assign dependencies between tasks and create a draft of
the project schedule. You have to play around to create a final and realistic version of this schedule so here is a step by step
instruction on how to do it. You can pause now and read through this. Next we can also find average
prices for the materials and hourly rates for the type
and level of labor we need so we can easily calculate
the total cost of a task. The idea is to perform
the bottom up estimate. First, you estimate all tasks, then summarize them to
the work package level. Then you summarize work packages
to the deliverables level. As a result, you can create a
draft of the project budget. Another critical note here, what I've just described is a generic way of estimating task, but if you work in the
software development industry, for example, you have a prepared team for the next few months, or if you work in a company that uses only in-house resources, there is no need to do it this way. So rather than assigning resources, estimating the duration and calculating the cost of the task, you directly estimated in
efforts in person hours for an average role that
you will have on your team. So in this case, you are more interested
in leveling resources and ensuring that you are using
all the available efforts. Let's get back to planning process. I keep telling you that you
have created the draft version of the schedule and budget. That's because we need to perform
risk management activities before we can finalize the project plan. We've been identifying and analyzing risks since the start of the project. Now we need to run dedicated
risk identification sessions based on the draft of our
project management plan. Then we need to finalize the analysis, select the risk we need to address and develop risk response plans, but what does it mean to
create a risk response plan? First, it means that you come up with a specific action plan. Then someone needs to execute the plan. Moreover, they may need money and other resources to do that. So in essence, it means
you need to add tasks. Also you can allocate additional time or money to overcome negative effects of a risk if it happens. So each risk response
plan should become a part of the project scope schedule and budget. By the way, sometimes you'll also introduce
new processes and tools to overcome a risk or
even a group of risks. In this case, you must ensure that these new processes will work well with other
processes and tools. Also, you need to ensure that stakeholders are okay with these changes. After all these updates to the project management
plan, it will change. You need to validate
that it's still feasible so you literally go to the
beginning of the process and quickly run all the checks that we have discussed so far. The last critical step here is
to create project baselines. A baseline is nothing more
than the final approved version of project scope, schedule and budget. Baselines are critical for any project management approach. They will help you to track progress towards the initial goal. Let me try to explain the importance of this project management concept. Imagine you are a captain of a ship. You need to sail from port A to port B. In the real world, a single vessel can leave a
port without plotted route, it's not allowed. The idea is that you have a plotted path and you continuously track
your progress along this path. If you deviate from this path, you adjust course to
get back to this line, you don't change the whole route. Now imagine you don't
have this plotted path. You only have direction. In this example, even
following straight north, you may end up in a
completely different world after a slight deviation. So I want you to remember that you don't merely manage the work on the project. You execute the project
management plan you created. I can't stress enough how important it is. The plan gives you planned values of all aspects of the project. That in the process of
executing the project, you collect the actual
values and in the real world, nothing goes as planned. Now, if we talk about
professional project management, you need to track all aspects
of the project the same way, quality, communication,
stakeholder engagement, motivation of the team,
acquiring resources, everything. If you see deviation, you start applying productivity
techniques, motivation, leadership tricks and maybe
even a bit of micromanagement to get back to the initial plan. Only if the deviation is too big, you need to start
negotiating to make a change in the project plan, specifically
in project baselines. These are changes in deadlines,
budget, and scope of work, but you need to ensure
that after this change, you'll be able to finish the project with the updated baselines
and most importantly, you won't be asking for
another change request for the same problem in a week or two. Finally, we are now
getting into the execution of your project. I have finished planning the project, so it will go smoothly now. Now this project manager can take a rest, but for some reason I have a bad feeling. So jokes aside, your project management plan
simply outlines the work, but it doesn't have all the detailed instructions
for technical problems. It doesn't solve conflicts
and of course your plan doesn't motivate people to act. So you need to encourage
and facilitate interactions between team members, stakeholders, and subject matter experts on daily basis. You need to motivate them
to search for solutions to technical problems and implement them according to your project management plan. Then you need to resolve
conflicts, remove impediments, track progress, interviews,
performance reviews, one-on-one meetings,
trainings, discussions, and so on and on and on. All these activities transform into some sort of communication. Most likely it will be
additional meetings, emails, phone calls, documentation,
and things like that. And overall, you will
communicate about 80% of your work day. So your goal is to ensure
that the team works on the tasks they need to work
on today and additionally, you look a few days ahead to ensure that there are no blockers. So you see, planning
was an intensive period, but it's relatively short
compared to upcoming execution and execution of the
project is a daily grind. That is why I recommend that you establish daily project routines. They will help you to keep
your sanity and control over the project. So here are the routines
I recommend to have. First of all, project
information maintenance routine. You must dedicate up to half an hour a day to ensure that all team
members report their progress, log their time, expenses, risks, and other performance data in the project management software. It's better to do it
daily rather than scramble all this information late
in the Fridays evening when you need to send a progress report. Second, a daily sync up
meeting with the team. It's a short meeting
where team members report on their daily progress and problems and it's your opportunity to correct the team's work if needed. Third, daily sync up with
clients and project owners. Ideally you want to keep
project owners up to date and engaged on daily basis. Fourth, daily motivational routine. Dedicate 30 minutes per day to motivate one or two team members. Don't wait for a special event
to connect with these people. These small meaningful
interactions have a great effect. Fifth is the communication routine. Specifically, I'm talking about
writing emails and reports. I recommend that you reply
to emails at specific times. Pick two, three or maybe
four times slots per day, and be intentional to clean up your inbox and answer all important emails. Also, you can put meetings in batches. It will give you free time
slots for deeper work. And again, remember that you
must continuously dedicate time to enrolling wave planning. You need to work with the
team to collect requirements, vacant polls and estimate future tasks, add details to your schedule and budget. Let's get back. I have one more critical
thing to share with you. So here's the problem as I see it. In this video, I've just
scratched the surface. You can try and search
all these processes, tools and techniques on YouTube, but then you still need to find a way to make it all work together as a whole. So instead, let me ask you this. Do you want me to explain this whole project management
framework in all the details? I'm asking because you
watch this long video, even though you are
extremely busy for a reason. Maybe you want to become
a project manager, but you don't know where to start, what to learn and how to get your first project management job, or you are a junior project
manager who struggles with mastering all this
risk management, leadership, stakeholders and how to
manage an experienced team, or maybe you are a mid-level PM already, and you want to become a great
project manager and leader, but you already know that PMP or PRINCE2 won't help you in the real world. In any case, as I see it, you have only two options here. Number one, you try to get
through it on your own, and you are in the same
place this time next year, with lots of wasted effort
and no further promotion and option number two, you 100% commit to mastering practical project management
framework in the next 30 days using a proven roadmap. You are going to make
this decision right now. That's why I'm so excited to let you know that my practical project
management online course is exactly what you need. I've used my 10 years of experience as a software project manager
and created a framework that anyone can use in the real world. Hundreds of students proved that. As a result, you get a comprehensive
course on project management with about 15 hours of
educational videos like this one, but broken down into
smaller digestible pieces and all these videos cover all the details that we outlined today. It literally contains
everything you need to know about project management
for the rest of your career. And the best thing about this course is that you get lifetime access. It means you can learn at your own pace, but also it means you can
get back to the course whenever you need to
refresh your knowledge because your career will
get a serious boost, you will start running more significant and more complex projects and I know you might be thinking
right now, okay, Dmytro, that's a unique and profound course, show me what I need to pay for it and actually I might
have charged you $1,000. The program is that good. There is a lot of value that you don't get from any other online course
because this one comes from my practical
experience, not from theory, but I am really passionate
about my profession. I believe that if I train you, there will be one more
great leader in the world. So I made the course as
affordable as possible. That's why go check the
details of the course and all its bonuses, then compare it with the price tag and your decision should be a no brainer. Go get the course today. (bright music)