Views

Enterprise:Management:ITmanagement

Contents

[edit]

Navigation

Home · Main Page · Enterprise  ·


[edit]

Related categories



[edit]

About the "IT Management" page

This page aims to offer some useful resources for the management professionals in IT development or operations. The issues in the field of IT management practice are very specific to the IT industry and for this reason presented separately. We apologize for that little information, this page is still under construction. Please stay tuned.

Image:Construction_worker.gif

[edit]

IS-IT management resources

Examines the core ingredients of people, process and tools and their impact upon success in information technology projects.
  • Barry Boehm's and Kevin Sullivan's article on "Software Economics"
  • Process Improvements for Software Quality and Reliability [2] local copy
  • IT Management frameworks [3]
  • TickIT – Software Quality Management [4]
  • Six Sigma – Quality and Process Improvement [5]
  • IT Balanced Scorecard [6]
  • AS 8015-2005 : Australian standard for IT Governance [7]
  • CobiT - Control Objectives for Information and related Technology [8]
  • M_o_R – Management of Risk [9]
  • PRINCE2 - Projects in Controlled Environments [10]
  • PRINCE2 - usefulness for MSPs [11]
  • Managing compliance: An overview of IT frameworks [12]
  • OPM3 - Organisational Project Management Maturity Model [13]
  • The Standish Group "chaos" report analyzing failed IT projects
  • The Project Smart Project Management knowledge base


[edit]

Ten Step methodology

Although theoretically suitable for any kind of project, the TenStep methodology is geared toward management of Information Technology projects. Similar as approach and broadly based on the PMBOK principles, the TenStep methodology is much less abstract and offers best practices and support materials. The following resources are available:
  • The "TenStep Project Management eBook" process library [14]
  • Quality assurance practices library [15]
  • Process flowcharts library [16]
  • Various templates library [17]


[edit]

Construx Software Development Best Practices

The Construx CxOne [18] methodology is based in great part on Steve McConnel's [19] works and on real-life project experience. The methodology is broadly based on the PMBOK principles but puts emphasis on real-world deliverables rather than theoretical process details. This is based on Steve McConnell’s Software Project Survival Guide (SPSG). In the same way as PMBOK does, the Construx CxOne methodology defines knowledge areas and corresponding practices (rather than PMBOK processes):

Construx CxOne knowledge areas and practices
Knowledge Area Practice
Configuration Management Change Control Board
Construction Daily Build and Smoke Test
Design Designing for Change Throwaway Prototyping
Engineering Management Miniature Milestones Top 10 Risk List Outsourcing
Process Lifecycle Model Selection Staged Delivery Lifecycle Evolutionary Delivery Lifecycle Evolutionary Prototyping Lifecycle
Quality Inspections
Requirements Joint Application Development Requirements Scrubbing
Testing Construction Testing


[edit]

Personal Software Process (PSP) and Team Software Process (TSP)

The PSP and TSP are terms coined by Watts S. Humphrey [20], one of the main contributors to the evolution of the Capability Maturity Model (CMM). He realized that, while CMM's focus was on the organization's processes, its success had to start at the "micro"-level. The first issue to address was the behavior of the software engineers themselves and of the teams they were part of. At the same time it was realized that the CMM model was too heavy to be adopted by Small and Medium Enterprises (SME) who were performing Software Engineering activities. The PSP and TSP were aimed at addressing some basic Software Engineering process improvement opportunities in such SMEs. In a nutshell the PSP and the TSP address the need for Disciplined Software Engineering and simple but rigurous quality assurance and process metrics gathering as part of the engineering practice.

Good resources about PSP and TSP are available:
  • The Software Engineering Information Repository at SEI [21]
  • The TSP/PSP home page at SEI [22] and the PSP Body of Knowledge [23]
  • PSP and TSP resources, templates and tools [24]
  • The Software Process Dashboard Project [25] for a free PSP/TSP support toolset.
  • Software Engineering resources at the USAF Software Technology Support Center - Introduction to PSP and TSP [26]


[edit]

The Capability Maturity Model Integration (CMMI)

The Capability Maturity Model Integration (CMMI) is a process improvement methodology that can be used at all levels of an organization. The CMMI is complemented by the Standard CMMI Appraisal Method for Process Improvement (SCAMPI). Organizations that embark on the process improvement following the CMMI methodology can formally conduct appraisals by a SEI-certified SCAMPI Lead Appraiser. The CMMI inherits from the methodology put forward by the Capability Maturity Model (CMM) that was geared toward software engineering processes. For organizations that want to migrate from CMM to CMMI there os a mapping available, for the staged model [27]. The CMMI expands the Capability Maturity models to other engineering disciplines, like Systems Engineering,Integrated Product and Process Development and Supplier Sourcing. Another enhancement to the original CMM, which was supporting only a 5-level "Staged Model", is the adition of the "Continuous Model". The introduction of the Continuous model has a number of benefits for the organizations seeking to introduce the CMMI-based process improvement framework:
  • Facilitates the mapping of CMMI practices to ISO requirements [28] local copy.
  • Facilitates the migration to CMMI of organizations that implemented the EIA-731 "Systems Engineering Capability Model"
  • Facilitates the synergy with the ISO/IEC 15504 (SPICE) [29] [30] SPI methodology.
  • Allow organizations to select the improvement targets in the process areas and practices that better suit their needs.


