Very common situation in government contracts and dealing with consultants in general. I am sure IBM and Accenture are in there some how. NYC government could have created a small crack-team of internal IT people who could build the system for less than a 5th of the current cost. Unfortunately most organizations view IT work as something fit for mercenaries and if you ask any King who has ever had to rely on mercenaries, they'll tell you it should be your choice of last resort.
The thing is here, no-one is incentivized to deliver. The bureaucrats who specify the system don't really care as it's not their money, and they justify their positions by sitting in meeting and writing reports that only each other will ever read. Then there are the consultants who are paid hourly...
Typically it goes like this:
Bureaucrats: Here is a 1000-page spec document that we have spent 3 years writing. We captured all the requirements at the beginning
Consultants: We can do this project for $X. However it will take a long time and a lot of people for us just to understand your spec, so any changes to it will cost $Y.
Bureaucrats: OK whatever.
Consultants: work work
Bureaucrats: Wait, we've changed our mind about this!
Consultants: lick lips
> The thing is here, no-one is incentivized to deliver.
Amen.
Incentives are everything, and if you look at most things without keeping that foremost in your mind, you'll see a hodgepodge of weird random effects ... but use that perspective, and most things make a ton of sense.
No, NYC couldn't have created a small, crack team for several reasons:
1) Government Software jobs pay less than civilian. It can take up to 6 months of paperwork to hire someone. While that paperwork is in process the job applicant must wait and can't be hired. Guess what kind of developers the government gets?
2) Requirements, they've never heard of them (sarcasm.) My last project had the language changed 3 times, went from a plug-in to a stand-alone app to an API, and during the 4 years had 3 different "final" decision makers. Feature creep was more like feature tidal wave.
3) Paperwork. There's massive amounts of it. One of my coworkers spent 1 month writing paperwork for 10 lines of code.
I could go on but the government does everything in its power to interfere with rapid development and then wonders why costs overrun.
> 1) Government Software jobs pay less than civilian. It can take up to 6 months of paperwork to hire someone. While that paperwork is in process the job applicant must wait and can't be hired. Guess what kind of developers the government gets?
Which New York City law mandates this? (not doubting that there may be one)
Hiring someone for the New York City government can take up to 6 months? What is it typically? (which is the only thing we should care about here without reason to believe it would be atypical)
>3) Paperwork. There's massive amounts of it. One of my coworkers spent 1 month writing paperwork for 10 lines of code.
Do you guys work for the city government in NYC? Somewhere comparable?
> NYC government could have created a small crack-team of internal IT people who could build the system for less than a 5th of the current cost.
So you're arguing that the NYC government is incompetent at running a project done by contractors, but it would be better at both FORMING and RUNNING its own team of contractors?
Internal IT people would be able to "cheat" by talking to actual users and stakeholders, doing stealth requirements gathering, examining the current system and how it's used, doing rogue user testing, etc. Basically doing all the things that everyone agrees are required for success on this kind of project, but which in the real world end up being dropped or neutered by bureaucracy. E.g., your "expert user" is the manager of the users and doesn't know anything about how they do their jobs, and you aren't allowed to talk to the actual users. An internal person would be more likely to have the personal contacts and trust required to work around crap like that.
Yea the internal IT people know what the ACTUAL requirements are and how the current system REALLY works. The bureaucrats writing the requirements and other documents usually don't understand the nuances of how the systems work in real life and will fail to capture the details and idiosyncrasies accurately.
An internal crack IT team is the only way to make something meaningful happen. Consultants should only be brought in when there is no in house capacity/capability. The best way to make applications happen is to have the programmer intimately know the requirements by being on site and intermixed with the end users.
Yes a small competent team could build the IT system for a fraction of the time and money. However they would only be successful if the business processes were well defined which I'm willing to bet they were not.
New IT systems often come along with changes in process, a well defined IT project should produce a system that follows and complements those processes. Instead what we often get are "boil the ocean" projects that attempt to fix process issues under the guise of an IT implementation.
^^^ This! I was involved on writing an invoicing system that ended up failing. The real intent of management was to try to bring more control to pricing using the project. Management was unable to negotiate this new process, so it ended up being an overpriced spreadsheet and was replaced a few months later when the company switched to Salesforce.
I don't agree. If they cannot control their contractors, there is no way they can choose and hire competent software engineers.
What they should do is just create an open bidding system for the work and make sure that the bids are well publicized, so that not only IBM and accenture will bid. And then they will pay the bid amount only when the whole system is ready and functioning according to specs and schedule.
Thus any cost overruns are not NYC's problem.
There is a million time keeping apps out there, I am sure there will be plenty of candidates willing to modify their app to the city's requirements.
Comments
Very common situation in government contracts and dealing with consultants in general. I am sure IBM and Accenture are in there some how. NYC government could have created a small crack-team of internal IT people who could build the system for less than a 5th of the current cost. Unfortunately most organizations view IT work as something fit for mercenaries and if you ask any King who has ever had to rely on mercenaries, they'll tell you it should be your choice of last resort.
The thing is here, no-one is incentivized to deliver. The bureaucrats who specify the system don't really care as it's not their money, and they justify their positions by sitting in meeting and writing reports that only each other will ever read. Then there are the consultants who are paid hourly...
Typically it goes like this:
Bureaucrats: Here is a 1000-page spec document that we have spent 3 years writing. We captured all the requirements at the beginning Consultants: We can do this project for $X. However it will take a long time and a lot of people for us just to understand your spec, so any changes to it will cost $Y. Bureaucrats: OK whatever.
Consultants: work work Bureaucrats: Wait, we've changed our mind about this! Consultants: lick lips
> The thing is here, no-one is incentivized to deliver.
Amen.
Incentives are everything, and if you look at most things without keeping that foremost in your mind, you'll see a hodgepodge of weird random effects ... but use that perspective, and most things make a ton of sense.
No, NYC couldn't have created a small, crack team for several reasons:
1) Government Software jobs pay less than civilian. It can take up to 6 months of paperwork to hire someone. While that paperwork is in process the job applicant must wait and can't be hired. Guess what kind of developers the government gets?
2) Requirements, they've never heard of them (sarcasm.) My last project had the language changed 3 times, went from a plug-in to a stand-alone app to an API, and during the 4 years had 3 different "final" decision makers. Feature creep was more like feature tidal wave.
3) Paperwork. There's massive amounts of it. One of my coworkers spent 1 month writing paperwork for 10 lines of code.
I could go on but the government does everything in its power to interfere with rapid development and then wonders why costs overrun.
> 1) Government Software jobs pay less than civilian. It can take up to 6 months of paperwork to hire someone. While that paperwork is in process the job applicant must wait and can't be hired. Guess what kind of developers the government gets?
Which New York City law mandates this? (not doubting that there may be one)
Hiring someone for the New York City government can take up to 6 months? What is it typically? (which is the only thing we should care about here without reason to believe it would be atypical)
>3) Paperwork. There's massive amounts of it. One of my coworkers spent 1 month writing paperwork for 10 lines of code.
Do you guys work for the city government in NYC? Somewhere comparable?
> NYC government could have created a small crack-team of internal IT people who could build the system for less than a 5th of the current cost.
So you're arguing that the NYC government is incompetent at running a project done by contractors, but it would be better at both FORMING and RUNNING its own team of contractors?
Sounds like nonsense to me.
Internal IT people would be able to "cheat" by talking to actual users and stakeholders, doing stealth requirements gathering, examining the current system and how it's used, doing rogue user testing, etc. Basically doing all the things that everyone agrees are required for success on this kind of project, but which in the real world end up being dropped or neutered by bureaucracy. E.g., your "expert user" is the manager of the users and doesn't know anything about how they do their jobs, and you aren't allowed to talk to the actual users. An internal person would be more likely to have the personal contacts and trust required to work around crap like that.
Yea the internal IT people know what the ACTUAL requirements are and how the current system REALLY works. The bureaucrats writing the requirements and other documents usually don't understand the nuances of how the systems work in real life and will fail to capture the details and idiosyncrasies accurately.
An internal crack IT team is the only way to make something meaningful happen. Consultants should only be brought in when there is no in house capacity/capability. The best way to make applications happen is to have the programmer intimately know the requirements by being on site and intermixed with the end users.
Yup, a buddy of mine works for Accenture and has been in NYC for 8 months now working on this project.
Yes a small competent team could build the IT system for a fraction of the time and money. However they would only be successful if the business processes were well defined which I'm willing to bet they were not.
New IT systems often come along with changes in process, a well defined IT project should produce a system that follows and complements those processes. Instead what we often get are "boil the ocean" projects that attempt to fix process issues under the guise of an IT implementation.
One reason companies hire consultants is not to outsource the project but to outsource blame and accountability to IBM, Accenture.
"How could the project fail? We hired some of the most highly recommended and expensive consultants. They didn't deliver."
What's that old saying? "No one ever got fired for going with IBM."
Yes a small competent team could build the IT system for a fraction of the time and money
A team that can do that AND is willing to navigate the treacherous minefields of internal politics at a government department doesn't exist.
^^^ This! I was involved on writing an invoicing system that ended up failing. The real intent of management was to try to bring more control to pricing using the project. Management was unable to negotiate this new process, so it ended up being an overpriced spreadsheet and was replaced a few months later when the company switched to Salesforce.
I don't agree. If they cannot control their contractors, there is no way they can choose and hire competent software engineers.
What they should do is just create an open bidding system for the work and make sure that the bids are well publicized, so that not only IBM and accenture will bid. And then they will pay the bid amount only when the whole system is ready and functioning according to specs and schedule.
Thus any cost overruns are not NYC's problem.
There is a million time keeping apps out there, I am sure there will be plenty of candidates willing to modify their app to the city's requirements.
I read Accenture (coughAccidenture*cough) and IBM and up-voted right away.