Category Archives: Programme Management

Programme Management – Customer Application / Domain re-use

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

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


Programme Management – Risk Management

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

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


Programme Management – Measurements, Metrics and Progress Reporting

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

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


Programme Management – Skills and Resourcing

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

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


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

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

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