All posts by Stuart Jobbins

Chief Exec - Sofintsys Ltd. Would like to ensure the next generation of Systems and Software Engineers are better equipped for the challenge, scale and complexity that will be their world. Trying to earn a living while I try to make this happen!

Programme Management – Planning and Estimation

When was the last time you ‘estimated’ your project? At bid time? Post contract award? When the Project Manager was put in post? When the project ran into trouble? At what point was the requirement secured, complete, unchanging?

If you have defined your software lifecycle, and the processes to be used in each component of that lifecycle, a programme plan should be a natural output; an instance for that particular product where much of the opportunity for task independence is defined by virtue of the product architecture.

Most software programmes will consist of many parallel activities, which are likely to be in different phases of the lifecycle, following different processes. If the lifecycle management tools are sufficiently instrumented, many ‘waypoints’ are available as tracking information, with little or no overhead on the developers! The ability to convert all this information into meaningful progress is dependent on understanding the expected progress through the plan; a relationship that has to be modified to account for previous experience to improve estimation.

Because all programmes are unique, calibration values are purely ‘seeds’ for a new programme. Estimation should be a periodic process that reassesses the remaining programme based on the progress made on the programme thus far executed.

Traditional Programme Managers don’t get Software Programme Management! There is nothing physically generated that is a clear indication of progress. Components that are generated may just as easily have their entire value destroyed by what appear to be an innocuous change, so ‘Chickens’, ‘Eggs’ and ‘Hatched’ comes to mind.

The key to software programme management is differentials – i.e. the rate of change. There are two competing processes i) the generation of components and ii) the removal of errors. Even in agile i) is not complete until ii) is satisfied. During the generation process, we also create errors, whose correction is a generation process and so on. With the application of good skills, focus on the objective, and carefully controlled correction, this recursion is finite, as the number of errors diminishes with each iteration. We will see in a later instalment, that measuring this recursion, its number of iterations, place relative to plan can provide us with useful progress indicators.

Armed with knowledge of when things are supposed to happen (the Programme Plan and its associated Lifecycle processes) it should be possible to predict where errors will be detected and thus a component is complete. This depends on the component’s nature/interfaces, the point at which that component makes a feature contribution to the product and the process in which the test environment (in which the errors are due for detection and removal) is planned to be used.

For economic purposes, all software programmes strive to achieve a singular goal, the removal of errors as close as possible to their point of introduction, hence the lifecycle processes are usually defined with this objective in mind.

The most significant risk that a Project manager must deal with however, is volatility of requirement, as this has the ability to change the components, their interfaces, the architecture and may result in significant rework of componentry and plan. Requirement change is inevitable. How you plan to minimise the impact of change is key to the success of the programme. Recognising that risk emerges from volatility enables you to derive an understanding of risk and an ability to plan its management.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

 

Managing Engineers

If you’ve ever run a personality profile test, such as the controversial Myers-Briggs Type Indicator, across your software engineering population you might have guessed at the result, but did you ever stop to think about how that matches with a general population; or even more, stop to think about how that personality type deals with communicating with other parts of the population?

Well if you found that your software engineers were introverted, data junkies, with obsessive attention to detail then that would be no surprise, as this matches the demand of most software engineering jobs.

So imagine you are trying to be a good leader, using your enthusiastic, gut-feel for what is right, to champion the project while attempting to create a cohesive team by using your perception of their strengths and their perception of one another to identify the group, roles and organisation. Yep, you’re an alien!

Put software engineers in the room and, acting as proxy customer, give them a problem and they will a) not talk to you, but b) want more data, c) suggest solutions based on their own experience or domain and d) argue that theirs is the best solution, all without waiting for a complete description. Give them complete, structured, unambiguous data and an assurance of certainty and they will go off and generate a good implementation; leave anything undefined and you will need to revisit, to understand their assumption set!

