During the past three years I have had the opportunity to gain some experience in the IT industry of Australia; From this period a few projects tend to stand out amongst most of the body of work I have completed and the organizations and people I have been called upon to communicate with and produce a final and professional result or product. In my experience there is always a lingering uncertainty that each new project will manage to embody all the past bad experiences of previous ones, one could argue that from the very get go there is an inherent entropy somewhere in the background waiting to manifest at any given moment. Usually triggered by someone in the team saying something that betrays his total lack of understanding and his derailment from the common project context, or even worse his predetermination to steer the whole effort the wrong way.
The truth is that in any given project there are always passengers, without exception I cannot recall one that didn’t and in my opinion it doesn’t really matter if there are. But there are some rules of engagement I like to call the “Guerilla Programmers Tactics Manual”. Many times management has a pragmatic approach towards programmers in terms of the project variables (time /deliverable’s /resources), on the other hand programmers have a pragmatic approach regarding how these numbers come to be, in other words how the qualitative aspects come to effect the project mix macroscopically. It is at the cusp of these fine differences that I have found most of the drama taking place amongst team members. In my opinion passengers are acceptable as long as that don’t tell the driver what to do and don’t take it upon themselves to jeopardise the whole effort by taking decisions for everyone. As an analyst I have one golden rule get your job description, role and the name of your boss etched in stone; and most importantly establish an agreement on the obligations and responsibilities you carry when changes occur, that is: none!
An example of such a project where the fine balances of different perspectives where violated was one of my efforts to migrate a network of art galleries and studios in Sydney, from a mosaic of legacy ill performing systems to a unified, optimized and bright squeaky clean IT infrastructure. One that would permit them in the first instance to at least be able to execute day to day operations with the least effort, time and cost. In my view the project was an absolute failure, the customer on the other hand was happy. Still in the interest of remaining sober I have to disagree. The reason being we ended up building another mosaic of legacy systems with new more demanding systems that still failed to realize the full productive potential of the business, in terms of ROI it was barely acceptable. The key reason why this effort ended as a half hearted attempt at success was my inability to keep the customer outside of my domain. Something that illustrates this is, although I was in charge of the designing, administration and provisioning the customer took it upon them selves to start parallel projects while purchasing useless and contradicting infrastructure based on their readings of marketing flyers passed down to them by any given sales rep. This infuriated me not because someone was taking over my “turf” but because it created real issues for me when time came to adopt it and incorporate it into the existing technology mix. Of course I couldn’t show that I was, rather I had to communicate all this while managing not to insult their judgement when I was implicitly stating that what they bought was heading for the trash. In the end a lot of money was spent which made them feel good, but still the general disarray remained the status quo. The power of leadership was never granted in the first place, even if they thought they had. These orders of business cannot be left to chance, they have to be determined explicitly.
Thankfully not all instances of my experience convey gloom and doom! I had been once been charged with the task of consulting a law firm that was an SME with an dispersed array of office sites, associates and partners. Each office had a local contractor supporting there day to day operations on failing and old infrastructure, with the wrong provisioning and setup which somehow managed to just get them along. The biggest problem was the inability of there local contractors to deliver solutions, that escaped from the traditional home technology market of the Wintel platform. Rather than taking the opportunity to solve their customers issues and make a killing in the process the contractors decided to prove that any investment in technology was worthless and in many cases impossible. They were happy with these systems not performing well and breaking down often enough to generate them a basic revenue. The law firm was not on the other had since it inhibited its growth, a situation that cost them money day by day. Most of my time was spent surveying and learning the way the business worked, what specifically needed to be done and how I could change the small aspects of the business from the ground up. I began a long term and mild plan of changes that took a little over ten months. Although it was possible for me to complete the project a lot faster, I decided to approach the business with a range of iterative cycles of revision, slowly introducing new processes and new approaches at a rate that all employees would be able to learn and adopt in their work cycle. The result was that I managed to develop a constant revisionist culture in the business where, sooner than I thought was asking me to bring them something new along to enable and empower them even further, it was a great success, the company without spending much money on infrastructure or training or any formal process managed to migrate to completely new systems and infrastructure within this period while everyone was competent at harnessing the power of it. We managed to spark an explosion of productivity and communication, while also giving me the technical leeway to develop end customer solutions based on that, which delivered great end value for the businesses class and competition. In essence we started from templates in word and ended in advanced collaboration software systems and IT systems services and ERP.
What I can take away from all of this is there is no particular rule book that can save you from catastrophe or guide you to absolute success. In any work environment I use my own rule book to establish a basic line of professional defence and accountability in all cases. Beyond the power politics that could save you or chew you up, one has to understand that they are there to make something happen, to realize an idea and for such a thing to happen a balance has to be developed which is not always the same. Some basic good planning is always important, in providing the first direction towards a right mix, but making the project mix actually work and perform requires the formulation of an actual team rather than the simple conjunction of a group of bickering guerillas each with their own rule books.
The bottom line requires team members to respect each other but also trust each others judgement on particular matters of their field, and shouldn’t go off on there own making bad decisions out of fear for the teams abilities or understanding. Many technology projects fail because either the management or the programmer start taking each other lightly and thinking of each other as just unstable or over reactive. This leads to one making decisions the other should be making, which is the root of all evil in this case, since failure lingers imminently for all and although they see it they can’t manage to get their perspective communicated to one another and salvage a ship that is going down for everyone. In my experience to often management is completely ignorant and creates its own assumptions which are childish in the best case, while the only thing that saves them most times is the company’s overall well performing financial’s. In the worst instances they manage to hire programmers that lie about everything and are mediocre at best which makes a good mix for failure.
