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!
Sourcing

Sourcing – Open-Source

Leave a comment

It is clear that, where there is sufficient common interest, an Open Source philosophy is capable of providing high quality solutions. There are many examples where the high number, and depth of expertise, of reviewers has clearly demonstrated development of high reliability solutions.

The problem is however that these solutions are then entwined with licencing conditions which aim to maintain that ‘freedom’ of information (and sources) such that opportunities for developing commercial product that contains components that are open source are essentially denied because the additional developments have then to be disclosed, rendering no commercial advantage in such endeavours.

It is however possible to make a commercial business out of value-added activities around Open Source (e.g. Linux packagers like RedHat).

From a sourcing point-of-view then, what are the conditions under which you should consider the use of Open Source? If you can collect no revenue from your bespoke developments once including, or a development of, Open Source components, then what other rationale might suggest you join in such endeavours?

In Eric S Raymond’s book “The Cathedral and the Bazaar” he alludes to a number of business opportunities, some of these are paraphrased here:

  • You could build an open-source tool (a ‘loss-leader’ approach) that enables people to easily access your paid-for service.
  • You can bundle in software that provides the user access to the functionality of your platform, when you are in the business of selling platforms (e.g. microcontrollers, or even Silicon IP) but not developing software. This becomes significant for commodity platforms who wish to separate their customers from the concerns of component obsolescence.
  • You can contribute to solutions that may be imposed as standards and are therefore not product differentiators, such as communication protocol stacks, and in doing so reduce your risk.
  • You can offer a transition from closed-source to open source as an ESCROW policy where the customer requires long-term accessibility, including potentially through the derogation of functionality on which he depends, derogation of the product, or supplier business collapse.
  • You can influence open-source tooling to provide features that would only otherwise be available in expensive commercial solutions e.g. Configuration Management, Version Management and Change Control, thus obviating the need for large capital investments.

Raymond identifies the major criteria for going (and by implication using – as this forces you to “go”) Open Source as where:

a)       Reliability, Stability and Scalability are critical

b)       Correctness of Design or Implementation are not readily verified other than by independent peer review

c)       When the software becomes a business-critical capital good (i.e. control of the business for customer)

d)       Establishes or enables a common computing or communication infrastructure

e)       Key methods (or their functional equivalents) are part of common engineering knowledge

“Open-source makes least sense for companies who have unique possession of a value-generating software technology, which is insensitive to failure, can readily be verified by means other than independent review, is not business-critical and which would not have its value substantially increased by network effects or ubiquity.”

Although with open source an individual, other than the product champion (‘owner’ in as much as he caretakes the development), has little direct authority on the product and its evolution, he may significantly influence development by offering suggestions for change. Depending on the capability and acceptability of the individual (or group) contributor, this could range from suggestions on potential features, to ‘patch’ proposals that offer an easy route to adding functionality to the implementation and its documentation.

The tooling, rather than delivered product, model offers many more freedoms to use open sources as seed material for bespoke non-commercial tool or method developments, but has as many pitfalls, as once ‘branched’ from the root-stock and its development community, so forfeits the maintenance, support and evolution.

___________________________________________________________________________

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)___________________________________________________________________________

 

Sourcing

Sourcing – Selecting and Managing Partners

Leave a comment

So, you have decided it is not profitable to develop some of your product yourself, but to get those components developed in the supply chain… but Where do you go? How do you know if they are right for you? Can you trust them?

Well hopefully in making the decision to not do it all yourself, but to find a partner or supplier, you have already benchmarked your own capability with the capabilities that exist elsewhere, so you have a source and an initial assessment of the potential suppliers. If not you really need to go back and re-appraise the decision on Make/Buy!

Typically that initial source of supplier information is from word of mouth, a trade body membership catalogue, reports from technology analysts or researchers (e.g. Gartner, Forrester, IDC, Ovum, Frost & Sullivan).

