time sheet
-
I don't use time sheets. In my opinion they are micromanagement overhead and I don't buy the reasoning that they offer a better project overview then, say, project journal. Also when you're engaged in extreme programming such buerocratic *#*!*?*@ reduces your productivity and increases the pressure (as if it was not high enough). There's nothing quite like dividing people to small teams and have weekly meetings in relaxed environment where data is gathered and the project journal updated. I've never seen a project manager doing hefty process engineering (including angry timesheet management and complex time estimation techniques using trivial statistics) that would always do better that someone who doesn't and would not manage troubles in exactly the same way as everyone else - by cutting down quality and functionality. The worth of timesheet data is for me smaller or equal to worth of technical analysis in trading. It's a myth much more then a practical tool. Tomaz
Tomaž Štih wrote: I don't use time sheets. In my opinion they are micromanagement overhead and I don't buy the reasoning that they offer a better project overview then, say, project journal. Like I said. I never used to like them but now they have real value to me and my business. Michael CP Blog [^]
-
If you're good try the labour market - there are better alternatives there. If not - work triple as hard as you need to to gain skills, then try the labour market. Tomaz
it's easy to evaluate a situation by its sound, assuming we know alot about a situation when you merely know a little, but i think it's human nature "we are fundamentally judgmental". but what i think most ironic is that in your other post you underestimate the info we acknowledge for little info like time sheet, but you still think that you know alot form my post. alot of us automatically wear "the Fixing hat" and try to give soluation when they catch asign of problem, but anyway thanks for your advice, assemizm
-
I don't use time sheets. In my opinion they are micromanagement overhead and I don't buy the reasoning that they offer a better project overview then, say, project journal. Also when you're engaged in extreme programming such buerocratic *#*!*?*@ reduces your productivity and increases the pressure (as if it was not high enough). There's nothing quite like dividing people to small teams and have weekly meetings in relaxed environment where data is gathered and the project journal updated. I've never seen a project manager doing hefty process engineering (including angry timesheet management and complex time estimation techniques using trivial statistics) that would always do better that someone who doesn't and would not manage troubles in exactly the same way as everyone else - by cutting down quality and functionality. The worth of timesheet data is for me smaller or equal to worth of technical analysis in trading. It's a myth much more then a practical tool. Tomaz
In the company I work for, time sheets are there as part of the client billing process. I can be working on one project in the morning for one client and another project in the afternoon for a different client and then there is the odd hour here and there that gets consumed for yet antother client because of some small but urgent task. So all that has to be accounted for so the correct invoices get sent out. Incorrect invoices == delayed or no money == damaged cash flow == financial difficulties == layoffs == :(( Tomaž Štih wrote: Also when you're engaged in extreme programming such buerocratic *#*!*?*@ reduces your productivity and increases the pressure Well, don't worry - the pressure can be reduced soon enough when your company doesn't bill the client for the right money, and then has none to pay you and has to lay everyone off. BTW, my company uses eXtreme Programming when necessary for a project. Tomaž Štih wrote: The worth of timesheet data is for me smaller or equal to worth of technical analysis in trading. It's a myth much more then a practical tool. While invoicing customers and clients may seem trivial to you it is vital for the health of a company.
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
-
If you're good try the labour market - there are better alternatives there. If not - work triple as hard as you need to to gain skills, then try the labour market. Tomaz
-
my manager ask me ever day why I did not fill my time sheet? what should I answer him
mohammed barqawi wrote: what should I answer him I wouldn't answer him. Just fill in the time sheet. They exist for a reason, a couple of reasons in fact. A very important one is to track the time you spend on the various projects you work on for billing purposes. Each contract has a master account, with subaccounts for each line item in the WBS. Often there are different rates of compensation for each item, and without accurate timesheets it's impossible to correctly bill the customer. It also is a legal requirement to maintain accurate timesheets if any of your work is for a government entity. Failure to do so can result in contract cancellation, penalties, and being barred from future contract competitions. Another reason to keep accurate timesheets is to build a historical database for future contract pricing and product cost estimating. There are rules of thumb for estimating the cost of various tasks - 10 lines of debugged code per programmer hour was a standard one when I was in the business - but they all fall far short of reality. Having an inhouse historical record of how long similar tasks have taken to complete is invaluable when developing a RFP response. Your company's future success in contract competition is dependent upon being able to make good estimates of expected development costs, and historical timekeeping data is critical to that process. Your future employment depends, in turn, upon the company's ability to win contracts or develop profitable product lines. Fill in the sheet and quit finding reasons to avoid such a trivial, but important activity.;P "My kid was Inmate of the Month at Adobe Mountain Juvenile Corrections Center" - Bumper Sticker in Bullhead City
-
Tomaž Štih wrote: I don't use time sheets. In my opinion they are micromanagement overhead and I don't buy the reasoning that they offer a better project overview then, say, project journal. Like I said. I never used to like them but now they have real value to me and my business. Michael CP Blog [^]
In a little but important way, they also make you a better developer - you get progressively better giving time estimates, which means you have a better chance of delivering on time. Something most customers value :-)
-
In the company I work for, time sheets are there as part of the client billing process. I can be working on one project in the morning for one client and another project in the afternoon for a different client and then there is the odd hour here and there that gets consumed for yet antother client because of some small but urgent task. So all that has to be accounted for so the correct invoices get sent out. Incorrect invoices == delayed or no money == damaged cash flow == financial difficulties == layoffs == :(( Tomaž Štih wrote: Also when you're engaged in extreme programming such buerocratic *#*!*?*@ reduces your productivity and increases the pressure Well, don't worry - the pressure can be reduced soon enough when your company doesn't bill the client for the right money, and then has none to pay you and has to lay everyone off. BTW, my company uses eXtreme Programming when necessary for a project. Tomaž Štih wrote: The worth of timesheet data is for me smaller or equal to worth of technical analysis in trading. It's a myth much more then a practical tool. While invoicing customers and clients may seem trivial to you it is vital for the health of a company.
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
It's also a question of fairness, noone gets overinvoiced. As I sell my time, not too much and not too little is equally important, for my pride as a craftsman.
-
It's also a question of fairness, noone gets overinvoiced. As I sell my time, not too much and not too little is equally important, for my pride as a craftsman.
Johan Rosengren wrote: It's also a question of fairness, noone gets overinvoiced. True, also if customers' think they are being overinvoiced they will go elsewhere.
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
-
my manager ask me ever day why I did not fill my time sheet? what should I answer him
The question is why aren't you filling the timsheet in ? It is the manager's responsiblity to see that resources are being used well and the timesheet is a basic tool for this. As long as you want a good salary from your employers you have to take their needs into account. Yes, I do a timesheet. Elaine :rose: The tigress is here :-D
-
it's easy to evaluate a situation by its sound, assuming we know alot about a situation when you merely know a little, but i think it's human nature "we are fundamentally judgmental". but what i think most ironic is that in your other post you underestimate the info we acknowledge for little info like time sheet, but you still think that you know alot form my post. alot of us automatically wear "the Fixing hat" and try to give soluation when they catch asign of problem, but anyway thanks for your advice, assemizm
I'm sorry but I really had no intention to pass judgements. My advice was an honest one: find a new job if you can; create conditions that will enable you to find one if you can't. I did not imply your abilities to do one or another. You see, most companies value employees accoding to following traits (in given order): 1) ability to produce results that they can sell, 2) ability to cooperate with other employees, 3) loyalty, 4) presence. Your manager obviously lacks leadership skills (2) and is therefore reducing productivity of his team. If he can compensate on other points (or if abuse is company culture) then that's acceptable. But if he can not then as a result of his bad leadership you will have poor 1), 2), 3) and eventually (when you get tired of it all) 4). You know best what the situation and culture of your company is. In my opinion we're selling our skills on the market. To raise our price we must find a company that will enable us to fully exploit our potentials and decisively contribute to the income of the company. Only such environment can offer us a perspective career path. And due to competition we must work hard to obtain the skills to be able to do this. These two thoughts are what I joined into my advice to you. Did not have any evil thoughts... Tomaz
-
In a little but important way, they also make you a better developer - you get progressively better giving time estimates, which means you have a better chance of delivering on time. Something most customers value :-)
Did not notice that. The technology was changing so quickly (in the past decade) that one day I was a Clipper Summer 87/5 expert, then C/C++ embedded systems expert, then Windows 3.1 C/C++ expert, then NT system programming expert, then VB expert, then ASP expert, then C# expert, and most of the time involved in design, architecture and process engineering. I hold B. Sc. in Software Engineering and have solid understanding of software process theory from SSAD, via CMM and ISO 9000.3 to the trendy RUP. Don't need people explaining me what is written in the books. I am just saying that I did not notice quality changes such as process pundits always envision at the end of the tunnel by applying time sheets. It is great if some of you really do benefit from them - I respect that. Tomaz
-
In the company I work for, time sheets are there as part of the client billing process. I can be working on one project in the morning for one client and another project in the afternoon for a different client and then there is the odd hour here and there that gets consumed for yet antother client because of some small but urgent task. So all that has to be accounted for so the correct invoices get sent out. Incorrect invoices == delayed or no money == damaged cash flow == financial difficulties == layoffs == :(( Tomaž Štih wrote: Also when you're engaged in extreme programming such buerocratic *#*!*?*@ reduces your productivity and increases the pressure Well, don't worry - the pressure can be reduced soon enough when your company doesn't bill the client for the right money, and then has none to pay you and has to lay everyone off. BTW, my company uses eXtreme Programming when necessary for a project. Tomaž Štih wrote: The worth of timesheet data is for me smaller or equal to worth of technical analysis in trading. It's a myth much more then a practical tool. While invoicing customers and clients may seem trivial to you it is vital for the health of a company.
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
When your company is under hourly rate contract then it is pretty obvious that they need hourly reports to bill the customer - I would not object to reality. I merely pointed out that somebody has yet to prove to me that time sheets really improve software process quality and that I'm not satisfied with the explanation: "it is written in every good SW DEV book and everyone's doing it". Historical existence of 15 billion Enetropneusta for every today's Homo sapiens is not proof that they were evolutionary superior. :-) Tomaz
-
Did not notice that. The technology was changing so quickly (in the past decade) that one day I was a Clipper Summer 87/5 expert, then C/C++ embedded systems expert, then Windows 3.1 C/C++ expert, then NT system programming expert, then VB expert, then ASP expert, then C# expert, and most of the time involved in design, architecture and process engineering. I hold B. Sc. in Software Engineering and have solid understanding of software process theory from SSAD, via CMM and ISO 9000.3 to the trendy RUP. Don't need people explaining me what is written in the books. I am just saying that I did not notice quality changes such as process pundits always envision at the end of the tunnel by applying time sheets. It is great if some of you really do benefit from them - I respect that. Tomaz
It is great if some of you really do benefit from them - I respect that. So why am I bitching? :-D Because I object to non-critical acceptance of the idea that: "Time sheets are good.". Tomaz
-
When your company is under hourly rate contract then it is pretty obvious that they need hourly reports to bill the customer - I would not object to reality. I merely pointed out that somebody has yet to prove to me that time sheets really improve software process quality and that I'm not satisfied with the explanation: "it is written in every good SW DEV book and everyone's doing it". Historical existence of 15 billion Enetropneusta for every today's Homo sapiens is not proof that they were evolutionary superior. :-) Tomaz
Well, my only gripe to the timesheet system I use is that I cannot attach personal notes to improve my estimation skills (or subdivide tasks up beyond the divisions required as part of the overall process it fits into at present). As someone else pointed out in this thread it does allow you to look back to see how long it took you to do a task the last time around, which means a better estimation this time around.
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
-
Johan Rosengren wrote: It's also a question of fairness, noone gets overinvoiced. True, also if customers' think they are being overinvoiced they will go elsewhere.
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
And if I'm conscientious, it will far easier to be authoritative when needed - for example when explaining to a client that the proposed shortcut is not such a good idea.
-
It is great if some of you really do benefit from them - I respect that. So why am I bitching? :-D Because I object to non-critical acceptance of the idea that: "Time sheets are good.". Tomaz
Tomaž Štih wrote: Because I object to non-critical acceptance of the idea that: "Time sheets are good.". And I respect that! If you would introduce time sheets to your developer, never explaining why, I can even imagine they are contra-productive.
-
mohammed barqawi wrote: why I did not fill my time sheet? I suppose the real question is, why don't you fill your timesheet in. When I was just a programmer working for somebody else, I used to think that timesheets were just a way of keeping track of me and making sure I was putting the necesssary hours in. Now I'm my own boss. I find timesheets to be invaluable. I work on fixed priced projects based on an original estimate. However it always takes me more hours than I quote for. This in theory is costing me money... or at the moment meaning less profit :-D However because everything I do is recorded on a timesheet. I can now see why things went wrong, what took longer than expected. What I missed when originally designing the project. My timesheets arent' about putting 9am-5pm for each working day. I have my projects broken down into tasks which I record how many hours I worked on a specific task. The tasks are based off the original design, new tasks are added to the spreadsheet everytime I do something that is outside the original scope. I also keep notes on what I did for each task and why it over-ran the estimate, this helps me to better understand the problems I've faced and make sure I build the time in for the next time. When I eventually hire developers, they will all use this procedure and they'd better have a damn good excuse for not using it. Michael CP Blog [^]
Michael P Butler wrote: When I eventually hire developers, they will all use this procedure and they'd better have a damn good excuse for not using it. When can i start :laugh: To most of us that may sound crazy. However if all the other aspects of the development process are handle with the same methodical approach I would have no problem performing timekeeping functions. In the real world (at least mine :)) that is not the case. You just know that the timekeeping data does not represent anything meaningful and that it is the LAST part of the development process that needs attention.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
-
Ted Ferenc wrote: One is 'We don't have enought time' in 99% of the cases they have enough time, they are just badly organised. Either way you very quickly come up with a solution. That's true. Bad organisation wastes so much time* Ted Ferenc wrote: But if you have a code for filling the form in then great, most companies don't. If you get bored and you have a stop watch, try timing these 'few seconds', from the time you stop your current task to the time you re start it. I only ever fill in anything to the nearest 15 minutes. I think that anything more finely graned than that is going to take too long to input. But there is one guy in the company who demanded minute precision on the timesheets. *
Looks around desk and starts thinking it might be a good time to clean it a little
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
Colin Angus Mackay wrote: demanded minute precision on the timesheets Why does every organisation have one of these types of people! That type of person is why I would do as instructed but I would put on the timesheet how long it took to fill in
"Laughing at our mistakes can lengthen our own life. Laughing at someone else's can shorten it." - Cullen Hightower