When I was a kid, I watched an episode of The Odd Couple, the quirky sitcom about two divorced men living together in NYC. Felix is the neurotic neat-freak; Oscar is the lackadaisical slob. ("Can two divorced men share an apartment without driving each other crazy?”) There was an episode in which Felix was arrested for ticket scalping, when in fact, he was trying to give away the tickets. Felix decided to represent himself in court. He challenged the police officer who had arrested him and during the interrogation on the stand, the officer said something to the effect that he “assumed” that Felix was trying to sell the ticket. Felix proceeded to walk over to a flip chart and right the word “ASSUME” on the board. As he did so, he replied, to the officer, “Do you know what happens when you assume? You make an ass out of you and me.” Circling “Ass”, “U”, and “Me” as he spoke. Classic 1970s American TV moment!
How many times have you started to answer a question with, “Well, I assume…?” How many times have your assumptions been wrong? And when your assumptions have been wrong, what have been the implications been?
A lot is left unsaid, and it is those unsaid words, requirements, needs, etc. that are most likely to cause problems on your project. I try to remind myself, and my team, that if I am assuming, then I don’t know. If I don’t know...I need to ask.
Consulting and Consulting managers often times find themselves having to make assumptions in order to proceed with a scope of work or estimate. In many cases, the best you can do is provide the estimate based on a set of assumptions, and that is OK, so long as those assumptions are clearly documented and agreed upon with the customer. Clarity will come during the early stages of the engagement (requirements gathering), and if any assumptions are proven to be untrue at any point in the project, then the project manager will issue a change request (CR) to address the new assumptions, changes in scope, and, potentially, impact on cost and timelines. (The CR is any project manager's best friend, at least between normal business hours.) If you don’t have the assumptions documented and shared across teams, the “agreement” is left to interpretation, and scope creep, missed expectations, and customer dis-satisfaction are sure to ensue.
So what do you do when you realize that you are assuming and don’t know? Simple...you ask. It is important that you don’t delay. Challenging situations need to be addressed early and often, and it is best to not wait. The longer you delay, the harder it is to address. If you realize you are assuming an important detail (and those that may not seem so important right now) or don’t know for sure what is need, and you don’t tell your customer straight away, they may think that you are well on your way to addressing the pain, when in fact, you are not. When you come back to them days or weeks later for clarity, they will quickly realize (or assume) the lack of progress and get frustrated. Now you have two problems: You don’t have all the information you need to make progress, and your customer has lost some amount of trust that you will do what you say you are going to do.
Don’t assume, don’t delay, get the information you need...Now. You should have plenty of opportunity to do so if you are running your project correctly. All project details should be captured in a requirements document, including agreed upon assumptions, you should have a periodic (weekly) status report that documents progress, action items and dependencies, and issues and challenges (great place to capture a gap in your knowledge or apparent difference of understanding), as well as periodic (weekly) status meetings during which such details can be brought to the attention of all.
You will find some will be frustrated that “this is coming up now,” but the amount of frustration will be significantly less than the frustration that comes with a project missing a deadline, a budget, or the intended need.
No comments:
Post a Comment