Input on new project management system feature, exposing to customer

Question

We had a customer come back to us and ask to be able to expose the backlog of our system to their customer in an easy fashion, as well as allow the customer to simulate deleting requirements and seeing the cost go down or increasing the due date and watching the cost go up. They also added proposed requirements where before new costs are given they are sent to the company for estimates; afterwards, they're replied to or sort of automated in summary.

Is this a waste of a feature or very useful feature?

Answer 1

If I understand correctly, you are a sub-contractor to another company which is delivering a product to the customer. The customer wants to be able to run through whatever scenarios they want to dynamically in order to get the best balance of cost/scope/time.

Silos are for grain and not project teams. It is better to have a discussion with all parties present rather than having one party go off by themselves and try to figure something out. Suppliers and customers are key stakeholders in any project and need to actually talk (not email or text or whatever) about these things.

If you are cornered and have to use this kind of feature then:

• COST - Probably feasible. If you have a pricing structure like in the construction industry (i.e. $X per road lane mile built) you could do this, or if your pricing specifies the costs for individual modules. You can work with the customer to find out the granularity that they want.
• SCOPE - Probably feasible. I'm assuming that you have clear acceptance criteria for the final product and that each sub-component is completely independent. You will need to clearly define any inter-dependencies of the sub-components so that if the customer takes out X he isn't making Y worthless.
• TIME - Probably not feasible. Since the customer's project is likely not being done in complete isolation from other projects, I don't think you can say "If you add/remove X from scope you will delay/shorten delivery by Y weeks" without looking at the other projects. If customer is trying to do this by themselves dynamically you would either have to provide them with info that they have no right to see or have them work under a set of assumptions that might not be very robust.

Answer 2

The feature request appears to reasonable but the implementation would be quite sticky. Since the resulting costs and schedules are based on estimates you would have to show how reliable a particular estimate would be.

You'd need to show dependencies and how some things can't be adjusted. You would you need show tasks that have some sort of fixed start date. You would have to have a way to show contingencies....... That is a lot of messy variables.

And you would need to plaster huge and Very Dramatic!! warnings on the output about how unreliable the output would be. I'm not sure how much real value the customer would actually get out of it even if it was executed perfectly.

Answer 3

This is a problem I deal with pretty much on a daily basis (and I like to tackle it too :)

You have two techniques at your disposal - you may use either or both depending on the situation:

• So-what's/Why's: keep asking so-what (or why) noting the intermediate answers. Repeat them on the intermediate answers till you hit an end goal - the real need. Feel free to branch out, no need to be linear (if thinking in terms of a graph). But don't get to over-bowed by this.
• Now that you have a real need/goal try quantifying it in any means you can either relative value (1-9) or actual money gained/retained as a result of time saved/retained etc., Get your team of developers and ask them to estimate the cost of this feature - either relative of absolute ($). A simple Value/Cost ratio should be able to tell you whether it's worth doing.

The goal that you got from the first step should also help you identify the "value" metric to use. It's entirely possible that you (and your stakeholder) feels it's worthless after the first bullet itself with a back-of-the-envelope calculation. That way no need to do step #2!

This technique has always proven useful to me in practice, helps the stakeholders understand if the benefit is really worth it as well as what's the true need and is it 'economically' worth getting it fulfilled/satisfied. Relative numbers work better than absolute, but absolute ($) may hit the point home better at times.

Note, I can't say whether the feature is really worth it since value lies in the eyes of the beholder, but I can give you some tools to help elicit that value and re-articulate the worth to the stakeholder(s).

Answer 4

Although, I'm a huge fan of transparency - strictly read-only -, this feature scares me. It kind of allows the customer to change the backlog without having a proper discussion with the team or organization.

Let's say I'm a small company owner who has a contract with the customer and a budget to keep. In the contract, I agreed on a set of features I'm going to deliver and my customer is allowed to see my progress which is completely fine and a good way of maintaining business relationships. The business situation of my customer can change, and he comes to me for changing our agreement. We have a discussion - because of the read-only access - , change in the contract and live goes on.

If the customer has write access to the backlog, this discussion is pointless from his point of view and I became his slave who has to be able to react on any changes - it is a resource allocation nightmare - and I have to keep my eye on my own backlog and look for changes. This is a sort of micro management on a different level.

So, I see the following issues: contracts, resource allocation, project planning, and need for a notification feature.

Answer 5

the situation you describe is very appealing. It's not very common having the opportunity to work in such a way with your customer. This scenario requires a very committed and knowledgeable customer. So, while the scenario has some cons, that other users have already mentioned, let me take the positive perspective and give some insights on how to improve success probabilities:

• As mentioned, it is important that the customer understand the importance and impact of the changes/new reqs on your work. You need to make sure that the designated PM on the customer side is experienced and focused enough, and also make sure that there is only one person from the customer as liaison with your group and editing the information on the tool.
• It is important the PM is able to detail the requirements at an appropiate level of detail for your estimations to be useful and "modular" enough so that adding and removing new reqs doesn't affect the whole plan, design and hence estimations.
• Among the rules that must be clear, there must be a certain point in which a task request goes beyond the "no return point". A task that has been requested for the next release/spring and the team has started implementing/designing(in detail) it, can not be cancelled (unless discussed directly with you).
• To help with that, better make sure the tool you use allows to specify different states for the different requisites. Every status must have its responsible.
• Last but not least, you must agree on when you will deliver the estimates as it may not be easy for you to respond immediately to any new reqs or doing so may impact the work of the group, that you may require to assist with estimations.
• Be patient, the first weeks you will have an avalanche of new requests, that will slow down to a stable situation. I had a similar scenario, in which Marketing was entering the reqs for the product through a tool and initially it was like a toy for them.
• Someone has already mentioned but I will insist on that, the tool must not replace any meetings or phone calls that you have with the customer. Use the tool to put together the information and go through the requirements and estimations with the customer regularly and specially before planning a new release/sprint. If you are into Agile/Scrum don't replace the sprint planning meetings take the tool as preparation work for those meetings.
• Depending on the kind of contract you have with the customer (fixed price, dedicated resources) you may need to adjust so that it makes sense for both. Charging for estimations is difficult in certain company cultures, competitive environments but should be kept in mind.

I hope it helps. I would be interested on a follow-up on how it worked for you and the tools that you chose for.