Here is what people have to say about David McLachlan:
“THE best instructor I have seen so far for the PMP, he not only gives you the information, but he TRAINS you to get into the mindset required to pass the PMP exam, and also to effectively manage your own project. Amazing course, amazing instructor, I believe in you, and so does David McLachlan.” – Xavier
“David McLachlan is one of the most sincere and personable teachers I’ve ever studied under. His positivity is genuinely infectious. It’s clear to me that what he teaches comes from a place of wanting his students to succeed, not just in the exam, but also in the corporate environment.” – Manunath
“Passed my PMP first try. In the 3rd section of the exam when I could feel myself getting tired, I imagined how you would read the question and break it down, and I heard your voice and your accent when reading the questions. I can’t recommend this (David McLachlan course) enough.” – John
“I have to say how amazing your (David McLachlan’s) video series is. Both my wife and I took the exam and we both passed AT in all areas. When I first saw your revies, I assumed they were fake because of how glowing they were. If anything, they under-report the true value you provide.” – Eric
“Hi David McLachlan, I passed PMP this week with 3 ATs. Thanks a lot for the humongous effort that you have put in to make things clear for us. You made me understand the concept so well. Thanks again David.” – Rekha
“Fabulous Project Management Plans(by David McLachlan) for any Project Management Professional (PMP). Saves you several hundred hours of work, prevents mistakes, and makes you look like a very experienced professional.” – Linda
“I took my PMP exam today, and could practically hear (David McLachlan) your enthusiastic, encouraging words as I made my way through the test. “How did you go?” “I KNOW you can do it.” “I believe in you.” I can’t thank you enough for your encouragement!” – Burt
“Highly recommend this (David McLachlan) course! The clear communication, efficient content, and handy review materials not only made learning enjoyable but also led to my successful exam outcome. Kudos to David for creating an exceptional learning experience!” – Said K.
“I passed my PMP exam today. I studied using all of your (David McLachlan) lecture videos as well as the several hundred question videos. You have a gift for explaining the material in an interesting manner with genuine excitement.” – DP
“I just passed my PMP, with all three Above Target. David McLachlan, THANK YOU!! I watched your YouTube videos and followed your class in Udemy. Thank you so much for sharing your knowledge, for taking the time preparing the materials, and BIG thanks for the enthusiasm and energy you put into, your smile and positivity are very motivating and encouraging!!” – Oddy
“I got my PMP certification two days back and wanted to express by sincere gratitude for your videos David McLachlan. What I liked the most is the way you have recorded them, the acknowledgement for the efforts and positive nudge was very effective. Thank you so much!” – Apurva
“I just passed my PMP today thanks to David’s Udemy course … it is hard to believe honestly! If you’re sleeping on the course, I highly recommend it.”
David McLachlan’s PMP Udemy Course is currently the highest rated PMP Course on Udemy.
See what people are raving about! Get the Project Plans, Project Tools in Excel, Udemy PMP Course or Udemy Agile course here:
Well done for improving your knowledge on Project Management! If you want to see the “Key Concepts & Tools” for Project Risk Management, click here. Enjoy!
Below you will find videos on all the Project Communications Management sections from the PMBOK Guide.
If you want to see the “Key Concepts & Tools” for Project Communications Management, click here. Enjoy!
Project Communications Management Overview
Plan Communication Management
Manage Communications
Monitor Communication
Well done for improving your knowledge on Project Management! If you want to see the “Key Concepts & Tools” for Project Communications Management, click here. Enjoy!
Well done for improving your knowledge on Project Management! If you want to see the “Key Concepts & Tools” for Project Cost Management, click here. Enjoy!
Well done for improving your knowledge on Project Management! If you want to see the “Key Concepts & Tools” for Project Scope Management, click here. Enjoy!
Below you will find videos on all the Project Integration Management sections from the PMBOK Guide.
If you want to see the “Key Concepts & Tools” for Project Integration Management, click here. Enjoy!
01 – Project Integration Management
Overview
Develop Project Charter
Develop Project Management Plan
Direct and Manage the Project Work
Manage Project Knowledge
Monitor and Control Project Work
Perform Change Control
Close Project or Phase
Well done for improving your knowledge on Project Management! If you want to see the “Key Concepts & Tools” for Project Integration Management, click here. Enjoy!
What is Tuckman’s ladder? It was created by Bruce Tuckman, a psychologist, and it’s a model that focuses on the way in which a team works from the initial formation of the team through to the completion of the project. As we get better and better at working as a team, things improve and change, and this is what Tuckman’s ladder describes.
There are five stages in Tuckman’s ladder.
We’ve got Forming, Storming, Norming, Performing, and adjourning at the end. These are the differences between them.
Forming
When we’re forming the team, this phase is where team members meet and learn about the project and their formal roles and responsibilities. Team members tend to be independent and not as open in this phase, so we’re still not really a collective team, we’re just independent people coming together. We’re still a little bit wary.
Storming
Next is the storming stage. During this phase the team begins to address the project work, the technical decisions and the project management approach. If the team members are not collaborative or open to different ideas the environment can become counterproductive. This is where we’re storming through those issues, trying to become one team eventually and you’ll see this happen all the time. All the independent people are working through those methods to become one collaborative team, and that’s where we start our norming phase.
Norming
In the norming phase we’re starting to work normally together. The team members begin to work together and adjust their work habits and behaviors to support the team instead of just working individually or thinking that everyone has a better way. Maybe we’re starting to come together as a team. The team members are learning to trust each other.
Performing
The next stage from here is when we are performing as a team, and this is where it’s a well-organized unit, we are we are really thinking as one team here. We’re interdependent, not independent. We have our skills but we are working towards one goal very collaboratively, and we work through issues smoothly and effectively because we all feel as though we’re the one team.
Of course with any project there is that adjourning stage, where a project will end. It is a temporary endeavour that delivers business value and so in the adjourning phase the team completes the work and moves on from the project, and it can be very sad if you’ve had a wonderful project team with a good performing stage. This typically occurs when the staff is released from the project, as deliverables are completed by the project or as part of the close project or close phase process in the PMBOK guide.
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.
