Throughout this website I make reference to The Engineering Approach.  The Engineering Approach is central to who I am and the way I think about projects.  It was core to my original intention in 1989 "to bring the disciplines of Engineering to the IT Industry".  This article provides an overview of my understanding of The Engineering Approach 25 years on

The Engineering Approach to 

Business Information Systems Defined

By

James Robertson

Throughout my website and my presentations I make reference to “The Engineering Approach”, I analysed this in 2003 and incorporated it in my book “The Critical Factors for Information Technology Investment Success” in 2004.  It has been discussed in my Briefings and Courses ever since.

It now seems appropriate to revisit this core element of my thinking in 2014 and capture all the learning that has taken place in the last ten years.

The Engineering Approach is summed up by two images that I refer to constantly in my courses and conference presentations:

On the left, a sophisticated Arch Bridge that has been standing for decades and which our society as a whole has a reasonable expectation will continue to stand for many decades to come.

On the right, the bridge failure in Minneapolis a few years ago in which 13 people lost their lives and 145 were injured and numerous vehicles were destroyed.  Failure occurred as a consequence of a series of mistakes that overloaded the bridge in an extremely unlikely manner resulting in the failure of one small component that in turn triggered the rest of the collapse.  The bridge had been standing for decades and it can be taken as a given that NONE of the people killed or injured had the SLIGHTEST reservation about crossing that bridge that day – such is our level of confidence in large engineering structures.  Note also that the collapse was on Television and Radio worldwide within minutes of the event, such is the level of surprise at such a failure.

It is a harsh reality that if one reads the reports of ERP and other Business System failures listed in my Catalogue of Failure the majority of projects end up at best as crude fords made of rubble dumped in the river and NOT as elegant and reliable bridges such as shown above.  Those that DO get to function as bridges are prone to failure at a level that causes huge business damage, as evidenced by the situation at Bridgestone.

So, WHAT is the essence of this thing that I call “The Engineering Approach?”

1.  It Works

Robust, tough, no nonsense, real, practical – IT WORKS.

People who become engineers become engineers because they thrive on the challenge of crafting things that work and work WELL, reliably, dependably, day in and day out.  People who become engineers for the money generally do NOT last long and that already starts to point to a problem in the Business Systems arena, there are a significant number of people who are in it because they regard it as easy low risk money.

2.  Failure is NOT an option

Engineers HATE failure, they spend most of their formal education and on-the-job training learning how to PREVENT failure AT ALL COSTS.  Engineers examine EVERY possible factor that can cause failure and they engineer it out of the solution.  By “engineer” I mean they systematically deal with every single element that can cause failure.  Engineers live, eat and sleep factors of safety against failure and managed probability of failure.  Engineers understand deeply that failure is INEVITABLE UNLESS they systematically design and manage failure OUT of the solution.

Engineers “design for success by engineering against failure”.

Engineers do NOT design bridges to stand up, they design bridges NOT to fall down – there is a FUNDAMENTAL difference in approach and attitude.

Pressing the delete key on a project that is under construction is NEVER an option!

Engineers have proven, tried and tested methods.  If they move beyond the realms of proven methods they are meticulous in ensuring that their extrapolation is safe and reliable.

Engineers do NOT engage in reckless experiments with new and untested technology just because it is there.

Engineers favour tried and tested technology unless there is REAL benefit to the client of moving into the realms of the latest and greatest.

3.  Highly qualified and accountable Professionals

Highly qualified, mature and accountable Professionals lead engineering projects.  Certified and licensed Professional Engineers hold four year honours level University degrees and at least three years of appropriately supervised and mentored in-service training BEFORE they can undertake ANY work unsupervised and they must undergo rigorous licensing procedures in order to be let loose on the world.

Even then it is many years before an engineer will be allowed to lead a major project and that will ONLY be permitted on the basis of years of relevant experience and proven track record – remember, engineers HATE failure and inexperienced people guarantee failure.

