Have you ever heard the urban legend about Van Halen’s contract rider that stated that the concert promoter must provide a large bowl of M&M’s in the band’s dressing room with all the brown M&M’s removed?
It’s true!
And for years I found myself at odds with the attitudes of my rock heroes. (I’m a closet ’80s hair-band fan.) Can you imagine the poor sap whose job it was to comb through the hundreds of M&M’s - by color?
The nerve of these pampered, self-centered, narcissistic minstrels who had somewhere along the path bought into the myth invented by Warner Bros. Records marketing team! I don’t care how many stadiums you can sell out, you are never cool enough to demand “no Brown M&M’s”! (Darn Kids. Get off my lawn!)
However, recently I got a fresh perspective on the purpose of a rock concert contract rider and the way Van Halen was using it.
The contract rider describes in great detail the set up and tear down of the band’s sets and in a very real way describes the day-to-day existence of the band on the road. Van Halen was the first band to bring big stadium shows out to the fans in small markets. The band knew which places had a high likelihood of being potentially dangerous for the crew, the fans, or themselves. They were aware of dangers like substandard construction of the concert venue, lax or under-skilled local contractors who were in charge of lighting, sound, or staging and poor organization among the public relations or security staff.
The band knew that in many cases, they had a better idea of how to put on an exciting and safe show than the people they hired in these small markets. As a safety check, they filled their contract rider with extremely specific instructions for how the promoter needed to run the show. But they couldn’t ensure that the promoter actually read and followed the rider. They had to take the promoters word for it that all instructions were followed to the letter.
That was until they came up with the idea of the bowl of M&M’s. The one that was to be placed in the dressing room, the one that was to have all the brown M&M’s removed. The band could take one look at that bowl and know instantly if the local promoter had or had not closely read and followed the instructions in the rider.
If they saw a single brown M&M they knew to line-check each and every part of the set up thoroughly. Did the promoter hire enough competent security guards? Did the lighting techs tighten down the clamps that hold the 100 lb lights suspended over the heads of the band? Did the sound engineer bother to plug the guitars into the amps? The Brown M&M’s clause in the rider created a trigger that let the band know what type of risk mitigation activities to begin once arriving on scene.
Triggers are one of the most useful tools a team of software engineers can pull out of their project toolbox.
Triggers, in the world of software development, are signposts along the project development path. They help answer the question, “Are the conditions such that my risks have now been elevated to issues?”
A Risk is a condition inherent on all projects; it is a thing that has the potential to become an Issue. An Issue is a problem that must be dealt with by members of the project team if they intend to deliver the project within the metrics of budget, timeline, and the client’s conditions of acceptance.
We track risks. We mitigate issues. But simply identifying and prioritizing risks by their likelihood and severity is not enough. Being able to identify WHEN a risk is evolving into an issue can save the project team a lot of painful rework and the client unnecessary heartburn. It is important that when the project team is identifying risks they are also outlining the triggers and corresponding activities to undertake to either prevent the risk from becoming an issue or lessen the impact should an issue materialize.
Anyone on the project team can (and should) help with this but I feel it falls to the Project Manager to “own” this part of the project lifecycle.
And Project Managers should take a lesson from Van Halen’s candy dish.
Van Halen was OK with being known as a bunch of pampered rockstars because it was better than being known for concerts like the Rolling Stones 1969 Altamont concert where security was provided by the local chapter of the Hell’s Angels and one fan was fatally shot. Or the Who’s 1979 Cincinnati concert where 11 fans were trampled to death in a mad rush to get the best seats in the “open” venue.
As a Project Manager, become OK with the role of gadfly, understand it is your job and your responsibility to initiate the discussion of “what could go wrong.” Then document the triggers and the mitigation strategies. Keep a watchful eye on them and be prepared to act. When the project delivers successfully, you get to enjoy that bowl of M&M’s - even the brown ones.
http://www.snopes.com/music/artists/vanhalen.asp
I’ve got lots of clients who use a single checkbox to mark a record Inactive, in lieu of deleting the record. It’s quick and easy and clear. But sooner or later, as Inactive records build up over time, most of them decide that they want to exclude all the Inactive records from the finds they do — but not all the time, just most of the time.
The obvious solution if you’re a hardcore FileMaker user is a multi-request find that uses the Omit option. You make one request with the criteria you want, then re-enter find mode, check the Inactive box and the Omit option, and select Constrain Found Set. But this can be intimidating to some users, and really, if I’m being totally honest with myself, I have to admit that it takes too many steps to be truly easy.
I could use script-triggers to postprocess all finds run in that context, but that demands enough budget or a compelling reason to undertake that level of complexity and effort. In the absence of either, you can offer an inexpensive solution by presenting the existing data differently, so that people can do a simple, positive find rather than a complex omit find.
Make a calculation field called Status, and code it to return “Inactive” if the box is checked, and to return “Active” if the box is unchecked. Expose this new field to find mode, and you’re in business. Now people can type in their find criteria as usual, including typing in “Active” in the Status calc field, hit the Enter key as they always do, and the single-request find will bring back only the records that meet the criteria AND have the Inactive box unchecked.
They are complimentary technologies - Flash is primarily a display platform and SalesForce is more data focused.
Using Flex or Flash to present data from the SalesForce cloud is a great way to make a really seamless and slick user experience. This latest development makes that even easier than it was previously.
Go to this page to find out more and download the IDE.
Using the Flash or SFDC IDE tools previously enabled you to make either a Flash Builder project or a new SalesForce project.
Now you can make a combined Flash Builder / SFDC project that uses a WSDL to enable you to connect to the SalesForce schema.
You can also create an Adobe AIR app which manipulates offline data and synchs it when you are online again.
There is no guide on how to download the WSDL document from SF for use in the IDE - here’s what you do.
Another trick to remember is that you’ll need your API key to connect to SalesForce - it gets pasted on the end of your password.
Flex / SalesForce integration enables the creation of awesome cloud-based enterprise apps, so get out there and start coding!
Caspar