www.aim.nl

January 21st, 2011: Revamping Public Sector IT Procurement to Favor Success and Small Business by Roger Sessions (ObjectWatch, Inc)

On the website of ObjectWatch the document Revamping CUEC Positon Paper by Roger Sessions can be found.

To be able to write additions/comments on the content of this paper I have created 2 section:

• Summary of the content of Roger's paper, introducing some points from the Dutch/European situation
• My additions/comments to the paper

Summarizing my comments and additions:

AAA

Back to the top

Roger's paper in relation to the Dutch/European situation

To get the content of his paper in perspective I have summarized the content. Roger start by writing about the US IT-market:

Why does the public sector use an IT procurement approach that has a long history of failure? Presumably the reason is that the public sector has yet to be offered a better solution. Given the high failure rates of IT procurement, you would think that the public sector would be desperately trying anything to improve the situation. Yet we don’t see this. So the process continues to be used, failure continues to be the result, and the same big companies that failed to deliver in the past are rewarded with new opportunities for failure in the future.

This is not only relevant to the public sector, but also to the private sector. And these remarks can also be made about IT-procurement on this side of the Atlantic. This way of procuring larg(er) IT-systems (systems of $5M or more) is called the "consolidated procurement" approach. This approach contains the following (fundamental) problems (in the public sector). It:

1. has a poor success rate, which hurts the public sector,
2. costs too much, which hurts the taxpayers, and it
3. excludes small business (as vendors), which hurts the economy

The paper introduces the "partitioned procurement" approach. Partitioned procurement is for procuring large IT systems by partitioning large projects into small (approximately $1M) projects. Partitioned procurement benefits public (and private) sector organizations because they:

1. improve project success rates, which helps the public sector be more effective,
2. reduce project cost, which benefits the taxpayers, and
3. invite small business, which stimulates the economy.

Comparing this the Dutch (and probably European) situation is worse. The main reason is the use of so-called preferred IT-supplier/vendor contracts. Many organisations keep a short (5+) list of IT-vendors who have a contract to exclusively provide certain IT-products en -services for a number of years. Some of the consequences of this approach are:

1. The total IT-market is dominated by a few large IT-vendors. These IT-vendors have preferred supplier contracts with a large number of organisations. For this reason many others have problems to reach the market they target and some already sold their business or went broke. It will be no surprise these IT-vendors are also the organisations who receive the procurement requests Roger mentions.
2. Most freelance IT-professionals and small(er) IT-vendors have a very hard time to get into the market. More and more their products and services can only be delivered through "channels" set up and controlled by these large IT-vendors (as preferred vendor etc.). These channels usually impose a lot of rules on the people and organisations allowed to use them.

Roger's paper calls the practice of bidding all or most of large (IT-)projects to large consulting organizations "upsourcing". The larger the project, the larger the size of the organization that will likely win the bid. The costs of a bid is usually at least 1% of the value of the bid to prepare a fitting bid response. This is also true in the Dutch/European situation. The preferred vendor situation just adds another reason to why only large(r) IT-vendors respond; they get these requests.

Roger's paper identifies a relationship between project size and project success. It states IT project success is judged by the way it meets the following criteria:

1. the project is delivered on budget,
2. the project is delivered on time, and
3. the project delivers the required functionality

The 3rd criterium is also called quality, where projects have to meet some balance of money, time and quality. The paper states the best predictor of project success is project size, where size and success are inversely related: the larger the project, the more likely it will fail. Project size:

• under $1M have a better than 75% chance of success: be on budget and on time while delivering critical functionality (quality).
• of around $2M have a chance of success less than 50%.
• of around $10M have a statistically zero chance of success.

According to the paper consolidated procurement roughly follows the following consecutive steps:

1. The public sector organization creates a long laundry list of requirements, which may consist of 1000's of items,
2. The requirements are sent out as an RFP (Request for Proposal), easily hundreds of pages,
3. A vendor is chosen, where the analysis of vendor solutions to large, complex projects is really difficult, and
4. The project is done and the results are implemented. The IT system(s) may include hundreds of thousands of lines of programming code.

The process of partitioned procurement follows the following steps:

1. Basic functionality: the public sector organization identifies the basic functionality it needs.
2. Project partitioning: this functionality is partitioned into a number of subprojects, none exceeding $1M.
3. The subprojects are bid out independently as well as in parallel: comparable to the given consolidated procurement steps requirements, RFP, vendor selection and project-implementation
4. An integration project is created as overseer/coordinator of the subprojects.
5. As vendors deliver their subproject it is added into the integration framework, extensively tested, and, if it passes, accepted.

The paper identifies the following issues that must be managed for a partitioned procurement approach to work:

1. It is critical the partitioning of the project results in subprojects that have as few interdependencies as possible (loose coupling). Interdependencies are very hard to manage.
2. Project implementation step: the partitioning of the technical architecture must closely follow the project partitioning.

