To put this in some perspective, they’re mostly doing it because the Brits did it first.
Still, having any recognition and awareness that there is a problem there is heartening. We’re just getting started here; last I heard, the good old habits were still in force, i.e. of starting software efforts with price tags expressed in hundred million euro multiples, letting them run for a while, then scrapping them as not even worth deploying.
Procurement is one of the big culprits here; a classic case of lost purposes. Ostensibly to save money, departments give a lot of power to policy-making bodies who then dictate a risk-averse process that departments must follow before they can spend their own money. This means that contracts now mainly go to contracting firms who positively relish dealing with red tape, but are less competent at actually shipping code.
Typically this leads to disasters, see above, which result in tightening financial controls, giving even more power to purchasing organizations, the almighty tail wagging all the dogs. The departments’ own IT people, in this setup, end up doing nothing much beyond filling out paperwork, while all actual competencies such as writing the software are “externalized” to contractors.
So the job description is basically to cure government of this addiction. I’ve been given control over a budget of a couple million euros to start with, and instructions to split it over about 10 worthwhile projects this year. Each project should have a 6-month roadmap, with a first go/no-go milestone at two weeks in (and an obligation to report in with something they’ve learned by getting out of the building and talking to end users). At least half of the development crew (4 to 6 people) should be in-house to the departments, not contractors. That should leave much less room to hide incompetence, but we’ll also provide a bit of mentoring to make sure these teams know a minimum of good engineering practice.
To put this in some perspective, they’re mostly doing it because the Brits did it first.
I remember when I was taught PRINCE2 project management one guest teacher came from the British police.
I ended up not using much of it, mostly because my projects are typically so that I am the team and the cost is my salary. So not very big. However one big idea I learned is that projects are supposed to be a triangle, where the PM is hovering between / above customers and vendors. Typically, when for example a consulting company is implementing a software for a customer company, they will have two PMs on both sides. So there is no real neutral arbiter of disputes. If this could be fixed, such as using freelancers as neutral arbiters, I could go back to the consulting world, as there would be no more of the bitter, unproductive fights that I fled from. Without a neutral arbiter it is often like “you signed a fixed price contract, now implement it for that price even if it seems to take 3x as much work” vs. “okay, fuckers, but then we will implement the spec literally without a care if it is really useful” and it ends up being bad for everybody.
To put this in some perspective, they’re mostly doing it because the Brits did it first.
Still, having any recognition and awareness that there is a problem there is heartening. We’re just getting started here; last I heard, the good old habits were still in force, i.e. of starting software efforts with price tags expressed in hundred million euro multiples, letting them run for a while, then scrapping them as not even worth deploying.
Procurement is one of the big culprits here; a classic case of lost purposes. Ostensibly to save money, departments give a lot of power to policy-making bodies who then dictate a risk-averse process that departments must follow before they can spend their own money. This means that contracts now mainly go to contracting firms who positively relish dealing with red tape, but are less competent at actually shipping code.
Typically this leads to disasters, see above, which result in tightening financial controls, giving even more power to purchasing organizations, the almighty tail wagging all the dogs. The departments’ own IT people, in this setup, end up doing nothing much beyond filling out paperwork, while all actual competencies such as writing the software are “externalized” to contractors.
So the job description is basically to cure government of this addiction. I’ve been given control over a budget of a couple million euros to start with, and instructions to split it over about 10 worthwhile projects this year. Each project should have a 6-month roadmap, with a first go/no-go milestone at two weeks in (and an obligation to report in with something they’ve learned by getting out of the building and talking to end users). At least half of the development crew (4 to 6 people) should be in-house to the departments, not contractors. That should leave much less room to hide incompetence, but we’ll also provide a bit of mentoring to make sure these teams know a minimum of good engineering practice.
I remember when I was taught PRINCE2 project management one guest teacher came from the British police.
I ended up not using much of it, mostly because my projects are typically so that I am the team and the cost is my salary. So not very big. However one big idea I learned is that projects are supposed to be a triangle, where the PM is hovering between / above customers and vendors. Typically, when for example a consulting company is implementing a software for a customer company, they will have two PMs on both sides. So there is no real neutral arbiter of disputes. If this could be fixed, such as using freelancers as neutral arbiters, I could go back to the consulting world, as there would be no more of the bitter, unproductive fights that I fled from. Without a neutral arbiter it is often like “you signed a fixed price contract, now implement it for that price even if it seems to take 3x as much work” vs. “okay, fuckers, but then we will implement the spec literally without a care if it is really useful” and it ends up being bad for everybody.