You have requirements
Recently we had an email discussion floating through the company. One of the questions was: “When the designer gets the requirements what questions should they ask to make sure the project is a success?”
Here are some of the comments that came back:
General
This step of any development process is all about gaining knowledge without detail level information of the solution. The key things we’re looking for are pitfalls, things that will bite us later on in the process. Every project is going to be subject to the classic forces: Scope/Requirements, Budget, Time. The information which can be gathered early in the process about the volatility of the requirements will partially dictate the choice of methodology. The budget and allowed time are usually better understood in terms of constraints.
State of the Requirements
How were the requirements gathered? Was a structured approach used? Could requirements change during the design phase?
Are the requirements reviewed and signed-off (an indication but no guarantee for the quality)
Are they clearly written, concise and consistent? Is there a structure to the requirements that allows the reader to find their way through and get an understanding for the scope and completeness? Or are they written in dense or a vague way that makes it hard to understand what is there
Check that all types of requirements included:
- Functional (maybe use cases)
- Data/object Models
-
UI Models
- Business Rules
- Non Functional Requirements
- External Systems
Are the assumptions and outstanding questions documented (this is a good thing)? Are they show stoppers (this is a bad thing)?
Has an architectural been involved while the requirements were created?
Stakeholders - Who has say and sign-off, who has design input. Finding these people early is important, especially those that are of a combative nature.
Hard limits vs. Soft limits - Knowing which restrictions placed on a solution are set in stone and which are a bit flexible can dramatically alter the nature of a project
Environment - On a technological level, providing correct development and build environment can make a major difference to the rate of a project. Having a well defined and implemented development (and deployment) environment is definitely worth the investment. In political terms it is important to maintain two key aspects of the work environment: People must be able to offer up new ideas and improvements to existing practice to be socialized by the team(s); People must not be made scapegoats of – there should be an environment which allows and rewards experimentation.
Pending changes to other projects (substitution, impacts): if any of the systems you interface with has pending changes / work in progress that will impact on your project, you need to know up front so you don’t have to repeat work. The problem you then face is coordinating with all the other teams you work with, but if they don’t plan sufficiently ahead this may be impossible to avoid.
Available resources (staff, cash)
Time for research and to do POC work / spikes - We know from project experience that doing proof of concept work and trying out design ideas on a small-scale to validate them ahead of implementation can dramatically improve the quality of estimates and prevent a team from pursuing a design that later proves to be flawed.
Pre-existing commercial arrangements / alliances that will impact your project
--------
Thanks to AD, AB and JE for your contributions.