SE Process Definition and Feedback
Let's gather here our ideas of how to streamline our internal process of receiving and addressing SE requests from other teams, in order to better serve them. Let´s welcome all our input!
Contributors
@Jose Maldonado (Unlicensed)
@Juan Carlos Yujra
@Mauricio Cardenas (Unlicensed)
@Jimmy Quiroga (Unlicensed)
@Mauricio Cardenas (Unlicensed) writes: I Suggest for new engagements to have a SoW well defined and after a proper analysis define the Time Estimation as with projects like Marburg University that was a Payed POC with excellent results an having this university engaged as client.
@Jose Maldonado (Unlicensed): I like the idea of exploring how to standardize the format in which requests are collected. However, let´s keep in mind the following overarching concepts to our whole operation:
As a Sales Support operation, we are mostly on the clock against a sales cycle deadline. So we will not always (not even usually) have enough time to focus on Business Analysis on a deep level. Of course, certainly we cannot jump into work without any analysis effort whatsoever, so I recognize the concern and challenge.
Paid PoCs, or Pilots, are for the most part responsibility of Professional Services. Here at SE we will usually work on PoCs prior to formal project engagements, so as a rule paid PoCs will be out of the question except in specific scenarios. Of course it is all subjective, but this is main mindset. As a general rule, we need to work with Sales to properly gauge and categorize these opportunities. For example, anything under 15k-20k is low end and should be addressed by Demos performed by Sales directly. At the other end, large opportunities will be able to afford paid PoCs. Our focus is the spectrum bracketed in between.
Formality is good but let´s not forget that we need to be an agile shop laser focused on helping close deals. So we cannot expect unfortunately airtight SOWs for every request. We need to be nimble, responsive and creative. Furthermore, if SOWs contain clear instructions of what needs to be done, then our job at SE would be reduced to the carpentry of just following instructions. Our real value is in the creativity of how to bring abstract concepts into material assets, particularly against vague or challenging requirements and deadlines.
That said, I definitely agree on us having the last say on what is actually delivered and, more importantly, by when. I like your suggestion of formality if only to ensure we are responsible for setting our own deadlines rather than being subjected by timeframes out of our control. However, back to point 1. We are all on the clock on a sales process and regardless of how much we push back, there is only so much breathing room before a hard deadline is reached.
Let´s put our minds together after we´ve done a few of these informal requests, so we can then come back and work on how to best formalize our requirements process in light of the aforementioned restrictions.
The problem of creating POC none payed and without a proper SDC with SoW to define a conclusive time, are that we'll engage in several projects without a punch to be converted into a sale (the lead might or not become client, because he doesn't have a commitment to the project because this is for free), and might deliver us into a wasted effort because of the pressure of time, commitment of the customer and in the end SE Team resources without having a decent time for development and analysis.
I have faced in the CST payed POC with good results and I consider that PS has their hands full and with urgent requirements of POC like MTA our team was key.
None the less, my main concern is the lack of generation a conformity document such as SoW because we do not have something to check with the client and define we reach your expectations and we accomplished our technical development, also that will give us the heads up about the amount of work we need to invest.