The CMMI staged model has the following components
  • Maturity levels, quantifying the predictability of an organization's performance, five in all and organized in an "onion"-like hierarchy, each level with its own "generic goals" and "generic practices":
    • Initial, whose processes are usually ad-hoc and chaotic, where firefighting and "heroism" can save the day.
    • Managed, where requirements and processes are managed, on a per-project basis, according to documented plans.
    • Defined, where processes are well defined and understood and documented in internal standards and procedures.
    • Quantitatively managed, where process-control measures are in place, based on quantitatively-measured process parameters.
    • Optimizing, where process-improvement processes are in place, based on process control measures and understanding of root-causes of process variation.
  • Process areas are sets of inter-related practices in an area of improvement
  • Generic and Specific Goals that address the "what has to be implemented" to satisfy the requirement of a maturity level and specific process areas.
  • Generic and specific Practices, that are activities which have to be performed in order for the associated goals to be achieved.
  • Common Features are groupings of the generic practices


The CMMI continuous model is in a sense similar to the staged model with the following differences
  • The "maturity levels" are replaced by "capability levels", with the addition of a level 0 "Incomplete"
  • The capability levels consist of related generic and specific practices for a process area
  • There are 2 types of practices : "base", corresponding to a capability level of 1, and "advanced", for capability levels of 2 and above.
  • The organization can simultaneously try to improve process areas that belong to multiple capability levels if that better suits their needs.
  • The maturity levels remain and they assess the capability levels attained in each process area.


Most resources related to CMMI can be found here and here.

Some CMMI resources:

[edit]

Cleanroom Software Engineering

The Cleanroom Software Engineering, both an engineering methodology and management process, aims at delivering zero-defect, certified reliability products through:
  • Application of the SWEBOK Software Engineering methodology
  • Rigorous requirements gathering and analysis
  • Incremental development using small-teams responsible for specification, development and certification
  • Formal verification of the design against the specification
  • Extensive testing based on use scenarios, automatic test vectors and statistical defect control


More resources on Cleanroom Software Engineering
  • Introduction to Cleanroom Software Engineering [31]
  • Cleanroom Software Engineering Reference Model [32]
  • Process Models in Software Engineering [33]
  • Cleanroom Software Engineering tutorial from University of Calgary local copy


[edit]

Release Management

Release management is the process of coordinating and managing the activities by which all releases to a live environment are planned, tested, and implemented. Release management ensures that releases are implemented in the live environment as quickly as possible to meet business requirements, yet in an extremely controlled and systematic process that limits impacts to the existing environment. The release management process is often neglected, due to limited resources and time to spend on operations process and because of the market presure. If the release management process is overlooked and not viewed as "mission critical" things can sometimes go terribly wrong. With an informal release management process, characterized by unclear roles and responsibilities and by unmanaged build processes, companies can experience problems like lengthy release cycles and product downtime, all leading to customer insatisfaction. The goal of release management is to insure packaging of system changes for deployment in the production environment while maintaining the integrity, functionality and availability of the existing service or product.

Objectives of a release management process include:
  • Develop a release plan that documents tested procedures for implementing changes to the live environment.
  • Provide timely notification to stakeholders for release information, over proper communication channels·
  • Ensure the secure flow of changes to software through a Definitive Software Library (DSL) storing master copies of all components.
  • Implement user acceptance testing and pilot staging with validation of rollout and back-out procedures.
  • Guarantee successful mplementation of the release in the live environment while maintaining system integrity, functionality and availability.


The release management [34] process closely interacts with other disciplines in the organization:

Specific roles in the Release Management process:
  • Release Manager
    • Responsible for facilitation & communication to insure problem-free & timely delivery of releases.
    • Has final authority & accountability for release implementation
    • Release process architect, responsible for efficient implementation of processes impacting the release management.
    • Coordinates release packaging and deployment activities
    • Coordinates resources involved in the release management process
    • Manages issues, risks, feature- and change requests, with respect to planned or deployed releases

  • Release Engineer
    • Tracks changes of release components in the version-control system
    • Responsible for applying the release versioning scheme and tracking it back to the components versioning
    • Responsible for the build system, tools and procedures
    • Responsible for creating and managing the "Release Note" documents
    • Responsible for the integration, versioning and tracking of release components from contributing groups


