Productivity on software projects
Staff, management, product and environment factors impacting productivity on software projects
Introduction
Good productivity on software projects is a sign of well-run organisations. When productivity is low, it’s often difficult to identify why, even if the reasons are in plain sight. Poorly understood causes coupled with pressure to improve might force management into taking inappropriate measures. These measures over time lead to unhealthy work environments, lower product quality and ultimately to even lower productivity.
Understanding what drives productivity is crucial for any organisation. In this post I list factors that impact productivity on (software) projects. The listed factors are based on management literature and my own experience. Broadly speaking these factors can be grouped into 4 categories: Staff, management, product and environment.
Staff
| Factor | Description |
|---|---|
| Team capability | e.g. years of experience, problem-solving skills, quality of communication |
| Staff morale | e.g. motivation, turn-over |
| Business leadership capability | e.g. decisiveness, cohesion, vision, stakeholder management |
| Application experience | familiarity with type of application developed |
| Technology experience | familiarity with given technology |
| Practices experience | familiarity with practices used on project |
| Target system experience | familiarity with target platform or environment |
| Domain knowledge | business domain know-how |
| Size | size of team |
| Specialization | e.g. hand-offs, communication overhead |
Management
| Factor | Description |
|---|---|
| Project control | e.g. progress assessment, bottlenecks, transparency |
| Project planning and scheduling | e.g. resource allocations, task dependencies, parallel work, prioritization |
| Process maturity | e.g. well-defined process, roles and responsibilities, effective, predictable, stable |
| Modern practices | using evidence-based practices and methodologies (e.g. not Scrum) |
| Process improvement | problem identification and improvement processes |
| Schedule constraint | e.g. aggressive deadlines |
Product
| Factor | Description |
|---|---|
| Product category | e.g. avionics, business, embedded |
| Size | size of software to be developed |
| Resource constraints | e.g. memory, bandwidth, CPU, storage |
| Product complexity | e.g. high/low level language, algorithms, complex domain, integration with other software, tolerance for technical debt |
| Product reliability requirements | e.g. SLO, correctness, precision |
| Real-time requirements | e.g. responsiveness |
| Product security requirements | e.g. PCI-DSS, audit norms, access management |
| Requirements volatility | e.g. scope changes |
| Requirements clarity | e.g. written requirements including non-functional, testable, prioritized |
| Required reuse | integration with 3rd party, using mandated technology e.g. frameworks |
| Architecture | wrong architecture decreases productivity with size |
Environment
| Factor | Description |
|---|---|
| Multiple organisations | multiple vendors involved |
| Multiple sites | project developed multi-site |
| Physical work environment | e.g. noisy environment, disturbances, security restrictions |
| Modern tools | build systems, automation, checkers |
Conclusion
Some factors like customer deadlines or mandated level of security for regulated industries will drag productivity down no matter what, because they are intrinsic to the project/product and thus outside of organizations control.
Instead, organizations should focus effort on factors that can improved, like a proper team composition, adequate work environment with private “thinking-spaces”, structured approaches to requirement capture or keeping project plans aligned with available resources.