Technical

1. do they have opinions about software engineering?
2. are those opinions sensible?
3. do those opinions conflict too strongly with our existing team?
4. do they really want to make good software?
5. do they really want to make the software we are making?
6. are they interested in users?
7. do they bring skills we don’t already have?
8. do they have the self discipline to work effectively within a team?
9. do they have the self discipline to make good quality software?
10. is their personality such that will they work effectively within our team?
11. are they creative and clever and self-motivated to apply it?

Non-Technical

1. do they have good negotiation skills?
2. can they explain themselves clearly?
3. can they learn something quickly? (do they listen to others?)
4. do they know how to learn in the medium and long term?
5. are they honest and insightful about the limits of their own knowledge and abilities?
   1. do they know what they can do already?
   2. do they know what they can’t do yet?
   3. are they willing to tell me what they can’t do yet?
   4. are they trying to blag?
   5. are they self-motivated?
   6. do they have something they want to achieve from working?
      (money, status, skills, friends, fun, whatever)?
6. do they like to share what skills they have with others?

Start-ups only

1. do they understand what a start-up is (in business terms)?
2. do they understand what a start-up needs?
3. do they understand the risks of a start-up?

Inability to proceed incrementally is risk factor for project failure. If you have to wait until the end of the project for delivery, then you get (or don’t get) all your features at that point. What if an unexpected event occurs? Then you may reach the project end date still with all features in progress and none finished!

How does this problem manifest? You have a big list of features that are partially working, or “in progress”, and few features that are “finished” or “not started”. Perhaps you have even lost track of which features are finished or not, or how completed the features are, or how completed the project is?

What I prefer to see in a de-risked project is: a list of completed features; one in-progress item that is currently being worked on; and a bunch of not-started-at-all items. It can be risky to have a process of “filling-in” the code from a sort of sketch implementation across all of the features – I generally prefer an incremental process of adding features one-by-one to a known finished and working base. If you need to check on features to inform the design process then implement simple, but complete, minimal versions of the key features. But do them one at a time.

The three main problem with lots of started-but-not-finished items are:

1. that it can be difficult to understand how much work actually needs to be done before you get any further completed features, there is a /risk/ that big surprises can come up late on.
2. that it is difficult for testers to give you early feedback on the quality of your implementation – they end up having to test all the features at the end. And at the end is when you have no time left to fix any problems they may discover. Of course they may not discover any problems, but I am talking about risk management and predictability.
3. and if you do get your testers going early then they don’t know if something they don’t like about the product is caused by an incomplete feature, or is a genuine problem. You can end up with lots of wasted time for testers and developers as they try and sort this communication problem out. And I think it can lead to testers getting used to a lower quality of half-finished software.

There are more problems actually, but those are the most serious ones in the short term. Maybe I will write more about this later.