I picked this up a while back and it’s been sitting in my notes ever since. It’s a risk assessment checklist for software projects — the kind of thing you’d run through before committing to a contract or kicking off a big engagement.

The original is a ten-page Word document with checkboxes. I’ve reorganised it here so it’s easier to scan. The categories are roughly in order of how you’d work through them: start with requirements, move through design and implementation, then look at process, people, and external pressures.

You can download the original checklist if you want the full Word version with the table formatting intact.

Requirements

This is where most projects go wrong. You don’t need everything perfect, but you want to spot the red flags early.

Stability — Are the requirements stable, or are external interfaces still shifting? If the spec is moving while you’re designing against it, you’re in trouble.

Completeness — Are there gaps you know should be there? If the customer has unwritten expectations, you need to surface those now, not during integration.

Clarity — Can you actually understand what’s written? Ambiguity at this stage becomes a bug later.

Validity — Do you and the customer agree on what the requirements mean? A spec that’s technically correct but doesn’t match what the customer wanted is useless.

Feasibility — Anything technically difficult? Precedent matters — if your company hasn’t done this before, be honest about it.

Scale — Is the system size or complexity a genuine concern? Not every project is big, but don’t underestimate the ones that are.

Design

Functionality — Any potential problems meeting the requirements?

Difficulty — Does the design lean on optimistic assumptions? Are there functions that are hard to design?

Interfaces — Internal interfaces well defined? Is there a process for defining them? Hardware being developed in parallel with software?

Performance — Throughput, scheduling, real-time events, recovery timelines, database contention. Has anyone done a performance analysis?

Testability — Is the product difficult or impossible to test? Does the design include features to aid testing?

Hardware constraints — Does hardware limit what you can deliver? Memory, throughput, real-time response, availability.

Reuse and COTS — Reusing software not developed on this program? Any problems foreseeable? If using commercial off-the-shelf software, are there integration or support risks?

Code and Unit Testing

Feasibility — Is the implementation fully defined by the design spec? Are the algorithms easy to implement? Is there enough time for proper unit testing, or will schedule pressure force compromises?

Testing — Are you starting unit tests before verifying code against the design? Has sufficient unit testing been specified?

Coding — Are design specs detailed enough to write code from? Is the design changing while you code? System constraints making it harder?

Language and tools — Is the language suitable? Multiple languages in use? Interface compatibility between compilers? Development machine the same as target?

Integration and Testing

Environment — Enough hardware for adequate testing? Can you build realistic test scenarios and data?

Product — Will target hardware be available when needed? Have acceptance criteria been agreed for all requirements? Are external interfaces baselined?

System — Has sufficient system integration been specified? Are all contractors part of the integration team? Will integration happen on the customer site?

Engineering Specialties

Maintainability — Does the architecture create maintenance difficulties? Are maintenance people involved early?

Reliability — Are reliability and availability requirements allocated to the software?

Safety — Are safety requirements allocated? Will it be difficult to verify them?

Security — Are security requirements beyond current practice or experience?

Human factors — Will the system be hard to use because of poor interface definition?

Development Process

Planning — Formal, controlled plans for requirements analysis, design, coding, integration, installation, QA, and configuration management?

Process control — Is the development process enforced and monitored with metrics? Are distributed sites coordinated?

Product control — Requirements traceability from spec through test cases? Formal change control? Changes mapped up to system level and down through tests?

Development system — Enough workstations and processing capacity? Tools people are familiar with? System reliable?

Management

Planning — Program managed according to plan? Re-planning when disruptions occur? Contingency plans for known risks?

Organisation — Roles and reporting relationships clear?

Management experience — Managers experienced in software development, the application domain, or large programs?

Communication — Problems communicated up and down the line? Conflicts with the customer documented and resolved?

Monitoring — Periodic structured status reports? Progress tracked against plan?

Quality assurance — Adequate procedures and resources?

Configuration management — Adequate system, adequately staffed, synchronised with site changes?

Work Environment

Quality attitude — Staff oriented toward quality? Does schedule get in the way?

Cooperation — People working cooperatively across functional boundaries?

Communication — Good awareness of mission and goals? Technical information flowing between peers and managers?

Morale — Non-productive atmosphere? No recognition for good work?

Resources

Schedule — Stable? Realistic? External dependencies likely to impact it?

Staff — Required technical skills available? Adequate personnel? Stable staffing?

Budget — Stable? Based on realistic estimates? Changes accompanying requirement changes?

Facilities — Development and integration environments adequate?

Contract and External Pressures

Contract type — Fixed price, cost plus, award fee? Is the type itself a risk?

Documentation burden — Excessive amount, picky customer, long approval cycles?

Data rights — Problems with COTS, developmental software, or non-developmental items?

Customer — Timely approval cycle? Understanding of technical aspects and software? Interfering with process or people?

Politics — Company or customer politics affecting the program or technical decisions?

Vendors — Relying on vendors for critical components?

On-Site

Logistics — Personal constraints, visa issues, contract restrictions?

Sign-off — Project Manager, Project SQA, Program Manager, Date.

The point of this isn’t to fill in every box perfectly. It’s to have a structured conversation with yourself and your team before you commit. Most project failures aren’t caused by a single catastrophic mistake — they’re the result of a dozen small things you knew about but didn’t write down.

If you use this, adapt it. Cut what doesn’t apply. Add what your projects actually need.