Start with 7 free days of training.

Gain instant access to our entire IT training library, free for your first week.
Train anytime on your desktop, tablet, or mobile devices.

Note: The content associated with this course was retired on March 26, 2018. However, this course still retains value as a training resource....
Note: The content associated with this course was retired on March 26, 2018. However, this course still retains value as a training resource.

This video training course with Steve Caseley provides a real-world experience by following a project through the complete Project Management lifecycle.

Recommended Skills
  • Project management experience
  • Microsoft Office
  • Microsoft Project
Recommended Equipment
  • Personal computer
Related Job Functions
  • Project Manager
This course follows a real-world project, implementing a Software-as-a-Service Warehouse modernization solution, from inception through to successful delivery. At each stage in the project, Initiating, Planning, Delivery, and Closing, the course reviews Project Management deliverable templates and explore real-world samples from the SAS project. The course concludes with tips and hints and lessons learned from Steve's 20+ years of other real-world projects.
 show less
1. Project Origins (27 min)
2. Where do I start? (24 min)
3. Project Initiating (36 min)
4. Project Charter (35 min)
5. Project Planning (34 min)
6. Scope Deliverables (38 min)
7. Project Schedule (31 min)
8. Project Budget (26 min)
9. Identify Risks (23 min)
10. Project Management Plan (33 min)
11. Project Startup (29 min)
12. Procurement Planning (33 min)
13. Delivery and Time Tracking (30 min)
14. Status Reports (35 min)
15. Communications (34 min)
16. Changes and Replanning (36 min)
17. Quality and Acceptance (27 min)
18. Team Management (28 min)
19. Risks and Issues (20 min)
20. Budget Management (22 min)
21. Closing (13 min)
22. Lessons Learned Part 1 (29 min)
23. Lessons Learned Part 2 (30 min)

Project Origins


Hi, I'm Steve Caseley from CBT Nugget. And welcome to this Nugget and the very beginning of our project management in the real world. And I'm calling this Nugget Day 0, or Project Origins. The source of projects, how projects get initiated, actually has a fairly significant bearing on our life as a real world project manager, because we have to pay some very particular attention to where those projects come from.


Projects coming from the Eureka moment in the shower and the drive to work have very little definition, and may not even be real projects. While projects that come from a strategic plan that have been on the books and scheduled for completion for the last x months may well have a lot of clarity and definition.


So let's have a look at what happens and where projects come from, and how we as project managers need to focus on project origins. So where do projects come from anyway? Well, they really come from anywhere and everywhere. But the origin of projects is going to heavily determine the amount of clarity, the amount of definition, the amount of material that's going to be handed to us to help us put together our true project plan.


So if a project comes from a wild idea-- driving to work, having a shower, at a party, wherever it's going to be-- our business owner came up with a wild idea, they're going to grab us in the hallway and say, "Steve, Steve, Steve, come here. I've got to talk to you.


I just had this terrific idea on the way to work this morning. I need you start working on a project." Well, it may well be a terrific idea, but if all that is associated with it is these wild ideas, driving to work in the morning, we as project managers are going to put a lot of focus into validating that in fact the wild idea-- as I keep calling it the Eureka moment-- really makes sense.


Not far off from that are the napkins. Sitting at lunch a bunch of business people were discussing current problems, and they created a project approach over lunch. Nobody had any paper with them, and I think the napkin idea is quickly fading because everybody probably pulls out their smartphone and types the ideas into the smartphone.


But let's stick with the napkin for now. They jotted down their ideas on the napkin. A little bit better than the wild idea because at least this is probably some sense of collaboration across multiple business people, but it's still pretty sketchy. It still needs a lot of details before we're really ready to develop a sound project plan.


Then we move into mandates. This is a project that's required. The government has legislated that you must be able to report workplace accidents, or the government has legislated that you must change the way taxes are collected on your product. The government has legislated a, b, c and d.


You have 6 to 8 months to implement it. Please get this done, or our organization is unable to continue to do business. Now the good news about mandates is the objective is often very clear, because it's been written by the government. The legislature has put together all of the rules and regulations.


