When working with new processes or projects, the main tasks are to deliver what is necessary, while constraining the scope.  This is the goal in any engineering project, but it is less clear-cut for more abstract items like software, particularly when there is no definable package of tools to be replaced.

If we are building a bridge or a water supply pumping station, the design proceeds by looking at the existing conditions.  These help us to define the scope or magnitude of the project.

An existing bridge that is always full of cars travelling very slowly indicates a need for something to change.  The delays in travel measure the pain being felt by bridge users, and the budget made available will be proportional to the pain being felt.  A water supply pumping station may be proposed in an area because of problems with water-borne diseases or the high cost of trucking in water for customers.  The number of sufferers and the severity of their suffering will drive the desire for change, or the cost of trucking in water may help to put an order of magnitude on the reasonable cost for improvement works.

Budgets for wastewater treatment plants will be determined on the same basis, with the design following the budget.  Skill is obviously required, but such physical, tangible assets are comparatively easy to imagine, design, price and construct.

Software development, and particularly the data modelling which is often at the heart of the required software, must follow the same processes as far as possible.

Special interests and gathering requirements

As a new engineer in the 1980s, I was involved in the design of a large sewerage pumping station.  Architects and several different engineering disciplines contributed to the design, and frequent co-ordination meetings were held to make sure that interfaces between different disciplines would develop successfully.  For example, the civil engineers had to design the incoming sewers and large pump wells, but had little interest in the equipment those structures would contain.  The mechanical engineers needed space for the pumps and drive shafts, but were not very interested in the electric motors which would drive them.  And, of course, all of the engineers had opinions about the work of the architects, but I won’t go into that!

Group interests

One of my very first tasks was to take minutes of those design co-ordination meetings, and this taught me a lot about different points of view.  Each discipline had a different opinion as to what was important, and this will be true in every project that involves more than one group of people.  A successful project must bring together the interests of all different groups in a coherent manner.

Individual interests

There is also the effect of personalities.  At times, the normal representative of a discipline was not available and another delegate was sent instead.  This delegate would sometimes report different information and different priorities from the normal representative.  At the very first meeting I attended, I did the best I could in recording and summarising what was said – not an easy task for an engineer straight out of college.  At the next meeting, I was abused by the boss of one of the disciplines in front of all the other bosses for exaggerating and overdramatising some problems and delays he said were minor.  It turned out that he had not attended the previous meeting, and his second in command had reported details as he saw them with an indication of urgency which his boss did not want presented to all the other groups.  Since the two bosses could not agree, I copped the flack – and had the opportunity to practice the proverb that “a soft answer turns away anger” (Proverbs 15:1).

What is the lesson to learn from this?  Different people see different priorities, and having more input from different people helps to make this more obvious.  Don’t rely on bosses to know the nitty-gritty of day-to-day work or of interaction with customers.  Contrariwise, don’t rely on workers to know the priorities or commitments of the business.  Getting more input from more people makes it easier to understand the real needs of a project.