Despite an endless ocean of advice on what to do (and not to do) in order to avoid enterprise implementation disaster, reality is often an imperfect one. Whether it’s a failure to understand the requirements, secure solid management support, evaluate the options, or install a Locutus equivalent to champion the transformation, mistakes get made. Some are recoverable with effort, others not so much. Ever wonder what happens if you happen to get it all wrong simultaneously, Titanic style? That kind of thing never happens, right? A Senate Committee on Homeland Security and Governmental Affairs has just proven otherwise and documented the truly horrific failure of the Air Force’s Expeditionary Combat Support System (ECSS) for the world to see. It’s subtitled “a cautionary tale” but it frankly reads with the same hopelessness as a squad of colonial marines holeing up against an entire colony of xenomorphs on LV-426.
There’s just a bit of hot-dogging going on in engineering these days and engineering change is right at the center of it all. Change is often regarded as the one guaranteed constant in engineering design. So it should come as no surprise that change is also central to cost and execution. Projects that execute well, handle change well. Those that struggle, often do so under the relentless weight of compounding change. As new Computer Aided Design (CAD) technologies continually accelerate the capability to change, pressure mounts to execute as fast as the technology will allow. Friction is growing as the simple ability to make a change increasingly outpaces the ability to manage change. They have a need. A need for speed.
Enterprise social networking providers are trying ever so hard to turn a hairpin corner, and finally break the stigma of utter uselessness that has long-plagued the purported social technology revolution. In the aftermath of so many smoldering train wrecks and flawed hypotheses, many underlying truths have emerged. The details of these lessons have been previously chronicled in Antisocial Enterprise, Part II The Wrath of the Engineer, and Part III The Search for Users. Here’s the short, short version: social networks are about people, business is about products and decisions. Up to now, the flawed assumption was that if social networks are so super-awesome for groups of people, and business is naturally just chock full of people, then social networking must, logically, also be super-awesome in the enterprise, Q.E.D. Zathras try to warn, but no one ever listen to poor Zathras.
This is Episode 3 of a continuing series about enterprise gamification, exploring aspects of game design that have relevance in improving the utility and effectiveness of engineering software and processes. If you haven’t already, go check out Episode 1: Press Start, which introduces the concept of gamification from this perspective. Episode 2: Achievement Unlocked tackles achievements/badging.
The mere utterance of the term “open world” resonates powerfully in gaming circles; it’s often a critical focus of contemporary game design. Open world play is seemingly now a requirement for all but the most esoteric AAA titles, and an important source of differentiation among indie challengers. But what, exactly, does open world design entail? Open world is a departure from the highly linear progression of traditional gameplay. Classical gameplay depends on a defined progression of levels, usually presented in a specific order of increasing challenge, or a highly scripted series of environments designed to carry a movie-like focused narrative. Open world is exactly the opposite philosophy, striving to provide as few barriers as possible into an experience primarily driven on the player’s whim. What’s the appeal? Open world caters to a specific human trait: the desire to explore and experiment. Curiosity isn’t just for cats, or the likes of Magellan.
Innovation in the enterprise often seems like the cruelest exhibit in the hall of oxymorons, despite the transforming technological landscape. Whether it’s Enterprise Content Management (ECM), Enterprise Resource Planning (ERP) or Product Lifecycle Management (PLM) the patterns are all too familiar. Tech conscious C-level executives, increasingly overlay far-reaching abstract requirements over the usual implementation planning activities. The fact that innovation and cloud solutions are trending lately should be a surprise to exactly no one. In some ways it’s a bit of enterprise buzzword bingo. At the heart of it, however, is a sincere desire to architect forward-looking solutions using the best available technologies. But typical corporate solution planning methodology is dependent on case studies to justify certain technology choices. Here’s a pro-tip to all you wanna-be solution pioneers: you’re not going to find case studies to justify a truly innovative technology plan. You will have to dispense with the idea of the human shield, turned corporate style. Stay in front of me where it’s safe.
A great void continues to expand in the application of Product Lifecycle Management (PLM) and even progressively simpler Product Data Management (PDM) technology solutions. A chasm exists between the large enterprises successfully engineering complex information infrastructure into manufacturing juggernauts, and the small design firms merely surviving with the digital equivalent of brute force. It’s literally becoming an abyss, a bottomless pit, baby; two-and-a-half miles straight down. When it comes to PDM or PLM, two flavors of solutions have dominated for an age: the big complex monstrosity, or the anti-solution, which usually means cobbling all things together with whatever came with Microsoft Office. The next step in PDM/PLM technology evolution must strive to fill that void, and find a meaningful compromise between the inequity of large and small, balancing robustness with agility.