Andy Jordan was our special guest.
His Twitter: @RoffensianPM
Transcript
Yegor: Everybody, good day, good morning, good afternoon. We have a next episode of Shift-M podcast, episode 32, and we have a special guest, Andy Jordan. Andy, say a few words about yourself.
Andy: Hi everybody and thank you very much for inviting me to be a part of this podcast. My name is Andy Jordan. I’m the president of a company called Roffensian Consulting. We specialize in project and program management, work with organizations helping them to deliver improvements to their strategic initiatives as well as Project Management Offices (PMOs). I am currently based on the island Roatan in the Caribbean. But I’ve got a lot of extensive experience in both Europe and North America.Yegor: Sounds great, thanks. Most of my questions today will be focused on a very sensitive topic which is project failures. So when everything goes well it’s one story, but when something goes south and we have problems, then most people don’t really know what to do, so I will really be interested in your experience in that cases. So my first question is how often do you see failures and projects which you consult when you’re working?
Andy: I think depending on the definition of failure to some extent, every project fails in some way. If you think about a project to the most basic level, we put together a plan or an idea that says “This is what we want to achieve and this is how long it’s going to take us and this is roughly how much it’s going to cost or how many people it’s going to take and these are the features that are going to be included in it.” And there’s so many unknowns when we do that, but inevitably something is going to go wrong, we’re either going to take more time or it’s going to cost more money or take more people are going to have to drop a few features or even what the market wants is going to move on. So in some ways something is not going to be achieved. I think the key is to then sort of say “Okay I recognize that something has changed”, it’s a failure based on our original definition but we need to change it to move on. And I think that often leads get worse or problems get worse because people fail to recognize that need to evolve that need to adapt to just learn and adjust as the project continues.Yegor: So you’re saying that failures is something which is happening normally and which we should have. Or… Did I get it right? Andy: Yeah I think so. I mean there are different types of failures, right? I mean if you are writing a piece of software and the code fundamentally fails to do what you wanted to do, you can’t really sort of say “Okay well that’s a different outcome, that’s kind of failure we can live with, we just adjust their expectations.” That’s a failure that you have to do something about. But in many cases a failure in one area is just an opportunity to do something different. At the end of the day if we can’t deliver what we said, we were going to deliver in the time frame for the money we’ve failed to do what we were expected to do. But we can still turn that around and make it a successful project if we still meet our customer needs, or if we still deliver something that’s worthwhile. We just need to recognize that failure is sometimes about shades of grey, if you like, as opposed to just a simple black and white, yes or no.
Yegor: And by saying “we” you mean all participants of the project like people who are paying for it, and then people who are spending the money, or you split those two categories? Andy: No, I think everybody has a role to play in project success and by extension in project failure even somebody who is involved in it, is just a team member and just a team member doesn’t mean they’re not important, but somebody who is sort of in the weeds and doing the day to day work. They have a much different understanding of what’s going on in the project, why things are going wrong, why a project is becoming a failure, if you like, than somebody who’s paying for it, and they have just as much of a role as in of identifying the problems and helping solve the problems, as does the person who is the sponsor, who is ultimately saying, you know, I approve, this projects were expected to achieve. Everyone has a role to play in that, and I think not only does everyone as an individual have a role to play. Everybody has to collaborate, has to work together because this is something that it’s a lot easier to solve problems is much easier to turn failure around. Once everybody is pulling in the same direction, once everybody is working together for the common good.
Yegor: You know, there is a Chaos report, so-called by Standish group, it’s quite popular document, and they re-issue every year and a few years ago, maybe the last year they said that about 94 percent of projects, which looks close to 100 percent, face problems or failures of some cost overruns or time overruns or just restart. So they are claiming that almost all projects we have in this world IT projects, they fail in some way, and they claim that this is a terrible problem, that we can no longer, I will quote them, we can no longer imitate these three monkeys - see no failures, hear no failures, speak no failures. So they say that we need to do something about it. But you sound like what you’re saying sounds like it’s a normal situation, we just need to you know learn something.. so what do you think.
Andy: Yeah, I mean Standish groups are the only one who comes up with similar reports. I’ve seen a lot of sort of, you know, reports where the headline is, you know, 90 something percent of projects fail. It’s good for grabbing attention, it’s good for grabbing the headlines and heck you and I are talking about it now, so I guess it works. There’s no doubt about it. If you look at a project and say “Success is simply about delivering on time, on budget and on scope”, then a very high percentage of projects fail. But that doesn’t mean that the projects themselves are bad in most cases. It means that the scope, the budget and the schedule, the time frame that we were given upfront were wrong. You know I could say to you “My project for you to do today is to paint the entire city of Chicago green by 5:00 tonight.” You’ve got to scope of the project - the city of Chicago. You’ve got a timeline and your budget is huge. You have to do it. So if you don’t do that, is that a failure of you in failing to do the project. Or is it a failure on my part by asking you to do something that is flat out impossible in the first place. Clearly that’s an impossible task. It’s a project that was set up to fail. It’s an extreme example, but a lot of the projects that are approved in organizations, especially in software delivery, are all about that kind of project. They’re set up to fail in the first place not deliberately, but because we don’t realize that when we say we want to build this product using five developers and 2 testers in the space of three months, that we can’t do that, it is physically impossible. So technically yes, that project becomes a failure statistic but it’s not really the same as a failed project. I prefer to look at things to say “Okay, in the grand scheme of things why did we approve a project. It wasn’t because we wanted to deliver a piece of code with five developers in three months, it was because we wanted to achieve a business outcome, a business goal. We wanted to deliver a product or service to a customer or a group of customers that will meet a need that they have and by extension generate value for us, build revenue market, share whatever it might be, if we deliver something that achieves that goal.” Who cares if it’s a little bit lack of features, a little bit late and it costs a little bit more money to develop. We’ve still achieved a successful outcome and that’s something that reports like the Standish Group’s Chaos report tend to miss. They fail to see the bigger picture. They just focus on the details.
Yegor: So it sounds like you’re blaming the people who are wrongly defined requirements which are the management layer.
Andy: Yeah I think there’s a lot of accountability in the management layer. I think there’s a lot of accountability in the project management layer and allowing that to happen although I realize that sometimes it’s difficult to push back but I think that there’s a systemic failure, an organizational failure in many organizations, that they fail to recognize that their success criteria of ontime, onscope, onbudget, have absolutely no bearing on whether or not the project actually achieves the results that were the reason why we invested in it in the first place.
Yegor: So there is no fault of programmers in those failures, or technical people?
Andy: Well I mean I’m sure that there are technical people who make mistakes. There are technical people who try to cover up those mistakes, who don’t always do things the way they should, who take shortcuts, who cut corners, who assume that something will work without testing it properly. There’s a lot of blame to go around when failure happens but I think that there’s too much focus on that kind of failure and not enough focus on the bigger picture. I don’t know anybody in any organization who comes to work every day saying “I’m going to do the absolute worst job I possibly can.” They’re not coming in to try and write bad code or faulty code or ineffective, inefficient code. They’re trying to do their best and they’re human beings. They make mistakes occasionally as do all of us. But that’s not the reason why 90 something percent of projects fail.
Yegor: So what is the reason. So it’s sounds like we all want this project to not fail. We want to do it right. We’re properly motivated to succeed. But still the majority of them just, well, not fail as we just discussed, maybe it’s not the right word for them, but they missed their deadline, they missed their budgets. So they go wrong. It keeps happening year over year, so why it’s happening. So what do you think is the cause of this?
Andy: So let’s go back to when projects are first thought of or proposed. Somebody is going to say “Hey we’ve got a problem or we got an opportunity or there’s something that needs to change. Your project is about changing something so we’re going to do a new release of an existing product. We’re going to create a new product, we’re going to put new system in place to get rid of some manual errors that are happening in our operations team, whatever it might be.” Someone says “This is an opportunity to do a project.” The next thing they’ll do is some kind of business” We know we’ve got this problem. We talked to a few people, we got a few experts involved, we think that we can solve if we spend 100,000 dollars. Give me six people for six months and, you know, I’ll do this, this, this and this and it will solve this problem.” That’s fine. I’ve got no issue with that at all. It’s a planning estimate, it’s a planning proposal, it’s a business case, it gets approved based on that business case. The problems then start in that we don’t refine those numbers. If I say to you I need 100,000 dollars to make this happen. That 100,000 dollars after the business case is approved suddenly becomes the total budget for the project. It doesn’t become an estimate that we know he’s way out because we haven’t done detailed estimation planning and actually figured out whether or not the 100,000 dollars, is 150,000 or 70,000 or whatever the real number is, we just say “Ok, 100,000, new budget, go make it happen.” We do the same thing with the scope we do the same thing with the number of people assigned. We do the same thing with a schedule. We never go back and refine those estimates as we go. And that’s something that is a lot of the reasons why we fail to deliver, because we’re guesstimating out front we’re coming out with these swagged scientific Wilder a”Ok we need to do a better job now refining those estimates, making more accurate, making them more detailed as we go. That piece is missing and that’s why we end up failing, because at the time that we actually set budgets we really don’t know what we’re talking about. Think about your own personal life if you decide you want to go on vacation or you want to buy a new car or whatever it might be. You can set yourself a budget, but you lock yourself into the first budget you think of on day one, you do some research and you say “Ok well if we want to go to this place on vacation or we want to have this feature in our car, we’re going to have to add a little bit more money to it. We’re going to have to compromise somewhere else and we refine over period of time as we do our research before we sign on the dotted line.” That’s something that we expect to do in our personal lives. It’s something we failed to do in businesses, that’s something we found to do with our projects. We just say ”Okay, this is how much we think things can cost. This is how much we think or how long we think it’s going to take. And this is what we think we can deliver and that becomes locked in. We have to meet it and it’s no surprise that we fail.
Yegor: And why it’s happening, why don’t we refine our targets?
Andy: I think a lot of the issues are systemic built into the way that organizations operate. There’s a failure to understand the project management process, the project planning process. So when we do high level estimates we say”You know it’s 100,000 plus or minus 50 percent or 100 percent or whatever, it’s plus 100 minus 50”, you know, and people will not listen to the uncertainty part, they’ll just lock in the number. If we then try and change that and say okay you know if we think that 100,000 is going to get locked in, let’s make it 200,000 dollars because that way we’re sure that we can get it done. Then it suddenly looks like an outlier from everything that’s happened in the past and people think that you know the problem is people just don’t know how to do their work properly they don’t know how to work efficiently. There’s a failure to recognize new organization, the management level that the process itself is broken. They think it’s the people doing the process that is the problem and it’s actually the process itself and that’s the piece that a lot of organizations have direct night simply because it’s the way we’ve been doing it for years.
Yegor: Well let me try to make up a hypothesis about this problem. Maybe people are afraid to come out with this uncertainty, like you said, in the beginning because in that case just like you said they will all look like somebody who doesn’t know what they’re doing but later running over the budget writing over the schedule will not be punished as badly because everybody used to see failures in IT projects and that’s why they don’t do that uncertainty the beginning. But they easily accept and admit failures later, because, like we know, 90 something percent of projects failed anyway. So it means that nobody will blame them for that.
Andy: Yeah I think you’re probably right. And I think that same logic applies on the benefits side as well, right? You know you can claim whatever kind of benefit you like “Oh give me the money to do this production” and generate 5 million dollars in new revenue for you, it’s going to be amazing. That’s what goes into the business case. But then no one looks at it again afterwards and while it’s fully expected that we don’t actually achieve that 5 million or we’re never actually bother tracking to see what happens. I think that you’re right. There’s a lot more visibility, there’s a lot more close monitoring of the business case. Those initial numbers but when we actually get the execution piece people don’t monitor it as closely and sure there may be a report that says we are late, we are over budget. But to your point well. So a 90 something percent of other projects so. No one’s surprised.
Yegor: You know you probably heard about this cone of uncertainty, it’s like the the paradigm that says that in the beginning of the project we have an uncertainty of like 300 percent. So when you don’t know anything upfront, you don’t know exactly what, you just starting the project in that particular point of time you can predict the let’s say the budget of the project with the with the accuracy of 300 percent. But when I do my projects when I try to bring up these numbers to my management sometimes they just laugh because nobody can put those numbers in their business plans and their business case they can’t say that the project will cost us 100 thousand dollars or maybe 400 thousand dollars. So from 100,000 to 400,000 - that’s going to be our budget. It’s completely impossible, nobody will sign on this plan. So maybe it’s a very deep problem in the entire industry. We just don’t understand how software development works. We just you know intentionally block, intentionally program ourselves for failures
Andy: Yeah I think you’re right and business cases in many organizations are not designed to truly be business cases, they’re designed to be sales pitches. They’re designed to get a project approved. So there’s no benefit in saying “You know, it’s going to take me up to four hundred thousand dollars” because, you know, full value will never get to project group, so instead you go “Uh, it’s 100,000 dollars.” Nobody wants to hear that uncertainty as you mention. And even if you put it down you can’t justify, you can’t explain why it’s 400 thousand, opposed to 300 or 500 or whatever it might be, simply because of that uncertainty and then you sound like a fool when you’re having the conversation with your manager and they say “Well why are you saying it could be 100, it could be 400? Why can’t you be more precise?” Well the reason you can’t be more precise if you don’t have enough information and you can’t explain that very well. So I think you’re right. People don’t want to hear it. And certainly sponsors don’t want to go to CFOs or senior management and say “I need a hundred thousand dollars for my project. But it might be four hundred thousand dollars so could you give me a contingency that’s three times the actual budget cost?» It’s not going to happen.
Yegor: You know I’ve been in the situation about six years ago, a long time ago, when there was a small project, a small startup, and they wanted to develop the piece of software which potentially could be as big as AirBNB or something, for traveling needs, for leisure hn needs. But initially it was a small startup and my team was supposed to develop a piece of software and they were asking me how much it will cost them, how big it’s going to be and I told them that initially we’ll be close to 100 thousand dollars or so and they said “That’s approximately the amount of money we have right now” and then we started to discuss features and I told them here and there will be more features in the future, here we’ll extend it, here we have a huge potential who add more and more features and software and they asked me during the dialogue they asked me”Okay, so it looks like it potentially could be a large project” and I said “Of course, one day it will cost you millions of dollars but that will happen one day when you will have some you know revenue and so on. So yes, you have to be prepared to spend millions of dollars. But that will happen later.” And the moment they’ve heard that, they canceled the whole thing, they said like “You don’t know what you’re doing, you’re just saying 100,000 dollars and then you’re saying millions. It seems like you’re trying to you know rob us and scam us somehow” and they cancelled the whole thing. So that’s my experience.
Andy: Yeah. And it’s not atypical, I know of an organization, it wasn’t quite in the same financial constraints but it was an organization that had you know billions and billions of dollars to invest in projects every year. It had one project that was going to cost 30 million dollars. And if the product was successful, it had the ability to generate about two billion dollars of revenue over the space five years and they were very concerned, that we were unable to say it every year 30 million dollar project as opposed to 35 or 40 million dollar project, because it was too early on the process. And I said “Well if the potential benefit is 2 billion, really does it matter whether it costs 30 million or 40 million. The will to pay, your willingness to invest in this project doesn’t change because the benefits are so large that sure you make marginally less money if it costs 40 million and 30 million.” But in the grand scheme of things the number is irrelevant. Maybe 10 million dollars. But it is completely irrelevant to the overall investment. You still want to go ahead and do it. You still want to make that commitment but they wouldn’t sort of make that commitment without knowing for sure you know this is thirty point three or it’s thirty two point six or whatever it was they needed that precise number. Even knowing that grand scheme of things it was completely irrelevant. Similar situation where you know the benefits could be huge and the investment back into the product could be huge down the road. But if that investment would depend on the revenue coming in but they got so scared about the total cost or side of that.
Yegor: What would you recommend to programmers and managers and people who are preparing those estimates to do in order to actually get an approval for the uncertainty?
Andy: I would say that the best thing they can do is always focus on the why - why is this project being done, and it’s not about anything that you’re trying to achieve in terms of features, to go by yourself for example, they didn’t want a brand new piece of software that potentially could attack the market. They wanted market share revenue customers you know whatever it might be. That was the business Scott if you can keep the conversation focused on that it becomes a lot easier to then have a conversation around cost uncertainty because she doesn’t really matter in the grand scheme of things whether or not the cost uncertainties at one end or the other as long as those business benefits can still be achieved. Now if the benefit of doing some is a million dollars and the cost may be half a million dollars or 3 million dollars obviously there’s a conversation that has to be had there. You know you’re not going to commit until you can do a more precise estimation of the cost so you can say okay let’s make sure this is going to be worth doing because the benefits may not be big enough to justify the cost if it’s the high end but in most cases have that focus, have that conversation around the benefits. The reason why the project is being done and it becomes a lot easier then to deal with the cost uncertainty piece.
Yegor: Uh-huh. And if they don’t listen to your wise explanations, if they just stay focused on numbers and still want you to sign on very exact and precise numbers, what would you do, you accept that or just say “I’m not going to work in this project”?
Andy: Well I mean from my standpoint it’s a little bit easier I guess because I’m not an employee of these companies. I’m a consultant to them so I can sort of say “You know if you’re not prepared to accept the reality of the uncertainty, then you know I’m not going to commit to it.” If I was advising an employee who’s maybe not in that position, then I would sort of say to them that if they’re going to force you to accept something that is still uncertain then there has to be a tradeoff to that. Think back to project management 101, where you’ve got the triangle of the scope, the budget and the schedule. If something gives him one of those, you have to be prepared to give somewhere else, so if you’re going to force me to work to a budget that I’m not confident I can meet, then you have to potentially give me more time to achieve the results you have to accept, that there’s going to be fewer features in place, or potentially that is going to be a lower quality outcome, because I can’t force everything to be fixed. I can’t say I will deliver exactly what you want, exactly when you want it, if you are also going to force me to do it for a fixed budget that I’m not confident about.
Yegor: You know that sounds reasonable to me. While the reports again about failures, they say that the majority of failures are coming from the management side. So only about 7 to 10 percent depends on the reports. Blame programmers and technical people and engineers for failures of the product. The rest of the presenters, the rest of the failures are put on the management layer, of people who are creating these estimates and planning, and failing to do something else. So my question is aside from planning. Aside from estimating, what are the other sources of failures? What do you think?
Andy: I think, from a management standpoint, I think a lot of the failure comes from a lack of understanding and a lack of engagement and a lot of stakeholders and sponsors and management layers think that their accountability for the project [inaudible voice] once they’ve done the approval that it can then just go into the black hole until something comes out the other end of it. And I think that’s something that is becoming even more true in the software development world, as software development becomes more and more agile in many organizations, because many management layers don’t really understand what Agile means, it’s just jargon that is beyond their comprehension. So they happily stay out of it, but when they stay out of the process when it disconnect from what’s going on, they’re not able to make intelligent decisions, and are able to guide her team to to avoid problems, or to recover from problems, so they’re not providing that support framework. The projects need in order to ensure that the project is successful at the end of the day. The teams don’t have the same level of context, the same level of understanding, of the drivers behind the project, as the management layers do. So if the team is operating without that management’s support, it’s right like driving the car with your eyes closed, you’re not sure where you’re going, you’re not sure where the problems are so it’s not really surprising that you get some.
Yegor: You know, again I totally agree, but while the previous podcasts I was recording, we were discussing the role of project manager in traditional agile projects and more traditional project, and it came up that in agile format we don’t have project managers, the entire team is supposed to be responsible for the result, the entire team is supposed to be self managing somehow. So there is no dedicated role of somebody who is taking responsibility for the overall result and here comes the question. So speaking about failures, you think it’s a good strategy, it’s a good approach to remove the product manager role and put the blame/responsibility the entire team, or we still need someone who will know that it is his or her responsibility?
Andy: I think the role of project manager in Agile initiatives is still an important one. It’s not the same as the product owner. It’s not the same as the scrum master and it’s not something that can be replaced just by having self organized, self empowered teams. I think that there is still a critical role for PM, in our job project, especially in agile projects are becoming more important to the business itself. When they’re just about delivering a piece of software internally with an IT, it’s less of an issue when Agile is a delivery approach that is being used for business transformation projects for the software to support those initiatives. There is an expectation that there’s going to be a degree of oversight, a degree of integration with other projects, a degree of tracking and accountability and reporting, that has to come from the PM, because the team doesn’t have the time or the inclination to do that, and they don’t have the skills or the background to do it as effectively either. So I think it’s still an important role. I think that a project manager can be the difference between success and failure on any project as long as they have the skills and the experience to do so. But at the same time, I don’t think you can take a traditional waterfall project manager and just drop them into an agile project without any training or experience and expect them to either succeed or be accepted by the team.
Yegor: But you know what I feel, that people don’t really like the word responsibility or the word blame or punishment or something like that. So they don’t they don’t want to see the negative side of the of our failures and instead they prefer to speak about, you know, about rewards and maybe about some support to each other, and things like that. So they are trying to… many people around like consultants mostly and Agile activists, they are trying to focus on like positive sides of our projects and our failures. Removing the negative element of that, do you think it’s the right way to look at failures from a positive perspective in terms of responsibility of people who caused that failures, or we still want to like an additional way like we have done 50 years ago, or we need to find the person who failed the whole thing and somehow, you know, do the retrospective with the focus on personal failures on particular people?
Andy: Yeah I mean I’m a great believer that people want to do their best. There are occasional situations where you have problems with sabotage, where somebody deliberately sets out to have a project fail, deliberately sets out to do something wrong. But those are very-very rare. Generally speaking I think people come to work with an expectation that they’ll have to work hard, but that they will do their best and go home. You know haven’t been respected for for doing a good job, but if there’s a failure that happens, we need to understand why that failure has occurred. We can’t sugarcoat it and pretend that there isn’t a problem that you know “Oh, everything’s great.” Never mind the fact that you know the project is sitting in the corner smoking and no good to anybody. You know it’s still a failure. We’ve still got to acknowledge that. But I don’t think it helps to say “The failure was the problem of little Johnny over there and let’s give him a round of applause for screwing up six months worth of everybody’s work, yeah, way to go, Johnny”. That doesn’t help anybody and it certainly doesn’t make you feel any better.” So we need to understand as an organization what is it that went wrong or more importantly, how do we stop it from happening again. But I don’t think that people being held personally accountable for failure is necessarily the right approach. There may be a situation where we have to say “Okay there is a problem. This was why the project failed.” It is specifically down to this individual who made a mistake who didn’t realise what they were doing or what it was. So they may need to be coached, they made to go through a training program and development program. They may be just in the wrong role and they may end up having to take on a different role in the organisation. But I don’t think that specifically [inaudible voice] the reason that something is going to help anybody and it’s not going to prevent the problem from happening again.
Yegor: Sounds right. Well let me give another example, let’s say we have a project in the organisation and that particular project failed because Johnny who was the project manager was not doing the re-estimates of the scope and of the budget like we discussed before and because we didn’t have those estimates in three months of work, the customer realised that the budget will be two times bigger than they expected and that’s why they cancelled the project but that was too late because they burned a lot of money. So it was a personal failure we’re going to say so of Johnny who didn’t do re-estimates for three months straight. But Johnny will say that “You know what, I working in this organisation and nobody told me that this is my job, this is my responsibility to do those estimates, say, every two weeks and the PMO, the office who is standing on top of me, who is supposed to teach me, train me and consult me on what is the process I should follow and how I should deal with re-estimates and with the customer and that’s why I didn’t do that.” So maybe we should blame you know to follow.
Andy: For sure. I mean I think we need to understand you know every time something goes wrong is what was the root cause not just the symptoms, but you know do the fishbone diagram, the Ishikawa diagram to actually get to the root cause of the problems and understand the systemic issue. Was it the case that that Johnny was told what to do or just didn’t do it? Was it the case that the PMO or whoever owns the project methodology didn’t put that in place? Was it a case that the reason the PMO didn’t put it in place was because their bosses or whoever that is said “Oh that’s not important, this is where we want to focus.” You know there’s probably a lot of blame to go around. I mean I’m a project management, professional background you know that’s been the focus of my career. So I have a tough time with a PM who says I didn’t do it because nobody told me I had to. If it’s part of project management and the PM should be saying “Hey I haven’t done any re-estimates here, you know, this is something that I would expect to do. Why are we not doing that and just challenge the PMO and say “I didn’t do it because nobody told me to.” At the same time I would expect the PMO to say “This is an important part of the way projects have to be done.” I would expect leadership to say it’s important that our estimates are current and accurate. Therefore please ensure that this happens”. So these are a lot of issues that potentially could have contributed to that problem occurring all of which have to be addressed as part of the solution. But you know taking the cattle prod out to Little Johnny is not going to help us.
Yegor: Yeah, makes sense. And again, quite an opinion, I keep reading in many places the software experts say that no matter what the process is, no matter how you organize the documentation, and the rules, and the formula of work, if the people are good people, if they are very motivated and talented, they will do the right thing. So we don’t need any process as well. We may need it but it’s not important, what’s important is to find the right people, the right Johnny who will by having a big heart will know how to manage the project, he will not forget to estimate or do whatever is needed. Do you feel it’s the right attitude?
Andy: I think the core of success of any project is definitely the right group of people being brought together to work on that project, you can’t create a team you can only create a group of people that group of people must then work together to evolve and become a team to actually sort of collaborate and want to succeed in order to support their colleagues and all the rest. So certainly having the right people individually and the right mix of people is critically important, that can overcome a lot of process failures. I wouldn’t go as far as to say the process itself or the documentation isn’t important. It depends on the situation. I completely agree with the Agile manifesto concept that now it is more important to deliver solutions than it is documentation. But there are projects where it is important to follow a rigorous approach where it’s important to have higher levels of documentation whether that’s for regulatory reasons, for audit purposes, you know whatever might be, but there’s no reason why you can’t do that within an agile project framework any more, than you can do it in a waterfall framework, but that’s not a replacement for the right team. It’s just a way for the right team to work on more structured initiatives.
Yegor: And have you seen in your practice teams that more often fail and teams which more often succeed in projects? And can you say that being a consultant when you join a team for consulting and you look at the team, can your say in just a few hours of conversation that team will most likely succeed, and that one will most likely fail?
Andy: Oh for sure. I mean a lot of it is down to attitude and mindset and just that team environment if you like; if you’ve got a group of people who are committed to working together, who want to help one another through it, who care about the success and wellbeing of their colleagues, then you stand a much better chance of succeeding, than if you’ve got colleagues where people don’t work very well, where everyone’s pointing the finger at somebody else. You can tell and I would say that in most cases that’s not something that happens at the start of a project. I think that obviously when you bring a team of people together, a group of people together it takes a while for them to actually evolve into a team. But when you first start getting to that point, everybody is committed to success when things go wrong, that’s when has the potential to undermine that team work. And it only takes one or two people sort of getting defensive or starting to blame other people on the team and that can break down and then you get that fragmentation and it becomes obvious that you can’t make wholesale changes in the team or the project itself is going to fail. But what I will say is that a lot of that is sometimes works often driven from outside the project itself. It’s not that the project team members start pointing fingers at one another, it’s that somebody in the management layer or somebody from outside of the project starts pointing fingers at the team, and instead of the team resisting that cohesively, they end up saying “Well don’t look at me, it wasn’t my fault it was his fault, or it was her fault or who it might be.” So a lot of that sort of catalyst comes from outside.
Yegor: So there is no way to solve the problem from the inside the team, we need to solve the problem with the environment around the team?
Andy: I think we need to… I mean it behooves project managers to create the kind of environment where people don’t support that, we don’t sort of tolerate that finger pointing approach, and PMs can certainly sort of try and nip problems in the budget and try to prevent them from getting to the project manager then it may well be that the idea of solving it completely is to make wholesale changes to the team structure.
Yegor: Have you seen those transitions or resolving of those problems of being successful, when the team now is in trouble, and then something happens and the management is know getting better, and then we resolve that, and the team starts working properly?
Andy: Yeah you certainly can recover. I mean depending on how bad it gets it can take a long time or it can take a lot of effort to get things to turn around. But there’s very few situations that cannot be recovered from. To some degree you just might find that there is one or two people that have to be swapped out, bringing some new blood, bringing some fresh ideas. Not necessarily because you know you have to take out the troublemakers, but it may be that just some people are so frustrated, so fed up, so disappointed with the experience they’ve had, that it’s not good for them or for the project, for them to continue work. They’re better off going to a different project or going back to work in a support or operational environment, and bring in new people to just sort of help build up the energy again.
Yegor: And when they hire you, so for example as a consultant for the team and you see the problem in the team and you realize that the actual problem is above the team, on the management layer. Do you go to the management layer and tell them that?
Andy: Oh, for sure, there’s no point in sugarcoating the issue. There’s no point in pretending that the real problem is somewhere else because all we’re doing is solving or treating the symptoms of this particular project, you’re not preventing the problem happening again. You have to help people to realize where the root cause of the issue is and it’s not in most cases because one of the management members is deliberately causing problems. It’s just that they don’t realize the impact they’re having on the team or the impact they’re having on the project, on work. So they need to understand “Hey this is what’s happening as a result of how you’re acting or the things you are doing and have better approach that that will be less disruptive for the team.”
Yegor: And do you think that client or the company or the person who is sponsoring the project has to know about problems or potential problems in the team, or is it better to keep the client some sort of you know in a dark and only bring the good news to the customer.
Andy: I think that there’s probably two answers to that depending on whether it’s an internal or external cast of a team. Certainly if we’re dealing with an external team then we should probably do our best to to insulate them from what’s going on internally. There’s probably a little bit more of an open door policy, but at the end of the day my personal belief is that unless an awareness of the challenges and problems helps the customer’s ability to have to support the resolution of it, then it’s just noise. They don’t need unnecessarily hear all good news, but they should only hear relevant news and you know problems in the team are probably not relevant to them at least early on.
Yegor: But it sounds like if we don’t inform the customer, then eventually the customer will know when the project fails. So maybe it’s better to keep the customer closer to the inner circles of the project and somehow you know get the customer on board, as close as possible so that the customer will be more prepared for potential failures and maybe can affect and resolve the situation somehow.
Andy: If the customer can contribute to the solution, absolutely they need to know what’s going on, completely, if I can’t contribute to the solution, and I would make a separation between the what and the why, I would happily tell them this is what is happening on the project, this is the situation we’re experiencing a few challenges, this is how we’re working to resolve them, you know etc, and give them a heads up if there’s a potential delay or potential loss of features or whatever it is. I wouldn’t necessarily tell them why it is that’s happening. They do need to know we’re going to be two months late. They don’t need to know we’re going to be two months late because there was a massive blow up between two managers and they couldn’t decide which approach needed to be taken.
Yegor: Interesting. Is a quite sensitive subject, you know, quite sensitive area where it’s always a question whether to inform the client then get the customer close to us and inform them about what’s going on, because the other thing you mentioned like estimating the project, it’s not only about estimating just numbers, it’s estimating the situation right. Because when we started developing we would just plan to make the project happen the way we wanted it to be in three months. The whole situation is different the whole environment is different, it’s a different story now and it’s better to inform everybody around it. Maybe, I’m just asking, is it better to inform everybody or is it better to keep them on the same on the same page where we started?
Andy: I think that in today’s world, whether we’re dealing with internal or external customers, the pace of change is so rapid that there’s a distinct possibility? So there has to be an awareness of that because no expectations needs move on and you know if you just deliver what was asked for three months, but it’s no use for that. But I think that that kind of conversation, that kind of awareness of what’s going on in the customer base, in the customer market has to be happening at an organizational level, rather than on a project level. We shouldn’t be looking just sort of at this project with this customer. We should be looking at all projects for all customers to have a better understanding of how the world is evolving. Certainly there are conversations at the project level that are driven from that way, you know, there is an awareness that a rival launched something with new features that no one had ever seen before. So “Hey, you know, let’s have a conversation with that customer about you know the next version of this, maybe you’re going to get that, that and that or whatever it might be” - it is the relationships between those conversations but I don’t think we should only be having them at the project level.
Yegor: And in general do you think we should fail fast or we should try not to fail for as long as possible? There are two approaches for that.
Andy: Sure. I think generally speaking fail fast are cheap, and there is exceptions to that depending on the type of project that we’re dealing with, but as a general rule I would much rather know I was going to fail as quickly as possible before I committed too much money to it or too much effort to it or too much energy to it and then move on to something else. The problem with that potentially is that it only works in an environment where you’ve got a leadership team that is prepared to pull the plug. I’ve seen a lot of pro”All right. That money’s gone.” They just thought they’d keep throwing more money at it and hope it would turn around.
Yegor: And maybe it’s related to the problem of politics, because in most cases in some cases, in most cases the software projects are not being run for the sake of deliverables, but mostly for the sake of just being the sources of salaries and expenses for the entire organization. So people need projects that will fail but keep going, keep running, because there are many-many people in the world, they all get salaries they’ll get paid. We have expenses. We live our lives while the projects are alive. So we don’t want them to stop we don’t want them to claim failures earlier. It’s better for us to keep them for as long as possible and in the end as we know we’re going to blame someone for failures because most projects fail.
Andy: Yeah, I mean there’s probably an element of that and I find it pretty sad if that’s the case. Sure we all have lives to live. We all have salaries that we need to be out to live those lives. But the reality is our employers the organizations we work for don’t exist to look out for our personal lives. They exist to support their investors or shareholders, or stakeholders, or whatever the structure of the organization is, and if you look at those organizations that the most basic level they do two things, they do operations the day to day staff, and then they do projects and the projects have a fixed budget available, a fixed level of investment available to them. And you have to generate the best possible return on that investment, because that’s what keeps the organization running. And if you’re allowing some of your management team or some of your supervisory levels to take a subset of that budget and invest it in a way that is not only not going to optimize the return on investment but potentially generate a never negative return on investment, just because we don’t want to cancel the project and potentially have to lay people off or you know leave people uncertain of their jobs. And that’s fundamentally a failure in the way the organization is being run.
Yegor: Yeah, that’s true. And maybe a personal question to you. So have you been personally involved in projects like failed, like seriously failed?
Andy: Oh for sure. Yeah I mean I’ve been involved in some fairly significant projects that have found in a very dramatic failure. I was with the department of a major insurance company that went from 150 people to 12 people in the space of about four weeks because they canceled a major initiative. You know, it’s part of what makes all of us, you know, the people we are.
Yegor: And how do you recover from that and maybe would you recommend something to our listeners, how do you recover from those major failures and move on and join the new project?
Andy: I think you have to recognize that it takes time. I mean it’s a form of grieving if you like, I mean I don’t mean to make you sound overly dramatic but it’s not something that you can just shut the door on and forget about it. It takes a while to recover from it and you need to give yourself that time and space and distance for it to happen. I think you also have to make sure that you don’t take it personally. Now everybody who has been working on projects for any length of time has experienced a number of failures. It’s not your fault. It’s one of those things that happens even if you made a mistake. It’s not your fault. It’s not something that you did deliberately. It’s just something that happened and you have to learn from it. You have to try and avoid making the same mistakes in the future, but you can’t sort of blame yourself because it does prevent it from moving on and to go back to the commitments you made a couple minutes ago. All of us are working to support our personal lives, right? We’re not working because it’s the best thing we can imagine to do with our time. We’re working because we need to earn money, to live, to be out to do the things that are important to us, with friends and family. And so that’s the focus that everybody should have is on protecting that and not allowing, you know, the past failure to prevent future success.
Yegor: Ok, it sounds reasonable to me. I think I am done with the questions. It was really interesting to know your opinions on that.
Andy: Perfect, thank you.
Yegor: I just hope you not to have any more failures in your professional life.
Andy: Well I hope so too, but I’m not sure that is going to happen, I think there will inevitably have a share.
Yegor: Ok. I think me too, that we will learn from them. That’s what I got from you today which was… yeah. Okay, thanks for joining us.
Andy: Thanks Yegor, I really appreciate it.
Yegor: Bye-bye.
Andy: Bye.
