Estimate how how long you think it will take based on your recollection of similar projects/tasks. Double that number. Let's say you come up with 200 hours.
Say this out loud to yourself: "I think I can complete this project in 200 hours given my current workload and taking into account: the quality of the specs provided, time I spend in meetings, time I spend answering e-mails and phone calls, time I spend getting my mind focused again after said meetings, e-mails, & calls, time researching/learning new things as I go, and level of red-tape in my organization."
If you laugh at the very sound of that statement, double the original estimate.
Repeat steps 2 & 3 until you can say it without laughing.
I live on the south shore of Lake Pontchartrain. Friends of mine live in Slidell. Bring:
- Mosquito repellent
- Lots of water
- Sweat towels (if you're like me and sweat easily)
- A chainsaw
- Good, durable work gloves
- Gas cans in case gas is still hard to find
- Food to distribute to residents
I'll preface my opinion by saying it depends on the type of application, the skillset & passion of the internal developers, and most importantly: how the internal development project will be managed!
I agree with others that if the application performs a generic function, such as ordering parts, that it may be best to go with an open source or COTS solution. But custom development can work wonderfully for the unique needs your company has.
I work for the engineering department of a major telecommunications provider. Development used to be handled by individual local markets who hired their own software developers & innovated with their own software ideas. I'm talking about industry specific things and processes that differentiate us from our competitors. Many of the local developers were quite competent & produced successful apps that people used and LIKED!
Yes, this arrangement had the drawback that each market was doing things their own way and sometimes duplicating work on the same concepts. But development was quick and responded to the changing needs of the business.
Just as the developers across the country started to discover each other and coordinate their projects on their own, the company decided it was time to pull all developers under national management as an Engineering "Support" Group. The original 11 developers were added to a ridiculously large org chart of 200 people, mostly managers with various titles. Development was the tiny box at the bottom.
If they had focused & directed the efforts of the existing developers in an efficient way, they could have turned out much larger and more robust applications. Instead, our internal customers now wait as long as 2 years for an application that could have been developed in 6 months or less. The opinion of the support group is negative, and the customers are reverting to hiring local people to do development under the radar just so they can get what they need.
I think the problem is that they added too many layers of the wrong managers. First, very few of them knew much about software development when they were brought in. Second, a majority of them were brought in from outside the company and had no knowledge of how we did business. Therefore, we lost our biggest advantages.
So now the developers, who used to work in the local markets alongside the engineers and who know the business, have no influence on which projects we do or how fast we can get them done. We're a tiny cog in a large machine. And we are openly disregarded as a function they would like to outsource anyway.
Don't misunderstand. I believe we needed to have centralized management. But I often feel that if they started with the 11 of us and added only minimal extras: technical writers, testers, and a small management team, we would have magnified the effectiveness of the original eleven.
Slashdot Mirror
If only those poor people in Atlantis had this technology before they found a ZPM.
First M5, and now this!
I live on the south shore of Lake Pontchartrain. Friends of mine live in Slidell. Bring:
- Mosquito repellent
- Lots of water
- Sweat towels (if you're like me and sweat easily)
- A chainsaw
- Good, durable work gloves
- Gas cans in case gas is still hard to find
- Food to distribute to residents
I'll preface my opinion by saying it depends on the type of application, the skillset & passion of the internal developers, and most importantly: how the internal development project will be managed!
I agree with others that if the application performs a generic function, such as ordering parts, that it may be best to go with an open source or COTS solution. But custom development can work wonderfully for the unique needs your company has.
I work for the engineering department of a major telecommunications provider. Development used to be handled by individual local markets who hired their own software developers & innovated with their own software ideas. I'm talking about industry specific things and processes that differentiate us from our competitors. Many of the local developers were quite competent & produced successful apps that people used and LIKED!
Yes, this arrangement had the drawback that each market was doing things their own way and sometimes duplicating work on the same concepts. But development was quick and responded to the changing needs of the business.
Just as the developers across the country started to discover each other and coordinate their projects on their own, the company decided it was time to pull all developers under national management as an Engineering "Support" Group. The original 11 developers were added to a ridiculously large org chart of 200 people, mostly managers with various titles. Development was the tiny box at the bottom.
If they had focused & directed the efforts of the existing developers in an efficient way, they could have turned out much larger and more robust applications. Instead, our internal customers now wait as long as 2 years for an application that could have been developed in 6 months or less. The opinion of the support group is negative, and the customers are reverting to hiring local people to do development under the radar just so they can get what they need.
I think the problem is that they added too many layers of the wrong managers. First, very few of them knew much about software development when they were brought in. Second, a majority of them were brought in from outside the company and had no knowledge of how we did business. Therefore, we lost our biggest advantages.
So now the developers, who used to work in the local markets alongside the engineers and who know the business, have no influence on which projects we do or how fast we can get them done. We're a tiny cog in a large machine. And we are openly disregarded as a function they would like to outsource anyway.
Don't misunderstand. I believe we needed to have centralized management. But I often feel that if they started with the 11 of us and added only minimal extras: technical writers, testers, and a small management team, we would have magnified the effectiveness of the original eleven.