I recall reading an article many years ago on "programming for job security", a satirical guide in programming techniques to create software code as confusing and high maintenance as possible, with the aim of securing work for as long as possible.
It was a light-hearted way of highlighting poor programming practices, and so I'm going to create my own top 10 list of business intelligence (BI) practices which will ensure job security, absolutely none of which should be followed at all!
1. Use magic: BI tools' capabilities are often measured with the assistance of "magic" quadrants which simplify a large range of tools into easy-to-understand visuals. Instead of selecting the best tool for your own specific problem, simply choose the topmost right dot in these quadrants. Should this not work out, not only will it extend the life of your BI project trying to fit a square peg into a round hole, it can't be your responsibility if you were simply following expert advice. Ignore the critics who may point out that the ability to choose a topmost right dot is an easily replaceable skill.
2. Mega-vendors: Get all your BI software from one mega-vendor which has a complete range of BI tools obtained by purchasing companies who a) filled a range gap and b) were available for sale at the time. The fact that, in some cases, the only integration between these products is the fact that the CDs now arrive in the same box is an opportunity for long integration phases in the project. With responsibility now resting in a single vendor, it's a win-win for job security.
3. Theory over reality: In many complex BI projects, there arises a time when theory conflicts with reality. Always insist that reality conform to theory. Services-orientated-architecture is one example; it's a great theory and works well in most instances, but the wrapping of XML around large volumes of data and the insertion of another data layer can lengthen the project considerably. Another benefit is that a medium data problem has now turned into a big data problem, and that just improves the status of your work.
4. Silos: The ultimate goal of BI is to deliver value to business. Try not to focus exclusively on this and break the project into as many silos (analysts, programmers, designers, architects, etc) as possible, where each link of the chain can only speak to the next link and not jump to the end goal. This breaks responsibility and authority for the project into almost untraceable components. Clearly a recipe for long projects and job security.
5. Data, not insights: Try not to get too wrapped up in the insights which create value, it tends to create business focus and interest in end-to-end delivery in the team. Delivering huge amounts of inconsumable data requires the BI team to constantly be around to help interpret. The downside of this is that it requires large amounts of time repeating mind-numbing work. The upside of this is that it requires large amounts of time (remember, it's job security we're after, not job satisfaction).
Remember, the real world does not exist.
6. Data quality: This is an integral part of any project's success in extending the life of a project. From an analytical point of view, the concept of "good enough" often suffices to add insight and value to business, but this can reduce the project timeline. Insist that 100% of source data be 100% accurate, even when not relevant.
7. Requirements gathering: This is key in extending any project's lifetime. Gather as many requirements as possible for as long as possible, noting carefully even those which are costly to implement and deliver little value. Encourage a 'wishlist' of every possible permutation. When development starts many moons later, the business environment has changed; business users have moved; the inflexible requirements list is a rich trove of change requests.
8. Performance: Don't worry about designing for performance, the hardware will save you, and if it doesn't then it's clearly not your responsibility. Demand never-ending upgrades, based on 'unexpected' data volumes and performance issues. Remember, the longer a process takes to complete, the longer the work takes.
9. Testing: Insist on spending as much time as possible, painstakingly and slowly building test data for any theoretical permutation. Remember, the real world does not exist (see point 3). Inevitably, performance will look great on these small samples, but deteriorate badly in production (see point eight).
10 Be inflexible: It is an IT project, after all. Insist on as much paperwork and as many signatures as possible. If you're really going to chase job security, you're going to make all those business people you made big promises to very unhappy, so you're going to need lots of paper from long-ago-departed employees to dodge responsibility.
So that's it, my top 10 BI practices for job security! You probably already have a couple of suggestions of your own by now. A word of caution, though, following these tips may ensure job security for your current job; however, it's finding the next BI job that may become a problem.
Share