How many times have you participated in this typical IT conversation?
Business: “How long is it going to take to enable that new FlimFlam engage-the-client-better module with those extra customizations we talked about?”
IT: “Last time we looked at that we said it would take a little over three months including changing the custom code in order to be able to use that new module.”
Business: “Well, we need it turned on by the end of next month when the marketing campaign starts.”
IT: “Um, err, change all the custom code, install the new module and enable it with those additional features in two not three months?”
The theme of this classic IT delivery challenge is the same:
In order to meet a communicated business need within a business defined time-frame, a perceived number of technical tasks need to be accomplished that don’t initially appear feasible in that given time-frame.
The initial reaction by most technically minded people is this is completely impossible. And yes, Agile or other project delivery methodologies have built in capabilities to handle fixed dates and variable scopes. But if you are faced with this common theme of questioning, I am going out on a limb and guessing you are not working in a truly Agile shop or else this question isn’t likely to be asked in this manner in the first place.
So, you rush out and grab your FlimFlam experts to communicate the need and the desired end date. You tell them this is the most important thing to work on and then you go back to your desk to get ready for the next crisis of systems delivery.
Consider taking the time to put together a work delivery estimate as your first priority. Why do this seemingly futile exercise when the business has already stated what they need and when they need it by?
You need to have some estimate data in hand to have a conversation with the business on what is truly feasible within a pre-communicated time-frame.
This conversation serves a few purposes that are critical to you and your team’s ability to deliver a quality solution:
- Establishes what in-flight work will be put on hold/delayed until this higher priority request is completed.
- Durations of time on sub-tasks enable the business to prioritize what features they truly need versus those that are just “nice to have”.
- Establishes a baseline so when other high priority requests come in or new feature requests are added, you can dust off the previous estimate, revise with the new needs, and re-engage in the conversation.
I can’t count the number of times I have chatted with a business sponsor that swore up and down they just had to have every item in their request delivered by an irrational date. Yet when presented with some work estimate that indicated everything wasn’t realistically possible within the time-frame [based on the cumulative hours/weeks associated with their request broken down into granular tasks], that same business sponsor started cutting “low priority” features left and right to meet their date.
Business: “You mean it is going to take a week just to get that data on the screen within the application? We can just use that old report that shows the same data on paper. Scratch that feature.”
The typical technical/engineer mindset applied to the theme of delivering unfamiliar technology within an aggressive (arbitrary?) time frame is to think it impossible given the number of unknowns. Get ready for panic and shortness of breath from your less seasoned technical staff. Giving them coaching and a framework to break down the seemingly huge and complicated requests into a logical sequence of executable tasks is the other side of the estimation challenge.
To help enable the technical resources to break down “the work” into meaningful, estimate able and negotiable chunks, I’ve attached a simple work estimation spreadsheet:
Below is a brief explanation of how the template works:
There are three tabs:
1. Template = where one fills in the data to create an IT work estimate.
2. Calculations = where certain values are used in calculations on the Template sheet. Changing numbers here causes the whole estimate to change.
3. Assumptions = certain assumptions, copyright and reference back to this article for explaining how the template works.
The top portion of the template (red arrow below) is designed to capture the basics about the estimate to tell it apart from other estimates: Name, project, dates, etc. Think of all the fields that would help you and your organization know what you are estimating.
The main section of the template is where the work break down and granular task estimating occurs. Gray fields throughout are auto-calculated but can be typed over if needed. The first task heading “1. Architecture Tasks” shown below is a section to capture the non-negotiable tasks that need to be executed in order for any business functionality to be delivered. This could be getting servers installed or setting up a new project in MS Visual Studio 2039 or creating a new code branch for the required new features which involves an act of Congress in your organization.
The “description” column is for the estimator to describe, in low tech language, what granular task is needed. Since one may need to sit down and discuss this with a non-technical business person, some effort to use language that is more descriptive and less heads down techie would be beneficial.
The “Low” and “High” are for the estimator to enter the approximate minimum and maximum hours needed to complete the task. The “Average” column in gray is calculated as simply the average to be used for the roll-up calculations at the end of the template. If there are a number of unknowns or the tasks could be quick but depending on X, Y or Z, might run long, use a wide range for “low” and “high”. This also presents the business conversational element of “Well, if this step goes well, it could be as short as 3 hours. But, if turns out we do need to engage the storage team and get more storage allocated, then this could take as long as 20 hours.” This is useful in setting the business’s expectations around variability in the estimate so they don’t get too fixed on a single, implicit number when things don’t follow the “happy path”.
The “Actual” column is useful for the engineer to record the actual time it took them to complete the tasks or the number of hours consumed up to the date the template is revised for some status reporting reason. This also paves the way for estimators to get better at more evidence based estimating/scheduling.
The “Complete” column is for the task executor to record if they indeed completed the task or if it still needs work to finish. Entering a “Y” means the task is complete. Blank or anything else means the task still needs work to complete.
The “Estimate Remaining” is gray and thus calculated as the remaining hours of the “Estimate Average” minus the “Actual” if the “Complete” column doesn’t have a “Y”. If the “Actual” turned out to be more than the “Estimate Average” then the column is left blank.
The “Notes” column (not shown here) is for any task notes that help the estimator or anyone reading the estimate to know some additional details about task that is driving the estimated hours.
The next section called “2. Development of Functional Unit 1” represents a block of work that roles up to some business identifiable chunk of work. Feel free to change the section name to reflect something all project stakeholders would understand. These sections are designed to be the negotiable features that can serve as that business conversation to determine what are the exact features needed and the corresponding work durations. Feel free to cut/paste as many new sections as is representative of the work break down requested.
In the above example from the template, Sample Task 2.1 represents a task that was estimated to be 7.5 hours but actually took 4.5 and is compete.
Sample Task 2.2 represents a task with 18.00 hours completed so far, thus calculated is the remaining 5 hours from the 23 hour estimate.
The “Sub Total” represents the min/max of the total work effort (142.25 and 181.25 in this example, which is a full ~40 hour delta) for an average of 161.75 hours of which 65 have been completed and 101 hours remain against the average. Thus, the business expectations can be set relative to the ~40 hour swing to help the planning for best and worst case delivery.
Below the “Sub Total” section are tasks that are relative to the overall IT work:
In this section, any standard deliverables or work associated with the doing the actual development work can be captured. In this example section, I added “unit testing” which I calculated as a percentage of the sub total hours of development work above. The percentage is pulled from the “Calculations” tab. In this case, I am calculating that unit testing takes 80% of the hours estimated towards development. You can add/remove entries or adjust calculations on the “Calculations” tab to capture the hours needed to deliver a quality solution that so many developers forget to include in their hard core development work estimating.
The two documentation entries represent either a fixed amount of time, in this case 10 hours, or hours that are a percentage of the total development work, in this case, 20% of the total hours. Feel free to add and subtract items that come up regularly to make the overall estimate more complete. Need production turn over documentation? Add an entry here. Need some change control document to push a solution into the next environment? Add an entry here. Over time, this section will settle into capturing the work that is regularly needed in every project but is easy to forget to estimate for each time.
Lastly, the final section includes the total hours for all the work which is especially useful in answering that initial question: “How long is it going to take to enable that new FlimFlam engage-the-client-better module?” One additional element that helps beyond the “how many hours” is the “Total Work Days” calculation which is based on a more realistic number of productive hours per day plus any reduction in time to cover other assignments that aren’t specific to project work such as researching a new technology or working on a special assignment of some kind. The calculations are in the “Calculations” tab. In this example, the productive work day is 6 hours (not 8 as some might consider) and 80% of those 6 hours should go to projects such as this one. Hence the “Total Work Days” is greater than simply 348.50 divided by 40. Again, feel free to adjust these calculations to aide in matching what your resources truly can dedicate to a particular project. Want to show the “cost” of assigning two concurrent projects to a single resource? Drop the hours to 3 and add another 20% to cover the cost of “context switching” and see how your estimates come to reflect reality a bit more as an example.
Once established as the “baseline” estimate, as new requests/changes come in, add them to the previous estimation sheet, change the date and quickly be able to predict when the overall solution will now be delivered. Get ready for another “what is pushing out the date?” discussion armed with your estimating data.
Once established on multiple projects in the “portfolio”, now you can hold these up against competing resources to show “if project X goes first, when would I get project Y next?” This is extremely handy if your resources effectively cost “zero dollars” in a non-charge back type corporate IT model.
Please give this template a try and let me know feedback on how effective it is with technical resources as well as a conversation tool with project sponsors.
For additional practical estimation articles, consider these I’ve written in the past:
- Is the Gantt Chart Useless in Agile Projects?
- More Pitfalls of Work Estimation
- The Art of IT Work Estimation
Also, for an excellent article on using a similar technique on prioritizing multiple projects, consider this great post by Peter Kretzman, “The Practical CIO: Difficulties in project prioritization & selection, part 2“.
For additional caution in getting too carried away with the accuracy of your estimate, consider Todd Williams’s article “Good Estimates Only Have a 50% Chance of Being Made”.