For most of the ‘physical industries’ (e.g. mechanical manufacturing) location of the supplier is significant to ensure a consistent logistical delivery, minimum transport costs etc. With software and an interconnected world, at first sight, this is not an obvious priority.  My personal experience however is that ‘accessibility’ of the supplier will determine the amount of time that you will spend on oversight and the supplier relationship, especially when there is a need for ‘intervention’.

Even for software supply, a nice glossy sales brochure, some historic glowing testimonials and sample CVs doesn’t give you the same information that you will get as a seasoned professional in being invited for a visit into their development offices. Be prepared to withhold judgement on the sales ‘spin’ until you know the details of what you will be getting.

Safety, Security and Quality are ‘cultures’ which all employees have to live… and the supplier’s ethos can usually be picked up from a visit to the development offices, much like you would when visiting a mechanical workshop; If tools and consumables are not neatly organised, put away after use and obviously well maintained – you need to be going somewhere else! If there is an absence of fire extinguishers, or access control mechanisms, it will be self-evident that these traits are not cultural.

With software developers, if a randomly selected engineer cannot tell you in detail how he interacts with the change control and configuration management processes, without resorting to the manuals, then walk away.

For any ongoing project, the software manager and project manager should know who their key technical players are (and not just the senior people, the real influencers); what the significant aspects of the product architecture are; the complex or risky areas of the development and what they are doing to understand them; and be at ease discussing the sort of metrics that indicate quality components are being generated on time e.g. the number of iterations of a component (from version control), where those evolutions were triggered (i.e. the types of error that escaped, where they were detected and resolved); how much effort is being consumed, how that relates to the plan, estimates and the consumption of contingencies.

You are going to want the same information made available to you, on your project, to give you the confidence they are conveying. If the information you need is not available, then you can easily imagine you will be asking for it later, once a crisis is looming or already impacted!

If it’s a small supplier, where all the design aspects are in 1 person’s head, who is working vast numbers of hours, including weekends… then irrespective of the heroic efforts… it might imply fragility that you cannot depend on.

Ideally you need a supplier who shares the same culture and ethos with regards the attributes you espouse, after all your product, like a chain and weakest link, will typically demonstrate the quality attributes of the poorest component.

You don’t want to be micro-managing your supplier, you want him to have the level of information to resolve his own problems and be a good supplier, whilst appraising you of risks that you need to jointly manage. Expect to need to invest and develop some of these traits in your supplier, so that they deliver what you need.

Ideal commercial arrangements should, like managing children, incentivise and reward correct behaviour, and admonish wrong behaviour without being punitive. Manage not only the development within the supplier, but your rights to the work, to give you the flexibility and portability you need, in the same way that the Make/Buy decision will have informed you about the level of dependence and exposure protection you need. In my experience, escalation to punitive legal clauses means your product is lost!

___________________________________________________________________________

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)___________________________________________________________________________

 

Sourcing

Sourcing – Make/Buy Decisions

Leave a comment

In this day and age it is key that a business spends its precious resources on things that add significant value to the product. In software developments it is all too easy to assume that you need to develop all of the components from scratch and with it the opportunity cost of those components.

There are often many alternative sources for those components, some come with a licensing cost, or at least restrictions, some with the cost of using a more suitably qualified partner… and almost all come with an overhead of assessing the relationship you will need with the supplier or an assurance of the quality of the acquired product to support your business.

The decision on ‘do it yourself’ or find some other source, should not be overly emotive. There are simple, and very visual, techniques that will help you through the ‘postioning’ and ‘value’ judgements that are useful with both technical and senior management audiences. Such techniques are more fully described here. https://sofintsys.com/papers/Make%20or%20Buy.pdf

The Make/Buy decisions will be swayed by the strategic intentions of the company, its expectation about what knowledge it needs to nurture and grow, or what is ‘commodity’ experience that is openly and cheaply available.. and a pragmatic understanding of current capability and ability to immediately embark on some endeavours without more expert support.

