Tail wagging the dog



  • It's been kind of quiet in here lately, so here is a fun little snippet I had yesterday.  If you guys remember, I'm learning how to be a project manager.  The boss wants me to do the PM work for a new and fairly complex enhancement project.  He describes it to me - modifcations to our software in addition to working with two other software vendors.  I guess he wants to guide me in what tasks to perform first, because he tells me:

    Manager:   Write up the quote first and then I'll help you with the scope of work in a few weeks.

    Me:   ....  WTF?



  • DM: Roll 5 D10 for a save vs. quote

     



  •  It's simple.  For any part of the project where you aren't sure about the scope or work involved, just assume it will take 1 developer 10 minutes to complete.  Problem solved, and the executives will love it!



  • Manager: Write up the quote first and then I'll help you with the scope of work in a few weeks.

    Me: .... WTF?

    Sounds like all the Project Managers here...

    The next step is "Work out what date it needs to be finished by, and then tell the developers to estimate their time so that they meet that date".



  • It's funny because it's true



  • @jetcitywoman said:

    Write up the quote first and then I'll help you with the scope of work in a few weeks.

    I'm a PM. Let me help a little.  

    The quote is a much higher-altitude view than the SOW. You know that you have to make some modifications to your software, and you have some idea what those modifications are. You know you have to work with two other software versions, and you probably know what they are.

    From this, even though you don't know exactly what your developers will be doing, you can get some idea how long it will take and what resources you will need. You will make some assumptions in this process; when a developer says he can build a web service that handles 2500 requests per second in a month, but anything over that will take three months, you will (probably) estimate one month and make a note of the limitation. Your note will say something like:

    "Dave B can do WS for <2500 RPS in 1 mth, need 3 mths for more"

    When you do your SOW, you will directly specify that your quote is based on a peak load of under 2500 RPS. It will say something like:

    "[feature] web service will handle a peak load of two thousand five hundred requests per second at the server without noticeable degradation in service level when properly configured. Initial configuration will be provided per customer specifications."

    The difference is that your SOW is frequently a legally binding contract. Once you agree that you'll provide this level of performance, you have to provide it. When the project is finished, if your customer comes back and says "we're only averaging 2,000 requests a second but heavy traffic bogs everything down", you can point to the words "peak load" and ask whether his heavy traffic is over 2500 RPS. If it isn't, you can point to "properly configured" and get the developer to identify any abnormalities or problems with the configuration. If the customer says that's what you gave him, you go to your source control system and pull out the delivered configuration. If the customer really hasn't changed that configuration, you point to "customer specifications" and have the developer identify any special requests from the customer that differed from his recommendations. If the customer denies making these requests, you go to your project documentation and pull out the written change request that maps directly to this difference. If you don't have one, you smile and apologise and tell your developer to fix it.

    On a more basic level, when you submit a final invoice that includes three months for a 5,000 RPS web service, and the customer points to your initial (lower) quote - you pull out the written scope change that authorised raising the peak RPS of that web service.

    A quote is just a quote. The SOW is what matters. When you write out your quote, it's just a proposal, and nobody is bound by it. The weeks from now to the SOW are for you to gather your data, formulate your quote, and demonstrate that you understand the high-altitude view of the project. Expanding that into a legally binding document under which your company will provide service, however, is a whole different ball game.

    This doesn't make it any less of a WTF, though. It's pretty much the exact opposite of how engineers manage things. ;)



  • @CDarklock said:

    @jetcitywoman said:

    Write up the quote first and then I'll help you with the scope of work in a few weeks.

    I'm a PM. Let me help a little.  

    *snip*

     

     You, sir, have blown my mind.



  • @CDarklock said:

    I'm a PM. Let me help a little.  [snip]

    Indeed... sad but true.  Frequently, a customer wants a ballpark quote before spending time on detailed scoping, just to see if it's within their budget, so that if it isn't, they don't waste time with the detailed scoping.  Which makes some sense, from that perspective.

    Just hope you're good at baseball if you're the one giving out the ballpark quote!



  • Okay, let me clarify some more.  We have what we call a "budgetary" quote, which is what everybody else calls a ballpark.  No sweat, I understand that perfectly.  This was NOT a request for a ballpark estimate.

    And there are many components of the request that are unclear.  For example, the customer has asked us to include some data download into one of the third party vendor's software.  But we'll be clarifying WHAT data to download and how to actually do the downloads (i.e. ftp versus sending over open socket, how often to send the data, what triggers sending it, etc.) at a later date.  We know who the other vendors are, but don't have any specifications for their software or what they need on their end from us. 

    So...  since this is a firm fixed price quote we'll do what we always do....  SWAG the hours and risk factors and come up with a price that hopefully isn't so high it gives our customer a heart attack, but high enough that we're covered if the project drags on for eighty years.  What do you mean it's not realistic?

    Oh, and the other thing that may be specific to us...  we don't bill for our time after the fact.  We bill for what we quoted and not a penny more. 

    It's actually an interesting challenge for me.  I'm studying PM best practices to try to get my PMP certification, but actually  ... well, let's just say I'm being taught at work how to not use best practices.  If I'm sharp enough to absorb both but not adopt a bunch of bad habits for future employers who might actually be interested in best practices, I'll truly be a rock star.



  • @jetcitywoman said:

    I'm studying PM best practices to try to get my PMP certification, but actually  ... well, let's just say I'm being taught at work how to not use best practices.

    Sadly, this is the reality of PM work. There's always this balancing act, where on the one hand you have the best practices in the PMBOK, and on the other you have what you are expected to do. Somewhere in the middle, you find something which is both better than those expectations - the expectations of non-PMs, which are very much like the expectations of non-engineers you encounter in technical work - and still within the realm of what the stakeholders will agree to do.

    Sometimes people get jaded and stop trying to balance. They just sigh and do what they're told and write it all down so they can say "this is what I was told to do". These are not "real" PMs, IMO. They just have a title. A "true" PM is always trying to drive quality in the process, to demonstrate that if we take these steps we will get better results. Over time, those results are demonstrated repeatedly, and the PM is able to drive more quality and better practices. You can get very discouraged very quickly in PM work if you're not ready to fight the world in order to change it.

    The upside is, as a PM, you have a very real ability to change the world for your company and its clients. And that's seriously awesome. It sounds like you'll be a good addition to the field. :)



  • @jetcitywoman said:

    clarifying WHAT [...] at a later date.

    Oh, and the other thing that may be specific to us...  we don't bill for our time after the fact.  We bill for what we quoted and not a penny more. 

    In that case, explicitly exclude the unclear parts from your quote. I once agreed to lead a project where many parts where "to be discussed" when the budget was already fixed - I won't do it again, ever.


Log in to reply