Although they may make good abstract thinkers (there is not much physicality to a software engineer’s world) especially if they have been exposed to many and varied projects, they like concrete information, so not many make the jump to systems engineer.

The hardware (electronics) engineer may have a different domain, but can be very like the software engineer.

The systems engineer has to, at least initially, withhold judgement regards a solution, has to ensure that the description of the system is complete, analytically identify gaps and solicit information from the customer about system behaviour in those hidden corners. Yet at the same time, the system engineer has to be sufficiently expert in all possible solution domains to recognise the strengths or weaknesses of those solution domains whilst partitioning a problem with many competing attributes.

With an agile development, that ‘incompleteness’ can lead to significant refactoring, whilst in a traditional project the rigidity of the solution may cause the system to feel ‘brittle’ and ‘unforgiving’.

To manage software engineers you need to hide uncertainty and remove fear of rejection; Allow them to work productively on what is certain and structured and keep their gaze, and worry, from the incomplete; Introduce their ‘date’ at the other side of an interface and act as chaperone.

As far as programme management is concerned, the big problem is risk management. Asking a software engineer to risk-reduce a programme, by experimenting, and you’ll end up with an ostrich. Risk management tasks needs to have structured objectives with clearly defined scope.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

 

Multi-Geography Development

Are you part of a large corporation? Does software and system development take place in multiple teams? Are they geographically displaced? (Recognising that for most software engineers 4 feet and 4,000 miles are the same!)

Most corporations tend to play to particular market segments, maybe several, but often multiple products within each segment. Business credibility makes this a natural alignment.

Those markets adopt certain standards, both of process, but also of technical interfaces. Even if you are making a different product to other teams, if you are serving the same market segment, likely as not you are duplicating efforts. In some cases the standards may be common across market segments, or the processes acceptable across multiples… so there is even more potential for sharing. The corporation sees duplication as wasted money… engineers see it as control of their own destiny!

Sharing takes effort, especially communication effort (which commercial software engineers seem to lack, even though they perform differently on social media!) and a huge dollop of ego-suppression, negotiation and compromise skills.

This topic has a lot of commonality with the Product Line theme previously, regards behavioural characteristics and organisational change, although technically the answers for re-use in these cases are somewhat more pragmatic and probably already available to you.

But let’s take a step back…

If I were in a small outfit, I’d have to focus on my expertise and the specifics of my product that were valuable intellectual property to me. I would look for commercial solutions or partners who had credibility to deliver bits I couldn’t afford to spend my time developing. I would have to make sure their products offered the flexibility I needed, or live with their restrictions (or go somewhere else). In other words I have to relinquish some of my wish to control, for economy of development.

…see a parallel here?

Why don’t big organisations who serve particular market segments (distinguished by both process and technical standards) organise themselves as commodity component developers and, separately, application developers/ system integrators?

Architecturally this would make sense: platform independent applications, sitting on commodity OS, sitting on (various) commodity device drivers, sitting on (several, possibly modular) electronic platforms, using commodity protocol stacks and standardised interfaces to sensor and actuation systems.

This would also play to individual skill strengths, improve reliability as one set of design, implementation and test sources and provide a clear technical ownership, a coherent technical community, authority and leadership. Of course the disposition of the groups could be virtual, with individual members of a co-ordinated commodity team being dispersed, but more realistically the development and test environments would require them to be co-located by virtue of their commodity group. You could even chose to serve the commodity internally or externally to meet business needs.

< humour_mode>

Ah,… now I remember, it’s about those egos and control… it’s not technical, it’s people.

Nothing anybody else will develop will be good enough for me, they won’t accommodate what I need, there is no way of communicating it and they would never develop it in time. For example, how would I know what component I need, how would I access it and how would I raise change requests on it that I could track?…

… it will never meet my safety, security or reliability requirements, I will have to deal with failures as no-one will warrant its behaviour and as for test evidence….

… and I’ve never heard of Open Source, so I know there is no development model that could possibly work like that, even if I could reproduce it all inside the corporate network!