In software, there are many specialist field which may not be matched by own capability e.g. the deeply embedded skills that have an electronic bias and register-level competence with the devices, hardware programmable devices and real-time performance; the application programmers who work to a well-defined API and rarely have to worry about the platform; the user-interface specialists, who understand the ergonomics, physiology and responses to fatigue of repetition, error-prone operation due to layout or colour use. It is rare that individual engineers are able to be highly skilled in more than one of these areas, although it may be perfectly possible for them to create solutions!

Once you have made the decision to acquire software (whether as a commodity purchase, or as a commissioned component or product) you could do worse than look at these checklists. https://sofintsys.com/papers/Software%20Acquisition.pdf

These can help you set out an objective set of questions so that all suppliers can be assessed equably. This can be of significant importance once such as ‘selection’ process is passed off to a commercial or purchasing team, as it enable an appropriate focus to be placed that will still need appropriate technical judgement of the answers to differentiate the most appropriate supplier… whilst keeping the engineers at arms length from the ‘price’ negotiation, or individual supplier bias… attractive in many large commercial organisations.

Whatever your selections, the necessity of assessing current skills, must be a combination of judgement of historic capability and the intention to support skill development with necessary training, the selection of highly productive tools, the protection of the value and intellectual property that is created and a clear connection to the business of market position, the technical and commercial offerings that match sales opportunities.

These attributes must be clear for both your internal team, but also the measures by which your designated suppliers and partners have to be judged as successful.

___________________________________________________________________________

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)___________________________________________________________________________

 

Project Organisation

Project Organisation – Influence and Authority

Leave a comment

The influence of Technical Authority on the Project timing can often cause tension with the Project Manager. This somewhat traditional battle is usually because the Technical Authority looks for answers that are the cleanest, elegant and most technically correct, whereas the Project Manager is usually looking for solutions that will give him the best position in a negotiation with the customer (usually time, cost or scope reduction) and the business.

If there was nothing technically challenging to a programme, there would be no risk, no need for a technical authority and the project manager would only need to progress chase the various packages of work, their cross-feeds and dependencies, externally supplied equipment, subcontracts or services. But if you’ve ever done an objective 3-point estimate on a software programme, you will recognise that the ‘ahead of time, on content, below cost’ area is very close to the ‘on-time, at cost’ marker …and all too frequently that tail programme (post the nominal ‘should-cost’ point) could run to two or three times nominal duration (or of you are in a Nuclear programme, probably 6 to 10 times!).

As a Technical Authority you want the Project Manager to help ‘manage’ the customer’s expectations, stop the customer making changes and generally damp his volatility. Additionally you want him to actively manage all your supply chain feeds, so that any dependent material or service arrives on time, is appropriately validated and commissioned, fully functional and well supported. You also want him to manage the department politics, reporting and any other administrative distractions, like presenting the product architecture a 100 times! Contingency for you is tolerance for dealing with things you might have overlooked, or due to the summing errors of a myriad of low-fidelity component costs.

As a Project Manager you want the Technical Authority to clearly identify the risks in the programme, how his product (solution) architecture mitigates, or accommodates change (brought about by those risks… and any reasonable change that the customer might want), and that all the quality attributes (cost, performance, safety, etc) have been thoroughly reviewed, by an appropriately skilled peer group, to give you that warm confident feeling. You want to see that all the disciplines (electronics, software, firmware, testers, etc) are aligned in their technical understanding, are clear on the product partitioning (and implicitly the boundary of their work and explicitly its interfaces) and in agreement on the ability to deliver their part against the programme dates. Contingency for you is your margin (against the Technical Authority’s failure) to ensure success at appraisal.

So why the tension between these senior positions? Surely their objectives are the same? Well… yes, but no… I’d also refer you back to an earlier instalment on personality types in ‘Managing Engineers’.

In being assessed against his objectives the Project Manager will likely be judged on Quality, Cost and Delivery; Cost and Delivery he controls by virtue of programme duration and resources (which he owns) irrespective of the technical impact; and quality… well that’s up to the Technical Authority to deliver… and it’s pretty subjective anyway (in the way a Project manager reports it!). Project Managers tend to be like teenagers, they know the price of everything, but the value of nothing. In short they are driven by praise from their seniors and its promotional connotations.

