Who “owns” IT Projects?
I said I would post on this topic, but it is really more of a history piece. Here is an excerpt from my book “Cascade”:
CHAPTER FOUR– Pick the Right Projects for the Business
…
Early computer projects were run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well; so, the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.
So, projects proceeded into more complicated areas of the business, and they started to break down, some failed, and now Management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable); and how did they all get started anyway?
(… because the business looks around and sees) a lot of current projects being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.
(This has to change to get these projects under control, including a new awareness…)
That awareness should include:
1) A recognition that IT projects do not belong to IT, they belong to the Enterprise as a whole, even if various non-IT parts of the Enterprise are assigned responsibility for some sub-set of projects.
2) An understanding that projects still originate the same way: a problem, challenge or opportunity is identified, or a new idea to improve the business is suggested. Sources for suggestions range from front-line staff to objectives stated in the Enterprise’s Strategic Plan.
3) The realization that dozens or more project ideas may be in play at any one time, but the average Enterprise does not have the resources to do them all; it must pick from the candidates which projects will get to proceed, and it must continue to do this as current projects are completed and resources are freed up.
It all boils down to best use of limited resources. The term that has emerged to describe all this is Project Governance. The most common analogy used to describe this governance is “gating”; a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, the rest wait for another chance when more resources are available, or are eventually dropped from consideration.
It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development (commonly called Construction). As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure as described above. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the Enterprise.
The key question then is: what projects does the Enterprise consider to be most valuable? (That’s for next time.)
See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf
Friday, February 25, 2011
Wednesday, February 23, 2011
Maybe it is time to define "customer" in IT Projects
IT projects and methods seem to big on the word "customer" these days...
Common definitions of:
customer - one that purchases a commodity or service
purchases - the acquisition of something for payment
So let me propose this definition: unless you are selling software as a product for real money, your IT project does not have any customers.
I have spent my career working on IT projects for companies that need systems to run their business more effectively/profitably.I have worked with many a sponsor, and many business people who will use the systems, but none of them paid me directly for doing so; we all worked for the same organization, with job titles and salaries to go with those titles.
Most of these organizations used some kind of budgeting/cost allocation to align the cost of the systems to the revenues of the parts of the company that would use the systems. However, this is not purchasing, it is management.
However, some of these organizations used a definition of an internal form of exchange - 'gray money' or better known as "funny money" - to not only allocate cost but to measure managers' effectiveness and often their bonuses. The main company I saw this at is no longer an independent organization, as it fell on hard times and was acquired/assimilated by a more successful company. One of the reasons was management choices like the following:
Two similar business units (same product, different market) needed new systems. One (Unit A) got a head start and developed a functional system. The other (Unit B) saw the system and said "we could use that too". Unit A asked for payment in funny money of half the cost of development. Unit B balked, and spent a lesser amount of real money to buy a package, because that looked better on Unit B's cost reporting... real money spent that should not have been necessary.
So, within an organization, there are no customers and there are no purchases; acting like there is can be detrimental to the organization as a whole.
But we are talking about customers of IT projects, surely that can't be the same; yes it is. Call someone a customer and they will act in their own best interest, however that is measured, and with disregard for the success of the whole organization.
IT projects should not have buyers and sellers; they should have teams of business and IT people working together to reach a common goal. So you see, the definition of "customer" in an IT project is that there isn't one.
Common definitions of:
customer - one that purchases a commodity or service
purchases - the acquisition of something for payment
So let me propose this definition: unless you are selling software as a product for real money, your IT project does not have any customers.
I have spent my career working on IT projects for companies that need systems to run their business more effectively/profitably.I have worked with many a sponsor, and many business people who will use the systems, but none of them paid me directly for doing so; we all worked for the same organization, with job titles and salaries to go with those titles.
Most of these organizations used some kind of budgeting/cost allocation to align the cost of the systems to the revenues of the parts of the company that would use the systems. However, this is not purchasing, it is management.
However, some of these organizations used a definition of an internal form of exchange - 'gray money' or better known as "funny money" - to not only allocate cost but to measure managers' effectiveness and often their bonuses. The main company I saw this at is no longer an independent organization, as it fell on hard times and was acquired/assimilated by a more successful company. One of the reasons was management choices like the following:
Two similar business units (same product, different market) needed new systems. One (Unit A) got a head start and developed a functional system. The other (Unit B) saw the system and said "we could use that too". Unit A asked for payment in funny money of half the cost of development. Unit B balked, and spent a lesser amount of real money to buy a package, because that looked better on Unit B's cost reporting... real money spent that should not have been necessary.
So, within an organization, there are no customers and there are no purchases; acting like there is can be detrimental to the organization as a whole.
But we are talking about customers of IT projects, surely that can't be the same; yes it is. Call someone a customer and they will act in their own best interest, however that is measured, and with disregard for the success of the whole organization.
IT projects should not have buyers and sellers; they should have teams of business and IT people working together to reach a common goal. So you see, the definition of "customer" in an IT project is that there isn't one.
Subscribe to:
Posts (Atom)