Time
3 hours 55 minutes
Difficulty
Intermediate
CEU/CPE
4

Video Transcription

00:02
hello and welcome to lessen 4.2 hybrid planning.
00:07
As we discussed in less than 4.1, we get a pretty good job outlining
00:11
the basic structure for an Angela,
00:15
a pure, agile project. And now we're gonna talk about
00:19
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
00:28
why do we do hybrid planning? Well, first of all,
00:32
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
00:46
agile is is really the way with the future. At least four technical projects I t projects. When I was
00:54
working for the State Wide
00:58
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
01:11
agile. We were actually trying to push agile as a viable alternative. But
01:15
the documentation and the regulations that typically exist within government agencies
01:22
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.
01:32
Um,
01:33
in the state of Florida, they're called legislative budget requests,
01:37
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
01:45
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
02:02
that has to go into asking for the money and unfortunately, well, as a taxpayer, I'm pretty happy about this. But
02:10
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.
02:21
I have no idea how it's gonna end up turning out,
02:23
but we're going to respond to change. It's gonna be awesome. Go agile. They're probably going to tell, you know
02:30
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.
02:38
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.
02:52
The more planning you can do on the front end
02:54
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.
03:05
So in hybrid planning,
03:07
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
03:17
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
03:29
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?
03:38
The idea of being
03:40
that once we get into the project execution,
03:46
if we've got good, solid, legally enforceable in the case of a contract
03:51
high level requirements, then I can use progressive elaboration and actually get to where I'm executing
03:58
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,
04:08
but it's, you know, the end versus the means. And what that means is
04:12
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,
04:23
you want to make sure that they're aligned with the end goals of the project, that there is a direct traceability to what
04:30
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
04:42
the good thing about that is that we spend some time doing that. We understand what we're doing. We understand
04:48
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
05:06
into not being able to be purely agile and actually changed drastically. And what I mean by that is
05:15
there's an idea of what's called some cost. So in a purely agile organization that self funding
05:26
every new dollar that you're going to spend on something, you need to think of that as though
05:31
it was the first time that you were going to spend that money
05:35
so that you don't get into the situation where
05:40
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
05:47
hydrogen powered car project
05:50
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
06:05
dramatic for effect,
06:09
but In essence, those billions of dollars are gone. They're wasted. No one's going to buy a hydrogen powered car
06:15
if the electric cars that someone, someone, finally cracks the code on electric powered cars.
06:18
So the smart thing to do the non emotional thing to do is just up.
06:24
So
06:25
everything
06:27
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.
06:38
The problem with hybrid projects is if it's big enough,
06:43
it can break the project, especially again when you're in the government space, where you've
06:47
promise to deliver something that maybe all of a sudden is no longer even needed by the people that are your customers.
06:56
So
06:57
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
07:08
the world as they occur in your mind to most government projects there. Multiyear project. So you're asking for money in year one.
07:15
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
07:29
private sector type project.
07:30
However, it does
07:32
mitigate some of the risks as opposed to pure, agile. And these are the risks that air at the
07:39
the business level, because again, technology changes, we don't necessarily care. We can adjust accordingly. But by having a mord,
07:47
uh, elaborated planning cycle,
07:50
you can get more business owner by in
07:55
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
08:11
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,
08:22
we're not gonna wait three years to deliver this new system,
08:26
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,
08:35
But we're not gonna tie our hands with
08:39
the details of every little work breakdown structure item.
08:43
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.
09:01
And then,
09:03
ideally, after a couple of generations of
09:07
a hybrid project, then you can make the pitch to the people with the money to say OK, now
09:13
we want to continue to build on this success and actually move into full blown agile methodology.
09:24
Here's a little interesting cartoon that I thought was pretty funny. And who doesn't love Gilbert? The
09:31
the bad rep that agile gets the reason why Ah, lot of folks in the government and in the large sector
09:39
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
09:50
there that
09:50
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
10:07
doing like they like they're doing here in this. Ah,
10:09
the Dilbert cartoon. Just shooting from the from the from the hip on this whole thing. We actually do have a strategy in place.
10:16
Eso in the video, we discussed hybrid planning
10:20
and I will see you on the next video.

Up Next

Agile Project Management

This course will introduce the history, applicability, and techniques used in various Agile project management methodologies. Agile has become one of the fastest growing and most popular project management methods throughout IT.

Instructed By

Instructor Profile Image
Kane Tomlin
Executive Consultant at FDOT, Professor
Instructor