Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Thursday, August 06, 2009

Why meetings are so disruptive

Paul Graham has a great article on his blog on why meetings feel so disruptive to many of us. He partitions the world into managers and makers. Managers live their working life in 1 hour increments, so slotting a sudden meeting in is no big deal. It is just an issue of where to go. Makers live their lives in at least half day increments so that a one hour meeting can render half a day completely useless. When the two worlds collide, the makers suffer.

As Product Managers and Business analysts we have to be both. We have to have a lot of meetings where we make decisions and try to figure out what the project is going to be. Then we have to have quiet time to create the specifications. It is really difficult to switch back and forth and he offers several strategies for dealing with the context switching.

Paul mentions that a very common strategy is for makers to just ignore meeting requests. I definitely have used this strategy many times, but it is a little rude and can obviously be a bit offensive. These days I tend to put all my meetings first thing in the morning or towards the end of the day. This lets me focus on productive work with a block straight through the day. The difficulty comes with people always wanting to go out to lunch. When my productive block is from 10am to 3pm, having lunch is actually quite disruptive.

How do you handle the maker vs. manager conflict?

Labels: , ,

Requirements Defined Newsletter Bookmark and Share

Wednesday, September 03, 2008

Creating Accurate Time Estimates

I recently joined a new project where I will be working as the person responsible for the developing and creating the requirements and documentation on a major development effort. As the person on the hook for a significant portion of work, I need to provide accurate time estimates for my portions of the project. I was concerned about providing accurate time estimates on a new project in a new environment. I am also very aware that deadlines are important and know that if I am unable to accurately estimate my deliveries, I will quickly lose credibility with the rest of the team. Underestimating my deadlines might also put other team members relying on my work at risk of missing their deadlines.

My concerns had me thinking that perhaps others might be in a similar situation. After a bit of research and analysis of my own process I compiled the following list of questions and suggestions to help when making time estimates.

  1. How accurate do your time estimates need to be?
    If an estimate needs to be very accurate, it is usually a good idea to take a longer period of time to consider and analyze the answer. It is not unreasonable to ask someone who is looking for a timeline for some “think time” in order to provide an accurate answer. However, when not immediately responding, it is a good idea to communicate a reasonable target for when you will have the estimates finished, even if it’s only 15 minutes of extra think time.

  2. How well do you fully understand the project/tasks that you are being asked to estimate?
    If a problem is complex, or if you do not completely understand all of the tasks you need to finish, it will be difficult to make accurate time estimates. Getting as much clarification as you can is necessary. Discussing the details of what you have been asked to accomplish with the person making the request might also provide them insight into the complexity of the request and your work process.

  3. How long has a task of this type taken to accomplish in the past?
    It is a good idea to maintain a personal log of tasks and an ongoing list of recorded time spent performing a task. I simply use an excel spreadsheet to record tasks I have finished on my projects and update it when I have a few moments at the end of the day or week. Having a realistic idea of the amount of time I spend on my tasks helps me to accurately predict future projects/tasks.

  4. Are there any assumptions, conditions or constraints which might affect your time estimate?
    It is impossible to predict in advance every detail of a project with certainty. It will be important to note your assumptions and constraints when you provide your time estimates to communicate your issues clearly. These could all be considered risks to the accuracy of your time estimate and should continue to be monitored as you begin the tasks/project.

  5. Do you need to add any wiggle room?
    You should consider adding contingency time if there is a lot of uncertainty about the tasks or many risks associated with your estimate. By increasing time to the estimate appropriately because a project is new and unfamiliar as a way to prevent underestimating your efforts.

  6. Are there any other elements to the project/tasks that should be included in your time estimate?
    One area I consistently forget when creating estimates is the amount of extra time I have to spend doing administrative tasks like organizing meetings, sending emails, or organizing documents. At times, these types of activities are not always predictable, but understanding how much of your work might be effected by other project duties is important. There is a small amount of extra administrative work in most tasks, and adding that into your work estimate will help your estimating efforts.

When I employ these methods they have lead me to more accurate time predictions that have also greatly reduced my anxiety over creating self imposed deadlines that are unrealistic. As I also have an intrinsic desire to please the person asking for my time, using some standard processes in producing my time estimates has lead me to win/win situations for both my project and myself.

Labels: , , , , ,

Requirements Defined Newsletter Bookmark and Share