The paper states partitioned procurement has 3 objectives:

1. Improving the success rate of public sector IT-projects is of critical importance, because the current rate of large IT-projects is very low. In the U.S. almost $30 billion dollars of federal funds is invested in large IT-projects “at risk” and they are costing the U.S. economy over $200 billion per year.
2. Reducing the cost of public sector IT-projects. First by not spending money on IT failures. Second because partitioning in small projects causes the total cost to be less than the cost the large project would have made because project complexity is dramatically reduced.
3. Nurturing the local economy. Partitioned procurement leads to downsourcing: the tendency to bid small projects to small vendors. The reasons why small vendors are more likely to win small projects are:
   • the cost to respond to the bid is much lower: $10 thousand for a $1 million project, an amount small vendors can afford.
   • large vendors are less likely to compete because projects under a million dollar are of less interest to them.
   • small vendors can compete with aggressive pricing since their overhead is lower.

Downsourcing is, according to this paper, preferably to upsourcing for many reasons:

1. Small organizations have lower overhead than large organizations. So downsourced budgets mainly go to salaries, not into corporate bureaucracies.
2. Small organizations include historically underutilized businesses. So downsourced projects represent an opportunity to redress past wrongs.
3. Small consulting organizations tend to be local. So downsourcing results in greater stimulation of the local economy.

Public sector procurement, today, is dominated by large businesses. They follow, even depend on their consolidated procurement approach. Therefore it is likely that many of these vendors will oppose the shift to the partitioned procurement approach and they have considerable influence on public sector decision makers. In his paper Roger concludes with the following remarks:

1. We should hope more innovative large vendors will see the value of partitioned procurement because they may be giving up short term profits on large projects but they will be gaining credibility in their ability to deliver. Because success is a problem in the public sector, vendors that are successful will have a great competitive advantage over those that are not.
2. Training is an obstacle. Very few procurement specialists are able to do partitioned procurement, especially the early phase of project partitioning where the larger project is partitioned into smaller projects. This phase requires specific knowledge and skills.
3. Partitioned procurement is still new. Many organizations are uneasy trying new approaches until they have been widely used and proven by others.

Back to the top

My additions/comments to this paper

The point Roger makes in his paper about downsizing IT-projects is indeed crucial to get results. Success is very necessary after so many years of problems and failures. Since the 70's (the years when I got my education in business informatics) there have always been problems and failures in IT-projects. Since Frederick P. Brooks published his famous book "The Mythical Man-Month" in 1975 a lot more IT-projects have been undertaken and his essays are still true. It is sad to see that during these 35 years problems have increased, not decreased. Many information infrastructures today look like Towers of Babel; they are nothing like the flexible, agile and effective infrastructures they may, or ought to be.

I also agree with Roger that complexity of current IT-systems and information- and IT-infrastructures is much to high. To get to the agility, flexibility and effectiveness needed we must create less complex constructs. And, as Roger advocates, we will have to define and work on much smaller projects to be able to really reduce complexity. It is the only way to get to infrastructures that do what IT has promised (and still promises) for such a long time.

My comments on Roger's paper are:

1. It focusses on the U.S. public sector. In my experience the content applies as well to the European public sector and to the private sector.
2. The $1M seems very strict. In my experience this can be a mean cost figure, but not an actual limit. I've seen smaller project go really wrong, and larger project go well. The problem is really in what needs to be done, it's complexity and the required quality. A good rule is to have assignments that result in applications/systems only loosely coupled to other applications/systems. In most instances the maximum price to pay will be the $1M Roger mentions.
5. a
6. Roger's point where partitioning of the technical architecture must closely follow the project partitioning. This is very difficult. Today technical IT-infrastructures are more like a common facility available to enable all kinds of systems delivering all kinds of functionality. It may be Roger uses the term technical architecture for the technical design of the functionality of the system. In this case he may have a point, although it is very difficult to create technical components by grouping and regrouping functionality.
7. It is strange the integration is one of the later steps in the a latter step in the partitioned procurement approach. It seems obvious to create the integration framework during the project partitioning step. Because project partitioning is about creating amounts of work (subprojects) of which the results must fit together. And this is, as I understand, exactly what the integration framework used in the last step will be
8. Roger bases his approach on functionality. This is quite common in IT, although it is not the logical approach
10. information in the center, not functionality.

A number of additional points.

1. Large IT-vendor take pride in the fact they have personnel who know eachother, and, for that reason, know how to work together. This is not the experience. Experience shows the right way to man an IT-project is based on personal competence, and on personal competence alone. I've seen many competent freelancers do real good work together, while I have seen many employees of IT-vendors who were unable to work together up to the end of their respective projects.
2. Accountmanagement overhead.
3. Knowledge of information

Back to the top