As a Lead Programmer my responsibilities include calculating the deadlines of the projects.
To do this I have discussion with related team players and calculate a deadline estimation. Sometimes, I got a scared voice from CTO saying that the estimated deadline is too much. Then I have to shorten the deadline. With a shorter deadline, programmers have to work with extra pressure.
How can I represent (points) to the CTO that the calculated deadline is reasonable?
1
One time-proven way is the scientific method, one could even say a data driven method 🙂
- Ask a Question (When are we done?)
- Do Background Research (What needs to be done? Divide et impera).
- Construct a Hypothesis (Calculate the time of completion, deadline).
- Test Your Hypothesis by Doing an Experiment. (Do multiple sprints, so you get real data from past sprints and estimations. The truth is in the data).
- Analyze Your Data and Draw a Conclusion. (How accurate were we? Make adjustments. Learn. Repeat. Iterate.)
- Communicate Your Results. (Tell your client/boss/CTO)
Multiple iterations is the key, so you get the real data to build on!
Source: Steps of the Scientific Method
1
Making estimations becomes much easier when the work is divided into smaller tasks. And the smaller the tasks are the easier it is to estimate them. This way the estimation become more accurate.
This also helps to clearly see how much time will be spent on each task. So when the management is complaining about the deadlines, you can show them what exactly the time is spent on.
If the deadline isn’t acceptable, some of the initial functionality should be reduced. Reasonable managers will go for a high quality product with fewer features than a pile of not-properly-working functionality.
Another trick is to “cheat” giving a little bigger estimations than necessary. But I think this is an extreme.
1
There is a huge body of work on software cost and schedule estimation. At its heart, the fact is that there is always some uncertainty, which means that there is always a nonzero probability of missing the deadline (and! a nonzero probability of coming in early). When you pull a deadline in, you are increasing the probability that you will miss the deadline, and you are increasing the probability that you are going to have other problems, because you are going to demand that your people cut corners, and cutting corners ALWAYS comes back to haunt you.
If you’ve kept historical data on projects and costs, you can calibrate an estimator to your organization, and you are then in a position to tell the CTO “This is what our historical data indicates we can do. If you want us to pull the deadline in, we will, but understand that you are going to have to accept increased risk of a blown deadline and serious bugs in the product.”
The worst case I ever saw was at General Dynamics. A failure of the software source code control system meant that a bug was inadvertently introduced. An accelerated release schedule meant that a critical test, intended to detect that specific kind of bug, did not get performed until a day or two after the release had been sent out to Edwards AFB for flight test. The test showed a safety of flight issue that could result in loss of the test airplane and/or death of the test pilot. (The test airplane cost many, many millions of dollars, far more than the production airplanes,because it was a hand-built one-of-a-kind bird. Good test pilots cost almost as much, and they are very long-lead items.) All hell broke loose.
I’ve always maintained that any software project has four variables:
- StartDate
- Duration
- Effort
- Staffing
You can control any three of them, but the fourth is a function of the other three.
- If you set StartDate=W, Duration=X days, and Effort=Y person-hours, you’re going to need Z people.
- If you set StartDate=W, Effort=Y person-hours, and Staffing=Z people, it’s going to take X days.
- etc.
1