In the old days I remember discussing missing assembler commands. One of them was LVK or something similar. The purpose was to provide "line voltage to keyboard" as direct user feedback...
I may have missed what you were asking - if you have spent millions implementing an ERP, you are attempting to use an ERP strategy over a "best of breed" strategy. This may be the motivation behind your CIO comments. If this is the case, your departmental applications should be dumped entirely and the business processes involved should be modified to fit the "best practice" processes built into the ERP. Where a department really has requirements for a separate system (this is a much rarer situation than most people think - especially in SBU's) a supportable interface to the ERP should be deployed. You are now supporting a hybrid ERP/BoB (which to some degree is often the case at most places claiming to be an ERP shop).
We deployed PeopleSoft here in 2006 with help of a third party partner - through diligent procedural development wehave become self sufficient even through major upgrades. A constant threat to our success has been the reluctance of process owners in the SBU's to even consider changing their business processes to match the vanilla processes delivered. More than once we have had to wait until a major decision maker retired to change processes only to find out the the new processes, after an initial painful adjustment period, are superior - better suited to our needs, easier to integrate, adapt better to changing requirements from users and governments, scale well and are easier to monitor and report on.
The question I ask myself when considering the root of the problem - who writes/approves a billing algorithm that can generate a monthly bill for a residential customer that can go into the thousands of dollars? If the costliest package from a vendor is say 150.00 per month, billing algorithms should max out at a reasonable multiplier of this amount, say 2 or 3. That should provide enough incentive for customers to educate themselves about the various packages and select the right one without getting "Bill Shock".
First - ONLY use estimates you get from your team, if your client needs a shorter deadline, ask you team for an estimate of what can be done by YYYY if the customer is trying to accomplish x. They may surprise you with creative options.
Second - communicate as best you can about what is going on in the bigger picture - explaining the current politics of the big hairy furball (your company) will help set the context (for the stupidity mostly). You should be up on this stuff because you get to go to the meetings they don't (and shouldn't).
Third - This activity should be your core duty. Getting resources (and training), coordinating projects with the clients so the requirements are good enough to act on and the testers are available when required. Incredible time can be added to projects by not having simple logistics set up between clients and the development team.
Fourth - Yep. And this can mean simple status reports (driven by a software tool). These PITA reports are invaluable in helping you keep the expectations realistic on your team from YOUR boss. Documenting the activity is the best way to convince your boss that you have your team working on the correct priorities.
and one more -
Five - give credit where credit is due. This can be done by simple public emails at the conclusion of projects/tasks but you can also promote your team by "getting their names and faces" out there from time to time.
I am a very reluctant techie to manager (15 yrs) who is still learning.
It is funny as hell and informative. It worked wonders for me too but that isn't why you should read it.
It talks about nutrition and exercise in a very good context. If you are going to limit yourself to 2000 calories a day, eating vegetables may be better for you than eating chocolate(for all the reasons being listed in this discussion) but it has nothing to do with losing weight. The fact that you are eating fewer calories than you consume every day will lead to weight loss. He calls diets "controlled starvation". Put the body under stress and it will eat its food reserves. Exercise is treated in a similar way. He doesn't dispute that it is good for you to walk or exercise every day but it has nothing to do with weight loss. It all comes down to the math.
Again, a few paragraphs from this work can't do it justice. It's worth the read even if you have no intention of losing weight.
cheers (on my drinking days I'd go without food for over 24 hours so the beer calories wouldn't take me off track - something I would never suggest for other people)
I went through a tough transition from techie/code writer to manager. I hire people old or young that will improve my team. Sometimes that means young people with enthusiasm and a misplaced sense of what the latest technology can really accomplish and sometimes it means hiring someone older who has lived through several "revolutions" in programming that will "forever change" the IT world. The more experienced (often but not always older) programmer/analysts are the better listeners who remember that our primary purpose is to build software systems that people can use intuitively to accomplish their work more effectively. They are also the ones that can resist the temptation to build "clever" code remembering from past code maintenance nightmares that just because something is possible doesn't mean it is good idea.
Lately, to help screen applicants we have found it is extremely useful to test and interview. This quickly helps us identify those with a balance of technical and communication skills. It is remarkable how few applicants carefully listen to our questions before answering. Most use every question as a starting point to launch into a detailed technical diatribe of their favorite projects, scattering acronyms throughout, forgetting that only one of the interview committee members (who have all been introduced and identified by position) has a technical background suitable to understand their answer.
Summary - those managers who want the best team members will find ways that do not prohibit older programmers from making it through the screening process. We will occasionally miss the truly gifted but this is unfortunately but part of risk management.
Slashdot Mirror
Planet of the Apes.
Bonus movie - the day the earth stood still.
Hard to pick just one!
vt220 - dialup modem - PDP11 at work.
In the old days I remember discussing missing assembler commands. One of them was LVK or something similar. The purpose was to provide "line voltage to keyboard" as direct user feedback...
I may have missed what you were asking - if you have spent millions implementing an ERP, you are attempting to use an ERP strategy over a "best of breed" strategy. This may be the motivation behind your CIO comments. If this is the case, your departmental applications should be dumped entirely and the business processes involved should be modified to fit the "best practice" processes built into the ERP. Where a department really has requirements for a separate system (this is a much rarer situation than most people think - especially in SBU's) a supportable interface to the ERP should be deployed. You are now supporting a hybrid ERP/BoB (which to some degree is often the case at most places claiming to be an ERP shop).
We deployed PeopleSoft here in 2006 with help of a third party partner - through diligent procedural development wehave become self sufficient even through major upgrades. A constant threat to our success has been the reluctance of process owners in the SBU's to even consider changing their business processes to match the vanilla processes delivered. More than once we have had to wait until a major decision maker retired to change processes only to find out the the new processes, after an initial painful adjustment period, are superior - better suited to our needs, easier to integrate, adapt better to changing requirements from users and governments, scale well and are easier to monitor and report on.
G
Are you suggesting that 50K from ONE online source (by no means the full extent of their income) isn't serious?
The question I ask myself when considering the root of the problem - who writes/approves a billing algorithm that can generate a monthly bill for a residential customer that can go into the thousands of dollars? If the costliest package from a vendor is say 150.00 per month, billing algorithms should max out at a reasonable multiplier of this amount, say 2 or 3. That should provide enough incentive for customers to educate themselves about the various packages and select the right one without getting "Bill Shock".
I was looking for an answer like this -
First - ONLY use estimates you get from your team, if your client needs a shorter deadline, ask you team for an estimate of what can be done by YYYY if the customer is trying to accomplish x. They may surprise you with creative options.
Second - communicate as best you can about what is going on in the bigger picture - explaining the current politics of the big hairy furball (your company) will help set the context (for the stupidity mostly). You should be up on this stuff because you get to go to the meetings they don't (and shouldn't).
Third - This activity should be your core duty. Getting resources (and training), coordinating projects with the clients so the requirements are good enough to act on and the testers are available when required. Incredible time can be added to projects by not having simple logistics set up between clients and the development team.
Fourth - Yep. And this can mean simple status reports (driven by a software tool). These PITA reports are invaluable in helping you keep the expectations realistic on your team from YOUR boss. Documenting the activity is the best way to convince your boss that you have your team working on the correct priorities.
and one more -
Five - give credit where credit is due. This can be done by simple public emails at the conclusion of projects/tasks but you can also promote your team by "getting their names and faces" out there from time to time.
I am a very reluctant techie to manager (15 yrs) who is still learning.
Did you read the Hacker's Diet?
It is funny as hell and informative. It worked wonders for me too but that isn't why you should read it.
It talks about nutrition and exercise in a very good context. If you are going to limit yourself to 2000 calories a day, eating vegetables may be better for you than eating chocolate(for all the reasons being listed in this discussion) but it has nothing to do with losing weight. The fact that you are eating fewer calories than you consume every day will lead to weight loss. He calls diets "controlled starvation". Put the body under stress and it will eat its food reserves. Exercise is treated in a similar way. He doesn't dispute that it is good for you to walk or exercise every day but it has nothing to do with weight loss. It all comes down to the math.
Again, a few paragraphs from this work can't do it justice. It's worth the read even if you have no intention of losing weight.
cheers (on my drinking days I'd go without food for over 24 hours so the beer calories wouldn't take me off track - something I would never suggest for other people)
Turn your pop up blocker off. You'll see that there are too many of these surveys out there already.
Now if you're looking for intelligent aggregation, summaries and publication of data from these surveys that is rarer.
I went through a tough transition from techie/code writer to manager. I hire people old or young that will improve my team. Sometimes that means young people with enthusiasm and a misplaced sense of what the latest technology can really accomplish and sometimes it means hiring someone older who has lived through several "revolutions" in programming that will "forever change" the IT world. The more experienced (often but not always older) programmer/analysts are the better listeners who remember that our primary purpose is to build software systems that people can use intuitively to accomplish their work more effectively. They are also the ones that can resist the temptation to build "clever" code remembering from past code maintenance nightmares that just because something is possible doesn't mean it is good idea.
Lately, to help screen applicants we have found it is extremely useful to test and interview. This quickly helps us identify those with a balance of technical and communication skills. It is remarkable how few applicants carefully listen to our questions before answering. Most use every question as a starting point to launch into a detailed technical diatribe of their favorite projects, scattering acronyms throughout, forgetting that only one of the interview committee members (who have all been introduced and identified by position) has a technical background suitable to understand their answer.
Summary - those managers who want the best team members will find ways that do not prohibit older programmers from making it through the screening process. We will occasionally miss the truly gifted but this is unfortunately but part of risk management.