669 karma · joined September 10, 2013
[1]https://www.iheart.com/podcast/105-behind-the-bastards-29236... [2]https://www.iheart.com/podcast/105-behind-the-bastards-29236...
A few things to note that aren't usually apparent in these articles. The "Podium" is not just the beautiful concrete walls you see holding the sails; Bellow the deck is around 3-4 stories of equipment and services (some below sea level) that serve the theaters, offices, back of house etc. that extend past the footprint of the podium, out to the edge of the quay in some places. An incredible warren of equipment rooms and tunnels crammed into a space that was probably too small for the final requirements. This is including a large seawater intake system that is used in water heating and cooling, the only one of it's type. I had the privilege of consulting there many years ago and was shown around. It was immense, you could easily get lost.
All services you would normally expect to see on a building exterior are hidden from view, no plant, no equipment. Where's the HVAC? The Loading docks? Car-park (under the stairs)? Heck, even the garbage was designed to be picked up by trucks driving through the center of the podium loading dock.
Due to the number of design decision made on site during construction there are no as-built drawings (that may have changed in the last 10 years). If you were down there drilling a hole through one wall, it was almost impossible to know exactly where it was going to come out on the other side.
In spite of all it's obstacles, latent acoustic issues etc. it is still a one of a kind marvel of modern architecture with no competitor. Utzon and Arup were true geniuses, innovators and visionaries.
[1]https://www.sydneyoperahouse.com/our-story/sydney-opera-hous...
In Australia (at least) banks are given rather descriptive measures to check for by the regulator. Some of these are quite standard but leave some room for the banks to decide what hard values they set in their checks. Every so often the regulator comes in, does an audit of these checks and tells the bank if they think the implementation could be better or not, but it's very arms length.
You see, when the detection systems produce a result (live or historical) they are then investigated further by human analysts. How many human analysts do you need to pay? Well, it's a tradeoff between where you set those hard limits and historically how many results you get over periods. You don't want to have a massive backlog, processing time is also a consideration, but how do you know when you're picking up actual money laundering and not just weird human behavior? When you think you've found something, you send it to the regulator and the police who take it from there. You don't get any feedback. It goes into a blackhole.
This sounds inefficient but perhaps (not sure if it's been determined) it avoids the case where you start overfitting to particular types of activity at the risk of ignoring others.
All banks implement their own checks, so assuming other parameters (customer base, technology, enterprise risk environment etc.) are the same there must be one out of any group that's better than the rest, but the regulator is the only one that could possibly know based on outcomes. Any signal from them will be picked up on by those actors trying to get around this.
This is hard, but the transaction is just a record of activity (albeit one of the only ones available to enforcers) usually after the fact. Maybe to achieve any meaningful reduction, you have to stop the flow in the first place, I don't know.
Luckily in our future Capitalist 2.0 society everyone will be aligned to the "shift" they work around UTC, of which there are 10 but they are coded in binary for simplicity.
Projects in the traditional sense produce new assets with new value with new benefits meant to be operationalized. You need to segregate associated costs so that you can depreciate the value of the asset once it's operational. Usually the cost is considered an investment and funded by separate finance.
Operational Projects support, extend, enhance existing business assets. This is the assembly line mentality and is more aligned with continuous improvement for which there is usually a fixed budget for the year and is completed during the normal course of business.
Yes there is some grey area but both are necessary.
What we are really doing is simulating many many permutations of the effects of known risk likelihoods and consequences across the graph. Otherwise in a large program of works we will tell Project Managers or Contractors that they can manage their own float which gives them flexibility to execute.
Another method that simplifies this is PERT[1] method, where you take, optimistic, pessimistic and normal durations to produce an expected duration.
[1]https://en.wikipedia.org/wiki/Program_evaluation_and_review_...
Agile works best in environments where the scope or execution methodology can not be discerned up-front or where it is crucial you need assurance that expectations are aligned. Your risk profile is much higher due to the number of unknowns, so a lot of time is spent doing work "around" the design and delivery of said thing to mitigate all that risk. As such, it works well for mostly corporeal endeavors such as building new software, or things that . This helps operationalize a feedback loop of try, test, re-align, try, test... etc. across stakeholder groups to help make small rapid course corrections until you get to where you need to go or abandon at an optimum time without marching like lemmings to a cliff.
It also works well in technical environments where there is a lot of collaboration and interfacing between different specialized groups. Forcing everyone to come together and be accountable for their dependencies to each other reduces those instances where blockers, compounding delays and finger pointing send things off the rails.
Estimating, assigning, controlling and monitoring, what you would typically term "earned value", in a project management sense is extremely difficult for these types of things. If the scale of work is large things naturally land on amounts that aggregate up to something useful
The two things I often see in agile projects/organizations that are often done poorly and lead to failure are:
- Maintaining a proper understanding and separation of the delivery risk (risk associated with building, creating) and the delivered risk (the risk you've baked into the "thing" by aspects of its design)
- Not allowing for or tracking risk mitigation, or how residual risk is trending
- Thinking because every project is unique that they are unique and therefore need a unique way of managing the project (i.e. re-inventing basic project management methods)
- Thinking your business is unique (it's not, less than 10% at most) and that therefore everything you do, including how you execute projects is unique (you don't).
CAD files (at least planar modeling as opposed to parametric or solid modelling) tend to have pretty straight forward data structures for geometry. Find the point or vertex struct and you're halfway there. The complexity is association and metadata which were nowhere near as bloated then as they are now.
As someone who works regularly for large asset owners, asset life-cycle information (digital and analogue) and the proper management of that information is often ignored because organizations pass that risk to the people working with the asset maintaining their own working knowledge to get their job done. We've had international Building Information Modeling standards since the turn of the century but there's often no business case or standard enterprise process to make leverage technology for asset management.
AI and ML are starting to appear more and more in the operations space, however many pilot projects have to start with digitizing the asset in the first place, which becomes a cost impediment for many getting off the ground.
It really frustrates me as there are great things that can already be done today but the initial step financially usually scares off anyone who has to know 5 years in advance what their operating budget is.
Occasionally I'll have flashbacks to a younger me doing a similar thing in Access with VBA 15 years ago. [herewegoagain.meme]
A wealthy individual approaches you and asks if they can buy this HDD off you for a large amount of money. You don't have a lot of money, your ability to make money is restricted and your government is always reducing social safety-nets. This proposition looks like your best chance. The wealthy individual takes your HDD, holds it for a while and then physically destroys it in front of you without regard.
But it's fine... Right? It was only some plastic and metal... You can go to the store and buy a new larger HDD with all your new money.
The biggest one I have fits around 9 and 10. No numbers until the end. As in don't show data, tables, (a group of) numbers, graphs etc. until you are ready to cede the floor.
As soon as numbers appear, people's brains start analyzing and trying to make sense of what they are seeing, naturally this can/will lead to an inordinate amount of time discussing provenance, methodology and other associated aspects, or silent thinking i.e. not listening to your analysis.
Of course this doesn't apply to every type of meeting, but I always ensure I get everything else in up front first. Leave the detail in the back, don't bury the lead.
The author would do well to look into management theory, initially Harold Leavitt's Diamond in “Applied Organization Change in Industry” now more commonly distilled down to golden triangle of "People, Process and Technology".
I don't know the answer, not can I offer any overarching counter-argument but I feel a deeper understanding of lessons learned in management theory and operating models for the author might help in their next iteration.
But yes, what changes are the business end users requirements for slicing and dicing performance data from 'subsets of this' and 'subsets of that'. I think HANA plus the move to the cloud will potentially help this.
Channel Tunnel suffered significant delays and additional costs for instance because the brackets supporting cable and pipe runs needed to be taken down after everything had been installed because of a latent design defect and replaced.
Imagine how long it takes to pull 20+km of cable off the wall.
Also, compared to other construction sites, tunnels are a different beast, you often need to transport huge amounts of materials, people and equipment long distances to get to your work-front (and back again). It might be a straight line, but it's still far.
As much as I love the Channel Tunnel (my father was an engineer on it and I grew up during the construction) the actual outrun cost benefit ratio just isn't there. Extra ferries probably would have been more economical.
We also have more complicated, and are dependent on, soft and hard power structures to access and use capital. A great place to start looking into these issues is Bent Flyvbjerg at Said, Oxford
I know this was partly joking but there are two real ways:
Knowing your true critical path and proactively re-plan and manage the risk of those activities that sit on it to clear the way for it to run smoothly... that's of course assuming you planned and estimated it correctly in the first place.
If you have a real schedule that is properly resource and risk loaded, run it through a monte carlo sensitivity analysis and see if you can re-plan those highly sensitive activities or de-risk them.
It is also more difficult to initially assess the skills fit of candidates for knowledge based work, especially those that require creative problem solving, and unlike other engineering disciplines past outputs are opaque and hard to rely on as simple markers of past performance.
For a project, in order to produce a good estimate you need to understand scope, then align it with precedent, adjust for your resources and productivity profile and then view all of that through a risk lens to set probable outcome ranges.
For a programme, in order to produce a good estimate you need to understand and manage the risks, constraints and dependencies across all your projects and ensure that the projected benefits (both hard and soft) are still net positive, meaning the investment makes sense.
From my observations at least it doesn't look like the idea of development as "investment" in a product or service is very common. I'm assuming because time to market is often the ultimate driver rather than cost, in which case, congratulations, you should increase your costs on more numerous and productive resources whilst aligning your strategy and risks to iterate on smaller scopes faster so that dead ends can be quickly parked.
The problem isn't so much the estimation process as it is more generally poor portfolio/programme governance and management practices and more specifically a lack of risk management and understanding of contingency at those levels. I find IT, and Software Development more particularly, to be some of the worst offenders, but that is because the risk profiles of such projects are vastly different to the risk profiles of other types of work. The productivity of your resources is difficult to discern and a lack of precedent for similar-enough projects and knowing what their variables were, all meaning you really can't produce a reliable estimate with incomplete information.
They shot the Ferris Wheel over the course of a whole day, going around and around and around whilst there was light. The cars were quite small for filming, so Reed, the cameraman and my grandfather were pressed up against the other side as far back as they could. He would recall it as being a grueling day.
I don't know if they ended up re-shooting that later, because in the film the background out the windows looks projected. He never watched any films he worked on, so might not have known.
He had so many stories from that shoot, which was odd because he didn't like talking about work, so I got the impression it was one of his favorite location shoots.
Over the better part of the last decade, many tobacco stocks are down (BAT, PMI, RT, JT etc,) however most dividends on their common stock are still increasing YoY. Not certain if it's generally above the market average but seems to be more than not.
If you look at long term production rates (sticks shipped) cigarette manufacturing has been dropping YoY for years. But this is because there is a general drop in demand from higher socioeconomic countries generally and as consumers switch to "smokeless" "next-gen" alternatives. My observation is that single sticks are usually sold at a much higher price in those markets (sometimes due to tax and regulation, but mostly due to local market value), whereas they are sold closer to cost of production in lower socioeconomic countries where they target larger volumes per consumer.
It's difficult to paint a picture from the data released in annual reports and market updates around what the transition (sticks -> e-cig consumable units) looks like and is perhaps purposefully obfuscated and will probably remain that way until forced otherwise. As such, relative points of comparison make their day to day activities harder to judge over the last few years but what everyone IS doing is huge amounts of M&A, Research and Capital Expenditure to meet this strategy whilst not raising capital from equity as their share price drops yet maintaining higher dividends. Why? Because they are cash rich.
Much more generally, from a business perspective, what's happening in the tobacco industry is fascinating (and equal parts horrifying depending on your point of view) as these paragons of global supply chain pivot to become consumer electronics companies.
The external microphones can be subject to a lot of wear and tear, external noise. I haven't any knowledge of a system as sophisticated as recording voice and storing, let alone pairing an audio segment to data on the pos. But rightly identified as a perfect opportunity to label training data, and you wouldn't think it would be too hard to deploy, at least in a limited capacity for the initial training and validation on this project.