hello and welcome to less than one point to the project Management overview of the faces of Agile I'm your instructor, Dr Kean.
In this lesson, you will learn
the basics of project management. 101
Why Software development Embrace project management.
What is requirements Gathering and the Iron Triangle? For those of you that have taken my enterprise project management class, this lesson will serve as a brief review
for those of you that have not. If any of these concepts seem unfamiliar or you would like more information, feel free to check out my Sai Buri Class Enterprise Project Management.
So project management, 101 A project is a different type of endeavor than what you would consider your operational business activities. It requires the development of a specific product service or event, meaning that it has a defined beginning and end.
Unlike operational activities, where
you if you're, say, a warehouse, uh,
Every day you come in, you shipped boxes, and it's always the same kind of work. There's no quote unquote and same if you're a cashier at a at a restaurant or retail location.
The concept of project management and the way they were going to see. How this impacts agile
is the idea that there is somehow
a magical science of designing the ability to do the most work in the least amount of time. So for those of you that are familiar with the waterfall type of project management, the idea that when I map out all of my dependencies and I become the most efficient
the performing the work of this project
that I will be able to get as much done as scientifically possible in the least amount of time. In essence, we become super efficient and there's no waste. We will get into that in more detail later on in the course. And what are some of the challenges of that, uh, that impact project management.
In addition, once you start actually looking at
executing the project, one of the Project managers primary roles is to manage the team. So if we design a structure to do the most work in the least amount of time,
then when we go to actually execute the project, how do we manage the team's throughput and workflow to take advantage of this quote unquote science that we used to manage the project.
So that's project management kind of in a nutshell. And for those of you that air well, most everyone will probably be familiar with the Apollo space program. That's where a lot of the development of traditional project management originated.
So the idea of the triple constraints, which we'll talk about later slide. And some of those things really came about
from the Apollo space program, which was one of the greatest endeavors of humanity. So it definitely did its job. It was a very effective project management process.
So that was in 19 sixties. Fast forward to the seventies eighties and nineties.
Once we started really building enterprise software projects, we needed a reliable and reusable and most importantly, a trainable way of actually
getting these software projects complete. So prior to this concept of project management and the idea that you needed a role called a project manager Ah, lot of these software projects were floundering, and, of course, they weren't even necessarily called projects at the time. So in the
mostly in the nineties, with the start to be a real need
for this process, these best practices that would help get these software products complete and out to market.
By the late 19 nineties, early two thousands P. M I, which is the Project Management Institute, was still not terribly. I t focused PM I actually celebrated their 50th anniversary the same US at the same time as the Apollo space program, and they were very focused on engineering,
product development, architecture some of these things, but weren't really focused too heavily on
I T based projects because the investment costs wasn't really there yet.
Fast forward to 2000 and two and a little known company, he said sarcastically named Comp Sha decided to develop a project management certification that was going to be focused specifically on I t projects. So they felt that the, uh
the PM my world, if you will kind of left the I t projects in the dark and they they thought they could step into this segment and compete. I'll give myself a little bit of a plug. I was one of I was one of those project management nerds or, I should say snobs back in the day
that also thought that calm she was was going to fill a niche that that needed to be filled.
And I was actually on the team that developed the initial project plus certification back in 2000 and two, and we all again all kind of thought of ourselves as we're gonna take this thunder away from PM I fast forward now, you know, it's 2019 almost 2020 and we see that, of course PM I adapted just fine.
So they also saw growth in the project management space four I t.
And were able to adapt and modify their existing processes to be more I t. Friendly.
process of requirements gathering and where this impacts agile is basically along. The ideas of there are multiple ways to perform work. And if we're interested in trying to develop the science of performing the most amount of work in the least amount of time,
we somehow need to gather these requirements and prepare to execute them.
So on the right hand side, you'll see more of a traditional business process model. And again, for those of you that have taken my enterprise product management class, you've seen this particular flow chart before, and it's kind of your standard. If this then this go back loop. You know, that's kind of that standard set up for building
software projects, but you can also use the same kind type of flow chart for almost any business process.
On the left, you'll see a more modern. This is actually a screenshot from Microsoft Dev ops, and this is a more modern take on requirements gathering. So rather than understanding all of the dependencies and the if then structure, we're just gonna list them out and make Little three by five cards of what the requirements are
and trust that the developer will be able to build them
without a whole lot of extra input. And that's going to go into a part of what makes agile project management more efficient than waterfall.
In addition, we always have the Iron Triangle. You can have a good, fast and cheap
picked two, so this is pretty much the most
I should say, the most well known
rule of project management.
We have three different constraints on our time. A time constraint, a budget constraint and a performance constraint, and a performance constraint refers to the what the software must be able to perform or must be able to do at the end of the project.
Now in traditional project management, we identify the driver and the week constraint. I e. The least flexible and the most flexible of the triple constraints.
And we're going to do the same thing with agile. But you'll see, based on the methodology that you adopt, how agile changes, how we identify the constraints. But it does not change what those constraints are. No matter how you cut it, we still have a finite amount of money time,
and we still have a certain amount of things that we must be able to
to do with the finished product. Also known oftentimes an agile as minimum viable product. And we'll go into more detail on that as well.
So in summary in today's video, we did a very brief recap of project management 101 why software development ended up embracing overall project management processes, how we can perform requirements, gathering and what the iron triangle is. In the next lesson, we'll see
where once software developers embraced project management, where they saw some issues and sought to improve that process.
I hope you have a great day and I will see you in the next lesson. Thank you