Release management and engineering practices insure that the builds and releases are consistent, reproducible and verifiabile. Each release has to be documented in a "Release Notes" document, to be distributed to the stakeholders in the release process (e.g. clients). In its simplest form, a "Release Notes" document has to address:
  • Introductory matters (purpose, glossary, audience, history of changes, references, disclaimer, copyrights, etc)
  • Basic features (concise description of product architecture, functionality, dependencies and limitations)
  • Configuration and customization (quick overview of installation instructions, requirements, parameters)
  • New features and enhancements (added in this release, ideally tracked down to RFE records)
  • Resolved issues (ideally tracked down to closed tickets and issue reports)
  • Known issues (ideally tracked down to open tickets & issue reports, workarounds if available)
  • Verification instructions (usually provided to the QA group, describes setups for targeted testing of issues & functionality)
  • Appendices (like detailed instructions on how to workaround a known issue)


Release management resources

[edit]

Agile Project Management

The Agile methodologies is quite popular today in the small-scale software development community. The Agile movement [36] can probably trace its ideologic roots back to Eric S. Raymond's article The Cathedral and the Bazaar. In a nutshell, most agile methods reduce technical risk by iterative software development, using timeboxing on cycles no longer than a month. Tom Gilb's Evolutionary Project Management (EVO) methodology also represents a theoretical base for the Agile movement. Each iteration ("sprint" in SCRUM terminology) is a complete cycle, with development, verification and release. At the origins of the Agile movement is the Agile Manifesto published in 2001. The idea of "lightweight" development processes appeared by mid-90's and methodologies like SCRUM or Extreme Programming (XP) were proposed before the "Agile" term was coined. Each Agile methodology has built its own jargon, metaphors and communication but basically the Extreme Programming and SCRUM are today's dominant agile methodologies, based on iterative processes, team-work, efficient communication and thorough testing. There is no consensus on the actual business value of introducing agile processes in the enterprise. There are known but disputed claims of projects having been saved due to an Agile approach. There also attempts to "sell" other methodologies (e.g. Rational RUP) as Agile approaches to development or compelling counter-arguments for the Agile methodology. The Rapid Application Development (RAD) methodology, can be considered related to the Agile methodology. It is characterized by prototyping, iterative development and timeboxing of each iteration cycle. The Joint Application Development (JAD) methodology, born at IBM as a joint-venture between users and developers, is a precursor and close relative of Rapid Application Development.

Some Agile references: Beyond the success stories with the Agile methods, the thing to keep in mind is that they are not universally applicable, especially for large projects constrained by time, budgets, process requirements and external dependencies. The Agile methodology seems to be appropriate for small software development projects but may become painful if applied in the wrong circumstances.

[edit]

Tiger teams

The term was first coined in the military with respect to a specialized, commando-style team, whose job was to test the strength of security measures by attempting to penetrate the security perimeters of "friendly" premises. The term is currently being used in the security practice, with respect to specialized hacker-like "black-hat/white-hat" teams that are validating the strength of the information security policies, by trying to penetrate firewalls, access lists and take control of resources. In the project-management practice the term is used to describe an autonomous, temporary, high-capability team, usually reporting to the highest echelon in the organization, responsible of providing a rapid-response to an urgent, special situation. In practice, in the Information Technology industry, tiger teams are called-in to solve in a timely manner thorny, unexpected technical issues that usually would amount to firefighting situations. Once the issue is solved, the tiger-team is dismantled.

Some resources on tiger-team approach

[edit]

Mounting an IT business case



[edit]

The DMR Fujitsu P+/Macroscope methodology

The DMR Macroscope system delivery process describes five phases: Opportunity Evaluation, Preliminary Analysis, System Architecture, Release Design and Construction, and Implementation. DMR Macroscope is a trademark of DMR and Fujitsu. The DMR Macroscope also describes 3 system delivery lifecycles: a Generic Development path, an Accelerated Development path, and a Package Solution Delivery path. Fujitsu "Solutions-oriented Development Engineering Methodology 21" (SDEM21) adds a lifecycle for component-based development called ComponentAA. The Software Process Engineering Metamodel (SPEM) metamodel, published by the Object Management Group (OMG) is used to describe a concrete software development process or a family of related software development processes. Several methodologies, like CMMI, RUP or DMR/Fujitsu P+ Macroscope can be described through the SPEM metamodel and tools exist [49] [50] for automating the process definition, execution and follow-up.

Resources

[edit]

IS-IT operations best practices

The management of IT operations especially when dealing with mission-critical environments in industry sectors like banking, government affairs or telecom, raises specific challenges with respect to the management methodology. To answer to these challenges a few methodologies, mostly based on the ITIL forbearer, have sprung.

[edit]

Information Technology Infrastructure Library (ITIL)

