Below you will find all the project management lessons so you can learn all about Project Management. Direct from the Project Management Body of Knowledge (PMBOK), these lessons will help you navigate the often difficult waters that are a part of completing a project or change in your organisation.
Project Management Introduction, Overview and Basics
Well done for working towards a better career and improving your life and knowledge! Project Management is one of the best overall disciplines to help you navigate difficult organisation situations when you are trying to delivery value and make a positive difference.
This article is about the importance of project management itself, and managing that project in a successful way from beginning to end.
There are benefits to having good project management – effective project management leads to meeting stakeholder objectives, increasing the chances of the project success, resolving problems and issues as they arise (which they always do), responding to risks that might arise, as well as optimizing the use of organizational resources so the people that you’re bringing on board to your project can be used in the absolute best way. Identifying failing projects and sometimes terminating them if you absolutely need to, and managing all of the constraints – money, scope, time frame – all of those need to be managed or shuffled around so you can still meet the project objectives.
Poor project management on the other hand is a different story. I’ve seen this many times and I’m sure you have to, because project management is quite difficult. That’s why it’s nice to have a framework to operate by. You could have missed deadlines where now all of a sudden your project is late. You could have cost overruns where now all of a sudden it’s going to cost two million dollars instead of 1 million dollars or fifty thousand dollars instead of twenty thousand dollars whatever it is.
You could have poor quality – so it’s not actually meeting what the customer wanted. You could be having to rework things to redo them over and over again and the customer is not happy about that. Expansion of scope, otherwise known as scope creep, where the things that the customer wants actually end up being more and more and more and they weren’t designed in the initial project for what we wanted to deliver.
Using a Proven Project Management Framework
There are lots of things that can happen if a project is not managed well, and even when it is managed well. These things can go wrong but that’s the benefit of having a framework to manage it by – you know you’re doing the absolute best you can to try and get these things on the left here (meeting those stakeholder needs, increasing the chances of success) rather than having missed deadlines or cost overruns.
Operations, Projects, Programs, Portfolios
There is a relationship here between three things and we’ve got basically at the very base level, at the operating level where things are done on a day to day basis we’ve got the operations of a business. And that’s where we’ve got shared resources and shared stakeholders, we’re going to have to use these resources and these people from within the organization to help us get the project done, and that’s an essential thing that we need to manage throughout the life of a project.
The next layer from there are our projects, and these are the things that are delivering change to our BAU or operations, but sometimes you want to have a really good overview of all of these multiple projects – there’s lots of projects happening and you need something to clearly define a bunch of those projects in one, and that’s where we come into a program.
Program managers might have a couple of projects, a handful maybe 10 maybe even 20 sometimes where they’ve got multiple projects all delivering the same strategic objective, they’re all delivering a similar thing but doing different things.
Lastly made up of programs and projects and operations are our portfolios. A portfolio manager will have multiple programs and then multiple projects under each of those programs and then lots and lots of BAU teams and operations within the operations side of the business.
There are many different business documents that you’ll need to help kick-off and then manage your project, and we call these Project Management Business Documents that we’re going to need in the managing of our project. There are two main business documents, which are the project business case, and the project benefits management plan. Ultimately the business case will help us kick off the project and start the project but the project management benefits plan will help us manage those benefits that we’re wanting to deliver and make sure that we are delivering on those benefits when the project is delivered. The pre-work we’re looking at is the needs assessment – for example what’s the need of this project? Why is it being kicked off? Why is it being initiated? That helps us and feeds into our business case.
Benefits Management Plan
The project business case also has the benefits management plan within that, so that we know what benefits we’re delivering. All these documents will feed into our project charter which ultimately is one of the first steps, or is the first step in initiating a project. From there the project charter will feed in with all of the information that we’ve gathered from our needs assessment, business case, the risks involved, the stakeholders as an early view of the stakeholders, and risks and scope and schedule that might be involved and all of that feeds into the project management plan on a larger scale where we’re using that now to manage our project on a daily basis.
Project Business Case
So let’s dive into the project business case. What is actually in it? There are a few things usually, and they include business needs – so a description of what is prompting the need for action. Maybe customers have fallen off over the last year and we’re wanting to get more customers, maybe there’s a lot of rework that’s happening in a certain area and we’re wanting to reduce that rework. Whatever the business need is, we’re wanting to include that in the project business case. It’s a feasibility study of why we’re initiating the project. We usually give an analysis of the situation, so what are the facts, what is currently happening, are we currently at 80% capacity but we need to be at a hundred percent capacity? Whatever it is put the raw data and that project management data and info into this analysis of the situation for your business case, and then based on that we’re wanting to give a recommendation.
What’s the need, what’s the current situation, and based on that what are we recommending that people do to make a change and deliver what we need to deliver for this project.
Lastly once we’ve done that of course we’re wanting to see how the benefits that we’re delivering will be measured. Will it be Bob over there in a certain department measuring this for the next two or three months to make sure that things are on track and that it’s actually delivering what we want to deliver? However we’re going to measure it we want to put that in the plan as well.
Project Benefits Management Plan
Which leads us into the project benefits management plan. How are we managing these benefits? We want to usually include what the target benefits are, is it increasing this or decreasing that, include it in the project benefits management plan. We want the time-frame for realizing those benefits – is it a year? Is it six months? Is it one month?
Next, who owns the benefits. This comes back to our BAU, our operations. What are the metrics that we’re measuring, what are the assumptions that we’re making when we’re here measuring these things? We just need to know what those assumptions are in case they end up being wrong, and then we can see why we didn’t meet the the target or maybe we did better than the target (or whatever it is).
Ultimately we want to see what risks there are to meeting those benefits as well and put those in the project benefits management plan.
How to Measure the Project Benefits
There are many different ways to measure these things and measure these benefits and some of these are called out in the project management body of knowledge. They are Net Present Value – you will need to know this for the exam usually they’re fairly straightforward to go into and often the way they’ll word it on the exam will be “you have a net present value of of this and a net present value of that, so which one should you actually choose?” And you choose the highest.
For your Return On Investment we just want the highest return on investment. Internal Rate of Return – we want the higher rate of return as well. The payback period we want a shorter payback period if possible, and the benefit to cost ratio we usually want a higher benefit to a lower cost if possible.
But all of those are just numbers and numerical objectives and financial objectives – usually we can also have things like meeting non-financial objectives, fulfilling contract terms or conditions, meeting governance or regulatory requirements, achieving stakeholder satisfaction, meeting organizational strategy or goals – all these things could be non-monetary benefits that we’re realizing at the end of the project and we can also include.
And those are the project management business documents as part of our foundational elements of project management.
This is the Agile Practice Guide from the Project Management Institute and Agile Alliance, and this particular one is delivering in an Agile environment.
Check out the video and article below!
Delivering in an Agile Environment
There are two things in focus when delivering in an Agile environment, and the first is the team and the project charter. The second is the way we measure results – it can be very different than that of a traditional approach when we’re using Agile. First let’s look at the Charter.
Charter the Project and the Team
Usually in a traditional approach using the project management body of knowledge, which goes through very set steps that will initiate a project with a project charter. It will go through what the project stands for, what the risks are, who the stakeholders are, all those things. It will initiate that project and kick it off.
Now in addition to that when we’re using an Agile approach, our cross-functional team will initiate with a team Charter. What that means is you’ve seen the cross-functional team before where we’ve got the roles like the facilitator, we’ve got the product owner, and they represent the customer or the business. And then we’ve got our cross-functional team members who are those T-shaped members who have a general knowledge of a lot of things and then one really deep specialty knowledge. So these team members are extremely valuable because they might have one deep specialty of development and then many many general knowledge areas such as design or testing or or even leadership. All of those different things.
Our team Charter includes the project vision or the purpose, and this is so important and it’s so wonderful as well. Why? Because we want to start with “why”. Start with why is a classic book by Simon Sinek, and it’s just a wonderful way to get everyone on the same page and make sure everyone is heading in the right direction. “Why” is it that we are doing this in the first place?
Once we’ve got that, we work on a clear set of working agreements and that can involve many different things. When we were working on the purpose and the why we ask the questions “why are we doing this project, who benefits from this project,” and what does done mean for this project? What is the definition of done, when do we finish working? And then how are we going to work together. Now the best role and this can be anyone who has this leadership quality is the Servant Leader, who may facilitate that chartering process sitting down with the team, facilitating everyone, getting them working together and extracting that information from the team.
So they can put it down into words where it may have been hidden before. The servant leader’s role is also to help coach and to help remove blockers.
Now the team charter is also a social contract. That social contract can include things like team values, such as the sustainable pace and the core hours. We’ve talked about the sustainable pace before – we don’t want people to be working the midnight shift and then crashing and burning the next day. Or really going crazy one week and then having three days off sick – it’s just not sustainable, and it’s not a great way to work. From an Agile perspective we want that sustainable pace, and we want to put that down in words. What is that sustainable pace? Do we have set breaks, do we have set hours, what are our core hours, are they late or are they early, does everyone get in at the same time? All of those things, let’s write it down.
We have working agreements such as what “ready” means, so the team can take in work. So when are you ready to take in more work? What done means – so when are you finished that work? And the team can judge that completeness consistently.
Respecting the time box – so they are iterations of two to four weeks, and their work in progress limits. If the team is working in an Agile format where they’ve got cards and maybe they have limits for how many cards they can take on at a time, you don’t want all of your cards sitting in the backlog of work, but likewise you need to make sure that everyone understands when they can take on a new piece of work as well. And that goes in the team charter.
We want ground rules, such as one person talking in a meeting at a time. Or maybe you want a lot of discussion, a lot of collaboration at a time and maybe everyone agrees with that. And we want group norms such as how the team treats meeting times – is everyone on time? Or can someone miss it if they’ve got something really important on? What are those rules and does everyone agree?
Of course you can put any other behavior that the team wants to work with or address. Maybe something has bugged someone in a previous working arrangement and they just want to bring it up and they want to say – “Hey this didn’t work well the last time or maybe this worked really well,” and they want to bring this up and that can go in the team charter
as well.
How Agile Teams Measure Results
As we’re delivering in an Agile environment, Agile teams measure things quite differently to that of a normal project. The way they do that is that they actually measure results in the way that the project is delivered in other words the pieces of the project that are delivered, the functional pieces.
Agile favors value-based measurements, and that’s value from the perspective of our customer. So what are the valuable pieces that our customer can get their hands on and use, and how many of those pieces have we delivered? Instead of normal predictive measurements like Earned Value Management or Schedule Management or cost management that we could use in a more traditional waterfall approach, by measuring what is done and re-planning at each iteration by iteration there’s less room for error and more room to correct course.
And we’ll see that in the way that we measure those results with a burn-up chart or a burndown chart, and these burn up charts or burndown charts are basically these story points remaining. As you can see we might have features and then often many smaller “stories” will make up those features. And features can make up larger increments that we’re delivering to a customer.
The pieces of work that we’re working on as a team – maybe we have a thousand stories altogether in the in the product backlog and then per iteration we might have 20 or 30 or 50, but each time one of those stories is finished we’re marking it off on the chart, so we’re basically counting down the number of stories that we have completed. We want to aim for a certain amount of stories so as you can see here over 10 iterations we’re wanting to
finish that amount of stories but in reality sometimes it is a little bit different. So we can give ourselves a guide but obviously when it’s happening it might fluctuate – it might go up and down or not go at the exact pace that we want it to, because life happens and things get in the way.
So by making it visual and by measuring by the story points and the features that we’re releasing and the things that are getting done and the value that we’re adding to the customer – that is the way that an Agile team will measure results.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. There are core frameworks and auxiliary frameworks that you will come across on your Agile journey. Depending on the organization or the team that you work in, usually someone will be using some of these methods. You don’t have to use all of them, as often many of them have the same core practices underneath such as visual management, daily stand-ups, having a product owner, and grooming a backlog.
It’s really useful to know the actual frameworks and the names that
people might be using to refer to them, just so that you can keep up with the conversation and also understand what’s happening underneath – the underlying principles behind these methodologies. This one we’re going to look at involves Scaling Agile methodologies. We’ve got Scrum of Scrums, the Scaled Agile Framework, we’ve got Disciplined Agile, and we’ve got Large-Scale Scrum.
Check out the video and the article below!
Scrum of Scrums
With Scrum of Scrums, it is similar to Projects, Programs and Portfolios. If you’ve worked in project management you’ll know that we’ve got portfolios at the high level, then we’ve got programs underneath that, and we have a number of projects underneath that. It’s just a really high-level approach to managing a portfolio of work.
Scrum of Scrums is conducted when we’ve got two or more teams, usually of three to nine people (most often in a scrum team we’ve got three to nine people so it’s not too big but also not too small) and we’re needing to coordinate all of the work across those teams. A representative from each team will attend a meeting with other team representatives around three times a week. This is very similar to the daily standup but not quite – it’s just a method of keeping everyone on the same page across streams. That representative from the team will attend the meeting with the other representatives from their teams three times a week to report on their completed work, their next set of work, any current blockers in their work and potential upcoming blockers.
This is a really good practice and it’s good to see what other teams are doing. Keeping that
communication line open is important when you’ve got multiple streams of work all working towards similar dates or similar deliverables. The goal is to ensure that our teams are coordinating their work and removing blockers across teams, not just within the team itself.
The way it looks is you’ve got your Scrum teams of between three to nine people. You might have multiple Scrum teams so then one of these representatives will come and report to the Scrum of Scrums meeting three times a week. Then once a week we’ve got the Scrum of Scrum of Scrums – similar to that portfolio level.
Scaled Agile Framework (SAFe)
As part of our Scaling Agile frameworks we’ve also got the Scaled Agile Framework, or SAFe. SAFe basically helps with detailing practices, roles and activities at the portfolio, the program and the project levels, similar to our scrum of scrums.
It focuses on organizing the enterprise around value streams, that provide value to the
customer. We’re focusing on the customer’s point of view. These programs that we’ve got and the projects within them provide this particular piece of value and it’s basically with the end customer in mind, so everything is all organized around that value to the customer.
The principles are to take an economic view, to apply systems thinking (so to understand that this small piece in the system will affect the bigger cog in a system will and so on), in other words nothing is done in isolation and we always think about the consequences of even the smallest actions. Assume variability and preserve options, building incrementally with fast integrated learning cycles.
Does that sound familiar? That’s definitely an Agile principle – we’ve got our iterative approach, we’ve got our incremental approach, all of these things help us get stuff into the
hands of our customers quickly.
We want to base milestones on objective evaluation of working systems. This is Continuous Integration where we’ve got all of our changes going up into the one
environment so we can see whether it’s working or not, and we can see that on a daily
basis.
We want to visualize and limit the work-in-progress, reduce batch sizes, and manage queue lengths. Now that will be familiar to you as well with the visual management approach of Kanban. We’ve got the Kanban board and we can clearly see the work and whether it’s flowing through the the value chain, or our team value chain, from the backlog on the
left to done on the right. We can clearly see whether it’s flowing or whether it’s stuck.
We want to apply this cadence for synchronizing with cross-domain planning, and that is where our scrum of scrums will come into it. So now we’re planning with other teams and we’re helping other teams remove blockers, and we’re making sure that we know what’s
happening across streams as well.
We want to unlock the intrinsic motivation of knowledge workers. This is something that I haven’t seen mentioned in any other part of Agile, but it really is a core part of Agile. In fact the all of the practices that we perform as an Agile team and their core methods will actually help unlock that intrinsic motivation. That’s where you’re motivated internally as opposed to just motivated by money or a bonus or something similar like that. We’ve got things like checking in with with our team and making sure that everything is really clear, helping bring meaning to the work by making sure the work is connected to the customer. All of those things really help with the intrinsic motivation.
We’ve got decentralizing the decision making, and that comes across with our whole team approach where we have all the people involved, not just you know one person or one team.
Large Scale Scrum (LeSS)
As part of our scaled Agile frameworks we’ve got Large Scale Scrum, also known as LeSS. LeSS aims to organize several development teams towards a common goal by extending the Scrum method across teams, similar to scrum of scrums.
Because of that you’ll see some similarities between LeSS and Scrum and some LeSS techniques have been added to scrum. These similarities we’ve got one single product backlog, we’ve got one definition of done for all teams so everyone is on the same page. We’ve got one potentially shippable product increment at the end of each sprint (and we’ve touched on that many times we’ve got a sprint of two to four weeks and we’re showcasing an increment to the customer at the end of that so that they can see whether we’re on the right track or not and that’s our potentially shippable product)
We’ve got one product owner, who is someone representing the customer. We’ve got complete cross-functional teams – that’s our T-shaped person, our generalizing specialists with one specialty area and many general knowledge areas.
We’ve got one sprint and sprint planning is more formally divided into two parts of what
and how.
We’ve got organic cross team coordination, we’ve got overall cross team refinement (an overall retrospective focused on cross team improvements). This is where we take all of those normal scrum methodologies and we apply them across all teams. For example that retrospective where we can get all of our teams together and say what’s working well
across our teams, not just within the one scrum team itself.
Enterprise Scrum
Enterprise scrum is a framework designed to apply the Scrum method at an organizational level, not just at a single product development effort.
It advises leaders to extend the use of scrum across all aspects of the organization and to generalize the scrum techniques to apply easily at those various levels. We are wanting to scale the scrum method with supplemental techniques as necessary – core principles like stand-ups, retrospectives, Kanban boards and visual management, having iterations and
increments and all of those things.
In other words we’re not precious about which scrum techniques we’re using, but we can add to them whatever we feel works for our teams as long as it helps us scale that method across teams.
Disciplined Agile
Lastly for our scalable methods we’ve got Disciplined Agile. DA is a process decision framework that blends various Agile techniques based on the following principles:
People-first
Learning oriented where we’re encouraging collaborative improvement,
Full delivery lifecycle, where we’re promoting fit for purpose life cycles
Goal driven, where we’re tailoring processes to achieve specific outcomes so we’re looking at results over the process – that’s one of the core things you’ll see in Agile come back time and time again.
Enterprise awareness, where we’re offering guidance on cross departmental
governance. That means we’re still managing across teams whether it’s by
any of these scalable techniques that we’ve seen or just a scalable scrum
technique that seems to be really the core common denominator across all of
these scalable techniques.
Lastly, Scalable, covering multiple dimensions of program complexity and doing that in such a way so using the Agile techniques where we’ve got Visual management across streams and Scrum or stand-ups across teams
All that can help us scale this this approach and help all of our teams work together.
And those are the auxiliary methods and the scalable methods of Agile.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, by the Project Management Institute and Agile Alliance.
The reason we’re looking at these is because there are many different methods that you’ll come across in your organization on your Agile journey, and there are many core methods that you’ll come across and also many auxiliary methods that you’ll come across as well. It’s important to know what they are, and a little bit behind them so you can match them up to the core methods and see whether a team is truly Agile or not. This one in particular is Kanban.
The Core Agile Framework of Kanban
Kanban translates to “visual sign” or “card” in Japanese. It has come from the Toyota Production System so it’s got decades and decades of proof behind it in a production environment, and now it’s found its way into technology and project management and even enterprise management as well.
It’s a form of visual management, and it comes from Lean manufacturing for monitoring the Work In Progress. It enables “Pull” and “Flow”, which are two key Lean concepts. The Lean concept of Pull means that we pull the work when we’re ready, so we never have too much work on our plate – we’re never overburdened. It was traditionally used for inventory, so we would never have too much inventory (which is basically money just sitting there in a manufacturing plant, in a business sense) but it’s the same for technology.
There are certain core Agile practices you might be doing as a team – and not necessarily calling yourself Agile or using the framework names, but still working in an Agile way. Knowing these core practices is a great way to get a deeper understanding of Agile as an approach.
One of the best places to update your skills in Agile is from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. This one in particular is collaborative user story creation.
Collaborative User Story Creation
With collaborative user story creation, it’s important because poor specifications are usually a major reason for project failure. We may have specified what the customer wants, and then when they actually get their hands on it they may actually have wanted something different. Or we may have misinterpreted what they wanted in the first place. Al of this results in them not really being happy with the end result. So poor specifications are often that major reason for project failure.
In Agile development, user stories are written with with a lot of the people involved, from the customers through to the people creating the product. We’ve got the developers who are developing our product, testers, business representatives or the product owner in the whole team approach. We have frequent informal reviews of the things that they’re creating just to make sure that they’re right, and everyone who needs to be is always involved.
There are certain core Agile practices that you may already be performing as a team – and if not they are very easy to start. Direct from the Agile Practice Guide, and by the Project Management Institute and Agile Alliance, this is a guide to daily stand-ups as they relate to Agile and Agile project management.
Check out the video and article now!
What is a daily stand-up?
Daily stand-ups are short meetings to update the team on what we’ve done since the last meeting, and what we intend to do before the next meeting. The intention is also to help remove any blockers and make sure everything is flowing nicely. In that way a daily stand-up is a short meeting that’s used to micro commit to each other as the whole team. With the whole team approach we’ve got everyone involved in the one place – it’s a cross-functional team. Everyone necessary is in the one place to produce this product or complete this project, so when micro committing to each other and uncovering and removing blockers we’re raising them in this short meeting called the daily stand-up.
Do you know the different types of project lifecycles you can use to manage your project, develop a product, or bring a change about in a company?
The Agile Practice Guide goes into four main project lifecycles: Waterfall, Incremental, Iterative, and Agile. There is also “Hybrid” – a combination, which many companies end up using.
Check out the video for details on them now!
There are Many Different Project Environments
In the video, we’re looking at the different types of project life cycles and when we might need to use them. The reason we’re doing this is because there are many different types of projects, different environments they operate in, and projects are often very different.
We might have different organizational structures – for example it might be PMO controlled or it might be functional manager controlled, it might be just within one team or within many departments. There are different life cycles involved in how to manage those projects, there are different management styles, different sizes, different customer needs and requirements, different products or outputs, and the list really does go on.
You might also have co-located teams or dispersed teams you might be governed by a supportive, controlling or directive project management office, or the functional manager of a team. Your sponsor or customer might want daily reports, weekly reports, or they may just have a completely hands-off approach and want you to do the work and report in once it’s done. You may have more than one customer group receiving the benefit of the project which can really complicate things, and of course the project may be technically simple simple or technically complex.
Now all of these things combine into what we look at as the project having easily definable work or high uncertainty work and that’s the difference where the different life cycles and the ways of managing a project comes into it.