The Technical Authority will be judged on how well the solution meets the customer’s current expectations (not necessarily the specification!) including all those changes, how robust it is and how pleasant the final system is to use. (Note that none of this assessment will care about how technically pure the architecture was, or how clever some particular feature of the design or implementation is executed, that the solution is ideally placed for future extension, or that its creation was severely hampered by being denied sufficient capacity and capability of resource at the appropriate times as defined in the plan). In short, he will be judged in the same way that most consumers judge books or wines, by their covers or labels… and the price, whilst affordable.

The key to ensuring cohesion, is to use the Change Control process equably for both Technical and Programme changes, peer reviewing the impact, and making PROJECT decisions (both Technical and Programme) for ALL change… as there is no such thing as a No-Cost change! This ensures that programme changes are NOT entirely at the disposal of the Project Manager, and Technical changes are NOT entirely at the disposal of the Technical Authority.

___________________________________________________________________________

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)___________________________________________________________________________

 

Project Organisation

Project Organisation – Team Skills and Assessment

Leave a comment

In an earlier instalment we talked about Managing Engineers, with some recommendations of understanding the personality types and a brief introduction to the idea of Skills Frameworks. In this entry I’d like to revisit skills frameworks to look at some of the practical benefits they can bring in organising a project team.

Firstly, it should come as no surprise that the skills framework can be used as an objective assessment tool, to gather the capabilities of your engineers in terms of the roles they have previously fulfilled, to what competence level and how recently.

If we repeat this over a number of project teams, as a Resource Manager for instance, then we have the basic material from which to derive a team of individuals who have the appropriate combinations of skills for individual projects… rather than just go for the people who have recently become available!

As roles are usually made up of a set of skills, each performed at a certain competence level (accepting that these may be different inside different companies, or for different regulatory or market needs), it is a simple task to do gap analysis between different roles and establish the obvious ‘growth’ route to the next role from each particular role. Typically this is a move to a role where either a new skill has to be added (possibly at a low competence level) or the growth of a skill is required.

As competence levels usually identify stages from the novice, through minimal supervision, to a supervisory role, then supervision of increasing numbers, on projects of increasing degree of difficulty, to expert… these increments are easy to judge (use the skills framework for regular periodic re-assessment). Some skills degrade with lack of use, so you may wish to ensure that sufficient continuous professional development is evident to maintain a skill (at the required competence level) that is not regularly practiced.

Beware though, although competence levels are typically identified numerically, these are labels not values. Do not attempt to do some mathematical or numerically algorithmic assessment of skills and competence levels as roles may have different spans; A software architect at a level that needs supervision on a complex project, may not be equivalent to a software test engineer who is a team leader on a simple project. If your job descriptions, like many, include several roles, the numerical score will not deliver you “the most valuable person”, or “the most loaded occupation”.

What is valuable, however, is the recognition when a skill is unique, or where you have very few individuals, as this relates to the fragility of the organisation, as well as giving indications about the ability to deliver concurrent projects. Weaknesses of these sorts should be the target of skills action plans, to generate, mentor or acquire the requisite additional strength. The reverse is also true, where skills are plentiful, skill plans should look to diversify those roles into different growth paths, or by increasing key individuals’ competence levels.

So at the absolute levels you can appropriately partition your staff for roles they are suited, understanding their growth challenges and administering appropriate support. Over a period of time, however, you can also understand the rate of growth by ‘trending’ the changes in assessment patterns (again not numerically, except possibly with competence levels within a skill, as part of a role of an individual’s job!).

Both absolute and trend information should help support individual training plans, ambition and career paths. They can be used to set and assess targets, used to inform on performance assessment or suitability for promotion or awards, but again a note of caution that competence levels are labels and not those labels are not equivalent across skills; not all skills require equivalent intellectual or effort levels and roles depend on the product, process and market expectations; jobs are often a tailored mix of roles, especially when staff are in short supply. So a skill framework should not be used as a blueprint to ‘cookie cutter’ a set of team members for a project, or be used blithely across a population for comparison.

