How to review a solution design?

Often, I don’t have the detailed knowledge of a product, programming language or a system, so what I do is to review the basic foundation for the solution design.

If you can’t explain why, what and for whom, the chance of making a design that fulfils a need is very limited. 

The design may not work in real life or there may be problems later in the project, so I agree with Greger Wikstrand that requirements management is a process during the whole product lifecycle. 

When staring a review, I present this short list to involved parties as a template of how to make a thoughtful review in a consistent manner.

•  Principles and guidelines from the strategies
•  Purpose and goal for the project or product
•  Value and cost for the calculated lifetime
•  Business need and/or business requirements
•  High-level information model
•  Functional requirements 
•  Non-functional requirements or product requirements 
•  Solution design including integrations to other systems 

The next step is asking them what parts they see as their responsibility and ask if they have a processes supporting their work, or if it’s more or less an ad-hoc approach. I don’t evaluate their decisions to omit different parts or selection of methods, or the lack of. Depending of the size of the project, complexity, time, importance, skills etc, those decisions may be correct.

What I do, is to analyse the parts and make a risk evaluation and point at those things can go wrong. If the risk is to high and the reward is to low, or unknown, my recommendation is often to halt the project and to redo, re-schedule or change the scope. Eventually make some proof-of concept development for critical parts. 

However, the normal outcome is a lot of yellow and green lights for the different parts. The recommendation from me is therefore often to adress the concerns in the development and to be followed up by the project manager. 

This method for review works very well for waterfall projects, but if you see each sprint as a small waterfall, this approach is also usable in agile projects. As the scope is much narrower, the effort to make such an assessment is also much smaller. 

So, if running an agile project, ask yourself who is responsible for each bullet from the list above and if is it described in some kind of documentation.