jump to navigation

Profit Centers vs. Cost Centers September 12, 2005

Posted by Coolguy in Service Delivery.
Tags: ,
1 comment so far
  • In business, an operating unit is either making money or it’s detracting from a company’s profits. In simple terms, it’s the difference between a profit center and a cost center.
  • Conceptually, a business unit is considered a profit center when “it’s set up as a small business — it has its own revenue and profit targets,”
  • On the flip side, a company unit such as the human resources department doesn’t earn revenue or turn a profit. Its objective is to hire, train and support the company’s employees, and there’s a cost to the company to run the unit. As such, human resources is typically viewed as a cost center.
  • IT departments traditionally were set up as cost centers. An IT organization would charge back costs to a business unit. For example, IT would charge a commercial loan division of a bank for monthly transaction processing costs or mainframe use costs. But it wouldn’t bring in a profit because the division would be charged at cost. In some cases, those costs may be absorbed by the company or as part of a business unit’s overhead.
  • If an IT department is a cost center, “the rest of the business views you as a burden”
  • However, it’s common for IT organizations to be set up as cost centers in highly-regulated industries, such as financial services or electric utilities, “to show regulators where the costs are” by charging IT costs to individual business units
  • Other companies, such as The Hartford Financial Services Group in Hartford, Conn., have elected to set up their IT organizations as profit centers with a goal of generating zero profit
  • Some CIOs think their IT departments should remain cost centers. “Our core competency [in IT] is to help our company build aircraft structures, not to code [enterprise resource planning] systems, so I could not see us as a profit center”

Software Methodologies August 1, 2005

Posted by Coolguy in Software Development.
Tags:
add a comment

A software methodology is the set of rules and practices used to create computer programs.

Heavyweight methodology:

  • A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly.
  • Heavyweight methodologies try to plan out a large part of a project in great detail over a long span of time.
  • Project managers tend to want to predict every conceivable project milestone because they want to see every technical detail.
  • This leads managers to demand all sorts of specifications, plans, reports, checkpoints, and schedules.
  • But this works well only until things start changing; therefore, project managers who use heavyweight methodologies will resist change.
  • The heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment.
  • An example of a “heavyweight” process is the Rational Unified Process.
  • Project team larger than 10-20 people and working in multiple locations may be a good candidate for a heavyweight methodology
  • Heavyweight methodologies can be the better choice when you have multiple teams working at different locations and you need tighter control to formalize key parts of the project.

Lightweight methodology:

  • A lightweight (or Agile) methodology has only a few rules and practices or ones which are easy to follow.
  • Several methodologies fit under this agile banner:
    • XP (Extreme Programming)
    • Cockburn’s Crystal Family
    • Open Source
    • Highsmith’s Adaptive Software Development
    • Scrum
    • Feature Driven Development
    • DSDM (Dynamic System Development Method

Middleweight method:

  • Halfway between XP and RUP
  • KobrA Method that defines a framework of specifically-defined KobrA Komponents, which are components described by a combination of UML class and object diagrams and textual documents
  • Known as Component-Based Product Line Engineering, the KobrA method is touted as being incremental and scaleable because it supports a higher-level, UML-based representation of components and a product-line approach to their application and deployment

Choosing a Methodology:

The essential points you’ll need to consider when selecting a methodology are:

  • Budget
  • Team size
  • Project criticality
  • Technology used
  • Documentation
  • Training
  • Best practices/lessons learned
  • Tools and techniques
  • Existing processes
  • Software