You need to teach senior managers what the nature of IT projects is, and manage their expectations. Assuming you mean ERP (enterprise resource planning) and not ERM (enterprise risk mgt):
manage stakeholder expectations. If there is momentum to do such project, it's usually because everybody is emotional: we need to do something, we need to act now! You need to render this much more objective, so everybody is still on the same plate one year down the road: clear objectives, how success will be measured...
(as suggested before) clarify why this momentum is there, each stakeholder has her reasons. Formalize these.
these projects tend to cost 3-10 times the license cost of the package: integration, change management
it takes senior mgt commitment: adopt the package, don't adapt the package (customizations are difficult to maintain in the long run: loss of internal knowledge, package upgrades...). But adopting the package means changing the way things are done today.
define the top 15 (or so) processes for the company, and based on these select the best-fit package, then be rigorous on minimizing customizations afterwards (again senior mgt commitment)
You need to teach senior managers what the nature of IT projects is, and manage their expectations.
Assuming you mean ERP (enterprise resource planning) and not ERM (enterprise risk mgt):
* manage stakeholder expectations. If there is momentum to do such project, it's usually because everybody is emotional: we need to do something, we need to act now! You need to render this much more objective, so everybody is still on the same plate one year down the road: clear objectives, how success will be measured...
* (as suggested before) clarify why this momentum is there, each stakeholder has her reasons. Formalize these.
* these projects tend to cost 3-10 times the license cost of the package: integration, change management
* it takes senior mgt commitment: adopt the package, don't adapt the package (customizations are difficult to maintain in the long run: loss of internal knowledge, package upgrades...). But adopting the package means changing the way things are done today.
* define the top 15 (or so) processes for the company, and based on these select the best-fit package, then be rigorous on minimizing customizations afterwards (again senior mgt commitment)
Expect a bumpy ride.
I don't agree with most of the recommendations above. Mixing semantics as happens in a lot of modern programming languages is not good for learning: pointer vs. copy passing as in primitive types vs. objects etc. Floating point vs. integer arithmetic with its automatic conversions...
When learning to program, there are 2 totally different things to learn:
1. clearly structuring a problem
2. the nitty gritty messy stuff: pointers, floating point number issues (rounding), communication with hardware (I/O),
A language like Pascal (if you have a dialect with supports pointer dereferencing (original pascal only made this possible via var-parameter passing) forces one to structure the problem, has very strict semantics and still lets one learn the complexity of pointers and the essential data structures: trees, lists...
Complement it with structured programming and stepwise refinement (Dijkstra) to learn to structure problems.
Once one masters all this, it becomes a piece of cake to write a well-structured C program, and picking up on all the additional nitty gritty stuff that C doesn't hide.
With ADT (abstract data type) based programming in Pascal, one approaches OO programming, and the step to OO-pascal or C++ can then be made.
A great language for learning how to structure a problem is a functional language like Haskell. Strongly typed, lazy evaluation, support for unlimited lists etc. Based on lambda-calculus, hence with strict semantics.
Sorry, but have no book recommendations at hand.
Slashdot Mirror
You need to teach senior managers what the nature of IT projects is, and manage their expectations. Assuming you mean ERP (enterprise resource planning) and not ERM (enterprise risk mgt):
Expect a bumpy ride.
You need to teach senior managers what the nature of IT projects is, and manage their expectations. Assuming you mean ERP (enterprise resource planning) and not ERM (enterprise risk mgt): * manage stakeholder expectations. If there is momentum to do such project, it's usually because everybody is emotional: we need to do something, we need to act now! You need to render this much more objective, so everybody is still on the same plate one year down the road: clear objectives, how success will be measured ...
* (as suggested before) clarify why this momentum is there, each stakeholder has her reasons. Formalize these.
* these projects tend to cost 3-10 times the license cost of the package: integration, change management
* it takes senior mgt commitment: adopt the package, don't adapt the package (customizations are difficult to maintain in the long run: loss of internal knowledge, package upgrades ...). But adopting the package means changing the way things are done today.
* define the top 15 (or so) processes for the company, and based on these select the best-fit package, then be rigorous on minimizing customizations afterwards (again senior mgt commitment)
Expect a bumpy ride.
I don't agree with most of the recommendations above. Mixing semantics as happens in a lot of modern programming languages is not good for learning: pointer vs. copy passing as in primitive types vs. objects etc. Floating point vs. integer arithmetic with its automatic conversions ...
When learning to program, there are 2 totally different things to learn:
1. clearly structuring a problem
2. the nitty gritty messy stuff: pointers, floating point number issues (rounding), communication with hardware (I/O),
A language like Pascal (if you have a dialect with supports pointer dereferencing (original pascal only made this possible via var-parameter passing) forces one to structure the problem, has very strict semantics and still lets one learn the complexity of pointers and the essential data structures: trees, lists ...
Complement it with structured programming and stepwise refinement (Dijkstra) to learn to structure problems.
Once one masters all this, it becomes a piece of cake to write a well-structured C program, and picking up on all the additional nitty gritty stuff that C doesn't hide.
With ADT (abstract data type) based programming in Pascal, one approaches OO programming, and the step to OO-pascal or C++ can then be made.
A great language for learning how to structure a problem is a functional language like Haskell. Strongly typed, lazy evaluation, support for unlimited lists etc. Based on lambda-calculus, hence with strict semantics.
Sorry, but have no book recommendations at hand.