در رادمان براي جلب مشتري استراتژي جالبي بکار مي بريم و آن اينست که کار ها را در زمان بسيار کوتاه تري نسبت به آنچيزي که مشتري توقع دارد پروژه را به اتمام مي رسانيم ، بدين تيب که براي يک پروژه مفروض به مشتري زمان معمول توليد سيستم را اعلام مي کنيم. مثلا براي يک پروژه کوچک يک ماه زمان در نظر مي گيريم که زمان منطقي است، اما پروژه را ظرف يک هفته تحويل مي دهيم! و مشتري را شگفت زده مي کنيم! چطور اينکار را انجام مي دهيم جزء اسرار است! هر چند در متن زير اين اسرار برملا مي شود!!

پيشتر در هنگام توسعه سيستمهاي نرم افزاري با استفاده از روشهاي ساختيافته، مديران پروژه ها براي تخمين زمان و هزينه توليد يک سيستم قبل از آغاز آن از روشهاي مختلفي استفاده مي کردند.
از مهمترين  روشهاي تخمين  در آن زمان استفاده از تجربيات گذشته در سيستمهاي مشابه و يا تخمين تعداد خطوط برنامه و يا تعداد عملکردهاي متفاوت سيستم مي باشد.
بدين معني که يک برنامه ساز زماني که مي خواهد در آغاز پروژه زمان و هزينه لازم را برآورد کند براي مثال در يک جستجو در تجربيات خود  يک نمونه نزديک براي سيستم جديد پيدا مي کند. براي مثال در فلان سيستم دو ماه کار توسط يک گروه 2 نفره صورت گرفته است (به عبارتي 4 نفر-ماه) و چون پروژه جديد هم شبيه اين تجربه مي باشد همين حدود زمان براي توسعه سيستم نياز است و يا چون مثلا يک کم از آن بزرگتر است يک مقدار اضافه تر. گاهي هم بر اساس تخمين تعداد خطوط عمل مي شد. براي مثال برنامه ساز محاسبه مي کرد براي ايجاد سيستم نگارش حدودا 10.000 خط برنامه لازم است پس حجم پروژه معلوم است و بر اساس اينکه يک برنامه نويس در روز چند خط برنامه توليد مي کند (انگار کار برنامه نويسي پارچه بافي است که با يک معيار کمي آن را اندازه گيري مي کنيم!) کل زمان بدست بيايد. به همين شکل براي عملکرد ها هم عمل مي شد. و با شمارش تعداد عملکرد (Function)  هاي اصلي و فرعي سيستم حدود سيستم تخمين زده مي شد.
با توسعه روشهاي مهندسي نرم افزار و مطرح شدن مفاهيم شيء گرايي (Object Oriented Concept)  در مهندسي نرم افزار بالطبع معيارها و متريک ها نيز متفاوت شد. در شيء گرايي با تکيه بر استفاده مجدد يا بازکارآيندگي (Reuseability)   از يکسو فرآيند توليد نرم افزار سريعتر گرديد و از سوي ديگر معيارهايي نظير تعداد خطوط کارائي نداشت. چون ديگر در اينجا با نمونه سازي از اشياء و يا با استفاده از وراثت و يا چند ريختي نه تنها مي توان از يک کد نوشته شده در قالب يک شيء مي توان بارها استفاده کرد بلکه با گسترش يک کد در کلاسهاي ارث گرفته شده حجم کد نويسي مجدد را کاهش داد.
به همين منظور در روشهاي شيء گرايي با استفاده از شمارش تعداد کلاس هاي کليدي (Key Class) و کليد هاي کمکي يا پشتيبان (Support Class)  يک تخمين نسبت به حجم کلي سيستم بدست مي آيد.
در روشهاي ديگر با شمارش سناريو هاي کاري و يا شمارش زيرسيستمهاي سيستم هدف و با بهره گيري از تجربيات گذشته به يک روش نيمه فرمال براي تخمين زماني و مالي پروژه استفاده مي نمايند. اين روشها تخمين بهتري براي زمان و هزينه مالي پروژه به دست مي دهند.
نکته حائز اهميت اينکه هر چند اين روشها تخمين خوبي براي روشهاي شيء گرا هستند اما با مطرح شدن روشهاي جديد مهندسي نرم افزار از جمله روش توسعه نرم افزار مبتني بر مؤلفه ها (CBSD: Component Based Software Development) بايستي در اين معيار ها اصلاحاتي به وجود بيايد و تغييرات عمده اي صورت گيرد.
با استفاده از مؤلفه ها (Components) و چارچوب هاي (Frames)  مناسب براي يک پروژه مي توان زمان توليد نرم افزار را به طور چشمگيري کاهش داد. در نتيجه در تخمين زدن مي توان با توجه به مولفه ها و چارچوب هاي موجود در کتابخانه توليدي عمل کرد. هر چقدر اجزاء سيستم جديد با استفاده از ابزارهاي موجود  بيشتر قابل توسعه باشند مي توان پروژه را سريعتر توسعه داد.

اسرار هويدا شد! مکانيزم کار اين است که ما در رادمان با توجه به زمان و نياز بازار در زمانهاي بين پروژه ها مولفه ها و چارچوب هاي عمومي توليد مي کنيم و يا در زمان هر پروژه ابزارها را به قدري عمومي مي سازيم که بتوانيم از آنها در پروژه هاي بعدي  استفاده کنيم. حال در يک پروژه جديد زمانبندي اعلامي به مشتري زمان را با استفاده از روشهاي معمول تخمين زده و اعلام مي کنيم. مشتري نيز معمولا با همين روش محاسبه زمان و هزينه را انجام داده و در مطابقت هزينه ها، زمان و هزينه اعلام شده ما منطقي جلوه مي کند. اما ما با توجه به توانايي هاي فني و ابزارهاي موجود، نرم افزار را سريعتر توسعه مي دهيم که باعث کاهش فوق العاده زمان براي ما مي گردد که از جانب مشتري هم مقبول واقع مي شود چون زودتر از آنچه تصور مي کرده به نياز خود رسيده است.

همين!