Vellenga's Law Of Project Redefinition
Back in the 1980’s I worked at GTE Laboratories in Waltham, MA. This was a research arm of GTE (originally, of course, General Telephone & Electronics), which funded long-term projects at the Laboratories on a yearly basis to benefit the other divisions.
It was a very cool place to work, with a lot of extremely knowledgeable engineers. It was like being in an academic environment for an industrial salary. And the prospect of working consistently on one project for an extended period of time was exciting!
But within a couple of years I noticed that projects frequently got either canceled or significantly modified. Often this happened at yearly review time, when representatives of the other divisions assembled in Waltham to see how things were going. But it could also happen because of changes in the marketplace — for example, because some EDA (Electronic Design Automation) tools had become commercially available, and they already did what we were designing our new tool to do. The regularity with which this happened led me to formulate
Vellenga’s Law of Project Redefinition
This “law” has turned out to hold in non-research environments as well — at least in the world of software development.
In a public corporation, for example, the funding cycle is quarterly, because that’s how often management has to report results to the stockholders (and to their own board of directors). Most releases of new functionality and/or performance in such companies are planned to take between six months and a year and a half, which is, of course, significantly longer than three months. But then a large customer weighs in with a special request, or the competition releases a new feature that we just have to match as soon as possible, or management designs a new licensing strategy, or whatever — or our software project just isn’t earning the kind of margins that the company wants, and our team gets reassigned. So as a developer, yes, I constantly need to be able to change my plans and my schedule at a frequency of every three months of so.
(I remember a time when we had the next release ready to go after nine months of development, including sign-off from Product Validation, and marketing announced that we’d have to change the licensing model — and release number — before sending the software out the door. That was a delay, though, of only about two weeks.)
Start-ups, in fact, have two funding cycles. The longer cycle, which prevails in the beginning, depends on what period — a year, a year and a half — your angel funds you for. But once you begin working with a real customer, you can wind up adapting your plans on an almost weekly basis. Been there, done that!
So if you want to guess how long you’ve got to work on the project without having the requirements change out from under you, look at the funding cycle. And design your software now so that you can adapt to change in the future!
It was a very cool place to work, with a lot of extremely knowledgeable engineers. It was like being in an academic environment for an industrial salary. And the prospect of working consistently on one project for an extended period of time was exciting!
But within a couple of years I noticed that projects frequently got either canceled or significantly modified. Often this happened at yearly review time, when representatives of the other divisions assembled in Waltham to see how things were going. But it could also happen because of changes in the marketplace — for example, because some EDA (Electronic Design Automation) tools had become commercially available, and they already did what we were designing our new tool to do. The regularity with which this happened led me to formulate
Vellenga’s Law of Project Redefinition
| The mean time between major changes to the definition of a project is less than or equal to the period of the funding cycle. |
This “law” has turned out to hold in non-research environments as well — at least in the world of software development.
In a public corporation, for example, the funding cycle is quarterly, because that’s how often management has to report results to the stockholders (and to their own board of directors). Most releases of new functionality and/or performance in such companies are planned to take between six months and a year and a half, which is, of course, significantly longer than three months. But then a large customer weighs in with a special request, or the competition releases a new feature that we just have to match as soon as possible, or management designs a new licensing strategy, or whatever — or our software project just isn’t earning the kind of margins that the company wants, and our team gets reassigned. So as a developer, yes, I constantly need to be able to change my plans and my schedule at a frequency of every three months of so.
(I remember a time when we had the next release ready to go after nine months of development, including sign-off from Product Validation, and marketing announced that we’d have to change the licensing model — and release number — before sending the software out the door. That was a delay, though, of only about two weeks.)
Start-ups, in fact, have two funding cycles. The longer cycle, which prevails in the beginning, depends on what period — a year, a year and a half — your angel funds you for. But once you begin working with a real customer, you can wind up adapting your plans on an almost weekly basis. Been there, done that!
So if you want to guess how long you’ve got to work on the project without having the requirements change out from under you, look at the funding cycle. And design your software now so that you can adapt to change in the future!
posted by Jim Vellenga at
8:48 AM
|
0 Comments
