CompTIA Project+ PK0-003

Project Planning

by Steve Caseley

Start your 7-day free trial today.

This video is only available to subscribers.

A free trial includes:

  • Unlimited 24/7 access to our entire IT training video library.
  • Ability to train on the go with our mobile website and iOS/Android apps.
  • Note-taking, bookmarking, speed control, and closed captioning features.

What is Project Management

Project+ and how to prepare for the exam

Pre-Project Setup

Project Planning

00:00:00 - Welcome back to the second half of the first part of the Project
00:00:03 - Plus. Last nugget in this nugget is focused on the first part
00:00:08 - of Project Plus Certification which is the pre-project setup
00:00:10 - and initiating. In the previous nugget we covered the first three
00:00:14 - components, requirements for pre-project setup, project characteristics,
00:00:18 - and project validation. In this nugget we're going to finish
00:00:21 - this section off, we're going to talk about the all important
00:00:24 - project charter. You've had some references to the project charter
00:00:28 - already. This is the final deliverable
00:00:34 - and really it's the only deliverable
00:00:37 - from project setup and initiation. And project charter is the
00:00:42 - foundation document
00:00:47 - for the project. It defines the business reasons and it provides
00:00:52 - the business justifications for our project and we're going to
00:00:56 - spend a considerable amount of time in this nugget discussing
00:00:58 - the project charter. After that we will conclude this nugget
00:01:03 - on a discussion of the project life cycle and how the project
00:01:08 - life cycle supports overall project delivery and we'll touch
00:01:13 - a little bit on organizational structures and what impact different
00:01:18 - organizational structures are going to have on your ability to
00:01:22 - be an effective project manager and this is really a continuation
00:01:25 - of the discussion we had in the last nugget related to the differences
00:01:29 - between operational management and Project Management. But first
00:01:33 - let's dive in and look at what's in our project charter. As
00:01:38 - I just mentioned the project charter is a key deliverable
00:01:45 - from project initiation,
00:01:48 - from PI, project initiation. It is the definition
00:01:57 - of what it is
00:02:00 - the project should do
00:02:08 - and as I mentioned it's the foundation for all the other activity
00:02:11 - we're going to undertake for our project.
00:02:15 - Project Plus suggests your project charter should contain all
00:02:19 - of these components. I'm going to share with you in a few minutes
00:02:23 - a template of a project charter that I have used for many, many
00:02:26 - projects. It contains all of these components. I have done some
00:02:30 - degree of summarization, i.e. my table of contents in my template
00:02:36 - doesn't have a section in the table of contents for each and
00:02:39 - everyone of these components but it certainly contains all of
00:02:43 - the components defined in the Project Plus for a project charter. But
00:02:48 - let's spend a few minutes discussing how the project charter
00:02:53 - is the key deliverable and how the project charter is the definition
00:02:56 - of everything the project should do. It's going to define the
00:03:00 - deliverables. If these
00:03:04 - are completed
00:03:08 - the business problem
00:03:13 - is resolved.
00:03:16 - Now you may say this is an IT project. The only deliverable that's
00:03:20 - going to satisfy the IT problem is working code
00:03:27 - and that's kind of a true statement but we also know that an
00:03:32 - IT project needs to use a project delivery life cycle, an SDLC,
00:03:39 - and the SDLC defines we need to have analysis
00:03:44 - and therefore we need to have deliverable set of analysis, we
00:03:47 - need to have design,
00:03:49 - and we need to have deliverables at a design, we need to have
00:03:52 - development, and we all have some extra deliverables at a development,
00:03:57 - and of course we will have the working code that we'll go through.
00:04:01 - So again we need to lay up front exactly what it is that we are
00:04:07 - going to complete as part of our project that's going to allow
00:04:10 - us to solve the business problem. And at this stage because we're
00:04:15 - still in project initiation our deliverables are probably identified
00:04:19 - by name only.
00:04:24 - We're going to produce an analysis document, we're going to produce
00:04:27 - a design document, we're going to produce a development document.
00:04:30 - We're not going to get into the details of what's going to be
00:04:33 - in those documents, we don't have that much information at hand
00:04:36 - in project initiation, but we're leveling the field,
00:04:44 - we're managing expectations,
00:04:47 - we're telling the business upfront that this is the approach
00:04:50 - and these are the deliverables we're going to produce. Obviously
00:04:55 - key to the business is the schedule
00:04:59 - and again one could say the only schedule, the only milestone
00:05:06 - is when you're done
00:05:09 - because when you're done is where the business problem is resolved
00:05:12 - and again true enough but again we typically want to define the
00:05:16 - milestones that says analysis will be done at month 1, design
00:05:21 - will be done at month 2, development will be done at month 4,
00:05:25 - and implementation will be done at month 6. Again leveling the
00:05:30 - field, managing the expectations
00:05:39 - they're not going to get this project in a single month, it's
00:05:42 - going to take a month just to get through analysis and so on. Obviously
00:05:48 - they want to know the cost,
00:05:51 - how much is this project going to cost and often you can get
00:05:54 - away with a single cost estimate, the total project is going
00:05:58 - to cost $50,000 or whatever the case is going to be, you may
00:06:02 - need to give them a breakdown of the cost estimates by the various
00:06:06 - phases, but again often although the deliverables and the milestones
00:06:11 - need to be broken at a phase level we can get away with providing
00:06:14 - a single estimate for cost. Now one comment on that we're in
00:06:20 - project initiation,
00:06:22 - we're going to give the business an estimate for cost, it's going
00:06:26 - to cost $50,000, but we also have to give them a sense of our
00:06:30 - competence in that estimate. This is $50,000 plus or minus
00:06:39 - 100%, it could be as much as $100,000, could be as little as
00:06:44 - $25,000, this is our best swag
00:06:49 - at what the total project is going to cost, we need to make sure
00:06:52 - they understand the confidence so that they are not going to
00:06:56 - be surprised
00:06:57 - at the end of the project if it comes in at $40,000 or it comes
00:07:01 - in at $70,000. We
00:07:05 - talked in the last nugget about the stakeholders. We need to
00:07:08 - identify all of those stakeholders, we need to document
00:07:13 - who they are and what their involvement in the project is going
00:07:16 - to be and we need to get that in writing
00:07:20 - so that when the project charter is signed off
00:07:26 - everybody knows what their commitment to the project is going
00:07:28 - to be. This person is my identified sponsor of acceptor; these
00:07:34 - senior managers are on my steering committee and so on. We're
00:07:38 - getting the commitment from the organization to participate in
00:07:41 - the project. Partly
00:07:44 - we've already laid out the project approach, we've defined what
00:07:47 - our systems development life cycle is going to be, what phases
00:07:50 - we're going to do, we can also define the project approach that
00:07:54 - says this is going to be an agile project, this is going to be
00:07:58 - a traditional project,
00:08:02 - this is going to be a phased implementation.
00:08:06 - Again, leveling the field, managing the expectations, making
00:08:11 - sure that when people sign off on this project charter that the
00:08:16 - conditions under which you are expecting to deliver the project
00:08:20 - are approved and accepted by the business. The
00:08:25 - problem statement
00:08:27 - in business terms
00:08:32 - you're defining the problem,
00:08:36 - the pain point that we've discussed already, in business terms.
00:08:41 - We're going to document all of the assumptions and the risks
00:08:45 - where at project initiation we've had to make a whole lot of
00:08:49 - guesses. Now management doesn't like us to call them guesses
00:08:55 - so we find another way to describe guesses and we call them assumptions
00:09:00 - and constraints. But our milestones, our deliverables, our costs,
00:09:04 - our project approach is based on the assumption that a previous
00:09:10 - project is in place, the assumption that a hardware upgrade has
00:09:14 - been completed, the assumption that various other conditions
00:09:18 - that must be in place for all of the promises that we're making
00:09:23 - in the project charter to be fulfilled. IT
00:09:27 - projects we've discussed many times are full of risks, you're
00:09:30 - going to hear me discuss risks over and over and over again throughout
00:09:34 - this nugget, we need to document the risks and we need to present
00:09:39 - them, and again we need to get them signed off that says "I think
00:09:46 - I can do this project in six months. I think I can do this project
00:09:50 - for $50,000 within my confidence level" based on these assumptions
00:09:54 - and constraints but because this is a project there are still
00:09:58 - other risks and here's my strategy for dealing with those risks
00:10:01 - and get all of that signed off. And
00:10:04 - finally part of the problem statement is really the definition
00:10:09 - of the project objectives. It
00:10:11 - is the key deliverable from project initiation, it's the definition
00:10:16 - of what the project should do, will do, and it defines all of
00:10:22 - the parameters within which this is going to be done and although
00:10:26 - it's kind of buried down here we've discussed it already
00:10:31 - the project charter needs to be signed off at whatever level
00:10:35 - of definition of sign off is going to be appropriate within your
00:10:38 - organization. My preference is to put a formal one-pager that
00:10:43 - says on date X the project charter, named, dated version was
00:10:52 - presented to the acceptor and defines the conditions in which
00:10:58 - the project will be delivered and get the acceptor to put their
00:11:01 - signature at the bottom of that and then on the other side of
00:11:05 - the bottom you put your signature that says "I the project manager,
00:11:09 - I the IT department also promise to deliver to the terms and
00:11:13 - conditions defined in the project charter." Again,
00:11:17 - my preference is a formal piece of paper; for signature, this
00:11:23 - is a very formal process, and I think it warrants the attention
00:11:26 - of signature. Some organizations that is just too formal, that
00:11:31 - is not normal process in the organization, so in lieu of that
00:11:37 - you may get away with I shouldn't say you may get away with you
00:11:40 - may opt for simply sending out an email that says "Dear sponsor
00:11:46 - I sent you the project charter via email yesterday. I've attached
00:11:49 - another copy for your reference. Please confirm your review and
00:11:53 - acceptance of this project charter by return email." It
00:11:59 - has the same connotation, has the same acceptance process, it's
00:12:05 - just not as formal as presenting the document, the piece of paper,
00:12:08 - and they require them to formally sign.
00:12:12 - I would like to suggest you should go no less informal that that
00:12:16 - but there will be organizations where still even that is too
00:12:19 - formal or the norm is they're not going to give you their response
00:12:24 - so as a worse case scenario I would again send an email "Dear
00:12:28 - business sponsor I sent you the project charter yesterday, I've
00:12:31 - attached another copy for your reference. Please get back to
00:12:35 - me with any issues or concerns that you have with us. If I don't
00:12:38 - hear from you within the next five business days I will assume
00:12:43 - that you have reviewed and accepted this and we will be proceeding
00:12:47 - to kick off the project."
00:12:49 - But you're talking about investing significant money on behalf
00:12:53 - of the organization,
00:12:55 - I believe we need to get some degree of formality to the sign
00:12:59 - off process. Broken record, I know, you're going to hear my broken
00:13:03 - record many times through this nugget series as well. I prefer
00:13:07 - formal signature, in lieu of formal signature I prefer formal
00:13:12 - response to an email but if that's just not acceptable in your
00:13:16 - business norms at least send the email that says if you don't
00:13:19 - get back to me in a certain acceptable period of time, and it
00:13:23 - should be a short period of time, I said five days, I would say
00:13:27 - it should be no longer than 10 days, if you don't get back to
00:13:30 - me I'm going to proceed on the assumption that you have accepted
00:13:36 - everything I've sais in the project charter and we will kick
00:13:39 - off the project.
00:13:41 - That's what's a project charter is, now let's have a look at
00:13:44 - a template of a project charter that I have used in other projects. To
00:13:49 - look at the project charter I'm going to deviate a little bit
00:13:52 - from the standard whiteboards and actually show you a template
00:13:55 - for a project charter and primarily because there's too much
00:13:59 - writing and you wouldn't want to have to live through that much
00:14:02 - of my handwriting as we explore the project charter. But the
00:14:05 - project charter is a formal document that you should produce
00:14:09 - I believe for every project that we take on as a project manager.
00:14:14 - Project charter, the name of the project, give it a date, depending
00:14:19 - on your organizational policy you may want to maintain revision
00:14:22 - history and so on I will leave that to organizational specifics
00:14:26 - but what I want to focus on right now is the table of contents,
00:14:29 - what goes into a project charter. And
00:14:33 - executive summary well probably every formal document we're going
00:14:38 - to produce needs a good executive summary, a project charter
00:14:41 - is no exception. As a matter of fact I would suggest in a project
00:14:44 - charter it's
00:14:46 - absolutely critical that we have a solid, strong, effective executive
00:14:53 - summary because we are going to present this project charter
00:14:57 - to our corporate executives to secure their commitment to invest
00:15:02 - corporate dollars into this project and as we all know often
00:15:07 - executives only read the executive summary hence the name of
00:15:10 - course we need to make sure that executive summary is powerful,
00:15:14 - compelling, and truly reflects the needs and the benefits of
00:15:20 - our project so that we're going to get the project approved. The
00:15:25 - rest of the project charter contents we're actually going to
00:15:27 - delve into more details as we work through the remainder of this
00:15:31 - nugget and the next nugget in project initiation but let's touch
00:15:34 - on what they should be. We need to identify who the project sponsor
00:15:39 - is. You need to have a single identified person with the power
00:15:45 - and the authority to help you make your project a success. Often
00:15:51 - this is the key business person and I often describe the project
00:15:55 - sponsor as the person in need. Your business person, your project
00:16:00 - sponsor has a business problem and your project sponsor needs
00:16:06 - your project to make that business problem go away so they're
00:16:10 - your best friends. You should enter into project delivery with
00:16:15 - your arm around your project sponsor's shoulder, best friends
00:16:19 - forever, with the goal of working together to make the project
00:16:23 - a success.
00:16:25 - Once we have that project sponsor identified we then need to
00:16:28 - go in and identify the key project stakeholders.
00:16:32 - Often this is in the form of an organization chart, who is your
00:16:36 - project sponsor's boss, and maybe even who is your project sponsor's
00:16:41 - boss's boss's depending on how high your sponsor is in the organization.
00:16:47 - I believe we need these key stakeholders and we need senior stakeholders
00:16:51 - identified because they're the people who have the power and
00:16:55 - the authority to make decisions to re-invest dollars to support
00:16:59 - our project when the project gets into delivery challenges and
00:17:03 - in spite of taking this Project Plus Certification exam and passing
00:17:07 - your Project Plus Certification you're probably going to and
00:17:11 - I would say definitely going to have some project delivery challenges
00:17:14 - that you may need to take to the key stakeholders. So we need
00:17:18 - to identify who the managers are but often key stakeholders are
00:17:22 - more than just managers, key stakeholders are going to be other
00:17:25 - interested managers at a peer level to your project sponsor,
00:17:29 - they may be subject matter experts who absolutely know what the
00:17:33 - brass facts, the details of the project are going to be. Get
00:17:37 - all of those people identified, document it, and on record as
00:17:42 - being of interest or having interest in your project. The
00:17:47 - business case
00:17:49 - supports the reason, defines the reason why the project is required.
00:17:55 - I often try to get my project sponsor to rate the business case.
00:18:00 - The business case should be written in business language. In
00:18:03 - myself the IT project manager often can't phrase the business
00:18:08 - requirements as eloquently as my sponsor so again I will often
00:18:12 - task my sponsor to do that, often I will help them along the
00:18:16 - way, they may not understand some of the nuances of writing a
00:18:20 - good executive summary or business case, but I would certainly
00:18:24 - again have that armor around the shoulder strategy of best friends
00:18:28 - forever in co-developing that business case. We
00:18:32 - need to make sure we define what the project's objectives, what
00:18:38 - the success is going to be, and how we're going to measure this
00:18:41 - success. This project will be a success when,
00:18:45 - obviously when the business needs the problem is resolved but
00:18:49 - how do we measure that?
00:18:51 - Written in business language, written in language that the executives
00:18:55 - are going to understand and say "Yes, I really believe in this
00:19:00 - project and I really support this project." Again this is a selling
00:19:04 - document. Your project charter is your foundation for future
00:19:07 - delivery but it's also a selling document. A
00:19:11 - key aspect to selling your project is your high level cost/benefit
00:19:15 - analysis. This project is going to cost $50,000, this project
00:19:19 - is going to cost $500,000, this project is going to cost $5 million. Whatever
00:19:24 - the cost your project is going to be it's going to be a significant
00:19:27 - chunk of change.
00:19:29 - Senior management is not going to be willing to invest that chunk
00:19:33 - of change unless they see some benefit. Why would I want to invest
00:19:38 - $500,000 in this project? Well you need to invest $500,000 in
00:19:43 - this project because it's going to have a payback of one and
00:19:47 - a half years or it's going to increase customer retention resulting
00:19:51 - in an annual savings of. Again define the cost and the benefits
00:19:56 - at a level that senior management is going to appreciate it and
00:19:59 - as a result be willing to sign off on the project. We
00:20:04 - talked about in one of the introductions that IT projects have
00:20:07 - a high risk profile. We need to be very honest upfront to our
00:20:12 - senior executives that says these are the risks, these are the
00:20:15 - areas I think this project could encounter delivery challenges
00:20:18 - and here is my strategy for removing, eliminating, mitigating
00:20:23 - the risks for the project should you approve it. And then finally
00:20:28 - document any assumptions and constraints that you have along
00:20:31 - the way that in order for this project to be a success I am assuming
00:20:35 - that in order for this project to be a success this constraint,
00:20:38 - this previous in flight project must be concluded or in order
00:20:43 - for etc. etc. Do a compelling document again this is a sales
00:20:48 - document to senior management, powerful executive summary, and
00:20:54 - keep the overall project charter brief. Now again I'm going to
00:20:58 - give you a generic statement that says a project charter should
00:21:02 - be 10 to 20 pages in length. Now if this is a multi-gazillion
00:21:07 - dollar construction project where you're totally rebuilding the
00:21:11 - entire highway infrastructure for North America it's probably
00:21:16 - unlikely that you're going to write a project charter in 10 to
00:21:18 - 20 pages but for most projects we're going to take on, especially
00:21:22 - most IT projects that we're going to take on in a business environment
00:21:26 - I would suggest your project charter should be able to be delivered
00:21:30 - in 10 to 20 pages as a sales document, an honest factual sales
00:21:35 - document, but it's a sales document to get the support to lay
00:21:39 - the foundation for our project's future delivery. Back
00:21:44 - to our road map, the next stage in our road map is 1.5 project
00:21:49 - life cycle and we already talked about the Project Management
00:21:52 - life cycle, initiating that's where we are right now.
00:22:01 - The last nugget in this nugget are all focused on the activities
00:22:04 - we do in initiating
00:22:06 - the Project Plus calls it pre-project setup and initiating but
00:22:12 - according to the PMBOK project life cycle they're one and the
00:22:16 - same. The next is planning this is a key area, we're going to
00:22:20 - have many nuggets on it coming up next to discuss all of the
00:22:24 - activities we do in planning. This is the key I said the project
00:22:28 - charter is the key deliverable out of initiating, it sets the
00:22:32 - foundation. Planning will pick up on the charter and expand
00:22:38 - it to give us the project scope and from the project scope we
00:22:44 - produce all of our other planning documents that are going to
00:22:47 - set the solid foundation or continue to build the foundation
00:22:52 - for our project. Then we move into executing which is where the
00:22:57 - team completes the activities,
00:23:01 - the project,
00:23:04 - into monitoring and control which is where we manage the project
00:23:12 - and finally into closing which is where the project is signed
00:23:17 - off and we get approval.
00:23:23 - We discussed all of these already in the overview and really
00:23:27 - everything in this project life cycle is what we're going to
00:23:30 - discuss throughout the remainder of this nugget series so I don't
00:23:34 - think we need to spend any more time on the project cycle in
00:23:37 - and of itself but I do want to show you a quick graph giving
00:23:41 - you a representation of how these various phases spread across
00:23:47 - our project life cycle. And
00:23:50 - this graph gives us the relative distribution of how our five
00:23:54 - phases of our project life cycle happen. The initiating phase
00:24:00 - is short and discreet and happens at the beginning of the project.
00:24:04 - We ramp up the initiating, we define our project charter, and
00:24:08 - we complete the initiating project. The only other discreet aspect
00:24:12 - to our project life cycle is over here in closing. Near the tail
00:24:16 - end of our project we begin our closing activities and we secure
00:24:20 - sign off.
00:24:23 - Initiating is discreet, happens upfront; closing is discreet
00:24:27 - and happens at the end but planning
00:24:30 - starts almost at the same time as initiating because we have
00:24:33 - to plan our initiation,
00:24:36 - planning will peak
00:24:39 - just about at the same time as initiating is finishing
00:24:44 - and that's we have now defined the project charter and we're
00:24:47 - taking and expanding that project charter into the project scope
00:24:50 - statement and developing the rest of our project components the
00:24:55 - scope, the time, the cost, the quality, the communications, etc.
00:24:59 - etc. and you will note that planning continues right down and
00:25:04 - actually that should continue a little bit further all the way
00:25:07 - or almost all of the way to closing, there will be planning activities
00:25:12 - throughout our project. Why? Because life
00:25:17 - is going to
00:25:21 - cause changes
00:25:24 - and when we encounter a change in our project we will need to
00:25:28 - go through a mini plan,
00:25:30 - we have new scope being added to the project, we need to go through
00:25:34 - a mini planning stage to add scope.
00:25:39 - Or a risk happens
00:25:42 - and the risk is going to change the project dynamics so we need
00:25:46 - to go through another mini planning session to deal with the
00:25:49 - risk. And, and, and the amount of planning time we spend on the
00:25:54 - project goes down close to zero as we come closer to the end
00:25:58 - of the project because as we get to the final stages of our project
00:26:01 - there's less opportunity or hopefully less opportunity for scope
00:26:06 - to be added or risks to happen or changes to happen in our project. Just
00:26:12 - as planning is starting to ramp down our monitoring, controlling,
00:26:16 - and executing phases ramp up and this is where the bulk of the
00:26:21 - project takes place. Executing is the delivery, monitoring and
00:26:26 - controlling is the Project Management activities. This is the
00:26:30 - peak of the project, this is when the team is at it highest head
00:26:34 - count, and as we move into the implementation stages again the
00:26:38 - level of effort will go down until we hit the closing stage. I
00:26:44 - wanted to show you this graph so that you understood Project
00:26:48 - Management is not a little bit of time upfront initiating, a
00:26:52 - little bit more time upfront planning, a whole lot of time in
00:26:56 - monitoring, controlling, and executing and a little bit of rime
00:26:59 - in closing. The key component of this that I wanted you to understand
00:27:03 - is that planning will take place throughout our entire project
00:27:08 - life cycle. And
00:27:10 - our final stop in our road map is 1.6 organizational structures.
00:27:16 - We're going to spend just a few minutes of time discussing how
00:27:19 - different organizational structures are going to impact your
00:27:22 - ability to influence control and manage your project and we're
00:27:26 - going to look at three key organizational structures. A functional
00:27:31 - organization structure, a matrix organizational structure, and
00:27:35 - a project organizational structure and we'll wrap that up with
00:27:38 - a very brief discussion on the pros and cons of each of these
00:27:41 - organizational structures. So let's see what a functional organizational
00:27:45 - structure looks like. A functional organizational structure is
00:27:49 - pretty much your traditional organizational structure. You have
00:27:53 - the top of the house, the CEO or the President, whoever is at
00:27:56 - the head of the organization, and reporting to the top are various
00:28:00 - functional areas. You have human resources, finance, marketing,
00:28:05 - IT, and so on throughout the organization. Each of these is going
00:28:09 - to have a head
00:28:11 - and under that there's going to be managers and supervisors with
00:28:16 - the various staff and these staff are focused on
00:28:20 - HR and
00:28:21 - really nothing HR and these staff focus on finance,
00:28:27 - I should just put down a dollar sign, and so on. Because we are
00:28:33 - focused on Project Plus where it's focused on IT development
00:28:37 - within the IT department typically you the project manager are
00:28:42 - going to be part of the IT department, probably have a background
00:28:48 - in IT but not necessarily,
00:28:52 - and most of these staff working on your project are going to
00:28:55 - also be from the IT department.
00:28:58 - The project implications of a functional organization is you're
00:29:02 - going to need involvement from
00:29:07 - the various business units
00:29:12 - to define requirements,
00:29:18 - to validate,
00:29:21 - to train, etc. etc. The bulk of the project delivery is going
00:29:25 - to happen in the IT department but you need to do that in conjunction
00:29:29 - with the business units to define the requirements, to test,
00:29:32 - and so on. The problem with the functional organizational structure
00:29:36 - is all of these staff
00:29:38 - knows nothing about project delivery, they're recognized experts
00:29:42 - in their areas finance and marketing so they know very little
00:29:46 - about IT and project delivery and
00:29:50 - they have their day jobs.
00:29:58 - They have a direct reporting relationship up through the finance
00:30:01 - department and they have a full time job working for finance
00:30:07 - for 35, 37 and a half, 40 hours a week whatever your normal work
00:30:12 - week is they don't have time
00:30:15 - to spend on project activity because they literally have their
00:30:19 - day jobs so being a PM in a functional organization
00:30:25 - is often very challenging because you don't have any realm of
00:30:30 - control or even an ability to influence the various functional
00:30:35 - departments that you need to help your project be a success.. So
00:30:40 - let's look at another iteration of an organization that often
00:30:44 - will assist in project delivery and that's called a matrix organization.
00:30:51 - A matrix organization starts off looking very much like the functional
00:30:55 - where you still have the top of the house and you still have
00:30:57 - your functional areas, you still have HR, finance, marketing,
00:31:01 - and IT,
00:31:03 - and you still have the situation where I described that the team
00:31:08 - comes from multiple functional areas, the difference being individual
00:31:13 - people, for example this team member is part of the marketing
00:31:18 - silo is also part of the team and that's where the concept of
00:31:22 - the matrix comes in. They have defined responsibilities to the
00:31:25 - marketing department but they also have defined responsibilities
00:31:29 - to the project. And whether the project manager comes out of
00:31:33 - an operational department and often that is the case operational
00:31:37 - departments will begin to build up project expertise because
00:31:42 - they're working in a matrix organization but the difference being
00:31:47 - they have a day job
00:31:51 - but in a true matrix organization the day job is less than full
00:31:56 - time so they have organizationally defined responsibilities to
00:32:03 - the marketing department, to their functional area, but they
00:32:06 - also have defined responsibilities to their other matrix reporting
00:32:11 - responsibilities and this gives the PM much more ability to influence
00:32:16 - and control.
00:32:17 - Now often when you read textbooks about matrix organizations
00:32:22 - they talk about weak matrices and strong matrices.
00:32:28 - And in a weak matrix
00:32:31 - the functional area still has the majority
00:32:37 - of the influence
00:32:40 - and the majority of the time
00:32:42 - is booked to the functional area. In a strong matrix I'm not
00:32:48 - going to say the line, the project has major influence but in
00:32:53 - a strong relationship it's often upwards in a 50-sharing that
00:32:59 - 50% of the team member's time is focused on
00:33:03 - functional responsibilities and 50% of the time is focused on
00:33:07 - the project.
00:33:08 - So a matrix is a significant step forward in giving project responsibility,
00:33:15 - project managers more ability to influence and control their
00:33:19 - team. And the final evolution of that is the pure project organization.
00:33:26 - And a project organization is focused purely
00:33:31 - on project delivery.
00:33:36 - Often you will not find a project organization in a true business
00:33:40 - unit but you often find a project organization in consulting
00:33:43 - organizations. So when a consulting organization comes in to
00:33:50 - deliver a project for your organization they come in with the
00:33:55 - "full meal deal." They come in with a Project Management office,
00:33:59 - a PMO, depending on how many projects you're going to be running,
00:34:02 - project managers are part of the large PMO so they are trained,
00:34:09 - experienced, and supported
00:34:16 - project managers in an organization structured for project delivery
00:34:20 - and individual team members report directly to
00:34:27 - and only to
00:34:29 - the PM and that gives the PM total power, control, and authority
00:34:35 - over the project team.
00:34:37 - So I think you can probably imagine if you were a project manager
00:34:40 - working to successful project delivery your preference would
00:34:45 - be to working in a project organization, often again project
00:34:50 - organizations in my experience at least don't typically exist
00:34:53 - in traditional business but they exist more in consulting organizations.
00:34:58 - The next better step is to work in a strong matrix organization,
00:35:02 - the next step is to work in a weak matrix, and finally the worst
00:35:06 - case scenario as a project manager is to work in a pure functional
00:35:10 - organization and with that I want to talk about the pros and
00:35:14 - cons of these various delivery approaches or organizational structures. And
00:35:20 - this chart to me really summarized the pros and cons of the various
00:35:24 - organizations the functional, the matrix, and the project and
00:35:27 - examines them in relationship to the loyalty of the team to the
00:35:31 - project manager, who the team reports to, whether the PM is typically
00:35:35 - a part time or full time responsibility, what the team's responsibilities
00:35:40 - are part time or full time, and the degree of control the project
00:35:43 - manager has on this. And we really discussed what's happening
00:35:47 - within the matrix throughout the discussions of the various organization
00:35:51 - structures so I'm not going to bore you and take you through
00:35:54 - that again. I wanted to put this matrix up and I would suggest
00:35:58 - you do a screen capture of this particular part of the nugget
00:36:01 - and print it off and spend some time understanding this because
00:36:06 - if you can basically reproduce this grid, this matrix in your
00:36:11 - head during your Project Plus exam itself you will be totally
00:36:17 - equipped or very well equipped to answer any of the questions
00:36:21 - that you're going to get on your Project Plus related to organizational
00:36:24 - structures because the questions are going to be related to if
00:36:27 - you are a project manager in a matrix organization what is your
00:36:33 - degree of control of or questions to that extent. So again
00:36:38 - capture this particular grid, use it as a study aid, be prepared
00:36:44 - to reproduce this mentally or write it down on that scrap paper
00:36:47 - the second you go into the exam and it will be a key aid in getting
00:36:51 - you through any of the questions on your exam related to organization
00:36:55 - structures. This concludes our two modules on the first part
00:37:00 - of your Project Plus Certification pre-project setup and initiating.
00:37:05 - The last nugget discussed the first three components of pre-project
00:37:08 - setup and initiating and this nugget focused on the project charter,
00:37:12 - your key deliverable,
00:37:17 - the foundation for your project,
00:37:21 - and its requirement to be formally approved.
00:37:29 - The other two aspects of this nugget we talked about the project
00:37:32 - life cycle and how our project life cycle consists of initiating,
00:37:37 - planning, executing,
00:37:42 - monitoring and controlling, and then finally closing
00:37:46 - and we examined that the only two discreet phases of our project
00:37:50 - life cycle are initiating, which happens at the beginning, and
00:37:53 - closing, which happens at the tailend. Planning is throughout,
00:38:00 - heavy at the front,
00:38:02 - but throughout to deal with changes.
00:38:06 - Executing is where our project delivers. And monitor and control
00:38:10 - is where we keep our project on track. And then finally we had
00:38:14 - a very brief discussion on organizational structures and some
00:38:17 - tips and hints to passing your exam and some considerations we
00:38:22 - need to have in mind as project managers when we're setting up
00:38:25 - our project structure as to whether we're working in a functional
00:38:29 - structure, whether we're working in a strong or weak matrix structure,
00:38:34 - or whether we have the utopia of working in a project structure
00:38:39 - itself. This concludes our second of two nuggets on pre-project
00:38:45 - setup and initiating. I hope this module has been informative
00:38:48 - for you and thank you very much for viewing.

Prepare Scope Statement

Create WBS and WBS Dictionary

Define Change Management Process

Develop Project Schedule and Resources and Roles

PERT/GANTT/CPM and Schedule Compression

Communications Management Plan

Risk Management Plan

Quality Management Plan

Cost Management Plan

Procurement Management Plan

Transition and Project Management Plan

Human Resource Management

Project Governance

Project Tracking

Project Change Management

Project Risk Management

Project Quality Management

Project Delivery Management

Earned Value Management

Project Communication Management

Project Closure

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus

Course Features

Speed Control

Play videos at a faster or slower pace.


Pick up where you left off watching a video.


Jot down information to refer back to at a later time.

Closed Captions

Follow what the trainers are saying with ease.

Premium Features

Transcender® Practice Exams

These practice tests help you review your knowledge and prepare you for exams.

Offline Training

Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching

Develop and maintain a study plan with assistance from coaches.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer


Area Of Expertise:
Project Management, MS Project, Development Methodologies, Agile Development

Stay Connected

Get the latest updates on the subjects you choose.

  © 2015 CBT Nuggets. All rights reserved. Licensing Agreement | Billing Agreement | Privacy Policy | RSS