4 ms·

I've participated on several >$10M Canadian Gov't IT projects over the years and you nailed it. Business groups will fight tooth-and-nail to keep their existin

I've participated on several >$10M Canadian Gov't IT projects over the years and you nailed it. Business groups will fight tooth-and-nail to keep their existing processes - partly to maintain status-quo, but also because the folks who represent the business know little about system's analysis/design, so they just simply aren't in a mindset to re-engineer. Combine this with the vendor's (not so hidden) agenda of milking the gov't and it's a recipe for disaster... every damn time.

sbarre 9y ago
A factor here that might be overlooked (and I'm not making excuses for the bad process you're describing) is that changing business processes means re-training all your non-technical staff (and everything that comes with that - training materials, manuals, forms, public-facing processes, etc). In a unionized environment like the Canadian federal government, that would likely incur not only a fairly high cost (but less than a failed technology project for sure), it's also a massive HR undertaking that business-side managers and leaders want to avoid at all costs. So they'd rather push all that work onto the technology teams to ensure process remains the same, even if it's the wrong thing to do. My personal anecdote on this: years ago in a past job, I led a team that worked on a project for Bell Canada to build a retention portal for their call centre agents, and the requirements were full of crazy and sub-optimal flows and features, and every single one we questioned was justified with "any other way would require too much re-training of unionized call centre staff". In one case, for a call centre in New Brunswick, the union actually had a clause that major process re-training could only be done every 2 years, regardless of cost.
3pt14159 9y ago
I've consulted to the Canadian Government on both a data science project and on cyber security as well. The technical people inside GC know what they need and it isn't IBM building custom software for something like payroll. They should use off the shelf stuff for the 95% of employees that have run of the mill circumstances and just use humans to handle the super long tail of bespoke needs that no other Canadian employer has to deal with. The problem is that the political side of the government doesn't trust their own technical staff and they get convinced by these horrible consulting companies like IBM that the only way to write good software is to spend hundreds of millions on it but don't worry it will pay for itself with all the cost savings on staff. They try to minimize risk through bureaucracy but they end up getting the opposite of what they want. Less useable, less secure software at 50x the price. What they would do if they understood software is communicate to the public about how good software projects need fast iteration and that mistakes might be made sometimes, but that the important thing is that they are easy and fast to fix and that there are risk mitigation strategies to stop mass leaks when penetrators get into networks. Also, the CSE should just be empowered to take GC servers offline whenever they don't conform to a predefined list of security practices. It's 2018 the fact that all of GC isn't on HTTPS / HSTS is quite frustrating and it requires all departments to get on HSTS preload lists because of the stupid way gc.ca is a subdomain of .ca.

sbarre 9y ago

A factor here that might be overlooked (and I'm not making excuses for the bad process you're describing) is that changing business processes means re-training all your non-technical staff (and everything that comes with that - training materials, manuals, forms, public-facing processes, etc). In a unionized environment like the Canadian federal government, that would likely incur not only a fairly high cost (but less than a failed technology project for sure), it's also a massive HR undertaking that business-side managers and leaders want to avoid at all costs. So they'd rather push all that work onto the technology teams to ensure process remains the same, even if it's the wrong thing to do. My personal anecdote on this: years ago in a past job, I led a team that worked on a project for Bell Canada to build a retention portal for their call centre agents, and the requirements were full of crazy and sub-optimal flows and features, and every single one we questioned was justified with "any other way would require too much re-training of unionized call centre staff". In one case, for a call centre in New Brunswick, the union actually had a clause that major process re-training could only be done every 2 years, regardless of cost.

3pt14159 9y ago

I've consulted to the Canadian Government on both a data science project and on cyber security as well. The technical people inside GC know what they need and it isn't IBM building custom software for something like payroll. They should use off the shelf stuff for the 95% of employees that have run of the mill circumstances and just use humans to handle the super long tail of bespoke needs that no other Canadian employer has to deal with. The problem is that the political side of the government doesn't trust their own technical staff and they get convinced by these horrible consulting companies like IBM that the only way to write good software is to spend hundreds of millions on it but don't worry it will pay for itself with all the cost savings on staff. They try to minimize risk through bureaucracy but they end up getting the opposite of what they want. Less useable, less secure software at 50x the price. What they would do if they understood software is communicate to the public about how good software projects need fast iteration and that mistakes might be made sometimes, but that the important thing is that they are easy and fast to fix and that there are risk mitigation strategies to stop mass leaks when penetrators get into networks. Also, the CSE should just be empowered to take GC servers offline whenever they don't conform to a predefined list of security practices. It's 2018 the fact that all of GC isn't on HTTPS / HSTS is quite frustrating and it requires all departments to get on HSTS preload lists because of the stupid way gc.ca is a subdomain of .ca.