And it's just our job to implement them. So a lot more clarity. But the problem with mandated projects is there's often not a lot of appetite. Yup, we gotta do it! The government says we have to do it. But it's not going to do anything but cost us money.


So therefore people aren't really excited about supporting it. It's just, oh, gosh darn it, we've got to do this to keep that government happy. And therefore, just go away Steve, leave me alone. I've got business problems to solve. The last thing I need is to spend more money.


Just please go get this done. So mandated projects have lots of clarity but typically not a lot of support. The ones that I like are the projects that solve operational pain. The business owner has recognized that if this project is implemented, it's going to make life better.


We're going to be able to do the things the proverbial better, faster, cheaper. So therefore, Steve, not only am I excited about this project. I'm going to do everything in my power to help you move this project forward. I'm going to turn over rocks, I'm going to plow through things.


This project is going to remove this operational pain. I'm going to be better, faster, cheaper, and I'm going to help you get this done. I'll do whatever it takes. These, again, at least in my humble opinion are the projects that are bound to succeed because everybody wants them to succeed.


Probably almost equal are the projects that come from business plans. So every year, your organization sits down and often part of the budgeting cycle but not always associated with the budgeting cycle, they develop the strategic plan for what type of things should we be doing in the next 12 months.


A medium range plan of what they should we be doing in the next 12 to 24 to 32 months. And then what should we be doing in the long range? So we have all of these business plans. Well thought out, well validated. More times than not, the business plan should be associated with resolving pain.


Sometimes the pain is a little less well defined. But they should have a lot of clarity. And then finally-- I've left it to the last-- is my least preferred style of project to work on, which is the boss's pet project. The boss-- the guy who owns the company, the guy who signs my paycheck-- comes to me and says, "Steve, I have an idea.


I'd like you to work on a project, to implement this idea for me. Let's get started." Sounds like a great idea. He's the boss. Whatever my boss wants, I'm going to do. My problem with my boss's projects-- and maybe it's just the nature of my boss's-- is the boss's project changes.


First we're going straight, and then we make a slight detour to the left. We're going to now move into the distributed field. And then all of a sudden, no we're not going to go distributed. It needs to be centralized. And then all of a sudden, halfway through centralized, he was just in the mall and found the new smartphone that does widgets and gadgets and [INAUDIBLE].


And all of a sudden we're going to be coding the project for the latest in smartphone technology. And my boss's project goes all over the place. I can't say, "No, we can't do that. We're changing the scope. It's going to cost you more money." Because the boss says, "That's fine.


I have lots of money. I don't mind spending my money. I think this is really exciting. Just follow my direction." And that's my problem with my boss's projects, is my direction goes left, right and sideways. And then the color changes from blue to green to yellow.


And the boss says, "Don't worry about it! I've got lots of money. This is really fun. This is how I made my company. This is entrepreneurship at its best. Just stay the course with me." Well, the problem with staying the course with me is my 6 month project is now 14 months.


And at some point in time, my boss's patience is going to fade, and, and, and... So, you know, as politely as I can without getting fired, I try to suggest to my boss, you know what? This is a really great project. Why don't you assign this project to one of your managers.


And one of the managers can help me develop this project based on what you currently want. And the farther I can get myself removed from my boss's whims and wishes, the more likely my project will have the same degree of clarity that I get from any other business owner.


And maybe I'm a little biased. Maybe I've just worked for the wrong bosses over my life. But my experience on the boss's pet project, it's a bit of a roller coaster ride. And without trying to sound like it's a repeat of the PMP Prep Series from the PMBOK, I do feel it's important to share just a few moments with you what do projects need to be successful?


Because as a real world PM, we need to make sure that we've got all of this in place. So we need the scope. So if you have the wild idea, the Eureka moment, the napkins, that's not scope. If you have the mandate or the legislative or be operational pain, you probably have sufficient details to give us the scope of what it is we need to do to successfully deliver this project.


We need some money. The Eureka moment, the business owner may say, "Oh, don't worry about it. This is going to be so awesome. This is going to be so great. Just start it. I'll go talk to the CFO. I'll go talk to the CXO. I will make sure this project gets approved." By the time they finish pleading their case, 4 weeks have gone by.


