Is a CIO or CTO required? Does On-Demand services make sense?

July 26, 2009

The question may sound almost blasphemous, particularly in light of numerous CIOs and CTOs I know who are all looking for a job – nevertheless it is a topic of great interest.  Just to ensure we all have the same understanding, let us define a CIO to be the “architect” who aligns IT to the business ensuring “best value” for the business.  CTO can be defined as the individual who delivers the IT in the most efficient manner possible.  To address the issue of whether a CIO or CTO is required, let us first classify companies based on size.

Ignoring the Fortune 1000, there are 17000+ companies who have between 500 and 10,000 employees.  Let us call these companies Tier-2 companies.  There are probably 200,000+ companies who have more than 100 employees but less than 500.  Let us call these Tier-3 companies.  There are millions of companies smaller, and for the sake of this discussion, let us ignore them (even though they may have IT needs).

The role of both a CIO and CTO is critical in Tier-2 companies, and I am going to assert that these roles should not report to a CFO, but should report directly to the CEO or COO.  It is possible, and likely, that the CTO reports to the CIO and may not even be called a CTO, but that is less important for this discussion.

Tier-3 companies who tend to emulate a Tier-2, generally have a CIO.  I take the position that in such firms, the role of a CIO is greatly exaggerated.  After all, once the IT vision is articulated, the role becomes more of a lower level delivery manager.  My view is that for such firms, an on-demand CIO service is valuable.  Organizations like Office of the CIO, USourceIT all foster on-demand services.  The advantages of the on-demand service are:

  • There are no excessive fixed costs (a small retainer plus on-demand service provides continuity).
  • Different skills are brought to the table based on demand – for example, if the focus is applications, then an applications architect may be better suited for the business.
  • Experience in different verticals and horizontals can help “reuse” the knowledge base – for example, if a firm needed CPG and manufacturing experience, then a CIO who has worked in such environments can offer rapid solutions to align the IT to the business needs.

The key to success for a CIO on-demand service is to provide a trusted value driven turn-key IT capability to Tier-3 companies that enables them to compete, grow and operate effectively.


Estimating the Cost of a IT Project

July 10, 2009

There has been extensive research and development in estimation techniques for software development projects, resulting in a number of formal methods and toolsets.  These models suffer from a variety of weaknesses:

  • The most objective methods, such as Lines of Code, Function Points and Feature Points have the inherent disadvantage that a great deal of design effort is required to get to a point where the estimate can be made, raising the question of “How much is it going to cost to give me an estimate of how much it is going to cost?”
  • In trying to solve this problem by moving the estimate earlier in the project life-cycle, the solution becomes “less known”, and therefore the estimation error rises.  However, the better the estimators understand the business domain, the more reliable the estimate.  If the estimators don’t have a good understanding, the risk is sometimes not in the breadth of the scope, but in the intractability of one or two component – “Nobody told me that this project required curing world hunger!”
  • Team productivity can be highly variable.  If the estimators know who will do the work, they can produce better estimates.  But often the estimators have been given that job because they are very good developers, and they then estimate how long it would take them to do it, and not the mere mortals who will be actually be assigned to the project.
  • Simple estimator bias: optimistic estimators vs. pessimistic estimators.
  • Unstated assumptions, misunderstanding etc.

For the SMB, the relative cost of an IT project can be very significant, and so the necessity to get a good estimate as early as possible is essential, as is the need for a reliable estimate.  There are several things that can be done to achieve both of these, using a set of formal techniques, and taking advantage of the typical limited complexity of SMB projects.

The estimation activity is split into three distinct phases.  These phases should be ideally kept sequential, though some backtracking frequently occurs.  The phases are:

  • Assessment: understanding and sizing.
  • Estimation: turning the size into an estimate of effort
  • Adjustment: reviewing and adjusting the estimate and the risks

In the Assessment Phase estimators analyze the software solution to be estimated. Time pressure typically constrains the estimators’ ability to understand the scope of the task, so a focus on ramping up the estimators’ knowledge of the business problem is essential.  The general approach is to model the solution, to identify the components, and then estimate their size and complexity.  Finally, tasks that are not strictly mapped to components are added.  The essential point is that effort is not estimated at this point – just size and complexity.  Here we introduce the first bias reduction mechanism: the “sizing” should be performed independently by more than one person.  If the SMB has never developed a system like this before, analogical estimation will be a problem.  Looking at similar implemented solutions implemented by competitors can help with understanding the complexity (for example, there are many details in the shopping cart checkout process: change quantities, cancel item, shipping options, calculating shipping costs etc. etc.)

The Estimation Phase consists of turning the output from the assessment phase into effort.  Doing so requires analogical estimation.  For example, “How much time will it take to develop the detailed requirements for, and to design, construct and unit test this shopping checkout module?”  This is both a function of the size and complexity of each task, but also of the developers’ knowledge and experience.  For example, if it developed in house, the in-house team may have a better understanding of the business, but less experience of the technology.

The Adjustment Phase focuses on two aspects of the estimate.  First is the difference between the estimates of individual estimators; second is assessment of risks.  In comparing the estimates of individual estimators it is frequently found that estimates of experienced estimators for the same task can vary widely for any number of reasons, but chief among them are general optimistic/pessimistic bias, and differing assumptions.  So this part of the adjustment activity is a dialog, which is better if mediated by an independent third party to reduce the risk of one estimator dominating the result.  Finally, the “riskiest” activities should be identified, and potentially adjustments made to the estimates.  You can think about this as identifying the unknowns.  For example, does the solution require the purchase and integration of a software component that we have no experience of?  This activity can often uncover risks that need to be mitigated as early as possible in the project, and perhaps before the project is committed.  This could be done earlier in the estimation process, but these risks frequently only get uncovered when estimation differences are discussed and an unstated assumption is unearthed.

Pricing and laying out a timeline are typically the final activities.  At this stage, staffing options sometimes have to be evaluated.  For example, can this project be outsourced, and if it is, what are the assumed offshore rates and the additional project management oversight required.