9 hours 3 minutes
Hi, guys. Welcome to control phase project Documentation. I'm Catherine MacGyver. And today our objective is to understand project wrap up documents.
So our previous modules are control plan and are monitoring plan have been focused on process owner documentation. Now we're going to focus on organizational and project team documentation. So, Dr Demming, if you remember way back he's one of our big influencers said, If you can't describe what you are doing is a process,
then you don't know what you are doing.
And I think that that's always particularly relevant to lean in Six Sigma teams because I feel like as we're going through our team and we're like, Okay, we're gonna give this away our process owner. We forget how to document and historically record ourselves. So we understand our process. And what did we learn about the organization
that is completely independent of the process itself?
our project's documentation, or what I like to think of as our project report, is our formal rap for organizational records. This is how we know that we existed and how we know what work we did in the project. So if there was ever a time in the future that the organization decides to revisit.
So we talked about going back to do make and
re improving upon already improved processes or for some reason, the process no longer supports the organizational needs. We can go back and see what exactly did the project team do? What did they learn? How did they learn it? So for that, what we want in our rep up record or a report is the final charter.
We want to make sure that we have our problems, statement, our business case,
our objective statement. We want our timeline or a time frame. We want our team members and why it was that they were important on that team. And we want to make sure we know how long did it really take?
This is important for us. Is a process team to learn from herself. So I think way early on, when I was talking about creating a timeline or a timeframe for domestic and,
you know, kind of putting your finger to the wind. As you get more established as a lean six Sigma Project team or lean six Sigma department within your organization,
you are going to get a better sense of how long were slow. Each of the dome make phases will take. So, for example, when I worked for a telecom company,
they had a lot of data. Like a law of data. They measured everything, which means that our measure phase didn't take as long because
there was so much data. We just had to identify what it was we wanted to look at. So as long as we were crystal clear on what our problem statement and what we were looking for was there was probably died in there.
So we flew their measure face. But conversely, I did some work in, um,
a school district eso elementary K 12 education. And they didn't. They had a lot of measurement data around their students, but they didn't have a lot of data around their operations. So we spent a lot more time focused on her measure phase. But God, they were good
analysis, like whipped through the analyzed face. So the reason why you want your original and your actual time from
is for you is a project team to learn from yourselves. The next thing that you want in your reports is you want copies of every single one of those tollgate documents you more copies of the tools. So if you did a sigh pop, you want that copy of that Sai Park? So we understand what information we were working from.
If I have to go back and review this project six months a year, five years from now
and those tollgate documents give us an idea of what did our sponsor know? What did we know from doing our tools and from doing our notes? Wouldn't our sponsor new from what we presented to them in our tollgate review,
we also want to know We also want to capture what our organizational learnings were. What did we learn about the company? That maybe it wasn't a factor in the process? Like what did we learn about benchmarking? Maybe, even though we didn't use our internal benchmarking for our improved solution development,
Maybe we learned a lot about it like we saw an opportunity for doing a project in there. Maybe we when we're doing our stakeholder analysis, we started seeing that
there are stakeholders that influence each other that have no relationship whatsoever. I will tell you that it always surprises my project team members
when they do a stakeholder analysis on me, and they discover that I'm actually highly influenced by our I T leadership. I tend to like to look at tech solutions, which means I want to hear from them about business applications. That's one of
my things. When I have a bias is I try to always look at the systems that were using, which means I pay attention to what the I T people have to say. That is a surprise for a lot of my project team members because I am a process person, which means I'm more focused on behavior and process steps.
So you want to capture those organizational learnings because they were something
that you took away from the project team.
So with that, when we're talking about our project documentation summary, this is a historical account of your project, and you want to make sure that it is detailed enough that somebody like me five years from now I can look at it and be like, Oh, I see what happened
with this process. I understand why they made the decisions that they made, why they want the direction that they went,
and if I were to do the process again or the project again using the information that they have, I would come just similar results.
If you are a lean six Sigma professional and you work for me, this is going to be one of the things that I am going to say until I sign off and say that your project is done, I want to see this and I want it to be big. I am.
I had a black belt who was really surprised when I'm like this is gonna be the most inefficient part of your job because
I want these reports to be at least 10 pages like, I want you to tell me why you chose the tools that you chose and what you learned from them, because I want to understand that we, as a project team, really made the time to invest that this project is a successful as it could be. And then later on,
I'm going to give our new built
copies of the reports and say This is what projects within our organization look like. So
that's it for the organizational project documentation. We want a historical record so that we know that the project team worked and where they went from and what their thoughts were. So we are looking back like, huh?
I think we did a project around that, but I'm not certain. Um, in our next module up is project storyboards, which will be it for our control. Faith. So I will see you guys there.