When I say that REAL engineers are “Professional” I do NOT just mean that they make their living from engineering, I mean that they are DEEPLY loyal to their profession, they have deep allegiance to their professional body, they CARE about the outcome and will do whatever it takes to achieve success.  No matter what the inconvenience or loss.

Engineers are subject to harsh statutory controls and aggressive sanctions including the possibility of criminal charges in the case of negligence or recklessness and their peers will actively support such charges in the event that they see that they are warranted.

Engineers have a deep recognition of, appreciation for, and respect for maturity and gray hairs, people who have been around the block, made mistakes, learned the hard lessons, KNOW how things REALLY are.

Engineers charge a fair rate for every level of team member and do NOT over charge for juniors and under charge for seniors and then short change the client on the seniors.

Engineers stand up to the client when the client wants them to do something that is dangerous or reckless.  True Professionals REFUSE to let the client go live until they are 100% certain it is safe to do so!

Are you starting to see a problem with regard to many of the people that one encounters in the business systems industry?

4.  Detailed design and specification

Engineers produce detailed drawings, specifications and schedules, down to the last field attribute and field exit process.  The last database field, the fine details of a robust set of test data that is FULLY representative, in fact has been engineered to be fully representative.  Detailed screen layouts, etc such that client personnel can fully engage with and comprehend the design, appropriate workshop methods, simulations, etc.

Engineers habitually have another engineer review their work and have technicians undertake the fine detail of the design under close supervision.  Engineers leave NOTHING to chance, they KNOW that success is a necessary consequence of rigorous quality control and attention to detail in every element of what they do.

Engineers expect to go through formal approval processes and have formal approval certificates issued.

Engineers expect and THRIVE on PRECISION.  They LOATH sloppy and ill-disciplined work.

5.  No compromise testing

Engineers undertake rigorous and non-compromise testing in a structured and formal laboratory environment.  They invest considerable effort in producing highly detailed test packs and test scenarios.  They are aggressive testers going out of their way to test every possible scenario and obscure extreme event.  They work systematically to explore every single option and they break it until it can NO LONGER be broken.  They thrive on working towards the formal issue of the Certificate of Acceptance of the testing and they get extremely irritable when confronted with sloppy programming and other sloppiness -- such as widely characterises the IT industry and particularly the business information systems arena.

6.  Multi-disciplinary integrated view

Engineers have a multi-disciplinary integrated view of the requirement, the project and the solution.  They recognize the FULL diversity of disciplines that are required and they ensure that they have ALL of those disciplines on the project team.  Whether it be basic bookkeeping and T diagrams, software design, strategy, executive communication, writing skills, the psychology of change, documentation, training materials, training, testing, coding, aesthetics, ergonomics and ease of use, data, data engineering, precision configuration, interview techniques, analysis techniques, facilitation techniques, note taking, project management, scheduling, project administration, liaison and project communication, precision of language, accurate writing, layout of screens, database design, diverse technologies, procurement, contracting, operation of the laboratory, etc.

Engineers embrace this multi-disciplinary diversity, they consult as and when necessary, even if for half an hour if they realize they lack expertise.  Engineers do NOT guess, they ask UNTIL they find mature experience to substantiate their approach.

Engineers ensure that there is a senior project director / leader / manager / architect depending on the size of the project who has the breadth of knowledge and experience to capably hold the full holistic integrated headline view of the solution and direct the entire team as an orchestra carefully coordinated to work together against a clear step by step plan to arrive at the final solution.

Engineers may work in specialist silos but there is ALWAYS a solution architect coordinating and tying everything together and owning the integrated strategic business solution view.

7.  Fundamental first principles approach

Engineers apply a fundamental first principles approach.

They build every structure from the ground up, brick by brick, reinforcing bar by reinforcing bar, bucket of concrete by bucket of concrete, bolt and nut by bolt and nut, line of code by line of code, data element by data element.

They understand how software REALLY works, they have written software while they were in training, they understand databases, they worked on those while in training, they understand communication techniques and precision language, they understand data and taxonomies.  Engineers do NOT take short cuts and cut corners.

