Professional services revenue isn’t as good as platform licensing revenue. However since we sell a platform product it’s difficult to do business without some capacity.
But taking things back to first principles the things to look at are these.
Is the project within our wheel house? - i.e. helping a client build out their ability to use our platform with a task which our platform excels - i.e. transforming transactional data from one source to another
Versus doing things which are complicated and go beyond the scope of our platform - for example what we did with Point Click Care (my bad!)
Is the project really building something which should be a feature?
This should make us pause since it’s going to be hard - we’re likely to get into realm of activities where Iguana doesn’t offer great additional value.
Can we do the very best we can with using conversational skills and clarification to do a really good job of identifying the need?
Using the skills of clarification can we bring the scope of the project to a frame of something we understand and have patterns for already?
Could we express the work that needs to be done for the client rather like this document is - in a short form which can be quickly read (not a 40 page treaty) to see the nature of the work.
We are looking for patterns of repeatability here.
This also helps to streamline our process and improves the client experience.
Could we make use of a platform like Confluence or similar to allow this?
Is the scope of the project small and well defined?
Small projects have less risk, can be performed faster
Does the project lead to increasing recurring revenue which is proportional to the effort being invested in services
Think of every professional services project as something which should have an outcome of leading to more recurring revenue happening after the project is complete. So after we are done the client turns into a higher margin client.
All the above is more of a potential framework for how we talk through a project - not an exhaustive checklist.