Drafting board

IT: The return of the engineer

Asking an IT professional to build a car, giving just a brief verbal description on the desired result will probably end up with something on triangle wheels. After having it run for several miles, the axis will be broken. The IT professional checks the results, runs some tests and repairs the vehicle by putting in a stronger axis. The vehicle runs again for a while, then the new axis breaks down as well. Now the IT pro is changing the wheels from triangles to diamond shaped… eventually, after plenty incidents they became round (enough). But now everybody is realizing that the car is only running at a top-speed of 50 miles/hour where expectation was about three times of that.

Seems impossible in the car industry? Right. But sounds oddly familiar in IT?

It baffles me every time: Starting an IT project, computer scientists, programmers even analysts tend to repeat the top 10 epic failures everyone could read about in any random book on how to manage IT projects. This happens not only to junior members of the team, that would be somewhat understandable although can only serve so far as an excuse, given that most of them I had the pleasure to work with had proper educational backgrounds covering the relevant standards and methods. The baffling part is, that this happens with senior members no less.

The number one mistake from that list is stripping the documentation of results of any project stage, be it business analytics, requirements engineering, development, testing or rollout and handover to operation from a bare minimum to literally non-existence. Thus forcing every subsequent project stage to guestimate rather than to know what is expected and what is needed for task completion. I am getting it – documentation seems to be the little and annoying brother of creation. Of building a new and shiny solution for a major business challenge – allowing the white knight to swoop in and rescue whatever princess is waiting to be rescued out there in the markets. On top documentation is expensive and very true, most of it is never being looked at again once handed over to the ops team successfully. And they are clever folks, they have been involved in the project, maybe the project was even following the latest catch-in-a-box project-setup called DevOps. They don’t need documentation. They know. Hence we might as well save that bite out of the budget there and put some extra features in. All in all, the business users expect features, not documents. The project will be faster that way. It will sooner be delivering the first artifacts of SCRUMy potentially deliverable pieces of code. Wow. That does sound good. We, the IT professionals almost believe it ourselves…

And for sure, the business owner’s love to hear about it. To them it sounds like the promise of getting more for the same price or even better, getting more for less, depending on the level of enthusiasm on our side. The bad awakening starts the moment, the beautifully delivered artifacts falling out of the blue sky and crushing on the rock bottom of any of the testing stages. The project falls into major delays, none of the initial estimates seems to having been realistic at all. Sign offs are not achieved and the game of blame has just begun. But lets step back for one second: Why does it seem like nothing functions as planned, why is everything at least an irritating bit off of what was expected? Did they not understand? Did they not see this? Where they not aware of what we are trying to achieve with that project? Right… documentation.

But is it all just the love for features and making the business folks happy no questions asked? Is the professional IT community falling into the trap of wanting to be loved that much, that they forget their enabling mission and lost touch with reality? Remember, enabling does not mean delivering everything by the businesses terms. It rather means understanding the business deep enough to become a true partner. A sparring partner if needed. That includes defining the limit of what is reasonably possible and only together, all hands on deck trying to push these limits further out. This by the way is the moment, where the level of IT understanding on the business owners side has at least to be on equal terms like the IT’s understanding of the business questions at hand. Anything short such a mutual level of understanding will not allow for severe limit pushing.

The solution is as simple as it might be painful: Invest in documentation. Make documentation an equal important delivery item as any new feature. Make furthermore sure your documentation will still be understood at least one year out from the moment of taking the solution live and at least by the members of your project team, who are hopefully still aboard then. If that sounds unrealistic, level up and get your documentation up to a standard where prior project involvement is not crucial to understand and maybe even widen the timespan to be covered. Why to put a timespan on it at all? IT systems are very rarely totally stable over time. Most likely your ops team will perform minor adjustments and optimizations while keeping it up and running. Even more likely your business owner will start requesting changes due to changing markets or adjusting business models the moment you drive your solution of the shelves. All this will have to be reflected in your documentation. Depending on your business environment it is hence very unlikely, that your documentation one year out from know still looks the same. Your documentation has to mirror any evolutionary steps your solution is going through. Only then, you secure your newly IT asset and hence your investment.

