in
Forums
Hi guys,
BLUF: I need some help wording an accomplishment bullet, where while I hit on-time on-budget, I don't think that's the most important part of the accomplishment. The most important part, to me, is that because _I_ did it, the schedule (and budget) were lower than had another developer been doing the project.
Background:
I'm a developer (obviously). Anyone who's ever worked with or managed programmers know that there can be a *significant* difference in productivity between the best and the worst or even the average. (I'm not the *best* *ever* - but I'm above average in my particular team.)
Several times in the last few years, I've been asked to estimate how long it would take me to complete a project. Nothing new there; that's, well, normal.
What I don't think is quite as normal is that I've come up with shorter estimates than the developer(s) that were more appropriate for the project (already knew the application being changed, or knew the customers, or whatever).
I've been given several of these projects, and have completed them. On time, on budget, to quality standards - the schedule made based on my estimates, and the budget based on the same estimates.
So, ok, I was on-time and on-budget; very good. Appropriate quality standards, also very good.
*Better* is that the schedule was shorter, the budget smaller, than had the other developer(s) been assigned the project instead. (Or rather, better is that the schedule was shorter/budget smaller *and* I still made it. Had I spent the time of the larger estimate, this would not be a good accomplishment, obviously!)
How do I word this? I don't know specific amounts of money or time. I know generalities: there were 2-4 weeks saved on the last one, that I did in about 2 months, for instance.
Also, should I say specifics of quality standards hit, the actual project (or rather a description of it), the language used, or anything like that? (I have the language(s), frameworks, and tools we use in my responsibilities.)
I'd appreciate any advice people have.
Comparison is fine
"Delivered software project 17% quicker than estimated by previous team by uninstalling minecraft"
I'll probably ask you a question about it in the interview, and you can explain the estimation situation briefly before going into the details of how you delivered.
As far as your other questions go: quality standards are a separate bullet; skip the project description unless it was building software that your new employer specifically needs built; technologies *should* go in your accomplishments, and they *shouldn't* go in your responsibilities. The only time I'd put a tech in my responsibiltiies would be if "in X" would otherwise go into most of my bullets.
For example, if I were an MS-SQL Server DBA (heaven forfend), and I spent all day kicking those machines, that'd go in my responsibilities (if my title weren't already "MS-SQL Server DBA").
However, if I were a developer and I used C# in a couple of projects, LINQ in one of those and a couple of others, managed to wheedle my way onto an IronPython project, and had my family kidnapped and held for ransom so I'd delve into some ancient ASP classic code and rewrite it in ASP.Net, well, I'd put those techs in the relevant projects, and not list them all in my responsibilities. Why? Because a hiring manager is going to want to know what you've done in each of those technologies. If I've got a huge and important C# project, then I'm going to want to see that your C# projects were the huge and important ones you worked on, rather than the ASP rewrite being your primary focus for 90% of the time and the C# things just little side hacks. When I see a bunch of technologies listed in a responsibilities paragraph, I think you're keyword stuffing and I won't believe you've got more skills in any of those areas than "I read the wikipedia page about it".