Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: success

  • Definition of Done

    Shim Marom’s post on (low) value of industry reports launched an interesting discussion in comment section, which I took part in by the way. The point we reached was how we define whether the project is completed or not.

    And here we come to the definition of done, term which I learned from Glen Alleman.

    On Time, On Budget, On Scope

    A definition which you will hear most often is project delivery on time, on budget and on scope. And there comes a problem. If we overrun a budget for ten bucks are we still on budget or not? What about thousand? Or hundred thousand? Depends on project, right? So what about 0,1% budget overrun? 1%? 5%? Where is the border between success and failure?

    Note: I haven’t even started with time or scope.

    While this definition sounds nice it hardly responds to typical complex project environments.

    The Story of Changing Goal

    I love the Apollo 13 story. Not only because it is a great story about heroes, but also because it is a great story to learn about project management. If I asked you what was the original goal of Apollo 13 mission probably no one would answer correctly. But well, they definitely hit the space for something more to become a base for a Hollywood movie or to coin one of the famous quotes (one of famous misquotations actually). The thing we remember is that Apollo 13 mission’s goal became saving astronauts’ lives. And we all consider it a huge success.

    Were original goals accomplished? No. Probably neither of them. The money was spent however. Probably more than planned because of unexpected problems. But over the course the goal has changed.

    Recently I’ve read similar story about Sir Ernest Shackleton’s Antarctic adventure. It is 18-month long story about fighting for people’s lives. And again initial goal, which was crossing Antarctic continent, was rendered invalid just after several days and the main problem became coming back home in one piece. Thanks to his commitment and determination Shackleton was successful in rescuing every single man from his expedition. Considering conditions a stunning success.

    Was Shackleton able to pass the Antarctic? No. Failure then?

    Maybe You Tell Us About Real Projects…

    You may say that those stories aren’t about typical IT projects which we deal with everyday. Yes, these are extreme examples but the same pattern we see very frequently, but in a bit different scale. Hey, that’s what embracing change is all about. We try to adjust the course of our projects to make them better respond to clients’ needs.

    After all I don’t believe all projects you took part in were specified perfectly at the beginning and carried through relentlessly to the end according to unchanged plan. My wild guess is only few of you had a chance to work on at least one project which looked a bit like that (and yes, Glen is probably among those few).

    Clients often deliver some wishful thinking as requirements, and then vendors go through them only roughly and come up with a generic document which describes fuzzily what should be done. No surprise the real goal appears to be changing over time as everybody realizes all the assumptions and gaps in initial plan.

    Definition of Done Is Changing

    OK, so goals are changing over time. So is definition of done. We usually do a crappy job defining done. But then we’re even worse in adjusting the definition along the way. We change expected costs and schedule. We change scope. Do we change our definition of done as well?

    I mean unconsciously we do, that’s for sure. After all we’re able to follow our gut feeling and tell this project was a success and that was a failure. We know that major schedule slip will be quickly forgotten if delivered software exceeds expectations. We know that being on time on budget and on scope isn’t a reason to boast when the client doesn’t use the system at all for some reasons.

    So yes, we should know what done means in each and every project. And no, we won’t have a single, universal definition which we can use against all our ventures. It is a very individual thing.

    That’s by the way the reason why the industry reports on state of projects will be criticized over and over again. There just aren’t universal measures which would be widely acclaimed.

    http://main.wgbh.org/imax/shackleton/about-one.html

  • We Achieved This but I Screwed That

    I was a part of an interesting dialogue:

    – Pawel, tell me about your last success.

    – The last launch went flawlessly which means the way we chose to organize the project proved itself as pretty damn good.

    – OK, and what about your last failure?

    – I feel I can’t get through with ideas on improving the organization.

    Now the good part isn’t really me answering these two simple questions, even though I think it is a great idea to ask your people from time to time about their successes and failures. The good part is something I caught myself at after a while.

    It was our success and my failure.

    And the better part – it is not just about words. It is about the way of thinking. I might have said I had chosen our methodology and probably no one would have noticed. But what you say isn’t as important as what you believe.

    If you just switch words to the right ones you will achieve something important – recognition in front of execs is quite a token of motivation after all. But if you really believe in what you say you’ll achieve much more. You’ll always act as the success was an effect of collective effort, not only when you are in front of senior management. Besides, it was an effect of collective effort, wasn’t it?

    So tell me, what your last success was. And how about your last failure?

  • What Makes You a Great Professional

    I have a small task for you. Think about a few people you know and you consider them as great professionals. Don’t limit yourself to any single role – choose anyone who is great no matter if he’s a manager or a developer or a dustman. Got them? Fine.

    Now a second step – try to name one attribute which is common for each of them. Something which isn’t, by definition, related to specific role or specific job. Depending on variety of people you’ve chosen this can be pretty hard, but try for a while – there must be something. Got it? Great.

    What you’re trying to achieve here is finding a kind of success factor. Something which would differentiate good from great, but at the same time probably not something which would guarantee a mediocre person to become a star. That just isn’t so easy.

    What have you chosen?

    My choice is: urge to learn.

    This is something which constantly pushes us ahead, out of our comfort zone. Even if we err along the way the overall result is positive. As the time passes we get better and better since, well, learning is all about getting better. We grow to the point when someone thinks about us when asked the question from the beginning of this post. We’re not likely to get there though, so chances are good there’s still plenty of room for self-improvement.

    Learning can be a part of your job – in this case you should be pretty happy with it. You can also do a job which doesn’t develop you much at the moment, but it is a lame excuse to stop learning. There are tons of great places to get better at whatever you do or learn something completely new. If you stick with whatever you already know you’re heading to side-track.

    I have great news for you: if you reading this, odds are you have this urge. If you take time to look for content discussing personal development in context of your domain (I don’t expect many dustmen here really) you’re well ahead of the rest of the pack. You’re here to learn something new. Otherwise why would you spend your time reading this?

    If you’ve chosen something else than urge to learn tell me what is your choice and why.