Tuesday, June 10, 2008
Enterprise Architecture and Responsible Estimating
Robert McIlree has a wonderful post entitled responsible estimating that continues a conversation by Timothy Johnson. I figured I would also provide additional insight that the others did not cover...
The pattern of irresponsibility is a trap that I frequently fall into. The problem as I see it is comprised of two elements. First, I am usually guilty of not asking questions around where development will occur. One must first acknowledge that development nowadays is no longer always an inhouse activity. It is one thing to make an estimate for a project with someone I have worked with for the last ten years and know all of their idiosyncracies, it is another to perform proper estimation for some guy in India who has less ability, less real-world experience and most importantly, someone I have never met.
Good estimation in the modern world requires developers to be somewhat plug compatible. While this concept is disturbing to many, reality says that the demand for this type of mantra will grow and be demanded more frequently. Minimally, the estimate in this model also tends to skew because if you acknowledge that all developers aren't equal, then you have to account for orientation, bringing someone up to speed on your culture, showing them where the bathroom is and so on.
My second observation is that in order to be responsible in estimating, you have to be equally responsible in capturing good business requirements. Simply put, most business customers have a good idea of what they desire, but don't have great abilities to articulate them. This simple truth requires IT to become more than just order takers and to in many ways read the mind in an intuitive aligned way.
Many architects, including myself understand the business terminology and can have great conversations with them. Where we fail is in our consistency of understanding all of the facets of our business. For example, I understand the sales side of our enterprise a lot better than I do the claims side of the business. Of course this deficiency can be rectified by simply talking to my peers, but I am sometimes guilty of falling into the EA Powerpoint trap where I talk at people instead of talking to them.
So, in summary to make estimation better, focus on making business requirements gathering better. Change your culture to allow for the right levels of transparency in terms of abilities of individuals and most importantly understand who is actually doing the work...
| | View blog reactionsThe pattern of irresponsibility is a trap that I frequently fall into. The problem as I see it is comprised of two elements. First, I am usually guilty of not asking questions around where development will occur. One must first acknowledge that development nowadays is no longer always an inhouse activity. It is one thing to make an estimate for a project with someone I have worked with for the last ten years and know all of their idiosyncracies, it is another to perform proper estimation for some guy in India who has less ability, less real-world experience and most importantly, someone I have never met.
Good estimation in the modern world requires developers to be somewhat plug compatible. While this concept is disturbing to many, reality says that the demand for this type of mantra will grow and be demanded more frequently. Minimally, the estimate in this model also tends to skew because if you acknowledge that all developers aren't equal, then you have to account for orientation, bringing someone up to speed on your culture, showing them where the bathroom is and so on.
My second observation is that in order to be responsible in estimating, you have to be equally responsible in capturing good business requirements. Simply put, most business customers have a good idea of what they desire, but don't have great abilities to articulate them. This simple truth requires IT to become more than just order takers and to in many ways read the mind in an intuitive aligned way.
Many architects, including myself understand the business terminology and can have great conversations with them. Where we fail is in our consistency of understanding all of the facets of our business. For example, I understand the sales side of our enterprise a lot better than I do the claims side of the business. Of course this deficiency can be rectified by simply talking to my peers, but I am sometimes guilty of falling into the EA Powerpoint trap where I talk at people instead of talking to them.
So, in summary to make estimation better, focus on making business requirements gathering better. Change your culture to allow for the right levels of transparency in terms of abilities of individuals and most importantly understand who is actually doing the work...