So where is the catch 22 here? Why is that not obvious to anybody – it seems obvious reading about it, right? The answer is hidden within the term Software Engineer. Focus especially on the second word: Engineer. If we take a brief look at what a general engineer does, it is all down to specifications, standards, and normative methods. It is taking previously established and tested parts/modules and combining them to form something bigger. All the engineer needs to know for that is where to look for the proper standard or needed methods and start orchestrating them in a new and maybe even creative way. It is mostly not inventing the methods again; it is mostly not creating a new norm. It is never without documentation of the single steps towards a solution. A classic engineer has documentation hard-wired into the DNA due to its education and due to how it got applied in the real world of business. For Software Engineers, computer scientists and other IT professionals that does not seem to be the case, surprisingly. They tend to re-invent the wheel, always believing they might find a previously unidentified angle that will speed up the current project, making it superior over all projects that went so wrong in the past… It is due to the fact that IT professionals forgot about or even never new how to be engineers. How to use our minds to combine previously established solutions to build something bigger, how first to conceptually work on a question and then deliver a solution. We tend to believe IT is so much more complex than any other engineering field. We therefore believe we can set aside most of the merits that field has to offer. Think again.

Changing such a situation, such an approach towards IT projects in any enterprise requires synchronizing the transformation forces of business and IT. The COO or head of innovation/marketing or who ever is the top executive in charge of running a particular area and the CIO have to interlink. First step would be to understand that there is no such thing as just an IT project. Any project either delivers value towards the business or is not worth undertaking. Hence every project involving IT involves business as well. That line might be a bit far stretched when upgrading your commodity IT – say database servers. But even then, a failure would be most likely crucial for the depending business solutions on top and therefore the relevant business partners have to be involved at least a little bit. From these day-to-day update-style projects up to major business transformations, CIOs have to be able to communicate the dependencies towards their business peers. They have to take up the challenge to truly engage and support the business in order to become a transformational enabler. They have to become sparring partners. That includes to being able swinging and taking a punch from time to time in order to stretch limits.

IT and business have to partner up in order to enable, in order to deliver together results that not exceed expectations but simply meeting them: In time, in scope and in budget.

Image source: Wikipedia, Fernost

2 Gedanken zu „IT: The return of the engineer&8220;

  1. I fully support your conclusion „IT and business have to partner up in order to enable, in order to deliver together results that not exceed expectations but simply meeting them: In time, in scope and in budget.“

    When talking about innovation projects, greenfield projects: My experience over the past years in the role of an software engineer I find larger-scale enterprise tend to build unnecessarily huge organizational distance between the engineering and business entities. Rather reducing them, new Roles are introduced over and over again, making it even harder for knowledge and information to flow. Also makes it difficult to develop a common understanding of project goals resulting in a valuable documentation.

    Not surprisingly that distance behaves proportional to the available project budget. Both gets dramatically reduced as soon as „software projects“ reach final stages. Time/Budget limitations are in sight and project managers start to get nervous about confirming commitments given earlier. I’d state that this phase of a project can be the most productive one, since goals get carefully worded to ensure all people involved get a very clear understanding of expectations. A documentation is an important artifact of communication in all project phases, but in my eyes not less important is, that people simply start communicating directly.

    Project documentation often simply lacks of important aspects of the engineering parts. These gaps gives lot of wiggle room for technical teams to to dramatically overengineer less important or even irrelevant parts while more and more leaving the focus on the project goals.
    Engineers force requirements/biz people to be as clear with documentation before they accept it, ensuring they feel like being able to fully understand the requirements. Then business might feel convinced their part is done and engineers simply have to transform text into tech. I’d say it should never be that top-down way! Try challenge your engineers and architects to formulate their concepts as clear as they expect it to be from the business side. Ask them to talk in a non-technical language and reflect decisions in simple words. These direct conversations will also shape the domain knowledge of your engineers, one of the most important knowledge.

    DevOps disciplines are a good sample when looking at dismantling barriers and reducing distance between engineering and operations entities. „They don’t need documentation. They know. “ might not be the idea the majority of DevOps would fully agree on. These DevOps culture is young, development in that area seems very promising to me. Important day-to-day issues we’re often facing are at least addressed and get the attention they need.

    What I do miss in project organisations are small groups of equitable peers combining business, engineering and operations. Outputs of these groups then could be well transported and manifested in documentation. Keeping in mind that documentation must have a value to all roles, not only be the forced artifact to be delivered alongside the delivery units. Promote it as a multi-purpose instrument. Only a common understanding and interest in the topic can make documentation a valuable artifact that takes influence on the actual behavior.

What do you think?