___________________________________________________________________________

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)___________________________________________________________________________

 

Project Organisation

Project Organisation – Variant Product

Leave a comment

As we saw in the previous instalment, few businesses exist purely to make a single product for a single customer, but sell variations of the same product to many customers. Few products can be assembled solely from pre-configurable parts (known as domain assets), but often include specific parts unique to that customer (application assets). The business imperative is that application costs be minimised and domain utilisation maximised.

But how do you organise many project teams to collaborate to achieve this, when individual programmes have different customer deadline, developments will be out of phase and every project has their own budget?

Let’s be blunt… it’s a significant culture change… and one that won’t be universally liked, but it can bring real business benefit, but it won’t for probably at least the first 2 projects. You are trading initial investment against incremental investment per project.

Marketing: Get them to declare the totality of products and its variations that they see, now, and as all future opportunities. They need to provide this, after negotiation, as a contract to Engineering; Engineering commit to deliver the engineering costs for these products far cheaper than they have previously on a per-product basis, over a set of say 3 or more products. Engineering should refuse to provide (at a Product Line cost) anything that is not declared in here.

Engineering: Analyse the product variations declared by marketing and produce a ‘feature model’ that defines all domain assets (sufficiently common that they can be provided using a designed-for system of pre-configurable variation) and commit to it in the contract with marketing.

Project manager’s and Budget holders: Get them to declare how much of their project is claimed as re-use, in traditional approaches… and deposit all of that portion of their budget in the ‘domain’ pool – from each and every project.

Domain Team: This is, by far, the largest part of the Product Line resource – if it isn’t you are going to fail. They work on all the common (domain) assets on behalf of all projects. They do this by designing for all the ‘designed-for’ market of products that marketing have defined (and nothing else) and testing for all required combinations of configuration. They provide a configuration control system that gives access to the components for every (application) project and a system that details how each component should be configured for their required purpose, along with the test assets for that configured item.

Application Team: These should consist of a minimal amount of personnel, possibly as few as 1 or 2, to work on the specific customisation required by their project customer that cannot be produced from configuring domain assets. They also are responsible for configuring domain assets to suit their particular project, integrating components into their build and testing the ensemble as a project application.

Project Technical Authority: They only have ‘authority’ over application components (i.e. components that are unique to their project). They have responsibility for ensuring their project is represented in the definition of domain components. This is also true for ‘change’ and their change control board scope.

Things to think about are: the configuration management of domain assets; the change control mechanism (how changes are assessed for impact and changes authorised and agreed); component compatibility; understanding the impact of errors when detected in un-configured parts of components and within specific configured parts of components; tracking components and their configurations into product… and in which the error will be manifest; the configuration process.

I can recommend some good practical experience-based reading Software Product Lines in Action.

___________________________________________________________________________

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)___________________________________________________________________________

 

Business, Development and Test, Programme Management, Project Organisation

Programme Management – Customer Application / Domain re-use

Leave a comment

Few businesses exist purely to make a single product for a single customer, although this may be the origin of many companies, in general it is unsustainable as a business. The obvious step is to sell the same product to many other customers, but unless the product is truly ‘commodity’ then each customer’s requirements are unlikely to be identical. This takes us to the logical next step of mildly variant products; the majority of the product and its mechanism of manufacture, stay the same, but minor variations are accommodated. These ‘customisations’ alter the characteristic of the product to meet the variations the business market needs to address those customers’ needs.

Buried amongst all that simple logic is the business requirement for the ‘customisations’ to be ‘near-zero’ cost so that the manufacturing costs (and its associated selling price) remains largely consistent across the market for near-commodity products. Those costs come from recurring costs of the variant manufacturing, materials, processing etc and the non-recurring investment needed to re-engineer the product, its manufacturing etc.

