Just be thankful if you don’t live here 
3 Likes
Could have been worse, IE 1.0 instead of Netscape 
.
Andy, those kind of things are not specific to Britain, they are common place among politicians.
Politicians seem to be a bit like family - ‘Can’t live with them. Can’t live without them’. However, with software development, putting undue pressure on can only result in taking shortcuts, mistakes or poor quality work.
1 Like
I agree with you 300% . . . and the pressure doesn't come only from politicians. I am sure you already been told "why is it taking so much time, you should already been finished". I once went after someone that was really fast . . . neglecting the details. The devil is in the details, and in those who skip them 
.
1 Like
Ah! Resource versus quality! That is one of a project manager's (PM) many challenges.
For better or worse, resource limits are a reality in all projects. Time is a resource and it is always finite. There sometime comes a point where, regardless of the argument for a deadline extension, the value of a project expires past that point.
Why? Perhaps the deliverable becomes useless. Perhaps the deliverable is part of a larger project that can not wait. Perhaps a resource involved in the realization of the deliverable will no longer be available. Etc.
Risk assessment and mitigation planning is part of project management. The idea is to come up with a good number of potential risks and rank them according to probability and severity. You then come up with mitigation plans to minimize probability and / or severity to acceptable levels.
Sometime no deliverable is better than a poor or incomplete deliverable. A potential mitigation then could be to kill a project before its completion in order to conserve unspent resources. Sometime a poor deliverable is better than none at all. A potential solution then could be to cut corners.
We have, in this case, a hard deadline for a legally binding agreement. A fixed amount of time must be set aside to allow governing bodies the time to read and either approve or reject the agreement. The fact politicians dithered and dawdled for so long and did not give the remainder of the project teams the time to do their job is unimportant.
Stupid, perhaps, but unimportant! Why? because a decision was already made, normally by business analysts but likely by politicians in this case, that a poor agreement is better than no agreement. From the politicians' likely point of view, this agreement can easily be amended at a later time on a piecemeal basis to iron out its easy flaws. (Ha! That one cracks me up.)
The politicians could just as easily have decided to extend the project… except that they made a very public hubbub that no extension could be allowed. Such an about face would likely not go well with the public. It could also open the door to extending negotiations instead of limiting work to using modern / correct references. Politicians are human after all. Then again… I am no longer talking about project management.
Ever had a project where stakeholders insist on increasing scope for the umpteenth time? Ever advised a client to kill a project?
1 Like
From my experience, all projects (especially those with a complex deliverable) suffer from feature creep. In part because stakeholder’s requirements evolve over time as well as their understanding of the technical underpinnings.
In aerospace projects there is a ‘design freeze’ moment. At this point, all parties agree on the deliverable’s specs that shall not be altered further, in order to safeguard delivery date. Commercial aircraft sitting unfinished on tarmacs are a costly result of blown delivery dates.
Any delays in specification will bite those tasked with production of the deliverable. Either the deliverable‘s quality will suffer and/or delivery date will be blown.
In that, political projects are no different from any other technical project.
Can things be fixed after delivery? Small things yes, but flaws in basic design will last.
Yeah! I love this trifecta!
The really fascinating part about this truth, is the counter-part.
Slow - Terrible - Expensive. You can completely accomplish all three. And I know we have all seen so many systems and software packages that are.
3 Likes
This would make an interesting case study, not only for the mess we got ourselves in, for instance is it wise to allow the general public to vote on something where the majority have no idea of the impact of their decisions? As @bdbd has started to do, correlate this episode in history against a typical project, software or not.
There are so many factors in play, some predictable such as specification creep (or creepy politician), others not (pandemic?).
Project management is my background and nothing to do with software. However, lack of resources also apply to a software developer who is also project managing (as many of us do). A busy manager ‘doing’ is not an effective person who should be ‘managing’. With resources available to allow effective managers, usually comes bureaucracy and lack of agility.
The biggest omission from our toolbox is the time machine to allow us to go back and reset the key events that ended us up where we are (in this case I’m referring to our workload and not Brexit).
Happy New Year everyone 
2 Likes
Brexit is showcasing how an undifferentiated ‘the winner takes it all’ strategy results in a loss for all parties involved.
2 Likes
My tuppence worth.
- One of my favourite reads in this regard is "They Write The Right Stuff" which can be found here: They Write the Right Stuff
This concerns the writing of the software for flying the Space Shuttle. Obviously with a project like that you don't get a beta testing phase and can't put out an imperfect program. Part of the methodology was to set up a code writing team and a code busting team. The first was charged with writing the code required; the second was charge with finding any coding errors. Each was hellbent on stopping the other in its tracks, by either writing code with no errors, or by finding errors. It was a successful approach, obviously. The two shuttle accidents were not due to software glitches. (Even so, the fact that an entire space shuttle was brought down by, in one case an o-ring and in the other case a failed heat shield tile, shows that tiny errors can sometimes have massive consequences.) - Re the mantra cited by Wim, I think in the minds of some, perhaps especially those whose eye is forever on the so-called bottom line, this exists as: Quick = Cheap = Good
3 Likes