They do NOT indulge themselves in fantasies with regard to ever more abstract and obscure layers of configurability to a point where NO ONE understands how things work and the costs of construction are orders of magnitude greater than simply building the system from first principles.

Engineers do NOT engage in mystical language like “cloud” and “process” to describe mundane elements and confuse clients.  They are NOT always looking to sell the client more for the sake of revenue targets.  They DO what is necessary.

Engineers UNDERSTAND what they are doing, they have done it before under the mentoring hand of a more senior and more experienced engineer and IF they do NOT understand they stop UNTIL they have found someone who DOES understand.

8.  Deep understanding of data and Precision Configuration

Engineers have a deep understanding that really it is the DATA that matters and that Process, that is WORKFLOW, is an incidental design output.  They model the business with great precision and continue to engage with the data and the configuration until the client is entirely familiar with it and entirely satisfied that it accurately and completely represents the business or organization to the software.

Engineers understand that it is the core master data, validation data and core configuration, coupled to carefully thought out and well designed and built software that is THE deliverable.

Engineers use PRECISE language and do NOT call something a “process” when it is NOT.

Engineers understand that strategic configuration and strategically focussed validation data, master data and configuration IS the opportunity and can deliver HUGE value with simple solutions.  They understand that precision configuration drives workflow optimization and operational efficiency leading to head count reduction as an ancillary benefit of a well-engineered solution.

Engineers NEVER undertake projects for head count reduction and regard human beings as valuable and to be treated with respect and compassion as THE asset of the business.  Yet, at the same time they accept that IF the solution really delivers there WILL be headcount reductions, all the way up the organization.  BUT REAL engineers focus on facilitating the client to grow their business so effectively that there are NO job losses only sustainable strategic growth that creates MORE employment MORE profitably and more competitively.

9.  Total Commitment – I WILL make it work

Engineers ARE COMMITTED!  “I will make sure that it works to specification NO matter what long hours I work and whether I get paid or NOT”.  Engineers own their mistakes and do NOT expect to get paid for fixing them.

Engineers are loyal, ethical, honest.  Engineers do NOT lie because the bridge will NOT stand up because you lie about the amount of cement in the concrete – the bridge WILL FIND YOU OUT – in the same way that the plethora of failed business systems projects around the world are pointing to suspect governance and suspect ethics.

Conclusion

A proven model that builds exceptional structures around the world daily – a culture, an attitude, a breed of men and women who are passionate about crafting high quality, high reliability solutions that grace our lives in every area of human endeavour.

The reality?

There ARE MANY people in the IT / Business Information Systems / ERP industry who conform to much of the above.

BUT

NOT all of it.

Many of them work for small companies that give their heart and long hours for little money to produce clever and appropriate systems that get trashed as a consequence of some lie like “Cobol is obsolete” when estimates indicate that there are 200 times more Cobol transactions processed daily than Google search queries and other reports suggest that SAP’s ABAP language is similar to Cobol.

And, more importantly, the management of many of the players, perhaps in naïve ignorance because they are NOT engineers, have NEVER designed and built things that work in the real world and believe that revenue targets are more important than robust, reliable solutions delivered with integrity lack MANY of the attributes referred to above.

The BRUTAL TRUTH is that the business information systems industry is an industry of amateurs and hackers.  YES, there ARE solid professionals out there and, IF you find one, look after them like gold, but there are a lot who lack the formal rigorous training and disciplines of engineers.

How do YOU respond to this information?

Look critically at the players on your playing field and assess whether you need to course correct.

Locate a strategic advisor who can help you to course correct.

Put the sort of disciplines and methods that are discussed throughout my website into place and start to raise the bar.

If you are embarking on a new project then adopt the Robust Procurement approach that I advocate – a tough contract is a powerful means of discouraging chancers and ensuring you select a tough and honest supplier.  Also a powerful means of FOCUSING their attention when times get tough.

And, when all else fails, give me a call!

James Robertson

03 September 2014

Download The Engineering Approach to Business Information Systems Defined -- Article in Adobe pdf format

Sort by: Newest First Oldest First Most Popular Most unliked