Software has a distinct ‘edge’ over physical product in this play:

i)                    It has little or no manufacturing costs (it can be replicated at near zero cost)

ii)                  With no ‘manufacturing’ investment, its non-recurring costs are in product engineering and test

Software re-use has had a bad press for many years, deservedly so if you look at the cost of engineering ‘follow-on’ products. In large volume markets, where amortizing these costs is insignificant, this may be acceptable, but in general, variant product from ad-hoc re-use is too expensive.

Deliberately designing for re-use has not always delivered the cost benefit. Obviously these designs require a bigger initial investment, but variants should be able to be realised cheaply. Unfortunately there are some business keys that need to be maintained to make this a business success, which are rarely championed or maintained and, as a consequence, the advantage is often frittered away, by well meaning, but misdirected, engineers.

Variation drives cost, both in design and in test. Engineering in ‘variation points’ in itself is not difficult, but combinations, and in some cases permutations, of use of those variation points can quickly become uneconomical. The reality is that not all possible combinations of variation are required and although they may realise a legitimate product, may not be a useful, or marketable, solution. The interaction of variation points, in providing a ‘designed-for’ product is then key to minimising the cost and risk in engineering. This interaction can be described as patterns of use of variation points to describe particular product variants. Managing these interactions are the keys to the techniques known as Product Lines.

Successful variant product strategies come from recognising your potential market place, analysing the potential variation required to meet their individual demands, carving out product sets that are sufficiently aligned that they can be engineered with well-defined patterns of variation. Keeping the resultant design then focussed only on serving that particular set of marketable products, minimising variation points, and defining the appropriate patterns of use, can deliver a sound business economic.

Few products can be assembled solely from pre-configurable parts (known as domain assets), but often include specific parts unique to that customer (application assets). The business imperative is that application costs be minimised and domain utilisation maximised. If the application development represents a small proportion of product cost, or the parts may be readily converted to domain assets for additional marketing opportunities, they are likely to be viable. Customers may be swayed if small features (unique to them) have disproportionate effects on product price. Getting this balance right requires co-operation between marketing and engineering, to define the right set of products and build the right (but minimal) capabilities of variation… and deny any others!

Mechanisms of variation don’t only play in software, but you can easily extend this mentality to PCB layouts and component populations, or enclosures and connectors to meet different environmental needs, say. A product may be the convergence of several product lines from different domains.

In software, there are many possible ways for maximising variation benefits using traditional principles of layering, modularity, separating demand from control, linearization of interfaces, that should be reflected in segregated variation mechanisms to provide opportunities such as portability, feature substitution, hiding behaviour and obsolescence mitigation. It is not unusual for Product Line solutions’ variation points to number in their thousands, the potential patterns of variation in their hundreds and yet the product variants generated for market only in tens. Managing this is key to being profitable!

These variation mechanisms can take many forms and can be applied (bound) to the system at many different stages (e.g. as source code changes using compilation switches, or as calibration changes post manufacture) and the choice of binding time will affect the mechanisms of test, the test environment, the build process and the potential vulnerability of product for safety through fault detection and accommodation, or security. These attributes give plenty of design space, but many potential trades (e.g. code size, performance etc) that will need to be carefully managed.

___________________________________________________________________________

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)___________________________________________________________________________

 

Planning, Programme Management

Programme Management – Risk Management

Leave a comment

Risk Management is routinely asked for on big projects and it inevitably ends up as a big process of hierarchies of spreadsheets or a database that identifies the risk, the potential impact and ways to mitigate it. I have seen many systems, and also seen many project and programme managers pay lip-service to them, by filling in either the bare minimum, or populating it with racing certainties! E.g. ‘Lack of resources’; This is not a risk, it is a management decision.

Yet, as far as software programme management is concerned, for any new development featuring any form of novelty (product, technology, architecture, people, organisation), risk management should be one of the key tools for planning the programme.