Damn, if only these Linux served Web-Host, Word Press Blog and AtMail applications weren’t so feature rich and reliable, I could write it all myself in a few years!

</ humour_mode>

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

Single Product or Multiple Product Variants?

There is no way to beat the cost of a 1-off custom product… but how often do you make a ‘ground-floor-up’ new product?

The cost argument is true every time, for an isolated product. But how many of your products are really an evolution of something you have done before and, tellingly, for which the engineering community are claiming large percentages of savings through re-use? Does it deliver?

If you can relate to that, then have ever thought about standing back and building the common parts as deliberately designed for re-use and just dealing with the customisations? Did you try it? You have to invest in making it work (which makes it more expensive), but obviously if you are ONLY working on the custom (application) bits for the second (and later) iteration, it must be a LOT cheaper. Did it work? Were you able to configure and deliver product as you expected, for those much improved costs?

Well, it may be obvious, but it’s not as easy as it looks to deliver on this technique, known as Product Lines, but get it right and it really delivers… more than just technically… it changes your organisation, culture and even the business connectivity between marketing and engineering! Planned, re-use without deliberate design doesn’t come anywhere close.

The prizes can be some of 10x productivity, 40% cost, 10x quality, 10x faster to market. Don’t believe me?… then look here or at these cases studies. Lots of industries use these techniques every day, and it clearly should work for those with high product repetition rates, large volumes, closely related functionality and, if you regularly develop similar products, it could for you. What you are doing is reducing the recurring cost burden, and with a wise investment, making it a non-recurring cost.

But if you think about it, it is a significant culture change:

i)                    You are asking the vast majority of engineers to work across-projects, on common (domain) assets, and very few engineers (if any) to work on a specific customer (application) project  – Project managers won’t like that (Loss of power/control).

ii)                  You are asking the company to use the vast majority of project funds as a ‘pool’ to serve the needs of many projects, rather than accounting each on its own, making it much tougher to spend control – Finance won’t like that (Loss of accountability).

iii)                You are asking the designers to define frameworks that are capable of being ‘dressed’ with a ‘pick-list’ of features with potentially sub-optimal connectivity or performance – Architects won’t like that (It’s hard and counter-intuitive!).

iv)                You are asking change control boards to separate scope and decisions for project specific or common changes, the latter needing all project representation to be quorate – Configuration Managers won’t like that (Difficult to make decisions).

There are numerous examples of this working all around us, from automotive assembly lines to software and many Open Source products (e.g. WordPress). The reality is, even if done right, the investment breakeven is reached at say the 3rd product iteration – so you need to hold your nerve.

The keys to delivery are well-documented, but centre around recognising the scope and variation of your market, the alignment of quality attributes and a steely focus on delivering a design that delivers just those patterns of configuration that you need (or forecast you need) rather than building an ‘all possible combinations’ product that drives complexity and huge cost.

Every customer wants a unique product, every supplier wants to deliver what he has, or a minimal change – have the best of both worlds.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

 

Software and Systems Collaboration

Why collaborate? Doesn’t this expose my IPR? Don’t I stand to lose more than I gain?

Well I think the answer is a resounding “No!”, but it really depends on who you put in the collaboration forums.

I have put a better prepared paper on this topic on my website here, but as I have accepted to chair NMI’s UK Systems and Software Leaders Forum, you would expect me to be a proponent. Over the last year this forum has exchanged ‘problem lists’ and there is a significant amount of common ground (an opportunity to collaborate and save costs on the solution). You can see a video report on my feedback to NMI here.

Where there has been expertise in the group, we have shared, in abstract, how we have gone about it (often 2 or 3 member companies will, independently, have had similar approaches in the solution) which gives the remaining members a flying start…  and some useful contacts/material, but just proves we are also wasting valuable engineering resource in this duplication.

