We’ve all been there… A BPM Software RFP Invitation… “Request for Proposal”… or as it is commonly known: “Another Sleepless Night”…
You stay up late… answering all their questions (what looks like thousands of pages….).
You get grumpy… (they probably won’t even read it…)
the impossible questions (probably be a stitched tender…)
the vague questions, the tick-in-the-box questions…
it goes on and on into the night… grumpy, grumpy, grumpy…
But when you’re finished, you’re quite proud of your work… (clear, decisive, professional. a work of art! A true masterpiece. Pat on the back…)
You then look at their time schedule… General Instruction for bidders – tick…
Business requirements – tick… Technical requirements – tick… Deadline for clarifications/questions back to the customer in order to be able to bid..
Ahah! Clarification questions back to the customer. Excellent! These guys are serious!
There is a formal procedure in vendor bidding, a certain etiquette.
It usually consists of questions the customer asks the vendor.
It doesn’t include questions the vendor can ask the customer.
Which is a pity, because it would enable the vendor to quantify the work needed.
It is in the customer’s best interests to provide as much information as possible to the vendor.
There is a difference in the amount of work needed in “simple process”, and a “simple process, but by the way we want it also to integrate into an old legacy system, run through a thousand steps, and automatically make coffee”
The difference usually results in a quick deployment where everyone is happy, or a project the drags on for ever, a vendor looking to run away, costs spiralling and everyone feeling that they have been screwed by the other side.
You request a price. You get a price based on the information you provide.
If you’ve sent a RFP to multiple vendors, without including formal “clarifications/vendor questions back to the customer” step – you are doing yourself no favours. During the bidding stage no vendor is going to risk annoying you by sending back a list of clarifying questions without permission. It is is your best interests to have this stage built-in to your tender in order to enable vendors to estimate correctly the amount of work required. It really is in your best interests.
Clarification questions back to the customer are very important.
These are my 20 questions I would always ask:
1. What is the business problem that we are trying to solve?
2. What impact does this have? Who does this impact?
3. Why do we want to resolve this now?
4. How critical is this process to the organisation?
5. What would be considered a project success?
6. How do you currently operate?
7. How long does it take to currently “run” the business process?
8. How much does the current process cost to run?
9. How many people are involved?
10. Total number of process that you are looking to automate as part of this project?
11. What currently happens with exceptions?
12. How long does it take to resolve them?
13. What are the issues with failures and alerts?
14. How is audit currently implemented?
15. How are KPI’s currently measured and monitored?
16. Are external companies and/or contractors used?
17. Does the process include integration into other systems?
18. Do you have defined processes?
19. What are the processes designed in?
20. Who is the stakeholder?
Adam Deane 
Excellent points! There are howeve quite a few more questions related to change management.
Typical customer answer to those questions: ‘You don’t need to know this and if your BPM system is as good as you say in your marketing then this should not bother you at all!’
Regards, Max
By: Max J. Pucher - Chief Architect ISIS Papyrus Software on 04/08/2011
at 8:50 am
Great article. What questions should you ask to an organization who is not mature enough to document its current practices. I am asking this because we have struggled in one of our previous projects where the bidding was done for a standard process and during implementation we found there was no defined process – our BPM implementation was being used as a way to standardize the process.
What and how do you articulate this risk in your questions?
By: Abhishek Mishra on 04/08/2011
at 9:43 am
Hi Abhishek,
A good question. It’s such a common problem that we factor in the design as part of the setup stage. I have yet to see a new customer that has a full design ready when we start.
Like you, we are used as a way to visualise the design as we build.
By asking question 18 and 19 I get a good indicator on if its going to be design-as-we-go, or will I be lucky. If they are not currently using any process designer, its usually a sign that they haven’t done process design before, don’t do it often enough, don’t have the relevant skills, or haven’t invested in that area.
On the other hand I have yet to meet a customer that doesn’t think that their processes are well defined, clear and ready to build… It’s all part of the fun…
Cheers,
Adam
By: Adam Deane on 05/08/2011
at 8:56 pm
Thanks Adam. I recall a project in which we had to do 19 versions of the requirements document because everytime they came up with a new idea. The irony was that after rolling out the workflow, they abandoned it saying there was a huge gap between the AS-IS and designed process. Fortunately, they paid us for our work lol.
I will share the experience on my blog http://bpmgeek.com
regards,
Abhi
By: abhishek mishra (@abhi1304) on 06/08/2011
at 5:00 am
Good hit, Adam.
#1 and #5 are my favorite. They never can answer these two. Not without a brainstorm anyway.
The finer and more provocative variant of #5: “How would you know it’s success?” No reason to launch the project without a commitment on this point, obviously.
By: Anatoly Belychook on 04/08/2011
at 11:48 am
Excellent questions!!
Ironically, most of the times in reality, these questions are asked towards the end of the project to prepare the case study. 😉
Thanks!
By: Neo Patel on 04/08/2011
at 1:58 pm
Great questions,
Not sure if this is related but there was a similar question raised on linkedin under the BPM Forum. http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=63753240&gid=161666&commentID=47499378&trk=view_disc
Craig
By: Craig Willis on 04/08/2011
at 4:51 pm
I usually see questions back to the customer as part of the formal process – but we rarely see vendors take advantage of the question-asking phase. I also often see a pretty comprehensive RFP that really just wants to know what the rates are for a couple of roles…. 🙂
These are great RFP questions-back-to-the-customer.
By: venture4 on 04/08/2011
at 5:12 pm
[…] Adam Deane strikes gold again with this post on a “Request for Answers”: There is a difference in the amount of work needed in “simple process”, and a “simple process, but by the way we want it also to integrate into an old legacy system, run through a thousand steps, and automatically make coffee” The difference usually results in a quick deployment where everyone is happy, or a project the drags on for ever, a vendor looking to run away, costs spiralling and everyone feeling that they have been screwed by the other side. […]
By: Great Request for Answers Post » Process for the Enterprise on 21/09/2011
at 11:11 pm