Sunday, March 7, 2010

Keep records straight. Question Everything

My wonderful colleague has a nice start to her blogging venture. I wished I could match a similar post. Alas, I give up. Can't patiently recollect the learning. Will challenge her with an equal post hopefully in future.

It took me 11 years, numerous projects in different capacities to arrive at the following thumb rules.

  1. Records are the way of business. Records are the primate model for communication, knowledge sharing and passing along to generations. Keeping records of talks, meetings, deliveries, issues, risks, numbers, reports is the way to do a business. Period.

What is remembered, referenced, linked, analyzed are the records, not the files and deliveries made in projects. So make sure to have:

    1. Emails as primary document repository. I know, it is not a good practice. But given the fact that there is lot of exchange through emails, it is better to preserve them and use them as "record reference repository". With Xobni, it gives more power to easy search the records.
    2. Put down all conversations in writing. It is still the best to track a conversation and find the missing links or the tangent views that are persisting and needs immediate traction to have a unified strength.
    3. Record of numbers is mandatory. Absence is a project crime. Make sure inflows-outflows, efforts scoped-consumed, schedule planned-committed, Cashflows-Profit Margins are all recorded and reported on time. Any attention flaws results in a bad project, however good the service/output and satisfaction levels are with customer.

2. Assume nothing. Question Everything. Ask hard for value.
IQ-lore says that asking "Why" 5 times, leads to clarity on a topic. I have found it hard to practice, since at times I fear looking stupid. Rather, I find it easier to ask these 5 questions and wait for responses to resolve a problem/escalation/hot issue that requires attention.

  1. "That is an assumption. Is there a record to prove the point? Are we having the same context in this instance as well?"
  2. "Is it a fact? Can I see the actual data? I take it as a perception and it could be perception error, in the absence of data."
  3. Why have we gone down the path? Is it still relevant ? Why do still need to persist with the same?
  4. Is there a different lens we can look at the whole problem?
  5. What you do is fine, but what would be the value you want customer to "take away"?How do you think you are adding value ? How do you intend to communicate that what you are providing is of value to customer ?


Reblog this post [with Zemanta]

Top Agile Blogs