 So, here we are. This is a quote that I found that I think very nicely encapsulates what I, the message I want to convey to you today. So, the one-legged unicorn is also a really nice metaphor for the likely outcome of some projects, especially those whose initial requirements are of the double rainbow variety. So, where do things go so wrong on our projects? Well, most of our projects that we work on can be very technically complex, but that's generally the thing that is of least concern. It's more the raft of commercial pressures that we're subjected to and misguided requirements that we sometimes get from our clients and stakeholders that really trips us up on projects. So, if you combine this with the input that's also required from all the different people of varying skill sets that we have on our teams, you've got the making of a very challenging project. So, how do you deal with such a challenging set of circumstances and deliver your project successfully? Well, you think we'd know by now, but clearly we don't. A lot of projects don't go very well. So, as you can see from this study, which has run for about 21 years and studied 50,000 different software projects of all shapes and sizes, you can see from the data that the majority of the projects are either challenged or they fail, completely fail outright. One thing I do want to mention up front today is that I'm not here to evangelize about agile. Agile projects have their own problems that you can see from the data in the previous study. So, a lot of them are still challenged and also fail, but as you can see from this, it's definitely worse for their waterfall counterparts. So, with the odds seemingly stacked against us as project managers, what do the traditional project managers do as a formula for success on their projects? Well, this is what a lot of them revert to. So, they do this and they stick to it by exerting control over all the factors they think need to be controlled on a project and might have an effect on their ability to complete the project on time and on budget and in line with the original specifications. So, this model of centralized control, as we refer to it, is really not a healthy approach. And that's really what I wanted to talk about today. And I really think this is one of the main contributing factors that leads to projects becoming very challenged as we saw before or actually failing. So, in order to explore this in a little bit more detail, we'll start by looking at the role of the project manager. What things look like when they're too controlling, discuss how they need to distribute this control a lot more broadly across the teams that they work with and in the process transition themselves from being a manager to more of a leader. Also outline the environmental factors at play and the sort of business structures that influence the behavior of the project manager and have a real bearing on how they relate to those around them. We'll look at moving from more of a hierarchical model to a much flatter one. We'll also look at the mindset of the project manager and how this really heavily influences the mindset of those around them and the teams that they work with want to highlight how they need to move away from a fixed mindset towards one that's much more open to learning and challenges. And then finally, finish by having a look at the culture that is an outcome of this sort of behavior and the varying levels of control that are exerted upon the projects that we work on. And then look at seeing how we can move from seeing projects as a money making process machine to them much more as a living organism that requires a lot of attention and care. So the controlling project manager. So who are these people? Well, there's this one. If you hadn't worked that out, that's a picture of me. So that's back in 2006. And what I'd probably consider the peak of my own benevolent dictatorship. I'd recently completed a certification as a project management professional, and it even got myself elected to the local board of the project management Institute in Sydney. So I was a very proud project management practitioner. And at the same time, proudly acknowledged that I was a control freak. So I thought and honestly believed at the time that that was a really good quality to have as a project manager. It also convinced myself that my competency as a project manager was definitely due to my attention to detail and my extensive knowledge of the standards that I just learned about. And my ability to be in control of every situation on every project that I worked on. So I was delivering projects on time and on budget, mostly. And as far as I concerned, I was concerned everything was all good. But it wasn't that great at all. So it was actually very stressful. And I realized that in order to achieve the sort of perceived successes that I was having on projects, I had spent the majority of my time pouring over documentation and plans, making sure that everything I was doing was adhering to those original plans. So it wasn't long after this that I had a bit of an awakening. And rather than continue down this path of professional development that I've chosen and been undertaking for many years, keeping to extolling the virtues of the different project management standards that I'd been become accustomed to, and being indoctrinated into, I really started to question the whole approach. So I guess what I'd like to look at is, well, what changed? Well, one thing I did realize that the only reason that my projects were successful was I was actually very good at communicating with the people that I was working with, and always made sure that clients knew where we're up to. And the team had all the information they needed, keeping the flow of information going right throughout the project, and all the parties on the project had, as long as everybody was adhering to the plans and specs, it was great. So the thing was, though, what I realized was still all about me. And working on these projects really wasn't that much fun. So it was certainly all very well-intentioned. My intentions for the interests of the project were right. But as I alluded to a lot earlier, it was still very much a benevolent dictatorship. So ultimately, every project was an ego-driven exercise that was used to inflate the importance of my own role on the project. And I strongly believe that in the absence, in my absence on the project, that the whole thing would collapse. So that was probably right. But realistically, I'd set it up that way. So I always also obsessively looked for ways to improve the process on the projects and make everything much more predictable and repeatable. I mean, the question I used to ask myself was how hard could it be to build a website? And it was basically the same process every time we work out a content structure, we do some designs, we add the content, build a few pages, and then we launch it. It really didn't need to be that hard. So that might have been true, say 10 years ago, when I was originally in this kind of mindset. And to some respect, to some respects, it's still true today on some projects. But these were marketing-driven websites, but they were rapidly involving into very functionally rich web applications, content management systems were getting much more sophisticated in order to support them. And the requirements on projects were becoming a lot more bespoke. So it took a long, took a bit of time to realize it, but ultimately we entered into the realm of what was product development. So I guess at some point here, I reached a bit of a tipping point and knew that I'd had to make a change. Didn't really know what that change should be. But I came up with a very brilliant strategy to deal with it. And that was like quit my job. So fortunately, I've been tinkering around on the side for a little while. Actually, building of all things are my own proprietary content management system. Because of course, at the time, that's exactly what the world needed was another CMS. But really statistically, a lot of them were complete rubbish and they were very expensive, or both. And it turned out to be a reasonably good idea and kept me gainfully employed for a few years. So during this time, I got a lot of exposure to product development. So I really became, I really came to appreciate the iterative nature of producing something that evolves over time and something that you really spend, rather than spend an inordinate amount of time specking things out right from the start. You you work very iteratively through the product development cycle. And I got to look at this through the sort of I guess the eyes of project management and the experience that I've had for for many years. So fast forward a few years and multiple scrum, water scrum fall, whatever iteration of various project management methodology you want to look at and other agile approaches. What have I learned? Well, I know for sure that it's not focusing on the on the process that makes projects successful or enjoyable. And it's much more about focusing on the people that you're working with. So making compromises and sharing the experience together, whether it's good, bad or indifferent. So it's a little like going traveling together and working out your itinerary as you as you go, as opposed to being the board guide, board tour guide, just leading a bunch of uninterested tourists around on the same tour day after day. You know, maybe you book a couple of nights to start with, just to be safe. And but then you work together and base your plans on a general idea of where you're going. And generally, those experiences that you have, like a travel experience is a much more engaging and much more interesting by the time you get to the end of it. Everybody's got a lot more out of it. So in this context, I still see the role of the project manager as a person who's done a bit of traveling around this area that you're in. They know where they're going, they know what they're doing. And there are the ideas that they help the group navigate their way around. You need to be much more of a tour leader than a tour guide. So your role is also to help solve the problems along the way. You don't necessarily have to be the one who has all the answers, but you definitely step in where there's a problem. And you're the one who facilitates a way to solve this problem. You also want the group to get along with each other, of course. So your role is about ensuring that the relationships are built between the team and that they're healthy. You want people to share ideas and develop a common language that will ultimately benefit the outcome. You just don't, you don't want to be just an interpreter on a project. You also want to encourage people to contribute their ideas and challenge the decisions that are being made. You don't want the team to be just a bunch of followers and go along with a set plan. It should be everyone's right to contribute and be heard along the way if they have something to add. So most of all you want people to feel empowered and contribute beyond their role in the group. So you really want to create an environment where people are willing to volunteer and take on roles and tasks. They really streamline the progress of a project rather than relying on making, relying on you to make something happen or pass along the relevant information. So I guess the question is why do you bother with all of this and why don't you just stick to the idea of Gantt charts and specifications? Well I strongly believe that it's actually, it can be quite rewarding to take this approach and I've certainly got a much more meaningful relationship with the people that I work with and the relationship with the clients that I work with as well. And so I think it really is a great approach and a much more inclusive approach. Probably one of the best examples that I have recently in the last few years, at previous next where I'm at now, is that we started setting up a teams based model a few years ago and we wanted to move much more to this collaborative kind of working environment with each other and one of the first things we did was try and identify technical leads within the teams and we talked to some of our more senior developers and we said you know we want you to take on this role and we want you to start you know taking a bit of a lead on on the projects and working through the requirements and working with the rest of the team on developing the solution and the response that we got on a couple of occasions but one person I remember in particular was that they said to me I don't want to be a project manager and that was that. They didn't quite comprehend the idea of what the team lead was about and what we were trying to do so ultimately what we did was just kind of back off. We pushed down that path of still creating a team-space model but we just sort of let it ride for a little bit and adopted some of these approaches that I was talking about and what's happened over time is rather than sort of force this idea on to these people who were uncomfortable with it in the first place and thinking that it was actually taking on the role of a project manager was that they've come to realize that that's not what it was at all and in the last couple of years we've seen a lot of our senior developers really step up and take on and actually take on discrete projects of their own literally to the point where I barely have any contact with the client throughout the course of the project. So that's a really good thing it's been great for the projects it's been really good for the team and it's been we get some really good outcomes for the clients as well. So what sort of environment creates this sort of controlling behavior with project managers? So the standard kind of operating model for businesses is one that's fairly hierarchical and very management driven. So any project manager who's operating in this environment plays a really big part in influencing the way that you approach your projects. So some client organizations that you work with have a very similar effect and influence on the way that the project manager can operate. They might be operating in the sort of way that I'm trying to describe today but they're imposing a very traditional or hierarchical model on the project and the project manager which makes it very difficult for them. So while the client might be very engaged in the whole project they're very heavily influenced by the management forces at play and the model that they have to work within. So one of the other very big things that we find is a huge problem in trying to be a lot more flexible and I guess a lot more agile in these projects is the procurement process that we have to go through with our clients. So they're asking us for a very prescriptive response to a very very specific set of requirements and a lot of their proposals are like this double rainbow vision that I was talking about before and then they put in place a contract that dictates the terms that you have to work within and you have to try to stick to all of these specifications that are in place. If you don't tackle that right up the front of the project that just has this roll-on effect right through the rest of the project and becomes an instrument of control throughout the project. So I'm not suggesting that any of these project managers on either side of the equation with the clients or in our team are inherently bad people they're all trying to undertake these things with the right intentions at the start of the project but they do end up much more or they tend towards a much more controlling type of behaviour in order to appease the will of this organisation that they're working for in a very hierarchical and traditional structure. So one thing that we also find now is that like I mentioned before we're dealing with client organisations who still work within this very traditional model where we're trying to be a lot more agile and a lot less controlling in the way that we're approaching our projects and then we end up with this clash of cultures, essentially a clash of environments in working together. So what tends to happen is that we try and coach the client through or we set up a structure at the beginning that's kind of less hierarchical and we try and take the project team into a much flatter kind of structure but it really seems to influence a lot of the behaviour right throughout the project and we find that by the end of the project we still have a lot of people who are very weary and very over it, kind of the same sort of experience that I had years ago when we were running projects based on Gantt charts and specifications. What we have found though again is if you really take some small steps and try to introduce some of these ideas into the project and to the client and sell them in on the benefits of being less kind of hierarchical and controlling about the projects that by the end of the project they definitely have learned things and a very recent project that we did was exactly like this where we'd set up a, well they had set up a very strict contract and a very defined set of requirements. We tried to introduce an agile methodology into the project and coached them through. Everybody was very enthusiastic about it at the beginning but as we went through the project these management forces I was talking about before just kept, I guess, eating away at the model that we were trying to build and constantly using things like the contract as a weapon to try and keep us on track. Suffice to say we did get to the end of the project, we delivered it on time and reasonably within budget but everyone on our team was completely over it and the client was over it as well. So we did learn things, it was worth investing the time that we did in trying to get people a little bit more on board with the ideas that we had but it was still pretty excruciating by the end of it. So what is a more ideal model? Well one, obviously we share responsibility across the team, it's not just about the project manager, they're not the one who has to shoulder all the responsibility to deliver the project and it's something I guess you could refer to as a much flatter structure, it's not the hierarchical model I was talking about before. You also want to create a bit of a shared vision, the project I was talking about before, we were trying to establish a shared vision, we do this a lot with a lot of our clients even while working with fairly prescriptive requirements and specifications, we want to try and take a little bit of a step back to almost before what the procurement process was to talk to them about what it is that they're really trying to achieve and then showing them a lot of their requirements probably don't really share or don't really relate to this idea of a shared vision. So if you can move much, obviously if you can start that way it's a much healthier place to be and not working to this predetermined set of requirements and specifications. And then that way you've got this shared vision that you can kind of use as a real anchor point right throughout the project and at any point that people start questioning the approach or trying and referring back to some kind of specifications at the beginning, you can use this idea of a shared vision to talk that through and come up with a better approach. The better approach is something that I kind of see as common sense really, looking back at the approaches that we were taking years ago around using Gantt charts and of course people still use today and specifications, it doesn't really make a lot of sense because there's always a lot of change on projects. Every project you ever do never meets the exact specifications at the beginning. You create this environment where you're actually building things that people don't want or they're not likely to use. So if you take that on board and use common sense really a lot of this really starts to fall into place. So starting the project as a discovery led exercise rather than a specification exercise where you spend an inordinate amount of time drawing up designs and creating huge documents that you use as the reference point throughout the project. You actually, you start the project, you agree to a budget, you agree to a general set of or you agree to your shared vision and a general set of high-level requirements and then you go into this phase of discovery where you work together with the client, you work together with the team to really flush it out. I mean this is obviously a very agile type approach, building up a backlog of work that you're going to work on but you're not doing things or you're not trying to make a set of requirements that are highly prescriptive. So once some of these ideas start coming out you can actually start building and prototyping them. So in the time that you would be spending building these huge or writing these huge specification documents you can actually be working on the solution itself and part of the discovery process can be this idea of prototyping and just actually getting in there and starting to build or creating some of, putting some of your ideas into practice. And on the design front obviously back in the day the approach was to create a set of photoshopped designs that were then pixel perfect or the execution was meant to be pixel perfect and again like a lot of functional requirements what you end up with is nothing like the original design that you that you were given. So again our approach is to be a lot more iterative about the design process and starting with a kind of a master design approach and working from there. And ultimately what you want to try and do is as I'm sure many of you are familiar with is this idea of continuous delivery. So rather than this start and end to a project what you really want to be looking at is this idea that you're going to be working together on this solution or this platform for quite a period of time and it's going to evolve and you want to try and get get it launched as quickly as possible with the most high priority requirements that you've got but then you are going to keep delivering and keep working on this solution together. So that that kind of paints a bit of a picture about the sort of environment that we don't want to be working in and the sort of environment that we kind of aspire to now. So the next concept I want to cover off is the idea of mindset. So I touched a little bit on it earlier about what the mindset is of the project manager and how the environmental factors around them have a great influence on their role and what part they play in influencing the mindset of the team. And the influence that a project manager can have whether they be a controlling type project manager or a much more open and collaborative project manager the influence they have on all of the people around them and the mindset of the team around them and the clients that they work with can be huge. I think it's a a huge amount of influence that they have. So obviously what they do at the start of the project is very important that really sets the scene for what happens throughout the project as much as the sort of things that go on through the procurement process of projects the way that you set things up generally has a very long lasting effect right through the project and even can have an effect years later on the relationship that you have with the clients that you're working with. So effectively there's two types of mindset and I think these relate quite nicely to the sort of mindset that you get when you have a project manager who's a bit of a control freak and a project manager who is a lot more open and collaborative. So there's two types of these two types of mindsets can be referred to as fixed mindset or a growth mindset and like the levels of control that you or are exerted on a project there's different levels across the spectrum of mindset but the general theory is that you're either one you tend towards one or the other doesn't mean that you can't move between the two or learn to be a more growth-oriented person. So a controlling project manager obviously has a very fixed mindset they do feel very empowered and feel that they know best and that managing projects is their thing and they're kind of the smartest person in the room around how projects should run. They already know how everything should go because they've got a very detailed Gantt chart they've got a huge set of specifications they've got this document to work from they already know how it's all gonna go and then they set course accordingly so it ultimately becomes kind of their way or the highway and they feel like they've already know all the answers so if things go beyond their current knowledge or things become too challenging on the project they tend to get very stressed. So a project manager that's much more open to challenges and learn new ways of approaching things as they go through and as problems and challenges come up through the project is likely to be far less controlling and help foster a much more positive mindset right across the team. So what are the sort of things that actually define the mindset? Well while I was preparing my talk I identified a list of keywords that I thought were relevant to the content that I was preparing for my talk and I grouped them as what I consider good or bad depending on how they related to this concept of control on a project. For most of them they were actually pretty easy to group it was pretty straightforward as to whether it was a bad concept or a good concept and a few of them stood out though and I found well I looked at them and in a very unscientific way I thought this is a really good way to kind of define what someone's mindset is by looking at these words or these keywords that have come up and understanding how they would interpret them. So this is a set of bad keywords that I came up with and what I've highlighted here is a number of the good and bad activities the practices the approaches and the behaviors associated with the different types of working environments of centralized control versus a much more distributed control type model and you can see here from the words that I highlighted these are the ones that I felt really stood out and would be a really good test to put in front of somebody to say what does this mean to you in the context of project management so you can see something as simple as mistakes or failure are they a good or are they a bad thing so on a more positive note this is the better approach and the sort of activities and the description of an environment that's a much more a much less controlled and much more collaborative type of environment and again these ideas of these keywords and the way that you look at failure or the way you look at mistakes really determines what your mindset is yeah sure sorry so again it's a very unscientific conclusion that I've come to but using something like this as a tool to question your own mindset question the mindset of the project managers that you work with or the projects that you're working on can be a really useful exercise to identify some of the areas where you want to try and encourage some change or move a little bit more towards this less controlling kind of behavior so the last thing I want to look at is is culture and culture is really an outcome of the three other things that we've looked at so the project manager themselves the environment that they're operating in and the mindset that develops as a result of their own mindset and the mindset of the team I think combining all those things together you end up with a certain culture so the less desirable culture is something I mentioned before and that is this idea of projects or businesses or both being just some kind of money-making process machine and what you have in this sort of environment is two types of people you have the people who are in control and then the people who are working for them so this idea of controllers and pleases and there's nothing particularly healthy about that type of model there's only one side of the equation there that really gets anything out of it but as I've alluded to before even when you are in that controlling mindset it's really not much fun the sort of relationship that you end up having as a project manager with your team developers designers is much more like a parent-child type relationship and back 10 years ago when I was much more in that kind of control freak mindset and had actually recently just had kids I felt that the couple of years of experience that I had as a parent was some fantastic skill that I'd now acquired that allowed me to be a better project manager because this is essentially the relationship that you ended up having with the people around you it felt like you were managing a bunch of kids but realistically what I've realised now is that that was more about my mindset than the people I was working with admittedly some of them were pretty challenging so this idea of failure looking at those keywords before the way that you interpret failure says a lot about the mindset of the project and the mindset of the project manager so the idea that failure is not acceptable is a very strong indication that you're not really in the right frame of mind and you're not really in a very healthy working environment it's okay to fail as long as you learn from that and you fix the problems but when failure does occur or people make mistakes this is what happens it's very blame driven it's like who made the mistake whose fault is this and you try and isolate the problem rather than just moving on and the working environment in which you're in is riddled with this it's full of anxiety and pressure to deliver according to the schedule or within the budget or based on the specifications that you've had laid out so this is something I kind of occurred to me some time ago and the way that I would describe how these projects go and what this environment is like what a project is like within this environment and you may or may not have heard of it it's pretty common in movies and theatre this idea of a three act structure and it kind of really nicely describes what a project looks like when you're in this very controlling type environment so the three act structure if you don't know it is there's the setup then the second act is the confrontation and then the final act is the resolution and that seems to feel very much like a lot of projects that I've ever worked on or that I've been aware of is that you spend most of your time in this second act in this period of confrontation and working through all the things that should have been delivered or according to the specification and then finally to get it across the line at the end you move into this phase of resolution and everyone sort of agrees and says yep all right well that'll do let's just all get out of here because we're totally over it so looking at what sort of culture that we really want to have we need to we need to appreciate that what we're working within is a living organism but a project team is a lot of people they all have very different personalities the whole project itself is really just a big living breathing organism it's not just this machine that keeps cranking out projects for profit so we want to move the culture much more towards this idea of a learning focused living organism so rather than this idea of controllers and pleases what we want is a set of co-drivers and navigators so as a project manager you want to have co-drivers and you want navigators with you you don't want to be the one driving the car the whole time and everybody else just following your lead it reduces the stress on you as a project manager incredibly to get people on board and to get people helping you deliver the project essentially so back to that example I gave before now that we've moved a lot more into this culture of having people step up and do what they originally thought was project management takes a huge burden off us as project managers to deliver the project itself and ultimately everyone is is responsible for getting to the getting to the end of the journey the relationships are they're much more adult so this idea of a parent child relationship I think well I can confidently say now it's basically non-existent in the environment that I'm working in and I don't think that way of any of my colleagues or anyone that I work with any more at all maybe some of the clients we work with can be challenging at times and you might revert back a little bit actually saying that there is a good point to be made here which I'll come to in a minute is that you will find yourself reverting back you can't ultimately just go from this idea of a complete control freak to just completely liberated and letting go of absolutely everything there are points at which you need to sort of step in and revert a little bit back to that that idea of taking control but you want to you want to let go of it as quickly as possible so yeah the idea of working working with your colleagues working with the teams on a really adult kind of level and I don't mean it just has to be that way for you as a project manager I mean everyone has to get on board there everyone needs to be grown up about what you're doing clearly the idea of failure is something that you accept back to the idea of this common sense approach it didn't make sense that you're going to fail things are going to go wrong what we're working with is is complex fortunately what we do is not mission critical it's not life-threatening you know if something goes wrong with a bit of software no one's going to die unless of course it's a piece of software on a narrow plane but yeah so the acceptance of failure is is definitely part of this culture and of course when you make a mistake you learn from it you move on I'm not suggesting that you want to just create this environment where everybody's okay to screw up all the time and you know you just magically will get there in the end you want to you want to be sure that everyone is actually learning from these mistakes and rather than an environment that's full of anxiety and pressure we want to be moving towards this culture of happiness I mean we all go to work for you know however many hours every week spend a huge amount of our lives there what's the point really and unless you're enjoying it unless you're going to be happy unless you're creating this culture and the environment that that breeds this it is actually possible to enjoy your work and be happy I strongly believe that I have my days but you know that really is the aspiration that everybody should have and I think that you know the whole point of talking about what I'm talking today is that I really think that this kind of model and I'm only looking at it from a project management perspective but this kind of model really does lead to people being a lot happier on the project and if you as a project manager can influence that I think that's something that you can gain a huge amount of satisfaction out of and it's the sort of thing you know gets you out of bed in the morning and makes you actually want to go to work and then finally in this idea of culture rather than the three act structure that I mentioned before what you want to get to or what this sort of culture is one where you actually achieve a bit of flow so this concept of flow where you really the whole team is just working together really really well and they're producing all this great work and you know it just it feels right back to that continuous delivery model you just you're not having these different phases working through this kind of really confrontational kind of exercise it is just it just it just works so um they're all the concepts that I really wanted to cover off today and just to wrap up on the idea of control the idea of a centralized model of control is really not an effective strategy at all I don't think it's an effective strategy in business and it's certainly not an effective strategy for projects you really want this control that you have as a project manager to be distributed right across the team everyone needs to have a sense of control across the project project managers need to be much less managerial I mean the title is project manager but they want to be much more of a leader project leader than a project manager and much more focused on on that as their role project should really move away from this hierarchical model and um try and achieve a much flatter kind of structure I mean there's a lot of there's always been a lot of talk around these idea of flat structures in business and they may or may not work for some companies but really what you're trying to the message you're trying to get across there is you just want to create a much more collaborative environment where there isn't this kind of you know on the boss you know you're the worker kind of environment um and I think if you even if you work within those kind of businesses and you work with clients who are that way inclined or that's their kind of business model I think you can still move towards this kind of structure on your project so you kind of isolate the project from the um the the organization that that you're working for or working with and so the idea of culture is to to focus on this culture that recognizes projects and the teams of people that work on the projects as as a living organism not just this this money-making machine that just cranks out projects for the benefit of the business and the profit of those who own them but as I kind of mentioned before things you know this is not a perfect model things are never perfect on these projects that we work on a lot of them are still going to be challenging a lot of them will still fail even if we try and you know exert a little less control as a project manager so really the aim of my talk today is is just to be highlighting and now a very what I consider a very outdated approach to project management and and highlight an approach that I think is much more compatible with the way that we all work and the sort of projects that we do so what I would what I would say is that if any of these does resonate with you you may already be well down the path of this kind of model of working as a project manager you may be working with project managers who are still control freaks or as a project manager if you're not comfortable kind of throwing away the gantt charts just yet I'm not saying that that's something that you have to do you don't need to throw them away what you just need to do is take small steps towards being less controlling and letting go a little more and I think over time as I mentioned before it's taken us literally taken us years to kind of create this culture and this environment but every step of the way we're referring back to this vision and this idea that we want to be a lot more agile a lot less controlling and reduced as project managers reduce the burden on ourselves to actually be able to deliver these projects more effectively and with a bunch of people who are actually happy about it so what I would say is if you're still stuck in that kind of mode of working and you're looking to get out of it then just sort of have a think about how you want to approach your next project and kind of imagine something that or imagine getting to the end of a project and and it's being something that people truly value and they feel really satisfied with the outcome and you know everyone's actually very happy ultimately it'll be a lot more enjoyable along the way and the experience of the project will be something that you know works for everyone so yeah again as a project manager I think just have a think about the sort of steps that you can take towards developing a better culture and developing a better mindset for yourself and then for those around you and don't underestimate the capability that people you work with have so this idea again back to the concept of a team lead or a technical team lead and someone who thought they were kind of your project manager well if we if we just left it there then we we've missed out on a hell of a lot so what what these people that we've been working with have been capable of is enormous it's well beyond what you know probably their original well they thought their original role was but it really has been very eye-opening so I take a step back relinquish some of the control that you have now to the to the people around you and you know see how they go see how they perform and I think you'll be pleasantly surprised so distilling this all down into kind of one simple rule to apply across all of this is a lot of different things that you can do as I've outlined today and a lot of different tactics and strategies and things that you can think about but I think if you kind of run everything through this kind of filter or this rule it really totally kind of flips the mindset from that idea of a controlling project manager to one who's a lot more open up the controlling project manager clearly thinks the process is the more important thing the less controlling project manager is far more interested in the people and and focusing on them and getting a really good dynamic going on the project and just to leave you with one final quote from one of my favorite shows I strongly believe that this is the case so thank you that's it so if you have any questions please feel free to ask them well I didn't it was all very waterfall so back then it was completely waterfall but I would say that we we do still struggle now with agile and like I said before you end up with these clashing cultures sometimes with the clients and organisations that you work with so I think the strategy is to just try and introduce some of the concepts and the artefacts of agile and try and move it more towards an agile approach as opposed to a waterfall type project and even just little little steps will make a big difference yeah sure I my question is around customer management so you mentioned that you set a leadership value early on in the relationship with your team that failure is okay which I think is awesome by the way and the way that we should all be doing this and I'm wondering how how you translate that value to your customer relationship so when something goes wrong and your customer is like who did this which they sometimes do what's your answer to that in the face of the customer to make sure that that that sort of what's the one I want to give on that personality of your leadership style translates to them and that they don't go looking for a neck to choke on your team or someone to get like fired you know yeah well I think we it's not about being defensive but it's not about it's not about taking a step back from clients either I mean when they like that if a client is looking for someone to be accountable or someone to blame on that I think we actually we find yourself getting a little bit protective of the teams that you work with I mean the whole idea is to just work through it and rationalize it with them spend the time and just make the effort to calm them down essentially so and sometimes that's that takes a lot of time but yeah I look that's really the approach is to just try and calm them down don't ever you know let somebody in your team take the fall for it and again it's not about making yourself accountable either so this idea that the project manager is completely responsible for everything and they're the one who should be fired or they're the ones who should be responsible for these things is not true either I think I think if you're dealing with dealing with that sort of situation you're dealing with a pretty difficult person yeah I mean it has to be pretty dire for us to get to that point I think well to be honest I think if you get to that point with a client you've kind of failed a little be yourself for not addressing that earlier or getting to the point but look we have had the experience with clients where you get these people who are just difficult and they will never stop being difficult no matter how hard you try and but I think to answer your question it's probably it has to be pretty extreme to get to that point I think there's a lot that you can do to prevent that sort of situation but then again financially you need to be protecting yourselves as well to make sure that you're not continuing to you know add more and more to these requirements that that they have all these ideas of what you should have delivered compared to the specs and those sort of things so yeah I think very extreme situation but great all right thank you well thank you very much yeah thanks Mark that was great yeah cheers yeah that's for me being stuck oh sure I had that I'm sure I had that all under control yeah yeah it's great yeah I think I even got to point where I'm she's the front I'm up yeah yeah she's very nice yeah but I didn't get through that it was the only way to do it really nice I know people speak to you probably yeah okay I appreciate it I appreciate it especially the question yeah it's something that you also will work for in the public sector yes we do we do a lot of government work it's just a difference from the understanding of what people have done it's totally don't want to take it well interestingly some of them will be coming anyway it's not going to be that job so that makes a big difference actually I didn't mention there is a client who's just been trying to stop working there