Do things happen quickly in your seat? I know my organization takes a little while to get a lot of things formally approved through the C ranks. We can get preliminary opinions very quickly, but that approval takes time. So again, it's going to take 4 weeks for this business owner to get that formal approval for the dollars.


By then I've invested a lot of time, a lot of money. And you know what? The C ranks has finally decided, no, it doesn't make sense. Your Eureka moment really doesn't make sense, so please stop. And by then, we've wasted a lot of corporate dollars. Any textbook, the Gartner Report, the Standish Chaos Report, all emphasize the importance of having a dedicated, focused, engaged, interested business owner.


This is where those operational pain projects to me work so well. Because I have a business owner who has operational pain. And by satisfying that operational pain I make their life easier. So they're very, very engaged. They're very, very committed.


They're very, very interested in making this project a success. As opposed to, let's say we've got one of those mandated. The government says we need to do x. Sure, I have a business owner. Sure I have a business owner who's committed-- and I say that with very small letters, committed-- to making a project success, because the government told us we had to do this.


But are they excited about it? No. Are they doing it because they have to because the gosh, darn government says we need to do this? Yeah. Are they paying attention to the project? Sure. Are they giving it their everything, their full attention? Absolutely not.


They're still trying to run the business, and deal with this annoying mandated project along the way. So, the more committed, the more engaged, and I hate to keep saying this but the more pain my business owner has, and the more pain that this project is going to remove from my business owner, the better off I'm going to be because the more engagement I'm going to get.


And finally is the approval. We can have the scope. The business owner may have some mad money stashed away that they can spend on it. We they may have great pain. But if we don't have the organizational approval-- again that approval at the C ranks: the CEO, the CIO, the CTO, the CXO-- the project is eventually going to get squished.


We need this project approved at the very top of the house, and that's what's going to allow us to be a success. So to sum that up, in theory PMBOK Guide says, every single textbook in the world says, as a PM, when you're head of the project, you're going to get, in theory, a validated vision.


That's the scope. Steve, here is a very clear statement of exactly what it is this project needs to do. You're going to do an inventory evaluation system, you're going to use this accounting method, it needs to be done under these principles. We're going to use pen and paper.


We're going to use handheld technology. We're going to use, we're going to use. But it's going to tell you absolutely what you need to do, what the parameters for your project are going to be. You're going to have that committed business owner, whether you have the pain or not, doesn't really matter, but you're going to have a committed business owner.


You're going to have approved dollars-- there's money to do this. And it's going to be delivered in a realistic time frame. If it's going to be a 12 month project, the business expects you're going to be able to deliver it in 12 months. As opposed to what happens when the CEO comes to you and says, "Steve, we think this is going to be a 12 month project, but we can't give you that long.


You need to get this done in 8 months." So in theory, you don't get any of that. You get the perfect world. You have a vision, you have a business owner, you have the dollars, and you have a realistic time frame. But without sounding totally negative, in reality what you're probably going to get is the napkin.


Or sometimes it's not even the napkin. It's the 'come walk with me, let's go grab coffee'. I had this Eureka moment in the car on the way to work this morning. Come walk with me and let's get this done. Another thing we often get is and assigned business representative.


It's not an engaged product owner. It's an assigned business representative. "Hi Steve. My name's Sally. And I've been told to come talk to you about this project. I'm not really sure what it's all about either, but I'm sure the two of us can figure it out." We can't deal with the people who are told to work on the project, because they don't understand the details.


They don't have the commitment. They don't have the pain. We need an engaged business owner, not an assigned business representative. We never get enough money, and we get projects that need to be done now. So, with all of that, as a real world PM, what do we do?


And for those of you taking some of my other courses, you're going to know this phrase for me: as politely if you can, without getting fired-- and in some instances maybe you really want to get fired, but let's assume you do love your job, and like the company you're working for-- so as politely as you can, without getting fired, you need to push back.


No, I'm sorry. I can't start a project based on a conversation getting a cup of coffee, based on your Eureka moment. No, I'm sorry. I really need-- No, I'm sorry, this project can't be done for $50,000. I have evidence, I have facts. So how do we get around that?


