Defining Project Scope

I am confused as to why some companies insist on running huge projects that invariably run into trouble with dates, quality and budget.

Here is an example of what I mean. I have worked for several customers who initiated the "SOA Project". These were multi-year, multi-team, multi-budget, multi-million dollar projects. And all of them ran into trouble one way or another just through being too big.

The last time I worked on one of these, my company was brought into to replace another vender who had thrown in the towel. i.e. It was so bad they would rather lose the account and walk away than complete the engagement.

SOA is not a project, it is an architecture pattern. Same thing applies to EDA. These are design principles that are applied to projects.

My thinking is this. A long term strategy should not be encapsulated as one project with a dozen phases. Instead, divide projects up into two categories:

Business Value projects are those that have a clearly defined goal with a concrete return-on-investment. These projects should be accounted for using a budget from a business unit. A couple of examples: Stream-line processes to reduce the average call handle time in a call center. Enable customer self service via the web.

Infrastructure projects involve bringing new technology into the enterprise that will increase the return-on-investment of Business Value projects. These projects should be classed as capital expenditure. For example: Implement a new middle-ware product to enable application integration with a legacy system. Implement an enterprise message system.

It may be that an infrastructure project becomes a pre-requisite for a specific business value project. If this is the case, then we should be clear on the cost accounting as this will dictate whether the infrastructure project is a good investment. For example, will this infrastructure enable other business value projects? Will it enable the IT team to better serve the business?

I look at these things as a Techie. Big problems are easier to solve if they are broken up into smaller problems. Small problems can be solved quickly (and for less cost) while working in the context of a long term strategy. We should maintain an agility that will enable us to change direction, as needed, without discarding that which has already been acheived.

In my view projects should not exceed six months in durarion. Three to four months would be the optimum size. In this way the business receives regular benefit from the IT team. Business propsers, makes more money, more money funds new projects, new projects help the business to prosper.

It boils down to this: Clearly defined goals based entirely on a well understood business value proposition. Small, agile teams working to a limited scope for rapid delivery.

James
Atlanta
April 2009