As
business technology managers we are constantly challenged by a need to
support a broad spectrum of information technologies within our
organizations. Now more so with the establishment of the amalgamation of
services that now comprises the cloud computing ecosystem.
The pure purpose of these technologies is to improve end-users needs as these systems evolve. Managers are in turn constantly challenged in an effort to present and optimize a single infrastructure to support the many different requirements within organizations.
We are blitzed daily with newer and allegedly better means to choose, implement, hone, improve, migrate or upgrade our technologies, via web-casts, product pitches, conferences, email blasts etc.
Some points to consider: are some of these marketing pitches for "change/upgrades" really necessary or inherently imperative to ensuring that operations run lean, effective as well as within compliance and budgetary requirements? The only fact that I subscribe to is, systems are dynamic in nature.
As managers, we need to evaluate the most appropriate of practices that will benefit our organization. These should include national and international standards, business goals, objectives and needs; budgetary requirements, external & internal threats, internal operational requirements. After which we should compile a decision matrix and rank requirements on importance or impact on functionality across the enterprise, which should align on-going IT operations with business requirements...and then choose to effect change ...or not.
Factors that should be considered are the intervals in time that we finalize IT operational decisions e.g. at the start of a project or in the instance where we encounter some event which changes our IT functions in a manner that warrants a re-evaluation of technologies.
Personally when I am commissioned to lead a project, I walk into our brainstorming armed with my well-worn Ishikawa (fishbone) mind-set.
Why?, well as most project managers will attest to, the requirements in week one never matches the requirements say in week six of a twelve week project. For me a good rule of thumb is to have an appropriate grasp of the end result required by senior management /client and draft a reverse process with my team to match the initial requirement. This leaves us ample branches for change in requirements from senior management or a client (as expected) and by extension, gives us some latitude with time and budget management.
I agree with my peers that, in order to ensure the successful operation of any IT infrastructure a solid framework must be in place. There are several standards that we can draw from during our planning implementation and control stages, some of which are :
ISO - 27001:2005 & BS 17799 - ISO 27002:2005
CoBIT - Control Objectives for Information and Related Technology
ITIL - IT Infrastructure Library
CMMi - Capability Maturity Model Integration
The importance of ITIL is well documented, especially given its place with respect to ISO 27001 in a sense, however I do believe that one methodology can draw on the other in certain instances.
The pure purpose of these technologies is to improve end-users needs as these systems evolve. Managers are in turn constantly challenged in an effort to present and optimize a single infrastructure to support the many different requirements within organizations.
We are blitzed daily with newer and allegedly better means to choose, implement, hone, improve, migrate or upgrade our technologies, via web-casts, product pitches, conferences, email blasts etc.
Some points to consider: are some of these marketing pitches for "change/upgrades" really necessary or inherently imperative to ensuring that operations run lean, effective as well as within compliance and budgetary requirements? The only fact that I subscribe to is, systems are dynamic in nature.
As managers, we need to evaluate the most appropriate of practices that will benefit our organization. These should include national and international standards, business goals, objectives and needs; budgetary requirements, external & internal threats, internal operational requirements. After which we should compile a decision matrix and rank requirements on importance or impact on functionality across the enterprise, which should align on-going IT operations with business requirements...and then choose to effect change ...or not.
Factors that should be considered are the intervals in time that we finalize IT operational decisions e.g. at the start of a project or in the instance where we encounter some event which changes our IT functions in a manner that warrants a re-evaluation of technologies.
Personally when I am commissioned to lead a project, I walk into our brainstorming armed with my well-worn Ishikawa (fishbone) mind-set.
Why?, well as most project managers will attest to, the requirements in week one never matches the requirements say in week six of a twelve week project. For me a good rule of thumb is to have an appropriate grasp of the end result required by senior management /client and draft a reverse process with my team to match the initial requirement. This leaves us ample branches for change in requirements from senior management or a client (as expected) and by extension, gives us some latitude with time and budget management.
I agree with my peers that, in order to ensure the successful operation of any IT infrastructure a solid framework must be in place. There are several standards that we can draw from during our planning implementation and control stages, some of which are :
ISO - 27001:2005 & BS 17799 - ISO 27002:2005
CoBIT - Control Objectives for Information and Related Technology
ITIL - IT Infrastructure Library
CMMi - Capability Maturity Model Integration
The importance of ITIL is well documented, especially given its place with respect to ISO 27001 in a sense, however I do believe that one methodology can draw on the other in certain instances.
No comments:
Post a Comment