Nice writeup! Interesting to see another perspective. I do this for a living too but very seldom to get hear others experiences (due to the nature of the work). My niche is enterprise CRM software so quite the same. Some comments/questions:
- Amazes me as well how quickly you can turn things around by just changing out parts of the team
- Also nice to see how you kept parts of the old team. There are most always skilled people even in massively failing teams. Reminds me to be humble (could be me sitting in the wrong project the next time)
- Rewrite is almost never necessary. You tend to want to do this starting out but normally that feeling comes from a good part not being in control and having knowledge of the ins and outs of the current software. Once you get to know it, it usually turns out to be not as bad (just more complex than it needs to be)
I have done this so many times now that I have my own little mental model for what to look at when I get airdropped in:
- Project managment. Do they have one dedicated project manager who is reporting status correctly and frequently to the stakeholders. Are plans available and follow-up, etc.
- Product management. Are requirements from the business gaterhered and negotiated down to clear and concise things that can be built
- Technical leadership. Do they use suitable technology, proper infrastructure setup (in your case not), is technical design simple to understand and not overly complex.
- Change management. Is the team communicating the comes changes effectively to the end users. Is training done and being planned correctly.
- Work process. Is there a good process that with good flow from requirements to created and tested feature.
My theory goes that if one of them fails, the project usually survives anyway, the others compensate. If two or more fail, the project fails.
Finally a question. You write that it is usually not a good engagement for you financially. Would be curious to know your business model here. I end up doing these projects on a hourly rate for the most part.
> You write that it is usually not a good engagement for you financially.
Not 'not a good engagement financially', rather the opposite. Just more risky. Typically I'll do these for daily rates depending on the perceived risk but I'm pretty flexible.
I have done this so many times now that I have my own little mental model for what to look at when I get airdropped in: - Project managment. Do they have one dedicated project manager who is reporting status correctly and frequently to the stakeholders. Are plans available and follow-up, etc. - Product management. Are requirements from the business gaterhered and negotiated down to clear and concise things that can be built - Technical leadership. Do they use suitable technology, proper infrastructure setup (in your case not), is technical design simple to understand and not overly complex. - Change management. Is the team communicating the comes changes effectively to the end users. Is training done and being planned correctly. - Work process. Is there a good process that with good flow from requirements to created and tested feature.
My theory goes that if one of them fails, the project usually survives anyway, the others compensate. If two or more fail, the project fails.
Finally a question. You write that it is usually not a good engagement for you financially. Would be curious to know your business model here. I end up doing these projects on a hourly rate for the most part.