Category Archives: Project Organisation

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

 

Planning, Programme Management, Project Organisation

Programme Management – Planning and Estimation

Leave a comment

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

 

Programme Management, Project Organisation

Managing Engineers

Leave a comment

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

 

Business, Project Organisation

Multi-Geography Development

Leave a comment

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