ITIL, COBIT, or DEVOPS. DEVOPS is bottom-up, COBIT and ITIL are top-down.
DEVOPS requires small groups (think startup). COBIT and ITIL require larger groups (think Large or Medium sized businesses). COBIT is free, ITIL is not. ITIL has more "respect" than COBIT. COBIT: http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx ITIL: http://www.itil-officialsite.com/ DEVOPS: http://en.wikipedia.org/wiki/DevOps These are frameworks for "IT Governance", "Change Management", and "IT Service Management", but be aware: it's not enough to do the checklists or hold daily scrums. You must initiate change in your organization on a personal level for this to work, you need a champion, and you need people to want this change. DEVOPS works in smaller groups, of concerned participants. ITIL and COBIT work better in larger groups, with participants of various levels of buy-in. Pick the parts from each that best fit the time, attention, and talent of your organisation, dump the rest, and ship better services. On Thu, Sep 1, 2011 at 12:06 PM, Will Dennis <[email protected]> wrote: > Hi all, > > We are working on becoming more rigorous in following processes in > building/delivering IT services here. As a part of this effort, we are > trying to come up with a lightweight process (i.e, not full-on ITIL, > etc.) to intake / analyze / decide on new requests for (or modifications > to existing) IT services. Here's what we've come up with so far: > > ========== > Proposed Framework > > 1. Identify issue/new service > 2. Business case - risks in doing and risks if not done/done well > 3. How best to solve issue/deliver new service (regardless of current > setup or constraints) > 4. What are the impediments to delivery > 5. How can the impediments be overcome > 6. Resources needed (both direct $ + manpower) > 7. How would the solutions be delivered (in house, outsource, > consultant) > 8. How would the decision be made (by whom, standard material to review) > > 9. Once decision is reached to proceed, how to prioritize with existing > workload > > > The following thoughts are based upon the proposed framework. They are > intended as a straw man for discussion. > > - Initiators of Change > > Change can be initiated from a number of sources, but the most likely > will be one of three sources: > > * An existing Community of Users who see the need to Migrate into an > expansion and/or upgrade of an existing Service Catalog offering. > * A new Emerging Community of Users who wish to adopt new services and > work methods not currently available in the Service Catalog. > * A Visionary who proposes Early Adoption of new services and work > methods not currently available in the Service Catalog. > > - Formulation of Requirements > > * Change requires direction. > * Direction is best provided by the Initiator providing a proposal > including a base set of Requirements. > * Requirements are in effect a set of Goals (or initial goals) > necessary to obtain the desired Service Catalog offerings. > > - Business Case - Risk/Benefit Analysis > > * A Business Decider will review the Requirements and Goals to > determine if the proposed change has Business Value > > - Technical Analysis - Potential Solutions > > * What is required from a purely technical viewpoint to satisfy the > Requirements and meet the Goals? > > - Technical Analysis - Costs and Resources > > * What is required to implement each Proposed Solution? > > * There may need to be multiple Proposed Solutions and/or multiple > passes through the Technical Analysis phases to obtain the most > desirable but achievable solution. > > - Business Case - Cost/Benefit Analysis > > * A Business Finance Decider will review the Proposed Solutions to > determine if they are cost effective in achieving the Requirements and > Goals > > - Scheduling and Acceptance Criteria Phase > > - Implementation Phase > > - Testing and Acceptance Phase > > - Roll-Out Phase > > - Feedback and Iterative Improvement Phase > > ========== > > I'm thinking this sort of process may have already been invented, and is > available "out there" already... We don't want a very complex process > (we are a SME) but we do want to be able to have a good framework to be > able to get good enough data to make a decision. Anyone have any > resources or thoughts about this? > > Thanks! > Will > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