Significant risks are, actually, usually pretty obvious… and a browse through the system requirements by someone with even little appreciation of the project, and little experience, will quickly identify the major issues that are likely to have big impacts. Once the big issues are addressed, there will be a much greater number of lesser issues which may take more expertise to assess with regards investment of ‘mitigation’. Iterating this process quickly drops you into the usual ‘noise’ of typical project variation.

Where the risk responsibility lies is often a key factor, in getting authority to address it. It is rare that big impact risks exist within a single discipline (and if it does the technical discipline manager is usually loathe to admit he doesn’t know the solution). These factors make declaring risk unattractive to some practitioners and may put the project and business at risk.

Investing in ‘experiments’ is really what risk management is about. When you don’t understand the science well enough to have some suitable engineering solution that has provenance, you create a task, switch from engineer to scientist (but with a focus on a particular problem), and look for possible solutions, or to gain some understanding, that allows you to mitigate, avoid, control or at least ‘size’ the problem and the effort required in solving the same.

But there is absolutely no point in defining and executing experimental tasks, if the learning is then not applied, in a timely fashion, to your real project. Classical failures in risk management are:

i)                    Doing the experiment too late, or on the project when eventually encountered

ii)                  Not using the information gleaned from the experiment to modify the programme, or product

iii)                Failing to understand the underlying science that creates the risk, such that mitigation actions can be assessed

iv)                Adding extra complexity, further technology risk or unproven processes in the solution

Often risk reduction programmes require trades between different parts of the system and need multi-discipline skills. Often these will be executed with third parties who have a better understanding of the underlying science, or an ability to think more openly (e.g. academic researchers and institutions).

Technology development programmes are inherently risk management/risk reduction exercises and show a maturity of the business in tackling the problem ahead of bidding a programme that deploys the technology in question.

Embedded software in control and information systems say, is practiced by a wide community of businesses but is largely protected as intellectual property within those businesses (and often inside individual business units). It is fair to say, that most problems in software will probably have already been encountered, and in most cases a solution exists, but others will be unaware.

Even if solutions don’t exist there is potential for finding partners who face that common problem to share the burden of finding a solution. These issues will be the subject of a further instalment, but the general principles of Industrial Collaboration can be found here.

___________________________________________________________________________

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)___________________________________________________________________________

 

Planning, Programme Management

Programme Management – Measurements, Metrics and Progress Reporting

Leave a comment

Previously we talked about Planning and Estimation. These estimation techniques are traditionally used at the beginning of a project, but are immensely useful as periodic techniques for measuring progress.

We observed that during the generation process, we also create errors, whose correction is a generation process and so on. In good programmes this recursion is finite, and measurement of the number and rate of iterations, and their place relative to plan, can provide us with key progress and  process indicators.

By observing the number of versions of a component generated (information drawn from the version control system) and relating it to the (programme plan) planned timing, you can understand when errors are being detected/corrected. If this has more iterations than you expect, the component may be too complex or the developer immature, say. If those iterations occur later than the plan, then the component development may be running late, or be insufficiently tested (which may be a fault of either development or test environment).

These trigger signal can usefully lead us to investigate the component, the development /test environments or the skills of the members of the team. If several components are assigned to the same team members the skill association may be evident; if all components, irrespective of team members, show the same propensity for iteration rates then it is likely the processes or environment is inadequate.

Software programme management is about identifying and fixing root causes of deviation to programme, rather than just about progress chasing. The manufacturing stages of software engineering are its processes and a careful watch should be maintained on both input quality and output as a measure of the process’ efficacy. Resource levels, skill requirements and lean processes are outputs from running a software programme that can be re-used as seed for a new programme, or for ensuring realistic planning of the programme.

Earlier we showed that understanding where errors should be detected is key to planning. For instance, a self-contained component with a simple interface (e.g. a Maths function), would expect to be error free very close to generation; A message transport protocol, that relies on the interaction of 2 different pieces of hardware, and a series of lower level protocol stacks, is unlikely to be error free until significant system test.

Early development effort (in creation of error free components) should major on ‘infrastructure’, i.e. the primitive components and functions that are used by all other features. Failing to sufficiently test these components may seriously hamper future progress at higher levels of application.