A big piece of it is to provide the facts. Yes, I know you want this done for $50,000, but I've done a preliminary budget. We need three developers, it's going to take four months, the salary rate for the three developers is-- Look at that. It doesn't add up to $50,000.


It adds up to $85,000. Present the facts as politely as you can without getting fired. Refute that it can be and in two months, that it can be done in $50,000, that you need an engaged business manager, and so on, and so on, and so on. So besides presenting facts, in a real world, as a real world PM, what do we do when we're in this day zero, the project origins, and we don't have one of those perfect projects.


Well, what we need to do is we need to turn it into a perfect project. We need to establish the vision for the project. And I deliberately use the word vision, because that's a word the business can equate to far better. The word scope is something we project managers focus on.


We fixate on it. PMI has been drilled bit into our heads for the last 25 years. It's what we recognize, what we support, but the business doesn't. So establish a vision. Go for some more walks with that person who had the Eureka moment. And flush it out.


Have some meetings, write it down, trade some emails, but work with the business and get it in business words-- that's why I'm using the word vision-- get it in business words that you can get some clarity, some confirmation, something that you can present up the food chain in your organization to the C ranks to get this thing approved.


And I think this is the most important. I should have a single bullet, the only thing on the page in blazing red colors and flashing at us: find someone who cares. Nothing is going to drag your project down more than a project owner who doesn't care.


"Hi, I'm Sally. I've been assigned to help you." Well, Sally doesn't care. "Hi, this is my project. And we're going to make it a success. For I'm also about to retire. And please don't schedule any meetings in the afternoon, because if it's sunny, I'm going golfing." Find someone who cares.


And as much as I overuse this term, find somebody with business pain-- I don't want them in physical pain-- but I want someone with business pain that my project can remove. Ideally the person with the business pain also has power and authority. But often that's not the case.


So you have a middle level manager who has a problem that a project can fix. But they're a middle level manager. They don't have power, they don't have authority. So work with that middle level manager, get your vision, develop a strategy to remove their pain, and then go up the business food chain to find someone in that business department, unit, area, whatever it is, with some power and authority.


Because we need to make the presentations into the C ranks. We need to find someone with the power and authority to get decisions made to get the project approved. But really what we need that power and authority for is, in four months' time, in six months' time, when our project is having challenges.


We need more money. We need more time. We need to get a supplier online. We need to deal with competing strategies or competing priorities from another business unit. We need someone with that power and authority to go to the bat to help our project succeed.


Ensure you engage your own manager. I'm assuming that we're working in some form of projectized environment where I am not necessarily within the food chain of the business area. I'm in the food chain of a project management office. I'm in the food chain of an IT department.


But I'm probably working outside of the business area. So I want to make sure that my manager's engaged. I had that some time ago that I was working with a business unit. They were fully-- every one of these things was in spades. I thought I had my personal manager engaged.


I sent him status reports. He knew what I was doing. And then finally, one day in a review, he said, "Steve, you've really annoyed me over these last six months. This project you've been working on for the marketing department, doesn't do me any good.


I don't know why you've been wasting your time and my time working for the marketing department. It would've really helped my case a lot better had you been working for the warehouse department." So all the status reports and all of the material I was sending to my manager saying, I'm doing this, I'm doing this, I'm doing this.


Apparently every time I sent him a status report, his blood pressure went up just a little bit higher, because I thought I was doing a good job. But he didn't think so. And he was the type of manager that wasn't engaged actively-- for anything I did for that matter-- but in this particular instance he totally disengaged until we hit that breaking point.


And then it began to make sense. That's why I haven't been getting any support out of you, isn't it? You hated this project. It was approved, but for whatever reason it's something that didn't work for you. So make sure you've got your manager engaged.


Because again, same idea with that power and authority, in four months, six months' time, when things are going wrong and I need support I need the business to go to bat and help me out, and I need my boss to go to bat and help me out. Fortunately in this particular project, I didn't have a lot of challenges.


It was a relatively simplistic project. It went in without any challenges. But man oh man, had I needed my manager, it wasn't going to happen. I know we're not doing lessons learned right now. That's much, much later in the Nugget series. But talk about scars that were almost fatal, mistakes that happened, do nothing without approval.


