1

We're busy with a proof-of-concept to replace an existing system, but there's disagreement on how one limits the scope of the use case(s).

We're managing multiple resources across multiple projects so we're looking for a POC to show that a new solution would help us better do resource planning.

The direction the POC has taken is a small working prototype working for one customer. I raised a concern that this it could not be considered a working POC since it only takes one customer into consideration.

The scope of the POC is limited to a hand full of use cases, but where the confusion seems to be coming from is the Use Case itself. Some of the team have taken this to mean One Use Case = One Customer, but I'm looking at this and saying a use case is:

A consultant creates a plan for their week (actor here is the consultant, weekly planning is the use case).

Or...

Delivery managers have a view on all resources to ensure there's no burnout (actor here is the delivery manager, the use case is a resource usage report).

My argument here is that you can't assume that because a Use Case works for one customer that it will work for another customer. In fact, in my own time I've tested the POC and it doesn't work for one of our other customers which happens to be the biggest customer in terms of revenue.

Understandably a POC has to be limited in scope, but perhaps I'm misunderstanding how this team defines a Use Case?

Improve this question
1
  • You haven't really told us how the team have defined Use Case. Commented Nov 14, 2022 at 11:54

1 Answer 1

Reset to default
4

Without knowing more about your specific project a good thing to remember is that a proof of concept is just that. It's proof that a concept works. To that end, a good proof of concept should look at a very specific set of concerns, and show that they can be tackled.

Going in, one should list out what goals the proof of concept should be trying to prove. They don't really need to show everything. Just that it's possible to work around 1-2 problem areas.

Keep in mind that it may take several proofs, to test out all the concerns that people may have. If we take a car, for example, we may want proof that it starts, that it can go 55, and that it can go 55 under a load. You may be able to start it. You can then test drive it at 55. Then you may need to do some math and research to see if you can prove that it can go 55 under a load, but that might not be part of the test drive.

The same is true with software. Your proof of concept is just that. You may not be able to test and prove every edge case. You may only be able to some basic concepts, but once you have done so you may be able to extrapolate.

So, with a proof of concept, you check out and prove the basic, high-level concepts of the software. You test the waters. If it looks like things can work, somehow, then your move on to things like pilots and alpha/beta phases to test if it can actually work in the real world.

Keep in mind that during product development you may do many proofs of concept style iterations. That's ok. In your example, maybe you need two proofs of concept. One that shows that the tool can work, and one that shows how you could handle multiple customers.

Finally, remember that the scale of a proof of concept is meant to be very small. It would not be uncommon to see a company spend $1,000 doing a proof of concept that shows that a tool can hold an address, then spend $10,000,000 building, implementing, piloting, and training that tool, so that its users can store an address. Then somewhere along the way doing another $500 proof of concept to see how this tool could store information for people that have two addresses instead of one.

Improve this answer
4
  • Thanks @coteyr I know my input was very superficial but your answer touched on a number of points that I had a concern with. In this particular case a better explanation would be: We have X number of existing customers where we run projects and we need to aggregate information from those projects in such a way that we can see how resources are used. However, customer A, B and C have nuances that are not at all uncommmon in the industry so if the POC requirement was to see if we "Could" get this information then to my mind it wouldn't work if you said it worked only for client A. Commented Nov 14, 2022 at 15:12
  • @Jacques, wouldn't that depend on how much the difference in peculiarities for A, B and C woulds affect the concept you are trying to create a proof for? For starting an engine, I can make a single PoC that is valid for both a lorry and a passenger car, but that will not work to prove the vehicle can reach 55 mph under load. Commented Nov 15, 2022 at 7:35
  • @BartvanIngenSchenau, that's a valid point. I guess in this case I know that the POC will not work with customer C because I took the time to prove it to myself. And, there are unanswerable questions when it comes to the current POC, which require such a major pivot that it would completely nullify the findings of the POC. We know this upfront because I've proven it. Yet the debate has still continued on in the direction of this being a valid POC because it works for Customer A. Naturally this led to a debate on what constitutes a valid POC in terms of use cases. Commented Nov 17, 2022 at 6:52
  • 1
    @Jacques, in that case, take a step back and try to get a agreement on what the scope of the PoC should be. Is is sufficient to prove that the concept works for a single customer, or is a more general proof expected. Discuss that also with the people who need to make a decision based on the results of the PoC, but neither option is inherently right or wrong. Commented Nov 17, 2022 at 7:47

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.