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


Leave a Reply