"Steve, come on. Take a walk with me. I had this great idea. Just go forth and spend a couple of hours on this." And a couple of hours turns into a couple of days. Do nothing without approval. Make sure your boss knows. Make sure the technology approval board knows.


Make sure business manager knows that Steve is about to spend two days, two weeks, developing a vision statement. Even if it's simple. If people-- the bosses, the top of the food chain-- don't know you're working on things, don't start. Now I don't mean this has to be a formal authorization letter.


Again, it's a simple. Maybe as simple as an email, to my boss, to my business sponsor's boss saying, we had a chat, makes sense. If you guys would agree that I spend the next two days working on this, I should be able to validate the Eureka moment and say whether or not it really make sense.


Do you agree? And wait for formal approval. Yeah, Steve, reply, works. Perfect. Scars that can be fatal. Do nothing without approval. As politely as you can, without getting fired, get the boss to give up her pet project. The worst projects I've ever worked on are ones that are the boss's pet projects.


They have no vision, they have no direction, they have a committed business owner, they have all of the money in the world, but these are the ones that we go left, and then right, and then backwards, and then sideways, and then green, and blue, then pink, then purple.


Get the boss to give up her pet project. As politely as you can, without getting fired. Dear owner of the company, I understand you have a really awesome project that I'm just totally pumped to be working on it. But you know what? I think you need to get this project assigned to one of your other managers.


They have more time. I'm going to require a lot of time. I'm going to require a lot of attention. Why don't you get another manager to work on this. Give them your vision, and let them enact it. You're the boss of the company. You need to spend your time in far more important places than with me in project status meetings.


Get the boss to give up his or her pet project, give it to somebody else who can give it the clarity, the time, the attention and the stability that it needs, as politely as you can without getting fired. Otherwise if you can't get the boss to give up his or her pet project, all I can say is, put on your seat belt, put on your shoulder straps, probably even a crash helmet, because you're in for roller coaster ride.


And again, maybe your bosses have more stability than mine, but those are the types of experiences I've had when I'm working with the bosses on pet projects. And the last piece of advice I'm going to leave you with may be unpalatable for some people, but start building your political support structure.


Project management is political. It's not simply sitting down behind a tool like Microsoft Project, creating a WBS-- a Work Breakdown Structure-- estimating and scheduling and saying, go forth and deliver. There is an absolute political element to successful project management.


You need to start building your support structure. Finding the people with the power and the authority. Engaging your manager. Finding out whether there are supporters or detractors in other business units. When the project gets ugly-- and hopefully by the time we finish this entire series, we've been through enough processes and suggestions and scars and lessons learned that we're going to keep most of our projects from going ugly-- but when the project goes ugly, we need the support structure to help us get our project back on the rails.


This concludes your Nugget on Project Origins. I hope this module has been informative for you. And thank you very much for viewing.

Where do I start?

Project Initiating

Project Charter

Project Planning

Scope Deliverables

Project Schedule

Project Budget

Identify Risks

Project Management Plan

Project Startup

Procurement Planning

Delivery and Time Tracking

Status Reports


Changes and Replanning

Quality and Acceptance

Team Management

Risks and Issues

Budget Management


Lessons Learned Part 1

Lessons Learned Part 2

To foster more active discussions, we’ve replaced the comments feature with our Learner Community in Slack.

The Learner Community is a quick and easy way to connect with more than 2,000 learners in real time. It’s also the perfect place to help us improve by sharing your feedback on our training courses and videos. To learn more about the CBT Nuggets Learner Community and our culture, review our community guidelines.

Join the Learner Community

Trouble signing in to Slack? Read our troubleshooting tips.

Have a technical support question? Contact Learner Support.

Entry 11 hrs 23 videos


Training Features

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

Virtual Lab
Use a virtual environment to reinforce what you are learning and get hands-on experience.

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

Accountability Coaching
Develop and maintain a study plan with one-to-one assistance from coaches.

Supplemental Files
Files/materials that supplement the video training.

Speed Control
Play videos at a faster or slower pace.

Included in this course
Pick up where you left off watching a video.

Included in this course
Jot down information to refer back to at a later time.

Closed Captions
Follow what the trainers are saying with ease.