Foundations of CtO: Change the Org for Benefits - BEYOND Agile, PRINCE2 + PMBoK-Guide Project Mngmnt | Simon Harris | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Foundations of CtO: Change the Org for Benefits - BEYOND Agile, PRINCE2 + PMBoK-Guide Project Mngmnt

teacher avatar Simon Harris, Seeking common sense for an often irrational world

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

10 Lessons (1h 2m)
    • 1. 0 Hello & Welcome

      2:04
    • 2. 1 'Framing' Noone ever did a project for its own sake

      6:10
    • 3. 2 The 7 Steps of A Change - From Concept to Benefits in Steady State

      1:33
    • 4. 3 The 'Light-Bulb' moment - Vision of an End-Point

      3:45
    • 5. 4 When Vision is Known We Are In A Project: 1st Define Scope & Acceptance Criteria

      10:13
    • 6. 5 Governance Decision Points For Benefits Realisation: 7 Step's Concrete Results

      7:37
    • 7. 6 Governance Part2: Project Control in Velocity or Earned Value Terms

      5:03
    • 8. 7 Governance Part 3: Simplifying the Model to just the 3 Essentials

      2:00
    • 9. Pt2 How the project components of the 'enabling-benefits-through-change' are described by 'well-know

      10:50
    • 10. 9 The Vocabulary of Agile, PRINCE2 and PMBoK-Guide (& Good-bye)

      12:50
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

13

Students

--

Projects

About This Class

  • Learn the holistic view of beyond projects to Benefits Delivery across Agile and Design-First Hybrid approaches
  • No pre knowledge required
  • Suitable for ANY-one & Everyone who is involved in responding to change in organisations - That is wider than managing projects

This is a short course that provides you with the foundations for later courses on 'How-To deliver benefits realisation and or successfully run projects and programs by making wise choices to mix and extend agile-iterative and incremental and or design-first approaches'

Here I cover "It is All about 'Change the Organisation for benefits' - the broader context that positions project management"

I'm sharing 40 years experience with you using some simplified descriptions of the journey from

  • 'Idea Moment' to the commitment of a Qualification decision,
    • This is pre-project
  • To Sanction decisions (Per sprint, release, stage or phase),
    • Typically the repetitive need to carry-out sprint or release or project or program planning 
  • To Acceptance (per Project Output Delivery),
    • The execution of the body of the program or project or phase or stage or sprints that form releases of output to the organisation
  • To Benefit Start,
    • The hardest part; changing habits to be new ways of working
  • To Project Closure and Recognition of Benefits in steady flow
    • A continuation of the hard part; bringing new habits to be a steady, strong flow of benefits for a return on investmen

Meet Your Teacher

Teacher Profile Image

Simon Harris

Seeking common sense for an often irrational world

Teacher

Hello :)

I'm Simon, I live in Edinburgh Scotland with my wife Lea. We have a daughter Becky close by and son Toby in UAE.

My topic is (almost) Project Management...

...which I believe needs to be rethought for most people's real needs most of the time. My passion is to add the common sense that the text books manage to filter out.

BUT you (I) can't turn the tide. The 'text-book' knowledge underpins most professional credentials and it is foundational. So I help folk with both "how to do it for real" and "how to prepare for professional exams".

Ciao