The names ITIL and IT Infrastructure Library are Registered Trade Marks of the United Kingdom's Office of Government Commerce (OGC). The library, currently at its version 2, consists in a series of books covering the core areas of IT Management with procedures intended to support efficiency and quality in IT operations. The IT Service Management elements of ITIL are also covered by the ISO/IEC 20000 standards. The "The Visible OPS Handbook: Implementing ITIL in 4 Practical and Auditable Steps" from ITPI retains from ITIL those practices supposed to maximize the ROI.

There are eight "base" ITIL books followed a ninth, more recent one, and the disciplines they cover are:
  • The IT Service Management sets
1. Service Delivery
2. Service Support
  • Operational guidance set
3. ICT Infrastructure Management
4. Security Management
5. The Business Perspective
6. Application Management
7. Software Asset Management
  • Guidance on implementation of Service Management
8. Planning to Implement Service Management
  • Guidelines for smaller IT units
9. ITIL Small-Scale Implementation


ITIL resources

[edit]

Service Level Management

The Service Level Management is an essential process area of the "Service Delivery" ITIL discipline, providing for continual identification, monitoring and review of the levels of IT services specified in the Service Level Agreements (SLAs).

References:
  • Best Practices For Service-Level Management - a Forrester REsearch whitepaper [52]
  • Service Level Management - a WebProForum tutorial
  • Service Level Management – A Process, Not A Document - a guide to SLM from PinkElephant
  • The SLA toolkit
  • Controlling and Monitoring the Service Level Management Process [53]
  • ISO/IEC 20000 – ITSM Standard [54]
  • IT Service CMM – IT Service Capability Maturity Model [55]
  • eSCM-SP v2: eSourcing Capability Model for Service Providers, Version 2 [56]
  • IT Service Management learning community


[edit]

Software as a Service (SaaS)

First pioneered by Microsoft, the Software as a Service (SaaS) business model is about providing online, as a lease, those software-based services that normally would stem from locally-installed licensed copies of software packages. This new delivery model enable companies to cut costs by no longer paying for owning the software itself and for maintaining its availability (e.g. maintenance, scalability, disaster recovery, etc.). Instead companies pay only for using it, while a software-services provider owns the licenses and is responsible for maintaining the availability of the services for its customers.

References:
  • Software as a Service (SaaS) - a primer from Microsoft
  • A field guide to Software as a Service - a InfoWorld review
  • What does SaaS mean for Business Intelligence [57] - an article on the alignement on software vendors to the SaaS model
  • AppExchange - a Web marketplace for on-demand SaaS applications for salesforce.com's Apex platform [58]
  • The future of IT Infrastructure Management - Leveraging the Power of SaaS [59]


[edit]

Microsoft Operations Framework (MOF)

The Microsoft Operations Framework (MOF) [60] [61] is based on the IT Infrastructure Library (ITIL) [62] standard. The way the MOF provide guidance for IT operations is through white papers,operations guides, assessment tools, best practices, case studies, templates, support tools, courseware, and services. The guides address the issues related to the main ingredients of the IT operations, namely people, processes, technology and management practice.

The main guides provided with MOF are:
  • Operations Architecture Guide
  • Reference Architecture Guide


MOF evolved following the lessons learned through the application of the Microsoft Solutions Framework. The basic components
  • Process Model for Operations
  • Risk Model for Operations
  • Team Model for Operations


A good collection of MOF resources is available here

[edit]

Microsoft Solution Framework (MSF)

The Microsoft Solution Framework (MSF), now version 4.0) [63] is a collection of Software Engineering best practices, processes and principles addressing the whole Software Development Life Cycle (SDLC). The framework is not limited to Microsoft-specific practices and technologies, although the main emphasis is on those. The MSF defines base principles, a team model and an SDLC model. There are two sets of SDLC best practices:
  • MSF for Agile Software Development (MSF4ASD)
  • MSF for Capability Maturity Model Integration Process Improvement (MSF4CMMI)


The MSF is centered around an iterative cycle with short iteration periods, and support for its processes and practices are available in the Microsoft .NET and Visual Studio development suites. An interesting presentation on the topic [64] local copy

[edit]

Application Services Library [65]

ASL and BiSL are best-practices libraries, closely related to ITIL and CMM, but complementing those at the level of Application Management, i.e. Application Design and Development and Functional Management. This compensates for the fact that ITIL focuses mainly on IS-IT Infrastructure Management. Unfortunately the ASL and BiSL libraries are available mainly in Dutch.

[edit]

Resources for the IT manager

Here are a few resources dealing with various issues, from firefighting to customer relations and knowledge management.

[edit]

Reading on IT management topics



[edit]

Resources and links of general interest

Retrieved from "http://www.mindtrek.dnsalias.net/components/com_mambowiki/index.php/Enterprise:Management:ITmanagement"