The over-riding impression is that Software (and especially Embedded Systems software) has a large (UK) population who have been very innovative at solving problems (and I don’t mean just Technical ones!). Any one company only sees a small proportion of that problem space, and more than likely those problems already have tried and tested solutions, by at least one other party.

If no-one has a solution to a common problem, then chances are that several members want a solution (opportunity).

If no-one has the same problem, we could probably work out, from our respective networks, who might have an interest in the problem and its solution, or be best placed to define and champion it, industrially or academically.

The bigger our community of industries with common scope, the more we stand to benefit, and the more leverage we potentially have! The key is to have attendees who can ‘abstract’ the problem from the commercial sensitivities of their business, and equally take away another businesses abstract and understand how to apply it for themselves. So good abstract thinkers only need apply!… but then again isn’t that a fundamental trait of a good software engineer?

I hope to get an article in the NMI yearbook for 2014 on this – due for publication in about March.

In the meantime ask yourselves this: Is the collaboration from industrial representatives on Standards bodies entirely altruistic, or is it to sway decisions in favour of their own business’ products and thinking, gain competitive intelligence, spot key talent and, for the individual, a network and career opportunity for seeking out those with more advanced thinking?

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

 

Software Costs

In all engineering business poor quality equates to cost; this is equally true in software systems. Lack of quality inevitably means re-work and expensive scrap (effort), and if it escapes to the customer, we get cost of warranty, customer dissatisfaction, reputation damage as well as the distraction of fixing things in a hurry (which consumes your management and engineering effort).

Conceiving a simple, well-structured product with a clearly defined and understandable architecture will help keep all the engineers working to the same goal, but their individual skill level and experience may differ. As software is not bounded in physical, measurable, materials but is a human endeavour, structural definitions alone are not enough.

Humans make errors, software is made by humans, therefore software will contain errors. Not all errors will be detected, but not all residual errors will manifest as faults, and not all faults will manifest as failures, so a product full of errors may never fail!

An unfortunate issue for software development is that software development automation tools are in themselves software and subject to the same problems.

Most experts agree that for software, processes define product quality, not unlike manufacturing. The choice of rigour (adding more feedback cycles for validating we have the right product, adding more events for verifying we are building the product correctly) determines how many errors we remove and therefore the ‘quality’ of the production item.

The cost of software development is directly related to how quickly (after injection) an error is detected, and the set of processes involved in the round trip of correcting and verifying its removal. If rates of injection were constant then: Less detection steps => errors found later => longer correction process => greater cost of correction. The reality is that rates of injection are not consistent, but are highly dependent on expertise and experience of engineers, but more detection steps => slower development=>more cost of development. However, it is generally accepted that error correction costs increase significantly with error duration before detection.

Early investment in detection and correction is easily wiped out if the system definition is volatile, hence high-rigour systems (e.g. Nuclear, Space, Aero) tend to be less able to accommodate late change without significant impact on cost or timescale; but then we expect these systems to be ‘right first time’ or at least accommodate any faults detected in operation!

The cost of software ownership is directly related to the number of fielded failures, which in turn is related to error escapes, irrespective of their root cause (and system change is the most common). Lightweight processes may save on development costs (and indeed cost of correction) but potentially field more errors/failures.

If the business offers warranties, has service level agreements or maintains a high reputation for robustness, lightweight may not be an appropriate answer, whereas for ‘disposable’ products (e.g. Mobile Apps) or prototypes, lightweight processes are key.

Be warned: Most businesses find it difficult to get their software engineering teams to live different process rigour levels for different phases or products!

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

 

Service Levels – Software enabled delivery and measurement

Building variant products in software defined systems can be used for market position both by offering different features, at different price points, but also by offering different service levels. Typically service levels define and offer minimum or expected goals for ‘availability’, ‘reliability’, or ‘performance’ say, and offer solutions to issues like failures, warranty, or problem management.

