What's Your Approach?

  • Japie Botma - Tuesday, August 8, 2017 12:58 AM

    Why not CUD without lying?  I stood up many a time saying I don't pretend to understand everything right now, but anything is possible and it sounds like an x day project.  Yes, you do put yourself under a lot of pressure and a few times I had to go back and change the deadline or increase the resources, but that did not happen a lot and it kept management happy. ūüôā

    I'm sure it varies with the group, but I've had issues where you say you don't know enough details, need to investigate a few things, caveat left and right, and give an estimate based on partial information. What the other person hears is "x days" ignoring any context. You then get into the details and additional information and despite evenings, weekends, and pulling out all the usual stops "x days" is not possible. Then you come back to explain your findings and the additional time required to be told "you said x days".

    So I get your point, but it has created problems for me in the past.

  • Nitin, I don't think that CUD is necessarily lying. To me, lying is someone speaking a falsehood they know to be false. When someone commits to something  before they understand it, I see it as they honestly thinking they can deliver, even if they don't ultimately deliver. And like you said, I have a strong suspicion that people who, like Richard Branson, commit first before they understand what they're committing to, do tend to get more in life and career.

    Having said that, I am much more the understand, commit and deliver type of person. Slow but steady. Be reliable. That's a recipe for a consistency, but also not for going beyond your comfort zone. For always doing what you've done before. 

    On the other hand, I see a danger in the type of person who takes the CUD approach, but doesn't deliver consistently high. If someone were a CUD type of person, delivering 75% of the time, I personally wouldn't want to go to that person for a big, new project of there's a 25% chance that he/she won't deliver. 

    I suspect that there's something we haven't identified. That the Richard Branson's of the world have another quality you haven't mentioned, perhaps because you don't know what it is. This other quality makes them deliver significantly more often than the average person would who takes on a challenge before they understand what's involved. I don't know what that quality is, but I sure would like to know.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • The crux of this equation is the Understanding part and how much risk all parties involved are willing to take. Branson's company is quite large today, and a lot of what he does is experimental, so he can afford to spin up projects with fresh talent. However, the math is different when the project involves creating or changing a mission critical application.

    On the flip side, you can't even judge how "amazing" the "opportunity" is for you personally unless you have at least some understanding of it. You may not even be doing yourself a favor by getting involved in it. Any of us here who have worked with Tech Recruiters or startup companies in the past know what I'm talking about. Have you ever sunk months or even years into an endeavor only to feel at the end, not a real sense of accomplishment, but rather felt that your time would have been better invested elsewhere?

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • While I agree with the previous assessment that an amazing opportunity and a project commitment are different, my comment is more to the point of the author. If you believe that all the options are listed, you should read the book "Sources of Power, How people Make Decisions" by Gary Klein.

    One other thing is that I would not agree that managers are analyst by nature. While some are, my experience is that they are no more inclined to analysis than the general population. Though most have likely been presented with faulty ideas on decision making.

  • In a large heterogeneous environment, it's unlikely that a project manager will understand all of the nuances of the mainframe, UNIX, and Windows platforms. However, he/she should make an effort to fill in the gaps before making a commitment. Worst case that I've experienced was when the Microsoft Project default duration of one day got left in for a Microsoft Exchange to Lotus Notes application email interface conversion while integrating an acquired subsidiary.

  • Early in my career I followed Mr. Branson's advice without ever having heard that quote and it worked well for me. I have an amazing wife that had more faith in me and my abilities than I did and she encouraged me to apply for jobs that I was barely qualified for. Thanks to her encouragement I have been blessed with some excellent jobs and a wonderful career so far. I have had the opportunity to learn and grow very quickly where if I had only stayed in my comfort zone I wouldn't enjoy the success I have today.

    I think for personal and career growth it can work well if you are prepared and motivated to learn. For a company, industry, or project team, I think committing before understanding can lead to setting yourself up for failure.

  • CUD is committing to unknowns. There's no way to set a completion date without understanding the scope of the project. I was assigned to one project where the "project manager" wanted a clean slate development to replace a system that wouldn't be supported by the vendor; the vendor provided an "end support" date.
    The clean slate program would be operational in six months. I said the clean slate development is impossible to deliver in six months. The "project manager" was furious demanding weekend work, no holidays, and no vacations. But she was the one that waited until the last minute to request IT resources. There's no way a replacement system could be developed and tested in six months; not even using the "Nine Pregnant Women Project Management Model" (Frederick Brooks, The Mythical Man Month).
    In the end, it was my "Plan C: Moving Van" that went into production. We just moved the hosting of the application from one state agency to another.
    We finally pulled the plug on that system last year after using it for three years.

  • Several times I recall that being the CUD type paid off big-time:

    1968  Monday:  visited a friend at his work, saw a computer for the first time in my life.  He had me take an apptitude test while I was there.

    Wednesday:  At home in the evening, phone call from their HR department, offered me a programming job with a 30% salary increase to start learning two languages.

    Thursday:  gave two-week notice at my old job.  Learned Cobol, and some long-forgotten report generator.

    Circa 1971:  Interviewing at a bank, was asked if I knew Autocoder.  My response was: 'No, but if you show me a couple programs I'll pick it up pretty quick.  Learned 360 Assembler on the job also.

    1974:   Started a new job that required learning interactive RPG II and highly structured Cobol to create a new IT department for a company just planning to start using computers.  Later implemented compary-wide systems using Burroughs-Unisys DMS II database systems for order-entry, inventory, billing, and A/R.

    Circa 1987:  Interviewed for a new position, was asked if I knew Fortran.  My response was:  'No, but I will by the time I start to work for you.'  Got Microsoft Fortran compiler and was well on the way three weeks later when I started the new job.   Also learned the Ingres database system while there.

    Circa 1999:  Took my last position as a DBA/SQL Developer using SQL Server on a project developing a world-wide network of dealer servers using replication processes for 24/7/365 processing.

    2010/04/30:  Committed to full-time retirement!

     

     

     

    Rick

    One of the best days of my IT career was the day I told my boss if the problem was so simple he should go fix it himself.

  • Rod at work wrote:

    I don't know what that quality is, but I sure would like to know.

    Rod, it sounds like you have it already!

     

    Rick

    One of the best days of my IT career was the day I told my boss if the problem was so simple he should go fix it himself.

  • bsclyde wrote:

    Early in my career I followed Mr. Branson's advice without ever having heard that quote and it worked well for me. I have an amazing wife that had more faith in me and my abilities than I did and she encouraged me to apply for jobs that I was barely qualified for. Thanks to her encouragement I have been blessed with some excellent jobs and a wonderful career so far. I have had the opportunity to learn and grow very quickly where if I had only stayed in my comfort zone I wouldn't enjoy the success I have today.

    I think for personal and career growth it can work well if you are prepared and motivated to learn. For a company, industry, or project team, I think committing before understanding can lead to setting yourself up for failure.

    Me too. I became a data architect because at some point, someone said, "Hey Glen, can you fix this? You seem smart." This was the former CEO asking me to fix the decaying data warehouse some programmers made for him. I have worked with databases, but not like this. But, I knew I could commit and figure it out later, which I did. 9 years later, here I am in a new career thanks to that decision.

    Richard's comments are really not be used for building a new airplane that could potentially lead to death. He is talking about jumping into an opportunity, not you gambling your companies 5 million dollar project. Essentially, what we should all use in life. For example, instead of waiting to get married because it's not the right moment, jump in, marry the girl (or guy). If you think about it enough, you will always find a reason NOT to commit to something. This includes a new opportunity if you're afraid to jump in (the water). Just jump already!

    • This reply was modified 1 month ago by  glenswan.
  • The idea that you can accurately predict an event without seeing all the moving pieces implies there is an unknow. If you do this repeatedly then all you can predict is you cannot predict. Even when right there is % of good fortune involved and not so much skill. Estimating is just that. Any good manager will know estimates are prone to error. I would rather drive a car that was refined with honest effor as opposed to one where someone overpromised and under delivered. In the end its an easy question to answer if you keep the perspective of the customer in mind. If you are still hesitant, read about Toyota TQM approach and you will see something missing, an emphasis on time.

    ----------------------------------------------------

  • My mentor said it like this, "Learn to get smart quick if you don't know anything about it." ¬†With 40+ years as project implementer I usually will say¬† Yes, it can be done, but given the risks and unknowns the timeline will be between¬† weeks, or months.

    • This reply was modified 3 weeks, 1 day ago by  Muller Anna.

Viewing 12 posts - 16 through 27 (of 27 total)

You must be logged in to reply to this topic. Login to reply