hello and welcome to lessen 4.2 hybrid planning.
As we discussed in less than 4.1, we get a pretty good job outlining
the basic structure for an Angela,
a pure, agile project. And now we're gonna talk about
what a hybrid project would look like and why we would do a hybrid project. I'm your instructor cane, and we will go ahead and get started. So
why do we do hybrid planning? Well, first of all,
it's very common for modern government projects. And the reason why that is for 22 reasons. One. The government which courses typically one of the slower ones to catch up, is, does realize that
agile is is really the way with the future. At least four technical projects I t projects. When I was
working for the State Wide
Technology Office for the State of Florida, one of my roles was overseeing all of the other state agencies and their projects, and you could definitely see the trend where they were trying to get
agile. We were actually trying to push agile as a viable alternative. But
the documentation and the regulations that typically exist within government agencies
really put a crimp on the idea of a purely agile project when the biggest reason why that is is because of the way that government does their procurements.
in the state of Florida, they're called legislative budget requests,
but they're basically the same. Whether it's federal or state government. You have to go and ask for the money. You're not given a budget
every year. That allows you to internally fund some of your big projects your technical rewrites, system replacements and whatnot. They have to get special funding, usually depending on the state. Have to be renewed every year. And so it's also there's a huge amount of documentation
that has to go into asking for the money and unfortunately, well, as a taxpayer, I'm pretty happy about this. But
trust me is not like a real viable way to get money from the government. So if you go in there and say I want to do this really cool technology thing, I've done very little planning.
I have no idea how it's gonna end up turning out,
but we're going to respond to change. It's gonna be awesome. Go agile. They're probably going to tell, you know
So, in addition to getting the money actually executing contract and this is the same for bigger companies as, well, the procurement part of it.
If it's not in the contract, lawyers get nervous. So that goes back to that trust me thing. You know, if you're not internally, funding the project or not, using internal resource is and you're having to go out and do procurements.
The more planning you can do on the front end
happier all of the business folks and the lawyers. And you know, that kind of stuff is it's got to be in some things have to be in the contract in order for it to be legally enforceable.
So in hybrid planning,
the planning phase usually looks an awful lot like waterfall. As far as you're doing your requirements gathering. Ah, you're documenting them and and you're
not quite going to the work breakdown structure level. But you're trying to get a lot more detailed planning than what would occur in a hybrid project or a agile project. So
you are doing requirements gathering. You are documenting. You're looking at high level budgets, high level timelines. How long is this stuff gonna take? how much effort am I gonna have to put in there?
that once we get into the project execution,
if we've got good, solid, legally enforceable in the case of a contract
high level requirements, then I can use progressive elaboration and actually get to where I'm executing
as agile as possible. So we talked a little bit about the requirements process in my previous class. I'm not going to spend a lot of time on it,
but it's, you know, the end versus the means. And what that means is
that the ends are the project goals. Why are we doing this? What is the goal and the means? Is that how we're going to get to it? So when you're designing requirements,
you want to make sure that they're aligned with the end goals of the project, that there is a direct traceability to what
gold this is going to support, and that's important both from a contract and procurement standpoint as well as any kind of regulatory or legislative standpoint. So
the good thing about that is that we spend some time doing that. We understand what we're doing. We understand
why we're fixing to spend a lot of the taxpayer's money on something that's going to hopefully benefit them. Ultimately, however, there is a little bit more risk in these types of hybrid projects because if a manger scope change occurs, then you've sort of legislated yourself or regulated yourself
into not being able to be purely agile and actually changed drastically. And what I mean by that is
there's an idea of what's called some cost. So in a purely agile organization that self funding
every new dollar that you're going to spend on something, you need to think of that as though
it was the first time that you were going to spend that money
so that you don't get into the situation where
you're designing. Let's say I use cars as an example. This is a pretty good one. You're halfway in the middle of a heavy duty
hydrogen powered car project
and you spent $50 billion all of a sudden somebody makes a breakthrough in electric powered cars, where they can go 1000 miles on a charge. They charge in five minutes. They cost next to nothing. I'm obviously being overly
dramatic for effect,
but In essence, those billions of dollars are gone. They're wasted. No one's going to buy a hydrogen powered car
if the electric cars that someone, someone, finally cracks the code on electric powered cars.
So the smart thing to do the non emotional thing to do is just up.
changed over the requirements. Go back to square line, canceled the project, whatever, and then adjust to that new major scope. Change. T Reach your organisational objectives.
The problem with hybrid projects is if it's big enough,
it can break the project, especially again when you're in the government space, where you've
promise to deliver something that maybe all of a sudden is no longer even needed by the people that are your customers.
you do want to do planning. You want to try to stay as flexible as possible on goal, being that you can adjust to as many changes in the in the
the world as they occur in your mind to most government projects there. Multiyear project. So you're asking for money in year one.
You're going to start working until year three, and you might not deliver it till year five or seven, so there, there's there's a lot longer timeframe versus a internally funded
private sector type project.
mitigate some of the risks as opposed to pure, agile. And these are the risks that air at the
the business level, because again, technology changes, we don't necessarily care. We can adjust accordingly. But by having a mord,
uh, elaborated planning cycle,
you can get more business owner by in
and at least at the high level, you've got some some cover, if you will, in the event that things go wrong and have to be adjusted. One of the things that I've noticed again within government. That's really where I've been working the last couple of years. But
it's a really good baby step. If you're a traditional project manager, if you're in a traditional project management organization or a government agency or whatever and we say, Look,
we're not gonna wait three years to deliver this new system,
we're gonna take our time planning it. We're going to make sure you are comfortable with the requirements. We're gonna have a pretty good idea how much it's gonna cost how long is going to take,
But we're not gonna tie our hands with
the details of every little work breakdown structure item.
We're going to gather those requirements prioritizing list of mouth and then execute according to agile methodology so that we can bring something to production sooner than three years and actually gain some value for this investment that we're doing.
ideally, after a couple of generations of
a hybrid project, then you can make the pitch to the people with the money to say OK, now
we want to continue to build on this success and actually move into full blown agile methodology.
Here's a little interesting cartoon that I thought was pretty funny. And who doesn't love Gilbert? The
the bad rep that agile gets the reason why Ah, lot of folks in the government and in the large sector
for the large cap company sector shy away from it is because it does have a reputation of being kind of the wild, wild West of all. These programmers are running around doing whatever they want
we don't have documentation on anything we can't see. We don't sign off on anything. So that's where, like I said it in the previous video, the project charter becomes really important as well. So it gives him a warm buzzy, lets them know that we're not just
doing like they like they're doing here in this. Ah,
the Dilbert cartoon. Just shooting from the from the from the hip on this whole thing. We actually do have a strategy in place.
Eso in the video, we discussed hybrid planning
and I will see you on the next video.