Estimations NOT based on Analysis

Today I will talk about how nowadays project managers estimate workload and create deadlines.

This Monday I got seven new requirements that I must implement in the system till Friday. Five days for everything – analysis, design, build and test. Generally it’s fine, I’m genius and professional I can do anything, but the problem here is that I haven’t even seen requirements (I’m not even talking about description), it just came right from sky, e-mail of type ‘!’  ‘seven new requirements ASAP deadline friday’ (yes, without punctuation and all lower case (I know, those things are told, like in, third grade or what!?, but this guy has finished ‘The Master of Business Administration’ (MBA)).

So, what I must do? Open the e-mail, read the requirements, analyze them, estimate… (wait WHAT? We already have deadline!!).

What I did? I went to my manager (the one who sent this e-mail) and asked, can I see data on what he based his analysis from whom he came up with this estimate, and can I see the analysis itself, as that could make my job easier. He looked at me a in a way, if I was talking Chinese to him. I don’t have any analysis, he answered. In that moment I couldn’t understand, am I stupid or… as this guy have MBA from a fancy university in United States of America while I just have diploma from post-Soviet state high school.

Okay, let’s get to the deal. I’m fourth year university drop out (yep, one of those guys), but with more than fifteen years of experience in software development. I started to learn programming (and everything about that) when I was twelve years old, back in dinosaur age, when people were afraid (and that was done by specialists) of upgrading their computers from Windows 95 to 98.

So, now you are probably asking me, okay, then what’s the correct way of estimating? Just change one word of today’s posts name. Estimation IS based on Analysis.

Simple as that.

Workflow:

1. Client says he wants new button named X on screen Y that does Z when it’s clicked.
• That’s a requirement.
2. Analysts read’s/hears requirement and does quick estimation based on his experience. This estimate always should be expanded two times (that’s also is based on experience). And this estimate should only have time needed for deeper analysis, as real estimate will be brought up only after full analysis.
• In this point, again based on experience, analyst tries to understand if client needs this thing, or is he just “thinking”, he needs. If client’s say’s he needs, doesn’t always mean he needs that, that’s the analysts job, to bring added value to client, and if this button isn’t bringing any, then there is no reason to build one (this topic is complete story on its own, that I will bring to the plate also, but some other time).
3. Management takes this estimate in to considerations and decides, will we continue or discontinue this (I like this word play here).
4. If decision is positive, analyst can start analysis. First, he tries to understand what this new button will do (functionality Z) and how that can be implemented with current functionality (on screen Y).
5. While doing analysis, he creates functional design, a high-level document that explains step by step what this button will do and how it will interact with current functionality (where it will be placed, how it will be named, what happens when it is clicked), the document that person with no programming background (client) can read and understand.
• Based on this document he creates user acceptance test cases for client with whom client will test button and approve if this is what he wanted.
6. Then, second document, technical design, a low-level document that has all the technical blabbering on how button will be implemented, in what ‘class’ code will be written, what interface if any it will trigger and what is send from and to through interface, what restrictions, rules should be implemented with button, what database fields will interact when it’s clicked, in what rows data will be saved etc. as I told all, technical blabbering. This document is the main document on what estimation can be created, as this document basically says, how much work programmer will have to do, to implement this button.
• Based on this document he creates unit/application/integration test cases what will test technical part of button, with whom programmers and testers will try to eliminate any bugs that can be accidentally created in the code by programmer.
7. When this is done – estimate can be created, how much time building and testing will take.

Problems with this approach? Yes of course, it could just take a lot of time, that’s why managers don’t like it, they better just take estimate out of the sky and base it on arbitrary assumptions. Like: in school (let’s take same, third grade) teacher gives home work for math, five exercises. You spit out quick assumption, five exercises, one exercise - thirty minutes, homework done in two hours and thirty minutes. So, now you go out with friends as you know you can spend some time with them after school as you don’t need all time after school for homework. You go back home, and start homework, then in first fifteen minutes you find out that two exercises are easy and you do them both in thirty minutes, but now, rest three are hard, and takes three hours each, yep you sit till 3am (or you can just drop them, as this is still just third grade, exams for university will not come in ten more years).

This is one of the biggest problems why nowadays there are a lot of overtime in IT projects. It’s just because estimations for work wasn’t done by the people who are doing the work. Managers only care about hitting deadlines, they don’t care about quality or proper documentation. A lot of time we don’t even create functional/technical designs, we just start programming straight in to the system without even understand, if client needs this thing. Is there added value to the requirement he is asking? If the client says he needs this new button, doesn’t mean he needs it, but that’s a story for some other chapter.

Bottom line – use your experience, technical and analytic knowledge to analyze input data and come up with estimate on how much time you will need to get output data you need – Chinese language for the MBA.