Anaplan Way - SOW and Foundation Phase
Hi
I am in Foundation phase of the Anaplan Way and realise most of the work is done in this stage. I am curious to know how do you set a budget for the project in the Statement of Work which is done prior to this phase without the activities of the Foundation phase? I realise through previous experience you will be able to come up with a ball park budget, however, not sure whether this is sufficient?
Regards
Thiru
Comments
-
You'll come across mature customers that will already have written some form of User Stories, and here, it's experience that will tell you what's lacking. For example, customer user stories might lack quality-of-life asks, like a functionality to copy Input Settings from one period to the other. Or they may miss to include override or adjustment value functionalities that are needed. Here, you have to be building a "bestiary" of models and what they usually include. Monthly Processes that are heavy on Input Settings will usually have a default setting that can be overidden. Reports of Actuals will usually need adjustment values, whereas Reports of Planning or Forecast will include some form of simulation. This merits a whole longer discussion.
And then there are customers who will ask for a quotation without formal documentation and will want to just discuss their process (if you're unlucky, they might even want to do it solely verbally). I've been burned enough that I will insist on 1) getting that rough User Story from them, and 2) presenting some similar model or if it's worth it, a Proof-of-concept (POC). I am not likely to make a new customer create formal user stories on that first meeting, but I will certainly be directing the conversation to getting the details needed for what would be the User Stories. I prefer the end-in-mind approach, and these are usually very specific reports that are the final output; this has to be clear on that first meeting, and you should never do a ballpark without knowing this. And then work back from there, what needs to be inputted, and what is expected as system calculation to get to those reports. Being on Anaplan during that meeting is the quickest way to get details from them, they will usually embrace or outright reject what can be seen; either way you will have gotten more detail that just a verbal discussion. A POC is the most effective way to get that, but I understand the effort, so just do the cost-benefit analysis for the work needed for a quick POC.
In either case, whether I end up writing it or receiving it from a potential customer, I will always include some rough cut/general form of User Stories in the SOW, because it's the document that everyone can go back to. I know you will never be able to give enough detail and it's just not possible to do this perfectly before the Foundation Phase, but get detailed enough that surprise asks for functionality can be clearly seen as in-scope or out-of-scope. Details will save you.
There are many resources for scoping here in the community, but I'd just like to plug the most recent one, I attended a Webinar on Personas which I thought was a really good one.
1 -
You'll come across mature customers that will already have written some form of User Stories, and here, it's experience that will tell you what's lacking. For example, customer user stories might lack quality-of-life asks, like a functionality to copy Input Settings from one period to the other. Or they may miss to include override or adjustment value functionalities that are needed. Here, you have to be building a "bestiary" of models and what they usually include. Monthly Processes that are heavy on Input Settings will usually have a default setting that can be overidden. Reports of Actuals will usually need adjustment values, whereas Reports of Planning or Forecast will include some form of simulation. This merits a whole longer discussion.
And then there are customers who will ask for a quotation without formal documentation and will want to just discuss their process (if you're unlucky, they might even want to do it solely verbally). I've been burned enough that I will insist on 1) getting that rough User Story from them, and 2) presenting some similar model or if it's worth it, a Proof-of-concept (POC). I am not likely to make a new customer create formal user stories on that first meeting, but I will certainly be directing the conversation to getting the details needed for what would be the User Stories. I prefer the end-in-mind approach, and these are usually very specific reports that are the final output; this has to be clear on that first meeting, and you should never do a ballpark without knowing this. And then work back from there, what needs to be inputted, and what is expected as system calculation to get to those reports. Being on Anaplan during that meeting is the quickest way to get details from them, they will usually embrace or outright reject what can be seen; either way you will have gotten more detail that just a verbal discussion. A POC is the most effective way to get that, but I understand the effort, so just do the cost-benefit analysis for the work needed for a quick POC.
In either case, whether I end up writing it or receiving it from a potential customer, I will always include some rough cut/general form of User Stories in the SOW, because it's the document that everyone can go back to. I know you will never be able to give enough detail and it's just not possible to do this perfectly before the Foundation Phase, but get detailed enough that surprise asks for functionality can be clearly seen as in-scope or out-of-scope. Details will save you.
There are many resources for scoping here in the community, but I'd just like to plug the most recent one, I attended a Webinar on Personas which I thought was a really good one.
0
