Do you have to go through some sort of formal change request/review process where you document what you will be changing, when it will occur, how long it will take, who will be impacted, what the backout/contigency is, and what the communications will be, then schedule a change and have it approved by the appropriate stakeholders, implement the change, test it, document it and have feedback?
If the answer is yes, then you are involved in a project.
I have worked in a lot of organizations where patching a database and similar functions are considered operational work. Everything is done informally and works great and the sun still rises in the east. I have also worked in organizations where the database in question is the backend to one of the nation's largest point-of-sale systems. Changes aren't as easy to push though.
It's really an issue of how well-tuned an organization is to its resourcing and risk management requirements. I'm finding more and more companies are reaching the limits of what they can accomplish informally. A lot of people are doing project work and are using project management techniques...they're just not aware that they're doing it!
You are either working on a project or you are working on operations. A project has a defined scope, time frame, is temporary and has a unique deliverable. Operations is on-going and repetitive.
If you are tasked with upgrading something, by definition, you are working on a project.
The Project Management Institute literature and methodology is quite clear and applies to all work sectors - IT, engineering, manufacturing, etc... It's a project or it's operations. Never both.
Projects can turn into operations upon completion of particular milestones. Operations can spawn projects for upgrades, etc. There is a relationship and there are dependencies but they are not one and the same.
Daily system maintenance of your database = operations. Patching of your database = project.
This may sound pedantic to IT people for something as "trivial" as a small upgrade, but when you scale it out to massive infrastructure work - be it expanding a data center or building a new refinery - the separation is the only way you can plan and then properly execute the work.
Re:consulting
on
Ageism in IT?
·
· Score: 2, Interesting
Never under-estimate the power of actually dressing "professionally" either. It is amazing how much more credibility you can have in the eyes of the "management establishment" when you emulate their behaviors. I have had more opportunities come my way "POST-bust" because I decided to bite the bullet and "play the game" through attire and politics. Ditch the jeans, t-shirts and sneakers. I even went so far as to ditch the Dockers and golf shirt. It's dress trousers, dress trousers and a blazer now.
When I informally polled my peers, there was an eery positive correlation between large monthly dry cleaning bills and career progression after the bust.
YMMV but mine's been excellent after making the change.
"Steel-toed boots" industries just aren't viewed as being "sexy", though. A lot of people I know beam when they tell people they write e-commerce code. But who brags about writing code system code that monitors valve pressure for a gas plant?
I went "high-tech" in 1995 when I interned at Nortel. The pace of work was insane. And this was BEFORE any dot-com phenomena. I decided back then that the high-tech was probably not the way to go.
So I did a hybrid and worked on advanced tech in the oil patch. Who would have guessed that some of the most advanced technology out there is used by guys who wear safety boots to work? I managed a chunk of one of the world's largest computer networks AS A RESULT OF working in a "lower-tech" industry.
That translated into being a consultant on one of the first projects that de-constructed the @Home alliance. That then translated into doing risk management consulting for a large multinational energy company. And now I am working with a group evaluating computer technology to control down-hole flow within the drill stem. How does that work when I didn't go to school for computer networking, risk management, energy production or business operations?
How come that since the "Bust of 2000" I've had MORE work than in the dot-com heydays AND I make over twice the money? Two reasons as far as I'm concerned...
1) I took control of my own career, instead of allowing some large company to set my fate.
2) I became a registered Professional Engineer, which differentiates me from almost every other computer guy.
My biggest problem now is choosing which project to work on next.
Although I feel for those caught up in the "culling of the herd" (been there, done that), I do believe that the real opportunities aren't in the "pure play". They are in the areas that need to figure out how to leverage high-tech in their favor. People really don't need one-click checkouts, but they DO need electricity and gasoline, and will continue to need these things for a long time.
If you know how to think critically, can prove it, and can show that you add value, there is ALWAYS work to be had.
Converting between $US and $CDN or any other currency is irrelevant. If you are in Canada, you make Canadian dollars. If you are in the US, you make US dollars.
The only people who might be using currency swaps are people who live and work on different sides of an international boarder community, or who are consultants like myself who live in Canada, but bill in $US dollars.
If a sub at Subway costs $6 in Canada, it costs $6 in the US. A sub only costs $9CDN in the US if you are on holidays and are not using your "native" currency for transactions.
My point? The comparison of service costs needs to be done more carefully. The costs of doing business are not level in all markets (employees, rent, competition, etc) and will be reflected in the price the consumer pays. So stop wasting your time arguing $25US vs $40CDN. It's irrelevant.
Lack of official Eudora and Netscape support would be consistent with the fact that Microsoft is the vendor and consultant for the transition, rather than Sun Microsystems+AT&T Canada.
The reason Rogers didn't act faster is because they couldn't act faster. They had outsourced the entire enchilada to @Home, where Shaw at least built their own backbone and CMTS tools. Rogers simply didn't have the staffing. As for investment in @Home Canada, Shaw and Rogers are both willing partners in that venture, and the two are both investors in Terayon.
Apparently everyone forgot the phrase "The devil is in the details."
Verifying the math on the design of a bridge may be routine, but the construction process is less than trivial. Beams must be certified. The concrete must be certified. The welding must be certified. The engineering component is simply not relegated to "making the math work". Mess up at any point and there is the potential for major liability.
That is because most US states are years behind Canadian provinces in their accreditation and portability processes.
The Canadian Council of Professional Engineers has Mutual Recognition Agreements in numerous forms - with ABET, through the Washington Treaty, through compliance with NAFTA mobility requirements.
In any case, most Professional Engineers, while licensed, practice under the Permit-to-Practice of their employer.
Man, anyone who throws fresh-out-of-the-oven code into production without testing it in a pseudo-production environment is looking for a world of pain and deserves everything they get.
You "verbatim-and-work-to-rule" people crack me up...Give the original poster some credit that he's implying moving through the Development-Staging-Production 3-tier model.
You install it in your test environment. You DO have a test environment, don't you?
The answer to these types of issues is really quite simple. An organization that issues standarized computing resources to its employees needs to issue separate resources for specific needs. If your organization does not do this, you need to educate from below.
Developing (and I use the word in broadest of terms) should NEVER occur on a desktop designed for standard office productivity. Develop on a specific system for developing!
It never ceases to amaze me how many technical people blame management for "not getting it". Try presenting your arguments in terms that management understand - productivity gains, cost-benefit analysis, etc. Using logic like "it's just better" doesn't go far.
Guessing as a non-technical manager what technical people want or need is like guessing as a parent what teenagers are thinking. You try your best with the tools and experience at hand, but you are always off the mark.
Pro-active employees are promoted. Silent employees have the same job title for a career. Whiny employees are eventually shown the door.
I wouldn't be surprised if Cancom [www.cancom.ca] didn't have a high-speed two-way satellite broadband service and a signal spot that covers all of North America in the next 24 months...
I'll just say that satellite connections are part of the Canadian cable industry's longer-term strategy to take on the telcos.
Slashdot Mirror
Here's my simple litmus test:
Do you have to go through some sort of formal change request/review process where you document what you will be changing, when it will occur, how long it will take, who will be impacted, what the backout/contigency is, and what the communications will be, then schedule a change and have it approved by the appropriate stakeholders, implement the change, test it, document it and have feedback?
If the answer is yes, then you are involved in a project.
I have worked in a lot of organizations where patching a database and similar functions are considered operational work. Everything is done informally and works great and the sun still rises in the east. I have also worked in organizations where the database in question is the backend to one of the nation's largest point-of-sale systems. Changes aren't as easy to push though.
It's really an issue of how well-tuned an organization is to its resourcing and risk management requirements. I'm finding more and more companies are reaching the limits of what they can accomplish informally. A lot of people are doing project work and are using project management techniques...they're just not aware that they're doing it!
You are either working on a project or you are working on operations. A project has a defined scope, time frame, is temporary and has a unique deliverable. Operations is on-going and repetitive.
If you are tasked with upgrading something, by definition, you are working on a project.
The Project Management Institute literature and methodology is quite clear and applies to all work sectors - IT, engineering, manufacturing, etc... It's a project or it's operations. Never both.
Projects can turn into operations upon completion of particular milestones. Operations can spawn projects for upgrades, etc. There is a relationship and there are dependencies but they are not one and the same.
Daily system maintenance of your database = operations. Patching of your database = project.
This may sound pedantic to IT people for something as "trivial" as a small upgrade, but when you scale it out to massive infrastructure work - be it expanding a data center or building a new refinery - the separation is the only way you can plan and then properly execute the work.
Never under-estimate the power of actually dressing "professionally" either. It is amazing how much more credibility you can have in the eyes of the "management establishment" when you emulate their behaviors. I have had more opportunities come my way "POST-bust" because I decided to bite the bullet and "play the game" through attire and politics. Ditch the jeans, t-shirts and sneakers. I even went so far as to ditch the Dockers and golf shirt. It's dress trousers, dress trousers and a blazer now.
When I informally polled my peers, there was an eery positive correlation between large monthly dry cleaning bills and career progression after the bust.
YMMV but mine's been excellent after making the change.
"Steel-toed boots" industries just aren't viewed as being "sexy", though. A lot of people I know beam when they tell people they write e-commerce code. But who brags about writing code system code that monitors valve pressure for a gas plant?
I went "high-tech" in 1995 when I interned at Nortel. The pace of work was insane . And this was BEFORE any dot-com phenomena. I decided back then that the high-tech was probably not the way to go.
So I did a hybrid and worked on advanced tech in the oil patch. Who would have guessed that some of the most advanced technology out there is used by guys who wear safety boots to work? I managed a chunk of one of the world's largest computer networks AS A RESULT OF working in a "lower-tech" industry.
That translated into being a consultant on one of the first projects that de-constructed the @Home alliance. That then translated into doing risk management consulting for a large multinational energy company. And now I am working with a group evaluating computer technology to control down-hole flow within the drill stem. How does that work when I didn't go to school for computer networking, risk management, energy production or business operations?
How come that since the "Bust of 2000" I've had MORE work than in the dot-com heydays AND I make over twice the money? Two reasons as far as I'm concerned...
1) I took control of my own career, instead of allowing some large company to set my fate.
2) I became a registered Professional Engineer, which differentiates me from almost every other computer guy.
My biggest problem now is choosing which project to work on next.
Although I feel for those caught up in the "culling of the herd" (been there, done that), I do believe that the real opportunities aren't in the "pure play". They are in the areas that need to figure out how to leverage high-tech in their favor. People really don't need one-click checkouts, but they DO need electricity and gasoline, and will continue to need these things for a long time.
If you know how to think critically, can prove it, and can show that you add value, there is ALWAYS work to be had.
So if I forget to wear my glasses, does the movie appear in 1.5-D?
Obviously, the GPL was drafted with traditional software in mind and is not tailored toward embedded systems.
Isn't this what Terry Lambert has been saying for a LONG time? Literally years?
"...during it's own industrialization."
Aaaarrrrggggh! The apostrophe! The apostrophe!
Just a heads-up to everyone...
Converting between $US and $CDN or any other currency is irrelevant. If you are in Canada, you make Canadian dollars. If you are in the US, you make US dollars.
The only people who might be using currency swaps are people who live and work on different sides of an international boarder community, or who are consultants like myself who live in Canada, but bill in $US dollars.
If a sub at Subway costs $6 in Canada, it costs $6 in the US. A sub only costs $9CDN in the US if you are on holidays and are not using your "native" currency for transactions.
My point? The comparison of service costs needs to be done more carefully. The costs of doing business are not level in all markets (employees, rent, competition, etc) and will be reflected in the price the consumer pays. So stop wasting your time arguing $25US vs $40CDN. It's irrelevant.
This is as a result of a new private peer with the University of Alberta that replaces the old wonky Videon peer.
As for upgrades, it's far from random... trust me...
Lack of official Eudora and Netscape support would be consistent with the fact that Microsoft is the vendor and consultant for the transition, rather than Sun Microsystems+AT&T Canada.
:-)
The reason Rogers didn't act faster is because they couldn't act faster. They had outsourced the entire enchilada to @Home, where Shaw at least built their own backbone and CMTS tools. Rogers simply didn't have the staffing. As for investment in @Home Canada, Shaw and Rogers are both willing partners in that venture, and the two are both investors in Terayon.
For the record, I consult to Shaw.
Apparently everyone forgot the phrase "The devil is in the details."
Verifying the math on the design of a bridge may be routine, but the construction process is less than trivial. Beams must be certified. The concrete must be certified. The welding must be certified. The engineering component is simply not relegated to "making the math work". Mess up at any point and there is the potential for major liability.
That is because most US states are years behind Canadian provinces in their accreditation and portability processes.
The Canadian Council of Professional Engineers has Mutual Recognition Agreements in numerous forms - with ABET, through the Washington Treaty, through compliance with NAFTA mobility requirements.
In any case, most Professional Engineers, while licensed, practice under the Permit-to-Practice of their employer.
...in a TEST environment.
Man, anyone who throws fresh-out-of-the-oven code into production without testing it in a pseudo-production environment is looking for a world of pain and deserves everything they get.
You "verbatim-and-work-to-rule" people crack me up...Give the original poster some credit that he's implying moving through the Development-Staging-Production 3-tier model.
If you read the post, you test in a TEST environment.
If your test environment does not allow you admin-level access, I suggest you communicate to your superiors that your test environment should.
You install it in your test environment. You DO have a test environment, don't you? The answer to these types of issues is really quite simple. An organization that issues standarized computing resources to its employees needs to issue separate resources for specific needs. If your organization does not do this, you need to educate from below. Developing (and I use the word in broadest of terms) should NEVER occur on a desktop designed for standard office productivity. Develop on a specific system for developing! It never ceases to amaze me how many technical people blame management for "not getting it". Try presenting your arguments in terms that management understand - productivity gains, cost-benefit analysis, etc. Using logic like "it's just better" doesn't go far. Guessing as a non-technical manager what technical people want or need is like guessing as a parent what teenagers are thinking. You try your best with the tools and experience at hand, but you are always off the mark. Pro-active employees are promoted. Silent employees have the same job title for a career. Whiny employees are eventually shown the door.
I wouldn't be surprised if Cancom [www.cancom.ca] didn't have a high-speed two-way satellite broadband service and a signal spot that covers all of North America in the next 24 months... I'll just say that satellite connections are part of the Canadian cable industry's longer-term strategy to take on the telcos.