Simon

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. 0 Hello & Welcome: Hello, my name is Simon. I'm going to spend about an hour explaining what changing the organization is about and how that feeds into running the organization. I've used the phrase changing the organization because I think if I use the expression project management, I'm talking about the wrong thing. I've got to narrow our focus. I think we're seeing a lot of books published like this one on the room anymore, on that shelf up there that are not doing justice to what it means to be able to initiate a run a change initiative in an organization. I've been engaged in that sort of activity for about 40 years. I've got letters that I could put after my name, but I choose not to these days. And I'd like to share some of that with you in order to cover what we need to talk about. I'm going to go through the topic from beginning to end about four or five times. And each time I will come at it with a slightly different focus or emphasis or point to be made. And most of the diagrams in here are pretty complicated. Because successfully running change initiatives in organizations has shown itself to no actually be trivial. However, I would hope that by the time you get to the end, you can see that actually the diagrams are not complicated, they're trivially simple. I just have many components. Since this is a video. You can watch it first time round at double speed, and then it won't take you long to watch as it's taken me to record it. You might then also find it useful to watch a second or a third time portions. And then you might wanna do a normal speed. Let's get straight in now, after that little preamble. 2. 1 'Framing' Noone ever did a project for its own sake: Everything I'm going to talk about is predicated on the idea that we need balance. And we need context or a frame around what we're going to talk about. I've already said projects is just part of a howl. So to give the context, we need to recognize that nobody ever did a project for its own sake. It's only ever parts of a journey before the project. There is a commitment through the project. There is control. After the project, there are benefits. So a project is simply the means by which we enable new ways of working. It's simply the way in which we CTO change the organisation. Whether our organization is a club or a government, or a country, or a business, charity, or anything in between. What we're doing when we run a project is we're saying the world could be better if we changed some of our means of operation or we change what we are actually doing. So a project's outputs create the enabling capabilities that allow us to either protect what we've already got or give us something new. And in all cases that's a potential for a benefit. It's good job its potential for a benefit because it always costs us something to do it. Now benefits and costs are not necessarily money. There are all sorts of benefits and all sorts of costs that attach to our evaluation of what we wanna do. Why are we doing? How will we do it? When will we do it? So those are all questions that we're going to need to be able to be equal to. There is a great deal of argument going on at the moment across a community, which again, I shouldn't really called a project management community. It does, but it's not really quite correct. Which is about, do we use big design up front or Waterfall, or do we use iterative and incremental or agile? And these words are confused and confusing. So sometimes it's better to design before you start working, and sometimes it's better to work before you design. And in every project, there are elements. There are better off using design first, and there are elements that are better off using action and monitoring and design or decide as we go. So the argument about waterfall and agile is an irrelevant one. It's a religious one, it's not a practical one. My conversational way through here has nothing to do with sitting exams. I think those have taken sulfur completely stupid direction. This is about how do we do the stuff for real? And that conversation about how you build the assets. Do you use iterative and incremental and adaptive approaches? Or do you do design? First is about development choices. It's not about the governance and control and management. And all the conversations that conflict or mix these things up together are because people are not seeing all components clearly. I hope through this next 50 minutes or so that I'm going to give you clarity across what those components are. So I project is the means by which we enable outcome or benefit. Because we have some desire, some utility for what we're going to create, what we're going to leave behind as a project legacy. And enabling those benefits has a cost. And we always need to do our best to understand the benefit and understand the cost and the difference between the two is value. And if we follow the approach that's often labeled agile, then we fix our development time and our development results and therefore our development costs and do as much as we can. And if we do the big design up front waterfall approach, we decide at the beginning what it is that we want. And as we work forwards, we find out how long that will take us and how much it will cost us. The Agile approach puts the variable into the delivered scope. The big design up front puts the variable into the when do we get it and how much does it cost us? Now the Agile community have been arguing this sense, probably 2 thousand, maybe 1995, something like that. The US Defense Department identified these considerations as a good approach some 20 or 30 years prior to that in the DOD 5 thousand series of acquisition regulations and suggestions. And we can trace the same ideas back for hundreds, if not thousands of years. So agile is the very new vocabulary to describe this staff. There isn't anything new in it. It's just relabeled. No, that's not true. There are some really good new insights in there. But they're not about how you do product development or how you organize work. We'll do bunk all of that as we go forward and map the vocabularies together. So whether you are not your real work environment uses one set of vocabulary or the other, which in fact, in most instances is irrelevant. It is, is not pure. Most environments are, are a hybrid or a mix of these. I'm going to equip you with all of the insights from all of the different sources. And I'm going to say how they are the same as the labels coming from other places. 3. 2 The 7 Steps of A Change - From Concept to Benefits in Steady State: So vision or view or mechanism number one is, let's have a look at what I change. Looks like. I've only got seven steps for this change. And that's going to cover everything. I'm gonna also argue that because we are talking about the idea from first conception through to benefits and potentially even disposal. That everything is actually a program inside a program is a project on two projects perhaps or more. And I'm going to start with the premise that we're taking a jet fighter, so very fast, very high level view of something that's very simple. At the beginning we can see to the end, there is no challenge or difficulty at the beginning of the project describing what the endpoint looks like. And there is no difficulty describing how we will arrive at that end point. Both are both clear and stable. Now projects can have situation where when we start we don't know where we wanna go. And, or when we start. We got an idea where we wanna go but not how to get there. So I'm leaving those considerations to one side for a moment. And I'm just starting with the customer knows what they want and is convinced and stable in that. And the team knows how to deliver it and is convinced and stable in that. 4. 3 The 'Light-Bulb' moment - Vision of an End-Point: Step number one or item number one is somebody with that vision and power has a light bulb moment and they have a vision of an endpoint. There. Endpoint in this particular case is a bicycle which is going to give them some sort of utility, some sort of benefit in the future. And that motivation to make something happen probably need some assistance in terms of our Project Manager, the Agile community is going to tell us that all management is evil. Well, that's just not mature or realistic for real-world organizations are full of people who have a legitimate right and a need to take things forward in a way that is under control and is and is being monitored and is reflecting the needs of taxpayers or business owners or relevant stakeholders. And we'll debunk the idea that management is, is evil. Now, agile environment would put other labels to roles in here. And we'll pick those up as we go. Can't do everything first. So at the beginning, I've got some sort of sponsor has a lightbulb moment, some sort of vision. They commissioned something to be achieved. And that achievement is going to be dependent on a group of stakeholders. And some of them in the green circle, green for governance. In these pictures. Some of them are going to be the decision making function. And in that circle on the left-hand side, we have a business representative, senior user in terms of prints as a project management method or product owner in terms of vocabulary from agile environments, the duties, role, description, et cetera, is pretty much the same. There are some nuances that we might get time to discuss as we go forward. Also in that circle in the middle is the person who's paying and we presume or receive the benefits, the sponsor. And also in that circle, one is dropped the ball is the suppliers. All projects are an endeavor inactivity to deliver something. So have a supplier, even if the supplier delivers to themselves as the recipient. Afterwards. We got some other stake holders in there. There's a project manager, grey Business head, blue body for concern for creating the output, delivering the products or services that the project creates and read lakes. Red being the color in my diagrams to show activity. And activity needs to be focused on quality, but that's not illustrated quite yet. But when it is, it will be yellow. So we have a stakeholder community. And the thing that has to happen early on is we need to understand the degree to which we disagree. Although it's desirable if what we find is that we all agree the destination or destinations. And that when we agree multiple destinations, they are compatible. If we don't agree the destinations or they are incompatible, there's politics to be dealt with. And I'm not gonna do that on the, in the discussion about along clear straight road, but it is something that would have to be here if I was making the diagram even more complex than it already is. So now we have a description of the starting components of a project. Let's box act together, let's aggregate it. And let's say, well, how would we move on from there? 5. 4 When Vision is Known We Are In A Project: 1st Define Scope & Acceptance Criteria: And what we would do to move on from there is that having agreed what the destinations are, we will decompose that down into the enabling deliverables or outputs from the project. What is a project must bring into existence in order for that benefit to be graspable, to be realizable. And as we work our way through here, we are scoping what we want to produce. And for everything that's to be produced, we need acceptance criteria. We need to do quality specification. Otherwise known perhaps has quality planning. And those are topics that we'll talk about in another video. But I, but quality specification, quality planning in Agile terms might be called definition of done. Might be called things like acceptance criteria means in some domains. And we might express, or we will express that what are we going to deliver in either a product backlog or I? Product breakdown structure? Product breakdown structure is the prince term. Work breakdown structure confusingly as the Project Management Body of Knowledge term, but they mean products not work. That's just a confusion. Like ball bearing isn't actually, isn't actually a bowl. It's a set of items. So vocabulary is no unwise literally translatable. In an agile environment, it's a backlog. It's a list of stuff that we might do. No, it's not. It's a list of stuff that we might deliver, product backlog. And while time we get to the point where time and money has run out, will it delivered some of it? But we wouldn't necessarily have delivered all of it. So that's the second chunk of activity. And maybe on the way through that second chunk of activity, Project has actually started. For project might not actually start until we've got the next chunk, which is once we understand the scope of what's to be delivered, we can ask people with expertise, how would you do that? And then answering the how would you do that question, we get the list of tasks or activities to be performed. And tasks and activities have to have a sequence, either because we don't have enough resources to do everything simultaneously, or because the laws of physics prevent it. For example, putting the roof on a building is not possible when the walls aren't there. Putting the walls implies is not advisable when the foundations are nowhere. And digging the foundations when you don't have permissions would be, in many cases a mistake. So we need to model our dependencies. When we model our dependencies for tasks, including dependency on resources, we determined how long things will take. And we can then produce things like schedules. And if we know how long a resource is going to be occupied for and how much resource costs. We can do things like budgets. And I have that blue line. Wiggles its way across the page there. And I could describe that blue line is the budgeted cost for the work that has been scheduled. Or I could just call it a burn up chart. So identical consent conceptual models, but with different names as always different between them is the name. Now if I'm in an agile environment, I might not draw a burn up. I might draw a burn down. If I draw it burned down, I simply make the line go this way. Instead of that way. There isn't anything fundamentally different in any of this stuff, apart from the name and the religion that claims the which name is correct and the other names are wrong. They're not, they're just different. Now, somewhere between stake holder agreement on destination and understanding of the work that's to be done in order to create some results. So that's task dependencies, budget resourcing, schedule, risk, and then either baseline or burn up or down. Somewhere between those is the point at which the project might be deemed to have started. And if I'm in an agile world, then my unit of, let's go forward and do some activity to produce some result, perhaps ten days. And we give it the name sprint. If I'm in a prince environment, we give it the name Stage. The two are identical in concept. They are a fixed amount of time during which we intend to deliver a predefined amount of results. And we hope that we can do it with our predicted amount of results. But reality often gets in the way and we can't always do it with the predicted amounts of resource. In the activity that goes on, the work. It builds results and it verifies those results versus the quality standards that we selected when we did quality specification or quality planning or definition of done. Definition of done says things like all the tests will have been passed. It doesn't actually say necessarily what the tests, where the test for ice cream might be, for example, that it's frozen solid. The test for, for a fizzy drink might be that it's actually fizzy. The test for a building might be that it doesn't fall down when there's an earthquake. And that it has a particular degree of thermal insulation, for example, all this stuff, all this quality staff is quality control done by the people who are building the product. It generates audit trails or feed back information that allows us to tell whether or not we are proceeding at the speed that we intended through the plan. And if we're in an agile environment, we'll call that team velocity. And if we're not, we might call it our schedule performance index. Again, the two things are identical in everything except for name. It just depends which religion you follow as to what you call the stuff. So that's a red activity work with the yellow Quality Center. And as we build component parts. So we need to assemble those parts, integrate them, and test them as an assembly. So the quality dimension in the red circle at the bottom is testing the component parts as they're built. The next red circle up, one just coming in now is testing the assemblies. And we could say that what we're now doing is confirming both the functional and non-functional characteristics of whatever the products are are being verified. And I got a phone here. Functional capability, it makes phone calls. Non-functional capability. It's not too heavy and the battery lasts for a long time. Battery last for a long time, could be argued to be functional. To eye care. Not particularly as long as you understand making a call is functional and not worrying too much is nonfunctional. And battery life could be either. Who cares about the label for the attribute? Let's just make sure that we understand it as we go through the planning activities and we confirm it as we go through the quality activities. And the if as we test, we find that there is something not as we want to, then we've got some scrap and rework. And that's unpleasant unfortunately. And that's the quality conversation. And I'm not going to go down a quality conversation any further now. But it's in the background. Is it relevant to where we currently are? If as I assemble things, maybe I've done three two-week sprints. I've assembled some stuff, I'm ready to hand it over to the customer. At that point, there must be some acceptance by the customer says, Yes, I will take that off your hands. It will give me some sort of benefit. I can use it. If it's an agile environment, we've optimized the time to the first hand over by creating a situation where we can hand over the minimum useful element, sometimes called a minimum viable product. But that's not quite the right use of that, that phrasing, but you may be familiar with that phrasing. So having a right to a situation where I can hand something to the customer in an agile environment. I'll go back to my backlog and say what's the next most valuable thing I can work on for the customer and are continue to go around that circle, continuously extending or delivering incrementally until I've delivered everything the customer wants all the time and money have run out. That's quite a busy diagram now, isn't it? I hope you'll agree that none of the individual bits were particularly complicated, but they all have to be there one after another in order to start generating the benefit and value stream. Let's just strip out all the stuff that's about control and just come back to the essential from the business perspective. Which is at the beginning somebody has an idea which is compelling enough to get a group of stakeholders to discuss and agree and work on and deliver so that we have benefit. And the benefit is the 20 years that follow after the 12 weeks in the middle. I mean, it might be ten years or a 100 years of benefits and it might be five years of development, might be five weeks of development. So there is our starting point for a read description of the whole. So I'm just going to. 6. 5 Governance Decision Points For Benefits Realisation: 7 Step's Concrete Results: Take out the stakeholder community there because I don't particularly need them for this bit of conversation. And I'm gonna say that arrow number one from the previous diagram, an arrow number two, where somebody has a lightbulb moment and we put in place a project manager. And so that was the totality of an area of concern to us. It's a bounded piece of work. And that bounded piece of work needs to make sure that we understand from the sponsor where we're going. Now a topic in change the organization that is not very well understood and is outside the scope of projects. And for that reason is very poorly covered by pretty much everything that claims to be a textbook on the topic is how do we do benefits management? And given that my person riding into the sunset or into the rainbow with a, with a bag of gold is really enjoying the benefit of my project activity. It's fundamental to having a proper understanding of this picture that we discussed benefits. Well, we need to add to the current canon of knowledge for project and program management or portfolio management to talk about, well, how do you get benefits done, right and well? And the first thing is that the beginning you need to cite to the sponsor, well, why are we doing this? What's the benefit? And the sponsor says, well, it will be great and will go, well, how do you know? And I say, well now c, and then you go, okay, right now I can write some tests. And the tests that I want are the sponsors of benefit entry test. What things will tell you that benefits have been enabled? And I want the earned benefit tests or the benefits flow tests that tell me that benefits are heading in the right direction, but don't start instantaneously normally. They start slowly and ramp-up. So benefit entry is when they start and benefit flow is when I can say, you know what, we don't need supporting project or program anymore. The operational RTO run the organization business as usual, is now in a new stable state. So this slot marks a milestone and I am going to call that benefits definition of benefit milestones. I'm going to say that qualification of the project sufficiently to be saying, OK, well, steps 234, we're about doing the planning stuff. So number three is about having, if we're going to see these benefits, what does that look to operational middle-management? This is the bit where people say to you, you know, that the trouble with projects isn't delivering the outputs. It's all the management who are operational management would come after the project. And they're not properly engaged and don't want things and a resistant etc. Well, my answer to that is we'll make sure when you start at the beginning you engage them and you ask the right questions. And the right questions here are as operational management, how will you enable the flow of benefits that would be proved? When we see the bent benefit entry and earned benefit tests being passed. What do you need in operational terms to be in place for that to be able to happen. What tipping points. And I am here directly referring now to the ideas that are in Malcom Gladwell's book, tipping points. What are the definitions of those tipping points? What are the three or four things that operationally has to be in place in order for the benefits that are enabled by the project outcome outputs to become outcomes and then become benefits. And these are creating business red points of recognition or business milestones. Maybe at this point I should define a milestone as the point at which we can recognize and achievement. Now we need a little bit more detail, perhaps. We had it in the previous picture. In order to be able to do planning, what we need is we need to know the functional and non-functional product product acceptance criteria. My phone isn't too heavy. Gotta define what isn't too heavy means and makes phone calls. We might have some technical specification there. Like it works on a, a, a 4G or 5G network. These are all about quality specification. There all about product specification. And they're about the translation of product into activities or work. So they're about product breakdown or product backlog to sprint backlog or work breakdown activity descriptions. And these now give rise to the description of the state that will have occurred when achievement within the projects as happened, these are development milestones. Now benefit milestones are often dictated right to left. Either business says, this is the target that we have to hit on when the technical community says nobody consulted us, that's Daft there half right? Nobody did consult them. But it's not daft. It's the way business works. Engineers understand you plan left to right. Businesses understand you plan right to left. Both of them are correct. They are concurrently, correct. And contradictory. It's the project manager's role to revise or to resolve the contradiction that's implied in the middle of that. And I haven't described enough to, you know, put it in this video. But we will resolve before we finished a series of videos. We will resolve that contradiction. Can't do everything at once. So when I've gone from the stakeholders and sponsors view of this is what the business looks like in the future. Backwards to. This is the work that we have to do today to move in that direction. I have the set of activities up here, which is about having built the sprint backlog or the stage work packages, the activities to be required, that's the tasks and therefore the skills required and the resources needed. Resources in Book times about people, equipment, plump, plant and machinery, and wrong result raw materials. I have the dependencies, so I now have the budget and the schedule. I understand by uncertainties, also known as risk. And I can build my baseline, either my Earned Value and earned time or my Byrne shot. They are plotting exactly the same staff. And somewhere between here and a little bit earlier, perhaps high consumption work to proceed. So in an agile environment that's sanctioning is, we've started the next two weeks sprint and prints terms. It's with approved a stage. Before I finished, I'll show you all the prints and PMBOK vocabulary and templates and documents. And I'll have contrasted them with the Agile or not contrast it because there isn't anything to contrast on showing you how they are also the Agile stuff. 7. 6 Governance Part2: Project Control in Velocity or Earned Value Terms: So the tin goes off to do the work, builds the things. Does the team product quality control, which is the Verification versus standards that we have done what was asked for. And that enables us to know the rate at which we are achieving. If we know the rate at which we are achieving that, and we know the basis or the expectation of achievement from the plan. Then we have our velocity. A 100% means we're proceeding as per plan. A 110% means we're going faster. 90% means we're going slower. So I have my velocity, which I could call earned value. That's my status. And I have that for the individual components. I can integrate those. And if I integrate things, I can ask questions like So now you stuck all the bits together. Can you make a phone call with it? And if you can't make a phone call with how heavy is it? So at this point I can start testing the non-functional characteristics. Like the response times, are faster than offline. When I touch the screen, it does actually light up. I don't have to wait ten seconds while the internal logic thinks about it. So at that point, I have, I have verified not some mistake on my slide because it says valid Felidae ID. I have verified the nonfunctional. If I'm not able to verify if I have to change that, validate that says validate the non-functional to verify the nonfunctional, then I have seen a result, found a variance versus my intention. And I must do an adjustment. And in doing that adjustment, I've had some rework. I've had some unnecessary work because I didn't get things right the first time. So that cycle of 3456 there repeats as often as is needed in order to deliver the totality of the result to the customer. And each time we deliver either a component part or the total results or the customer. The customer says, yeah, that makes my purpose. That is to say the customer validates fitness for purpose against need, which is different from the team doing verification versus the specification. The team can only do what was asked for. The customer judges against what was wanted. If we have a breakdown in description between Watts wanted and what's asked for, then again, we get a problem and I'll cover that in a video on quality rather than this one. But eventually we get to the point where the customer has accepted, wants to be delivered. And at that point, we are able to ride off into the sunset. So each time the team is ready to deliver, we get acceptance. And that might happen every two weeks, every two hours, perhaps. In a very agile iterative projects, it might happen only once in a big design up front and then build everything and deliver once. There is an advantage in that approach, you wouldn't want to build a nuclear reactor based on our, let's make it up as we go along scenario. Because when you get to the end, you want to know the non-functional characteristic of this is safe, was designed in from the very beginning. So things that have high non-functional characteristics around safety on normally novel ways is no there's no absolute rule in any of this stuff. But normally that's better done with design upfront than it is with iterative. There's a very famous agile paper that said, Would you have your next house built using our Joel on that was written by somebody who was a proponent of Agile, saying It's not suited for every circumstance. It is suited for a lot of circumstances and we really do need to understand how to mix the best of both into our environment. So delivery from the team marks the point at which we can start to generate our benefits. And it's the final delivery and benefit flow that perhaps marks projects closed. Project closure. We probably don't have our benefits being delivered in a steady-state. So we're not actually at the point yet where that sponsors earned benefits test has been proved to have been met. So the bit from two through 27 is the project. But the bit from one through two earned benefit is the business perspective. 8. 7 Governance Part 3: Simplifying the Model to just the 3 Essentials: If I clear out again and simplify down, so the, so what do we actually care about? Well, what we actually care about in a change, the organisation flow is, can the sponsor articulate what it looks like when we're receiving benefits in the future. Can the team work and generate status data that allows us to confirm that we are headed in the right direction and allows us to predict when we will finish or how much we will have delivered when we run out of money, depending on whether we're a big design up front or agile put the triangle of cost time performance. Either way out, doesn't matter what mmm, it makes differences about how you do the control structure and then deliver, deliver, deliver, close the project. When deliveries are finished, close the initiative by saying we're no longer in a changing environment. We're now in a run or businesses usual environment. When we see that the benefits are in steady-state. Or to simplify even further. Sponsor qualification, sanction, approval, delivery, delivery, delivery, closure, benefit flow. And the story. We've seen it all once now, it's tightness, nearly 40 minutes. I've got two other views that do not add anything in terms of breadth or depth. But I look from different perspectives. And they formalize some of this stuff in ways that are commonly described in textbooks. So we've just been through the reality of what does it look like to go from? I had an idea and I've got the money to invest in it through two, I'm getting the benefits. What does it look like from the other perspectives? 9. Pt2 How the project components of the 'enabling-benefits-through-change' are described by 'well-know: Let's take as the first perspective that real-world logic. And let's map it into the vocabulary and boxes and formality of either a prince to environment or an Agile environment. Because to all intents and purposes, the two are identical. I've said it a lot of times now. I've got three elements, three big circles up there. One is mapped product-based planning. That's the prints liable for. Have a product backlog, have a set of epics or themes that define the components of a roadmap or where are we going? I've got some schedule stuff, which is what does the clock and the calendar do as we perform the work? And I've got some activity cost and resourcing staff, which is the who's gonna take home what tasks in order to create the deliverables. And we start with that business gray, focus on what are the results, blue that we need to deliver? And how would we know that we had them yellow quality. And we might put that sort of stuff in print turns into a project mandate or PMBOK terms, Project Management Body of Knowledge terms, we might call it a, we might call it contract or business case, or somewhere around here, we might call it Charter. And at this point we're expressing the customers quality expectations and their acceptance criteria. And we may not have finished, we may not even have started at this time to be able to say acceptance criteria. But we know that these things are important to us. So we've got our roadmap, our epic, our themes, and we might have some aspects of uncertainty. And our sponsor probably needs some help doing that. And the person that they might enlist to give them help would perhaps be called Project Manager. There might be called business analysts. They might be called product owner. So they are just put product owner in. Prince, As I said earlier, we would call them the senior user. And the conversation needs to move on a little bit in terms of detail and prints would say, well, create a project product description and it gives us a template in the manual, its template number 21 in Appendix a. Agile gives us a set of letters to describe what that template also says. Now the template doesn't use the term invest. It uses the term smart, specific, measurable, achievable, realistic, and time-bound. But invest stands for independent, negotiable, valuable, estimatable, small, and testable. Well, basically they're the same thing somebody just decided, let's not use the word smart because that's already being used by other people. Let's invent a new one. And that's so that we can have something local to us. And that's all well and good. But it doesn't make them actually different in intent. So we're gonna define our target epic. And decompose it into component parts. Notice the Business Dimensional Gray element here is slightly less prevalent, and the blue or deliverable bit is much more prevalent. And the quality that is still prevalent, the yellow. We're doing our quality planning on quality approach determination here, and Prince tells us how to do it in appendix a 22. The quality management approach and Agile tells us how to do it by doing things like define the definition of done. And possibly if you believe that it's a good thing to do the definition of ready. And for every story as you make it investable, that is to say you make it testable. You define what the acceptance criteria are and what the quality standards are. So you don't exactly the same thing, you just given a different label. From there. We've got our product backlog or our product breakdown structure. They're just different names for the same thing. We're down to the lowest level, but a lower level of what are the products that we've got to produce. And at this point we can b into the project team. There is no particular need now for anything to be described in business terms because we are now talking to a group of folk who were about building these things. And they fundamentally don't need to know why, but they don't need to know what. So the conversation above with gray and blue was why and what? The conversation now with blue, yellow and red is what and how and how good the yellow is code for how good. And we might do things like estimate resources and estimate work. So I've got Story Points perhaps to use our Jarl vocabulary. Under. I know that the velocity of the team is that I can produce 50 story points a week. Or maybe it's three story points a week. It's team specific. But now I know that if I've got a 100 story points and I can do 50 a week. I've got two weeks worth of work. So now I've got durations and I know the dependencies. And should I choose two? If I know dependencies and I know durations, I can determine the critical path, the path that determines what the delivery time will look like. If I am in a scope driven world and I'm not gonna go off down that alley way in this conversation, but it will be in a future conversation. So I've got a baseline. That baseline is for ten days worth of work in a sprint, sprinting environment, Agile, it might be for a 100 days or 500 days in a big design up front approach. It's a combination of what we're going to do. So and therefore what we're going to produce, and therefore, what quality level it will be at. Another conversation that we need to have. The difference between it matches its specification and it's the best money can buy because they are different. And that then allows me to say, and the risk I have in not meeting that baseline is my tactical risk. Notice that the top of the picture, we had, the conversation about the mandate or the business need under strategic risk. Is it wise to invest in this? Whereas at the bottom we have the technical risk, which is, if I try and make this work, will I succeed? Now, do I have the skills and the capabilities to meet the baseline? Will I deliver a 100 story points in the next two weeks? But at any point I now have a risk inclusive baseline or I have a need to go back and maybe changed the activities to be performed. The read backwards going R0. Or maybe I have to question and challenge whether this is the right product set. Or maybe I even have to go back and challenge, is this the right business destination? I might have put against this single, double and triple loop learning in play here. However, when I get to the situation where I have a balance, remember the scales at the beginning of the previous video. When I have a balance between all of the factors of the resources, the products, the quality specification, the timeframe, et cetera. Then I have a baseline that I will execute against and I will gather status data, most, all of which is enabled by doing appropriate quality control. Then I will get back the information that tells me what was the budgeted cost, the work that has been performed. And I can compare that now with the budgeted cost of the work that was scheduled. And as a result, I can complete my burn chart. My Byrne shot has empirical data to a point and then a projection beyond that point. And that projection beyond the point is predicting where we will be going. As I take the status diets are and compare with expectation. So I'm looking at my Byrne shot. My burn chart says, you know what, we're only gonna have done 75 story points of delivery by the end of this sprint. Or my big design up front waterfall approach says it's gonna take a month longer than we expected to deliver all of this content. So I can use the idea of reporting backwards into the organisation taken a quality information about the work performed to predict project or predict where we will be. Vs, expectation will either be, this is what you'll deliver in the timeframe, or this is the timeframe to deliver everything you wanted. And in both, either environment, we may well adjust our expectations as we go. That's change control. Change control in the big design up front says, baseless, all aspects of baseline require authorization and effectively so does Agile. But it's, but it says what we won't change is the timeframe and the quality. What we will changes the scope. And as I said to you, the Department of Defense wrote this into the DOD 5 thousand acquisitions along with things like you need to have a product owner. Although they call Dark concept the integrated product team. Now this picture is expressing for us the vocabulary and the process control flows that we could find in the prince manual. The PMBOK doesn't really give us a control flow. And it also describes for us the control flow will find if what we're doing is holding sprint planning meetings and the like. It's taken us from qualification through to sanction, and then from sanction through to delivery, and then from delivery through to project closure, and from project closure through to earned benefits. There is nothing in this picture that is incompatible with or, or additional to the last picture that we saw. It's simply representing it in a different way. 10. 9 The Vocabulary of Agile, PRINCE2 and PMBoK-Guide (& Good-bye): And here is our last different representation of exactly the same stuff again. And using exactly the same color scheme that we've already seen is to say grey is benefit of business. Blue is product. Pink or red is our activity and monitoring, and yellow is quality. And I've got one additional use of color scheme at the bottom here, which is the flow of benefits goes from not very stable and effective in read through yellow to green, which is a green and pleasant land in the future when benefits are flowing well. And onto this picture, I am going to put both the prints and while all three of the Prince, the PMBOK, and the Agile vocabulary, wherever you live in disciplines and religions. Somebody within the corporate environment, CAPM, corporate projects and program management. Corporate or program management has the responsibility to kick things off to approve an investment. And the prints term is project mandate. The PMBOK term is probably business case, leading to something that could be at this point a charter, but the charter might be a little bit later. And Prince tells us at this point of qualification, because we know what the business end point looks like. Prince has no concept of how to define the benefits, but that I did with you half an hour ago. But print says, the project starts with sufficient authorization. And what we need to do is appoint the project manager. That's process number one in the starting up of project area or of prints, which I think's chapter 12 or 13 or the prints manual. And item number three in that same chapter, I'm going to say it's chapter 12, I think it is. Item number three says define the project's approach. So items 13 are appoint the projects, the appointment project decision-maker and the project manager and determine the approach. And the Project Management Body of Knowledge would say, yeah, you should do that. And we put it in Chapters 13, Section one, and Chapter nine part so and then you have to define the goal. And there's a bunch of initials in there that I'm not going to expand because of the time available. But look what we do at the bottom there is we plan using the picture that we've just been through. How are we going to build the project plans? So we're planning of the planning. And as a result of that, we get project initiation, we get that sanctioning. And this very definitely is the point at which I can say that the Project Management Body of Knowledge would say we had a charter. So project management body of knowledge or guide at so might just have said the Charter was a little bit earlier, but it's definitely no later than this point. Prints would now label this point the project brief. It gives us a template, a 19. How Jarl doesn't have these concepts because it's about how the team delivers on behalf of a product owner. So this is staff an agile product owner needs. But agile scrum, for example, doesn't tell us either that we need it or how to do it as a result. So agile starts a bit later than prints on, print starts a bit later than the business needs. And PMBOK arguably starts later than prints as a result of having permission to spend time and money. Oh, the other thing I should just say is that this is not the only sanction we're gonna see. Because remember, sanction happened every time we went round that loop that ended in delivery. And we're going to see that on this picture. Print says to us, you always need to tailor any method to the situation at hand. And that's a translation from the business need through the products to the control structures for the delivery of the work in a safe manner. And the Project Management Body of Knowledge Guide To says, yeah, we agree with that entirely and we've put it in 6.165.16.17.18.19.110.111.113.2. Chapter 13 of the Project Management Body of Knowledge is specifically understand your stakeholders. 13.1 is determined who they are and 13.2 is, how are you going to manage them? And all the other ones, 5.16.1, et cetera, are how are you going to manage scope, schedule, and budget quality, procurement, risk augments, decouple our think. Print says, yep, we agree to. You need to create a risk management plan. You need to create a change management plan, a quality management plan, and print size week put those in chapter 13, no, chapter 14. And we put them in paragraphs or sections 2345. And the result of all of our is we built the control system. When we have a control system, we know what the project plan, the high level governance structure needs to look like. So now we can plan at a high level, a roadmap level. To use the agile vocabulary, we can plan a roadmap level, what this project looks like. But we also need to plan the, the detail of the next. And Prince calls stage and agile calls it a spring. And agile would say two to four weeks long, ten to 20 days. And prints will say, yeah, that's fine. But Prince would probably go more like 60 or 90 or a 100 days than ten or 20, but there's no reason why you shouldn't do it either way around. I'm Prince to Agile would be very happy to say, you know, this is how you integrate prints and agile ways of working. And when we have all that lot, we stick in some sort of document which prints would call the project initiation documentation. And the PMBOK would call the Project Management Plan. We describe in paragraph 4.2.3.1, prints would describe it in appendix a 20. Agile wouldn't describe it in anything. It's probably your big visible charts or at least it's a couple of post-it notes or piece of paper pinned in the bottom of the corner of your status board. And then you go off and imprints terms. You commission a sprint, you commission a work package, you commission a piece of work, the technical activity gets done or the technical activity gets agreed. Sorry, that was my mistake. Received the work packages agreeing. Yes, boss. I have enough resources to be able to deliver their so yes. Team, we know what we're doing. Then we do the work with a heavy focus on verification, which is quality control. In process. I've got a lot to talk about inequality, but not in this video. We give a status update. Now there are perhaps some tensions between how an agile team would do its state to sing and how an organisation that has governance structures would interface with that, which I won't go into here. But the Agile team might be completely happily posting staff to a whiteboard in their workspace, whether that's a physical whiteboard or something like mirror, although Miro or one of the other, or Trello or Asana, Jira and all those sorts of sorts of tools. It doesn't matter what sort of tool we're using there. We're tracking our status and and that status information is causing corrections and generating reports up to whatever leadership decision-making functions might be necessary when we need guidance or approvals. Eventually this too or 20 weak piece of work or to, or 20-year piece of work has delivered something into the organisation. We deliver the results and not we've got a delivery milestone there. And we need to confirm that into the organization. And the Project Management Body of Knowledge calls this accepted deliverables. Prince expresses this as the satisfaction of the principle of focus on the products. And the Agile world takes it as a sprint demonstration. And they are showing to the customer of what has been produced. So we could either be doing things in a 100% of investigation before design, a 100% of design before build. Or we can be doing minimal amount of investigation, design, build, deliver. And that's why the d is at that point because that's when maintenance starts. Because we've now delivered the first thing. If we carry on delivering and delivering and delivering, then eventually we run out of work in this sprint or release. So we go off and we repeat the planning processes, and the sanctioning process comes back in. And we go back around the loop again. So now imprints terms, we have a new stage started. And in Agile terms, rather than a new spring, which is possible that wouldn't be a contradiction to what I've said. It's much more likely that we've got a new release started and that we've got multiple sprints within a release. And we go around the cycle again until in Agile terms we run our time. Or in big design up front, we run out of scope to be delivered. At which point we need to confirm with everybody, hey, everything's done. Everybody happy. So check all the products are approved, check everything's being handed over. Check everybody's happy. Close the project. Because this was an Agile and prints and Project Management Body of Knowledge Guide description. There's no earned benefit in here. The earned benefit bit is off the side of the picture because none of these things have an understanding. Therefore, they didn't set things up at the beginning and they don't follow things through at the end. Beyond the scope of the project. The only bit that's left, right into this picture and applies to all three is that every now and again, shit happens. Things don't go as expected. We get issues occurring. And so we need corrective action and we possibly need to escalate that upwards in the organization to get advice and perhaps approvals. And when we do that, we have to go through some sort of exception handling process. And that exception handling process is still necessary in agile environments. Although perhaps in some agile environments it's a little less clear how you handle it because it's not well-described. And that's now brought us into the realm of doing things like agile at scale. And therefore we get approaches such as safe and safe, you could argue, has just taken us back to the old disciplines of hierarchically arranged corporate. I'm control of change from executive from top of the organization to bottom of the organization with a bunch of Agile vocabulary across it. And that works perfectly well because I've been explaining here for the last hour, just about an hour now, all of these approaches are actually the same thing. What's changed is some philosophy, some view of what it means to build and foster teams and give teams authority and trust. And the vocabulary that we use to describe some of the component parts. But other than that, It's pretty much the same from the beginning up to project closure. We have a control system in the middle. And that control system keeps us in a good place.