For these service level agreements (SLAs), prior measurements are required to understand the potential business benefit, and ongoing measurements to ensure the appropriate quality of service, or even use/abuse by the user. Software-based control systems are well placed to collect and inform the business and provide the ongoing monitoring.

Information from monitoring systems is routinely used for both Condition-based maintenance and Predictive maintenance in many industries in large electrical machines, jet engines and automotive components. These enable optimal service periods, replacement of marginal components to minimise future shop visits, improving availability and even initiate service events to mutual benefit of customer and service shop. The monitoring information can be used as feedback to inform the designers of usage scenarios, the business of excursions outside the warranty or SLA and the service bay with diagnostic information, both live and historic, in support of fault investigation.

The business trick is to use the existing control system sensors to maximise information or its synthesis, and only augment this sensing set when there is clear business value to be gained. Additional instrumentation, its signal processing, the transmission of information and its analysis all add complexity, cost (both unit and recurring) and delay.

The more connected our social world, the greater the opportunity for making this information more immediately available, carry more contextual information (e.g. time, location, user demands, even weather!) and enable businesses to refine their offerings, more value opportunities, or even additional products.

Technically, the key problems are collecting valid (and validated), accurate, information (differentiating signals from noise) without losing valuable transients, local processing, compression or selective storage, opportunities for (robust and secure) transmission which balance immediacy, bandwidth, and cost and off-line analysis of what potentially could be large, continuous, streams of individually correlated, but systematically uncorrelated, data.

For exceptional systems, these technical problems may be exacerbated by adaptive techniques for monitoring, storage and transmission both from local decisions and those decisions commanded from the larger off-line analysis.

Of course the determination of the appropriate margins for decisions based on the information is key to business opportunity and risk!

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

 

Systems Engineering, Interfaces and the effects of System change

A System Engineer’s role is to understand the customer’s need, unambiguously document the intention and use, including validating it with the customer, and then define and describe an ‘optimal’ solution in terms of components that can be engineered independently, yet will integrate to deliver the required capability.

Obviously an ‘optimal’ system is subjective and needs further definition of the qualities of the system and at the same time respond to the constraints that the physical manifestation of the system solution will impose. Lots of experience or Crystal Ball gazing required! Finding a balance that will satisfy the customer is considered success.

 

A recurring theme, then, is “understanding the customer”, including immersion in his world; and playing the proxy customer for the development team during design, integration of components into the system, and validation. (We will deal with Verification, Validation and Integration in a later instalment.)

The customer may not be singular, but a series of ‘actors’ (human or machine) on the system who present different interfaces and needs. In large, or long-lived, systems these needs (and interfaces) may change and those changes may need to be accommodated. If this is the expectation, then the system engineer will also have to deal with the necessary future-proofing, and pass that flexibility into the component definitions.

System change is the single most disruptive attribute to Software Systems development; almost all cost and schedule overruns can be traced back to this root cause. System change (especially change that crosses system component boundaries) must cause system re-evaluation to understand the impact, or opportunity to contain, component changes and the influence on the overall capability.

In order to mitigate such change by design, system architects (a particular role within system engineering) will use techniques such as interface standardisation, modularisation and layering to partition components, create propagation boundaries and separate concerns; in general however, these are at the ‘cost’ of some optimisation, say of processing power, efficiency, speed of response, weight etc.

Change is inevitable, whether through component obsolescence, change of use of system, or in search of improved performance. Good systems engineers will design solutions that can accommodate the most probable causes at low impact, but as system size, complexity and lifetime increase be prepared to invest in system engineering to minimise the total cost of ownership.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

 

Brand Positioning and how Software can help product variation and allegiance

As a component supplier or an Original Equipment Manufacturer (OEM) you will be providing each of your customers/markets with a custom application, whilst behind the scenes, re-using as much from other evolutions of product as possible.