Having a ‘slick’ change mechanism, that is suitably controlled, makes the development productive and efficient. No other process stage needs as much effort at being lean. Instrumenting this change process will provide all the valuable information from which the above metrics can be extracted and compared with the ‘expectation’ implied in the plan.

Careful control is required to differentiate causes of change, e.g. internal due to errors in implementation, refactoring due to not being able to accommodate a previously unaddressed requirement, or externally driven change. All will impact your development effort, but the project manager should have contingencies for the first two and be able to negotiate cost, programme etc changes for the last (even if still internal!). No change is for free, even scope reduction can cost money in a programme in which design effort has already been expended.

Now all you have to do is convince the business that your estimates and contingency are correct, including a statement on the assumed requirement that is addressed, and defensible, by reference to previous metrics and adjustments for the success or lack thereof on previous programmes.

Finally, it is never acceptable to arbitrarily cut costs or programme duration without a commensurate change in scope, skill capacity and capability, or 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)___________________________________________________________________________

 

Planning, Programme Management, Project Organisation

Programme Management – Skills and Resourcing

Leave a comment

The set of knowledge and experience, which we call skills, required within a software engineering team to successfully execute a software development programme is quite significant. These skills are commonly gathered together in specific subsets to form what we largely all understand as particular roles and have some relationship to software process steps. Depending on the make-up of the team, size of the project and its organisation, individual people may have jobs whose descriptions consist of a number of these roles.

Skills are commonly defined in terms of a practitioners experience and knowledge level and range from the novice to expert, usually with a number of levels defined in between that often relate to the ability of a practitioner to e.g. work with supervision, work on small tasks unsupervised, work on larger tasks, to lead tasks or supervise others etc.

The assignment of skills and roles has been addressed by published frameworks, explicitly in SFIA (Skills Framework for the Information Age) a collaboration between IET and BCS, or implied in IEEE’s SWEBoK. The SFIA definition is generally aimed more at the IT Industry (and has been adopted by IEEE for use in its ITBoK), whereas SWEBoK majors on software engineering.

Professional institutions and professional registration bodies around the world require not only a number of these skills to be amply demonstrated or evidenced, but also a number of behavioural, ethical and moral attributes (such as committing to continue learning) that make up a rounded engineer.

But, irrespective of the particular subset groupings or competence levels of defined standards, skills frameworks can help us select teams, organise projects and assign roles to meet process requirements. Different industries and regulatory bodies may require independence in certain roles, or of individuals within a project to mitigate common-mode failures of say design and test interpretations of a requirement.

The fact that common skills re-appear in many roles gives us indicators of growth (either in expertise level within a skill, or addition of another skill) and therefore potential for role or even job migration, allowing planning managers to both take on ‘stretch’ capabilities and provide sufficient expertise to mentor such individuals. The overall capacity and capability of a team can be estimated through assessment of its level of skill in assuming the required roles and used to calibrate the programme duration and costs, risks or contingency requirements (e.g. as a CoCoMo factor).

As a practitioner, it is natural to want to progress to higher levels of skill, but as we migrate into other roles (say technical management rather than hands-on) then those skills can subside through insufficient regular practice, so skills need to be regularly re-assessed. This is consistent with many professional registration requirements for re-assessment and re-affirmation as a practitioner.

Levels of overall project team competence  may vary with the product market, for example its safety or security concerns and may add additional skills and roles which are completely unused in other markets (e.g. Business Systems development may employ different roles than those for Medical Devices, Armaments, Aerospace or Nuclear Reactor Control and Instrumentation developments).

As most of our software systems seem to be gradually walking our consumers up an expectation of  flawless operation and hence build social dependence (e.g. GPS navigation systems), we may need to seriously consider what roles are necessary for our business to be assured of their software developments in future markets. Knowing you have deployed an appropriate set of skills can only help support this.

___________________________________________________________________________

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)___________________________________________________________________________