Software and re-use have an exceedingly oversold pairing when looking at business economics, but there are strategies and development processes which may be of economic use. One such strategy is ‘Product lines’ which we will address in more detail in a later instalment, but is a mechanism for changing the cost model of producing variant products, centred on an architectural approach and well-managed variation points; It’s widely used in automotive, mobile phones and the like but may be economically deployed on lower volume industries.

For applications whose capability can be defined by software (‘feature content’) it is common to market a premium product with ‘full-house’ capability and other market offerings with various sub-sets of functionality. Delivering the premium product first provides the greatest development burden, but usually fastest delivery to other market price-points; or alternatively a way of incrementally introducing features of value; both need to be clearly architected appropriately to achieve the overall capability and matched to the business’ sales strategy, price-points and timing.

Getting the ‘patterns’ of feature sets right needs to be a symbiotic relationship between marketing and engineering, to satisfy the set of valued configurations, lest we fall foul of driving in needless variation and complexity (which in turn drives cost and programme) as we saw in the last instalment.

User interfaces are an area where there is an opportunity to build a brand image, and with it, brand allegiance; however the design of these should not be left to engineers without the necessary specialists skills in human interface design. As the ‘face’ of the product, it clearly needs to respond to the customer’s needs, be simple, robust and reliable, but also fit for the environment in which it is to be used.

Customers are often poor at expressing what they want, but recognise what they don’t like, so expect lots of iteration; an obvious home for low cost development prototyping (see previous instalment). Unless your market produces applications for user (mass-) customisation such as website design or workflow and management summary tools, avoid building in flexibility that could destroy the ‘look and feel’ you wish to establish, especially if this is to extend to potential vertical markets for companion products.

Human Machine Interfaces present a significant opportunity for mis-operation, whether accidental or malicious, and poor robustness here can quickly frustrate the user, or even lead to accidents. In the modern, connected world, any weaknesses are quickly disseminated and rapidly tarnish reputation.

______________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)______________________________________________________________________________

 

How do I know if my Software Engineering matches market expectations?

You’ve bid for, and won, a new contract, or conceived a new product, but do the engineering costs truly reflect the expectations you have as a business, and how are you going to assure it’s aligned and remains that way?

To be profitable you need to get the timing right, so that determines development timescales.

You know what the market expects in terms of product reliability and the effect failures will have on the business, because you understand the sales forecasts, the intended market life, the warranty you are offering, and customers’ expectations of your brand.

There are “must haves” in your feature content which give you market position, but also lots of “me toos” that you can’t leave out. To get the product sales life, you require flexibility to accommodate upgrades, ward off the competition, or respond to the changing market.

All of these factors have an impact on product engineering and, if software is a constraining factor, will be significant for software systems engineering, where they will need clear assignment of priorities. Failure to do so will have engineers ‘invent’ flexibility you don’t need.

Key product characteristics, risk recognition and management, choice of development processes, sources of components, team capability, structure and organisation, intellectual property, partners and suppliers all play a significant part in starting down the right track and as a reference point for remaining on track. You need to act as proxy customer and set these out for your engineering teams.

Change and flexibility both drive cost in, so reduce them as much as possible… and moderate your appetite for change! Unrealistic timescales, compressing programmes and overloading resources are also the biggest drivers of cost escalation (and business failure). Good businesses concentrate on what they are good at, or those items they need to protect, and use partners or suppliers to source the remainder… the same should be true in software, but it needs appropriately capable software management internally and overseeing the supply chain, so get the best you can and use it appropriately.

The choice of software engineering processes dictates the product quality attributes and that includes the balance between initial development investment and cost of managing fielded failures (unreliable product), hence this choice should be an informed business decision. Different processes for risk reduction and production may also be inevitable and contrasted with ‘prototyping’ in other industries… be realistic, don’t expect to salvage much of the prototype into a product, or your prototype is over-engineered!

We will talk about Programme Management, Project Organisation, and Sourcing including estimation, cost relationships, measuring and managing programmes, and capability assessment in later parts.

______________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)______________________________________________________________________________